Нормативная документация

Software-defined storage (SDS) от NetApp

28 апреля 2015 г. | Категория: Теория и практика SDDC, Программно-определяемые системы хранения

Чтобы представить Software-defined storage (SDS) от NetApp в общем контексте, начнем от противного. Но прежде необходимо отметить, что подавляющая часть рассуждений на тему SDS, страдает неопределенностью, в подтверждение этого обстоятельства Wikipedia признает, что обобщенно, на философском уровне определить предмет SDS и должным образом классифицировать не удается, во всяком случае пока. Единого подхода к SDS нет, как впрочем, нет согласованного мнения о том, чем SDS отличается от виртуализации СХД.

Возьмем для примера сборку в одну в конвергентную систему некоторое количество стандартных серверов с непосредственно подключенными к ним накопителями СХД типа DAS, здесь для создания SDS можно применить общую для них всех (глобальную) файловую систему. А, например, для создания систем управления более сложными носителями нередко применяют технологи виртуализации СХД (Storage virtualization) или управления ресурсами СХД (Storage Resource Management, SRM). А еще для оптимизации работы сетей хранения Storage Area Network (SAN) или горизонтально-масштабируемых сетевых систем хранения Network-Attached Storage (NAS) могут быть использованы специализированные устройства, в том числе и программные, так называемые appliance).

Несмотря на очевидное разнообразие подходов наибольшее хождение получило мнение об обязательности реализации разделения системы на два уровня Control Plane и Data Plane, в SDS известного по программно-определяемым сетям Software-defined Network (SDN). В целом это верно, но такая сепарация управления и данных при более детальном рассмотрении в СХД не является непременным условием.

При взгляде извне разделение на Control Plane и Data Plane привлекает своей строгой логичной дихотомией, программное обеспечение Control Plane сосредоточивает в себе все функции управления устройствами, расположенными на уровне Data Plane, а Control Plane передает в устройства соответствующие команды. В таком случае накопители могут быть простыми и быстрыми, от них ничего другого кроме исполнения команд не требуется, поскольку весь интеллект передан наверх. К тому же сверху картина виднее, реализуемый в таком случае централизованное такой подход к управлению м общей массой ресурсов представляется эффективнее, чем автономное управление отдельными устройствами.

Двухуровневый подход изначально возник в приложении в приложении к сетям, он стал базисом программно-определяемых сетей SDN, потому, что с точки зрения управления инфраструктурой, в сетях все достаточно просто, здесь необходимо всего лишь контролировать маршрутизацию пакетов, имеющих универсальный формат, в том числе стандартный заголовок с предопределенными атрибутами: IP и порт источника, IP и порт получателя, протокол. Содержащихся в заголовке данных достаточно для функционирования программного контролера SDN первичного, начинающегося с наполнения таблиц маршрутизации и далее для их последующей модификации, в тех случаях, когда возникают узкие места (network bottlenecks), а также изменяются, добавляются и удаляются порты. Стандартизация сетей для решения задач управления является несомненным благом, она позволяет создавать контролеры SDN без необходимости в какой-либо кооперации с другими вендорами.

Однако прямой механический перенос той же самой идеологии разделения на Control Plane и Data Plane в область программно-определенных СХД оказывается невозможен в силу того, что природа СХД намного сложнее, чем сетей, в них отсутствует присущая сетям строгая стандартизация и наличествует великое множество разнообразных пропраетарных решений. К примеру, каждый из дисковых массивов имеет свою операционную систему (storage OS) программные интерфейсы API и свой собственный набор функций. Чтобы стать частью SDS такой умный массив должне быть лишен всех этих индивидуальных особенностей, а все его управляющие функции должен взять на себя Control Plane. При передаче всего управления в Control Plane интеллектуальный массив по своему статусу низводится до уровня простого набора дисков JBOD (Just a Bunch of Disks). Разумно ли это? Если да, то может быть стоит вообще отказаться от мощных массивов и положиться во всем на JBOD? Но на нынешней стадии развития SDS такой отказ нереален, поскольку ни один из производителей SDS не может предложить такой же класс функциональности, который уже реализован в массивах, например способность к самовосстановлению (self-healing), синхронная репликация (synchronous replication), многоуровневое кэширование (cache tiering), модернизация без нарушения работоспособности (nondisruptive upgrades) и многое другое.

Как обычно в технике рациональнее всего компромисс, следует признать, что деление на Control Plane и Data Plane совершенно разумно, но эту идею, как любую иную не следует абсолютизировать. Чтобы создать SDS достаточно вынести в Control Plane часть функций, например четыре основных: образование логических пулов хранения, создание RAID-массивов и кодирование, предотвращающее потерю данных (Erasure Coding), балансировку нагрузки и обеспечение качества обслуживания (Load Balancing / Quality of Service), подготовка отчетов о состоянии (Status Reporting). При желании могут быть добавлены какие-то другие, но эти составляют базисный набор.

NetApp и SDS

У NetApp свой путь к SDS, в отличие от большинства других компаний, недавно вступивших или еще только вступающих на стезю SDS, в этой компании не видят в предмете SDS для себя ничего принципиально нового, даже термин Software-defined storage в некоторых случаях признают маркетинговым ходом. Например название серии из пяти записей в блоге Рубенщтейна названа “Software Defined” — Been There, Done That", оно отражает явно скептически-ироническое отношение со стороны автора, его можно перевести что-то вроде "Видели, знаем". Автор начинает с утверждения: "Я не вижу ничего особенного в том, что называют SDS“ . 

Особое положение NetApp по сравнению с другими производителями СХД вполне оправдано, оно основывается ее технологической родословной, компания более 15 лет назад, предугадав будущее, избрала для себя отлично соответствующий современности образ "софтверной в облике хардверной (a software company in hardware company’s clothing). В те времена такой ход был нетипичен, тогда конкуренты основное внимание уделяли конкретным решениям, способствующим повышению тех или иных показателей с помощью множества различных решений. В NetApp же момента основания в 1992 году ставка была сделана на специализированную операционную систему Data ONTAP, ее разработчиками стали основатели компании. Data ONTAP представляет собой внутреннюю ОС NetApp, оптимизированную для выполнения различного рода действий, связанных с обеспечением хранения данных и доступа к ним.

За минувшее с тех пор время выпущено множество версий ОС, для целей создания SDS на данный момент актуальной является NetApp clustered Data ONTAP 8.3. Этот стало возможным благодаря тому, что Data ONTAP служит платформой, унифицирующей доступ к протоколам, она предоставляет полный набор процессов, средств и инструментов для работы с данными, поддерживает интерфейсы Fibre Channel, FCoE и iSCSI, а также сетевые протколы. Применяя Data ONTAP можно создавать гибридные облака, осуществлять виртуализацию систем хранения данных во всех наиболее распространенных средах (UNIX, Windows и Linux). Наличие в арсеналеNetApp операционной системы Data ONTAP позволяет компании естественным образом перейти к созданию программно-определяемых СХД, не делая каких-то радикально новых шагов, не создавая специальных технологий деления на Control Plane и Data Plane. Data ONTAP обладает достаточным потенциалом, чтобы обеспечивать виртуализацию систем хранения примерно так же, как VMware виртуализует серверы.

Релизы Clustered Data ONTAP 8.Х не случайно названы кластерными, они впервые открывают возможность создавать системы хранения корпоративного уровня принципу, с горизонтальным масштабированием. Кластеры такого типа обычно собираются из контролеров для СХД с матричной организацией (fabric-attached storage (FAS) controllers), то есть из компьютеров, оптимизированных для работы под управлением ОС Data ONTAP. Контролеры объединяют в себе NAS и SAN, они предоставляют свои порты через которые хосты и клиенты получают доступ к системам хранения. Между собой эти контролеры объединяются по выделенному 10-gigabit Ethernet, а данные хранятся на дисках и флэш-накопителях, подключенным к компьютерам.

Клиенты и хосты получают доступ к данным через виртуальные машины хранения данных (Storage Virtual Machine, SVM), существующие внутри Clustered Data ONTAP. SVM определяют пространство хранения, доступное клиентам и хостам, аутентификацию и доступ по сети в форме логических интерфейсов (Logical InterFace, LIF), а к собственно данным по линическим номерам устройств SAN LUN или томам NAS. По аналогии виртуальным компьютерами VM эти SVM обеспечивают доступ к логическим, а не физическим массивам хранения данных. SVM отделяют сервисы данных от физики хранения данных, то есть делают примерно то, чего добиваются разделением на Control Plane и Data Plane.

Одна виртуальная машина хранения SVM может использовать множество сетевых портов и множество сетевых контролеров, чем обеспечивается горизонтальное масштабирование. В то же время один из портов контролера и один и тот же фрагмент памяти может быть использован несколькими SVM, поддерживая таким образом коммунальный разделяемый доступ к данным (multi-tenancy).

Один кластер может содержать в себе множество виртуальных машин SVM, предназначенных для выполнения различных функций, включая виртуализацию серверов и десктопов, большие репозиории контента на базе NAS, файловые системы общего назначения. С использованием SVM можно создавать отдельные независимые области хранения (tenant). Компоненты каждой SVM не привязаны к какой-либо физической аппаратной части кластера, тома SVM логические но мера LUN и логические интерфейсы LIF могут физически перемещаться, сохраняя свое логическое представление для клиентов и хостов. В то время как накопители и сети в кластере могут меняться клиент сохраняет неизменным доступ LUN и LIF.

До последнего времени для Storage Virtual Machine именовалась иначе —прежнее название Vserver, хотя в новых версиях название изменилось, суть осталась прежней. Отдельная SVM представляет собой безопасный и надежный логический раздел СХД, доступ к хранимым в нем данным поддерживается средствами Clustered Data ONTAP. Виртуализация хранения средствами SVM является ключевой технологий, используемой для создания программно-определяемой СХД в той трактовке SDS, которая принята в NetApp. Избранная в NetApp точка зрения в целом не противоречит другим известным определениям SDS, различия обнаруживаются в реализации. Поскольку SVM действительно является логической абстракцией физических ресурсов кластера, то такой подход следует признать в полной мере программным, он действительно предполагает, что SVM полностью отвязывает клиентов и хосты от специфики используемого аппаратного обеспечения.

SDS, построенная на базе с SVM соответствует требованиям, которые можно себе представить:

• Работа в облачной среде. Кластер как одна или несколько SVM может быть размещен в облаке. SVM способны поддерживать множество разнообразных протоколов, поэтому они на них можно развернуть те или иные облачные приложения.
• SVM безопасны. Каждая SVM работает как независимый от других совершенно отдельный домен безопасности (security domain), которому доступны только приписанные ему данные. Таким образом обеспечивается взаимная независимость индивидуальных "жильцов" (tenant), обитающих в облаках.
• Администратор обладает всеми необходимыми инструментами для создания SVM и поддержания на качеством обслуживания протяжении всего ее жизненного цикла с соблюдением групповых правил правил качества обслуживания (policy groups quality of service QoS) для различных облачных сервисов, предназначенных для потребителей.
• Возможность масштабирования. Высокий потенциал масштабирование органически заложен в Clustered Data ONTAP. Дополнительные контролеры и накопители естественным образом и весьма просто могут быть добавлены в кластер, если при изменении требований требуется повысить емкость или производительность. Новые диски, кэш-память, сетевые ресурсы могут стать доступны каждой SVM для создания новых томов данных или для миграции нагрузки на новые ресурсы для обеспечения требуемого баланса и соблюдения непрерывности работы.
• SVM не привязана к жизненному циклу того или иного физического контролера, если появляется некоторое новое оборудование, ресурсы SVM без нарушения операций перемещаются со старого контролера на новый. 

NetApp рассматривает решения SDS в контексте более общих решений SDDC, где SDS обеспечивает более высокие показатели эффективности по части использования ресурсов, готовности и снижения в средах хранения как SAN, так и NAS. В качестве основного компонента ля создания SDS используются виртуальные машины хранения SVM, поддерживаемые операционной системой Clustered Data ONTAP. Кроме того для создания SDS используются:

• NetApp OnCommand — набор инструментальных средств для менеджмента программным обеспечением и интеграцией 
• NetApp FAS series — системы хранения данных типа fabric-attached
• NetApp FlexArray virtualization software — ПО обеспечивающее менеджмент как массивами от NetApp, так и массивами третьих компаний, подключаемых с использованием интерфейсов Clustered Data ONTAP.

Обобщенное решение SDS состоит из следующих частей:

• Cloud-enabled storage —СХД, способная работать в облаке. Cloud-enabled storage должна поддерживать средства для создания SVM (Storage abstraction layer), для интеграции с гипервизором серверов (Hypervisor integration), для поддержки клонирования SVM (Virtual machine cloning) и оркестровки и автоматизации управления компонентами СХД (Orchestration and automation of storage components). 
• Storage management — Менеджмент СХД
• Storage monitoring and remediation management — Мониторинг СХД и менеджмент восстановлением
• Storage automation and orchestration tier — Уровень автоматизации и оркестровки
• Hypervisor — Гипервизор на уровне SDDC
• Midtier orchestration — Оркестровка на уровне серверных VM, с этого уровня выполняются обращения к SDS 
• Cloud monitoring and problem remediation management — Контроль и ликвидация проблем на облачном уровне

NetApp считает, что важнейшее достоинство своего подхода к SDS в возможности поддержки разнообразных аппаратных платформ, как локальных (on premise) так и в облаке с использованием стандартизированного набора сервисов хранения и программных интерфейсов API. Сегодня список поддерживаемых платформ включает:

• СХД NetApp FAS, они уже оптимизированы для использования для поддержки Сlustered Data ONTAP, кроме того FAS могут входить в конвергентную инфраструктуру FlexPod, разработанную совместно с Cisco.
• Массивы третьих компаний могут работать под управлением Data ONTAP при посредстве NetApp V-Series
• Общедоступное на рынке "железо" (Commodity hardware) может быть включено в состав SDC при помощи NetApp Data ONTAP Edge
• Ресурсы облачных провайдеров можно использовать при помощи NetApp Private Storage for Amazon Web Services

В качестве практического примера использования SDS можно привести совместный проект NetApp VMware по созданию программно-определенного ЦОДа (Software Defined Data Center, SDDC). Такой SDDC построен по пятиуровневой модели, на каждом уровне используются технологии обеих компаний, они работают совместно и взаимно дополняют друг друга. Здесь еще использованы адаптеры компании Blue Medora. 

Интересно и развернуто корпоративную точку зрения на Software Defined Data Center (SDDC) и Software Defined Storage” (SDS) от лица NetApp выражают Зев Рубенштейн, Индиго Фучс и Ларри Фриман. А наиболее полным источником информации является портал библиотеки NetApp.

Автор: Леонид Черняк 

Теги: SDS, системы хранения, NetApp