Cфера хранения данных – одна из самых консервативных в области ИТ, поэтому любые новации воспринимаются здесь скептически. Достаточно сказать, что аппаратные ресурсы, особенно процессоры, традиционных СХД, как правило, отстают от актуального модельного ряда на одно-два поколения. Это связано с тем, что требуется продолжительное время на отработку кода на фиксированной платформе. С чисто программными решениями чуть проще: они разрабатываются с учетом широких возможностей по выбору «железа» и готовы работать как на самом старом, так и на самом новом оборудовании.
SDS – относительно новое понятие. По одному названию логично предположить, что это хранилище данных, которое управляется программным обеспечением без каких-либо аппаратных технологий. Но в таком случае любое современное хранилище является Software Defined, поскольку «железо» СХД мало отличается от современного ПК – те же x86 процессоры, память, диски. На сегодняшний день осталось мало решений, использующих специализированные аппаратные решения, такие как, например, микросхемы ASIC. Зачастую на системах хранения стоят еще и те же самые версии ОС Windows/Linux/UNIX, что и на серверах, но в урезанной редакции, а весь функционал реализуется только средствами специализированного ПО, как на обычном компьютере. Это наводит на мысль: нужно ли вообще выделенное устройство под названием «система хранения данных»? Или ИТ-рынок технологически уже готов к тому, чтобы свести аппаратные ресурсы серверной части и части хранения в единую аппаратную платформу, а функционал объединить под единой виртуальной системой управления в рамках сервис-ориентированной модели предоставления ресурсов? Эти вопросы и пытаются описать концепции SDS и смежная с ней SDDC.
Из-за новизны технологии отличий в понимании дальнейших путей развития ИТ в литературе можно найти разные признаки SDS/SDDC, иногда даже противоречащие друг другу. Само понятие пока не стандартизировано, и каждый производитель в зависимости от конъюнктуры рынка подает под маркой SDS то одни, то другие технологии. Если пытаться классифицировать SDS по функционалу и сравнить с тем, что уже распространено на рынке, то SDS – это нечто среднее между облачным (сервис-ориентированным) подходом и виртуализацией СХД. По сути, это эволюция или, если хотите, реинкарнация технологий, которые пять-семь лет назад были на острие атаки.
Подходы вендоров
На наш взгляд, самые интересные и инновационные подходы к SDS – у вендоров, которые разрабатывают ПО, хотя бы потому, что аппаратная абстракция там наблюдается в «чистом виде», без унаследованных технологий.
У вендоров, занимающихся традиционными СХД, подход к SDS более консервативен. SDS позиционируется как «конструктор» для любителей «ручной сборки» (в дополнение к классическим СХД), но не как решение, критичное для бизнеса, или замена традиционным СХД. Функционал подбирается таким образом, чтобы разграничить позиционирование технологий и не допустить пересечения интересов разных бизнес-подразделений крупного производителя.
У аппаратных вендоров есть другой интересный тренд: попытка из традиционных СХД сделать SDS-решение путем простого выделения операционной среды имеющегося массива в отдельный продукт. Это выглядит абсолютно логично: на выходе получается востребованная и уже проработанная технология SDS без необходимости что-то изобретать. Есть и другой тип вендоров, которые предпочитают покупать стартапы на рынке виртуализации систем хранения данных и SDS и развивать продажи за счет имеющегося пула заказчиков и мощной маркетинговой машины. Первый подход – с разделением имеющихся продуктов на программно-аппаратные и чисто программные решения – выглядит более логичным.
Управление информацией внутри SDS
С определением понятия Software Defined Data Center (SDDC) тоже есть трудности, обусловленные его новизной. Точнее всего определить SDDC как ИТ-структуру, которая объединяет в себе виртуализованный подход ко всем ИТ-ресурсам – вычислительным, коммуникационным, хранения – с сервис-ориентированной моделью. Или в виде формулы SDDC = SDN (Software Defined Network) + SDC (Software Defined Computing) + Server Virtualization. И все это под единым механизмом управления. SDDC – по сути, еще одно название облачной инфраструктуры.
Внедрение SDS имеет смысл рассматривать только в контексте полного внедрения SDDC, с попутной перестройкой бизнес- и/или ИТ- процессов под сервисно-ориентированную модель. Отдельное внедрение SDS в классический ЦОД не имеет смысла хотя бы потому, что установка, настройка и тестирование программного обеспечения на «самосборном железе» гораздо сложнее и дороже, чем установка и внедрение классической программно-аппаратной СХД и подключение ее к уже созданной физической или виртуальной серверной инфраструктуре.
Решения SDDC уже появились и активно развиваются. Это так называемые платформы гиперконсолидации (Hyperconverged Infrastructures), где система хранения и пользовательские приложения интегрированы в едином гипервизоре, полностью стерта граница между сервером и СХД, а есть просто набор аппаратных ресурсов (процессор/память/диски/интерфейсы) и приложений для конечных пользователей.
Для приложений SDS должна выглядеть как обычная СХД с протоколами NAS/SAN. А что делать с другими дата-сервисами: резервным копированием, архивированием, репликацией, управлением контентом, интеграцией с публичным облаком и т. п.? Для этого обычно требуется дополнительное ПО. Однако если мы говорим о программных решениях, логично будет упаковать весь набор компонентов по управлению данными в единую платформу, сделать все операции прозрачными для пользователя и предоставить ему привычный SAN/NAS (пусть даже и виртуальный) интерфейс. На данный момент на рынке работают несколько вендоров SDS, но ни один из них не предлагает законченного интегрированного ILM «из коробки». На наш взгляд, это одно из перспективных направлений развития SDS/SDDC.
Облачное хранение как SDS
SDS подразумевает полную аппаратную абстракцию, поэтому облачные хранилища, работающие в модели SaaS, – это программно-определяемые хранилища в чистом виде: мы даже не знаем, где именно хранится информация, не говоря уже о «железе», на котором лежат пользовательские данные. При этом имеем другие признаки SDS, в частности, практически неограниченную горизонтальную масштабируемость по объему и количеству пользователей. Подобные решения SDS предлагает целый ряд компаний: программное обеспечение для организации облачного сервиса хранения данных в рамках модели частного облака. При установке такого ПО в дата-центре заказчика заказчик получает весь привычный облачный функционал (хранение данных, папки общего доступа, синхронизация данных между устройствами, веб-доступ, доступ с мобильных приложений для iOs/Android). Следует отметить, что лишь немногие компании, предлагающие облачные сервисы для хранения данных, знают, где физически находятся данные, способны контролировать их конфиденциальность, доступ, мониторинг содержимого на предмет несанкционированного контента. Облачные сервисы для хранения данных в частном облаке – это еще и удобный и гибкий «облачный бэкап», а также защита данных в процессе совместной работы, что намного безопаснее «обезличенных» публичных облаков.
Вопросы практического применения
Принимая решение о внедрении SDS/SDDC, ИT-департамент сталкивается со следующими вопросами:
- кто отвечает за сохранность и консистентность информации – производитель ПО или аппаратной части;
- как организовать защиту данных внутри SDS;
- требуются ли расширенные сервисы по управлению информацией внутри SDS;
- нужны ли в SDS технологии по повышению эффективности хранения, такие как дедупликация и компрессия.
Разумеется, главный вопрос из этих вопросов – первый. Если с классическим подходом в форме программно-аппаратного устройства (Appliance) все более-менее понятно, то Software Defined Storage по определению не способен обеспечить тот или иной уровень SLA в виде 99,99 + %. Вендор программного обеспечения просто не сможет гарантировать такую защиту, поскольку не знает, на каком «железе» будет работать его ПО. Это одна из главных причин того, что реализация масштабных проектов в сфере SDS не так распространена для бизнес-критичных приложений. Однако при реализации распределенных ЦОД часто прибегают к решению, когда один ЦОД реальный, а второй – виртуальный или арендованный. В таком случае основной ЦОД строится из классического представления: серверы – СХД, а второй (рЦОД) представляет собой некие арендованные виртуальные мощности (как правило, на базе партнера). В подобных виртуальных рЦОД и есть потенциальная ниша для производителей SDS-решений.
Нужны ли расширенные сервисы по управлению информацией внутри SDS? С точки зрения как ИТ-департамента, так и конечных пользователей, если внутри уже будут заложены сервисы по защите данных, архивированию, обеспечению катастрофоустойчивости и другой дополнительный функционал, это сократит сроки внедрения и упростит обслуживание.
Как организовать защиту данных внутри SDS? Как резервировать SDS? Где хранить резервные копии всех данных: на той же самой аппаратной платформе (в другом разделе) либо на выделенных специально для этой задачи системах хранения данных – Appliance? Разумно ли резервировать SDS таким же SDS на удаленной площадке или лучше выделить специальное место/устройство для хранения резервных копий? Например, в гиперконсолидированном SDDC «от одного производителя» для защиты данных может быть организован только специализированный API с весьма ограниченным набором функций и поддержкой фиксированного набора хранилищ резервных копий. Более того, среди рекомендаций будет предложено заменить резервное копирование репликацией таким же «гиперконсолидированным» SDDC – Appliance по проприетарным протоколам. Это не совсем защита данных, так как при подобной репликации данные не могут быть извлечены: мы не можем достать информацию из этого SDDС и подключить, скажем, к тестовой платформе VMware или Hyper V, работающей на «другом железе». Также не получится сделать резервную копию на съемный носитель, как следствие, возникнут проблемы с соответствием требованиям регуляторов и отраслевым регламентам, вопросы compliance и legal hold.
Рынок x86 архитектуры полностью коммодитизирован. С учетом того, что аппаратное обеспечение под SDS может быть любым и в любой комбинации, встает вопрос: нужно ли экономить на хранении, когда стоимость дисков непрерывно снижается, а емкость постоянно растет? По опыту Commvault, это зависит от общей сложности инфраструктуры и размеров экономии. Кроме того, данный вопрос стоит рассматривать с точки зрения управляемости инфраструктуры – чем меньше «железа», тем проще: наличие механизмов дедупликации, компрессии может снизить не только совокупную стоимость владения, но и риски, связанные с потерей контроля над разрастающимся ИТ. Последний фактор многие компании (особенно работающие в финансовом секторе) ценят намного выше, чем показатели экономии на стоимости жестких дисков. На наш взгляд, будущее именно за такими SDS- и SDDC-решениями, которые позволяют самостоятельно выбирать и аппаратную платформу, и платформу защиты и управления данными.
Следует также отметить, что закрытость SDS-решений – вопрос не только защиты, но и возможности подключения расширенных сервисов, таких как контекстный поиск, аналитика содержимого, веб-сервисы доступа, организация совместной работы над документами. Если с защитой данных мы настаиваем на открытых API и классических подходах по РК и архивированию, то по части дополнительных сервисов чуть проще. Любой подобный дополнительный функционал может быть реализован в виде приложения на платформе встроенного гипервизора SDDC/SDS. Главное, чтобы производитель SDS/SDDC явно не запрещал подобные «апгрейды».
Рыночные перспективы
Рынок в плане организации сервисов управления данными внутри SDS/SDDC огромен. Это и базовые сервисы по защите данных (резервное копирование, репликация), и расширенные сервисы по управлению информацией (контекстный поиск почтовых и файловых ресурсов, архивирование данных приложений, многоуровневое хранение), и контроль содержимого, состояния приложений и аппаратных ресурсов.
У любого вендора SDS возникают проблемы при интеграции определенного набора функционала в существующую (как правило, не первый год) ИТ-среду. В процессе реализации нужно решить главные вопросы совместимости аппаратных компонентов, программных модулей, не нарушить существующий уклад вещей и не понизить общий уровень SLA внедрением нового ПО. Как уже было сказано, системы хранения – консервативный сегмент ИТ-рынка. Это одна из основных причин невысокого спроса на продуктивные системы хранения бизнес-критичных приложений, построенных на SDS. Однако мы активно внедряем SDS в рамках проектов по облачному хранению данных для защиты рабочих мест пользователей и организации совместной работы (в России были реализованы проекты на десятки и сотни рабочих мест).
В целом SDS – это, безусловно, современный и правильный подход к построению дата-центров будущего. Но предстоит еще много работы, чтобы это стало ИТ-стандартом, начиная от унификации подходов и заканчивая совместимостью интерфейсов.
