Ведущие производители систем хранения данных рассматривают программно определяемые СХД как стратегическое направление развития отрасли и один из важнейших компонентов программно определяемых ЦОД. Ключевые преимущества SDS состоят в гибкости, автоматизации управления и экономичности. Но по сути это очередной этап эволюции давно известной технологии — виртуализации систем хранения.

 

Одним из наиболее обсуждаемых в 2013 году подходов к созданию ЦОД стал программно определяемый центр обработки данных (Software Defined Data Center, SSDC; см. статью автора «Что такое SDDC?» в «Журнала сетевых решений/LAN» за июль-август 2013 года). Идея SDDC была высказана VMware в 2012 году. По мнению многих, в этом — скорее, маркетинговом — термине нет какого-то глубокого смысла, хотя в целом идея понятна. Но как бы к данному подходу ни относились, проблема лишь в сложности его полноценной практической реализации на нынешнем этапе.

Согласно определению IDC, SDDC — набор слабо связанных программных компонентов, обеспечивающих виртуализацию и объединение ресурсов ЦОД (вычислительных, сетевых и предназначенных для хранения данных). Задача SDDC — связать разнородные ресурсы ИТ для предоставления интегрированных сервисов. В VMware программно определяемый ЦОД понимают как инфраструктуру с высокой степенью виртуализации и автоматизированным программным управлением, предоставляемую по модели «ИТ как сервис». Иначе говоря, архитектура SDDC предполагает распространение концепции виртуализации на все ресурсы ЦОД, а также абстрагирование ресурсов и автоматизацию управления.

Кроме того, SDDC предусматривает возможности создания пулов ресурсов и гибкого их использования в виде сервисов. Для упрощения процессов выделения и освобождения ресурсов концепция серверной виртуализации должна быть распространена на сеть и системы хранения данных (см. Рисунок 1). Важнейшая роль при этом отводится управлению. Задача программного управления — обеспечить гибкость и масштабируемость SDDC для быстрой адаптации инфраструктуры ИТ к требованиям новых приложений.

SDS: назад в будущее
Рисунок 1. Virtual SAN — горизонтально масштабируемая архитектура со встроенным кэшированием на SSD — абстрагирует и группирует твердотельные и «обычные» диски из множества серверов для создания единого разделяемого хранилища. При этом обеспечиваются избыточность и простое управление на основе правил хранения.

 

SDS В КОНТЕКСТЕ SDDC

Частью SDDC является программно определяемое хранение данных (Software Defined Storage, SDS). В отчете IDC «Worldwide Software-Based (Software-Defined) Storage Taxonomy, 2013» утверждается, что программно определяемые СХД будут медленно, но верно превращаться в важнейший компонент любого ЦОД (как программно определяемого, так и традиционного), где требуется более эффективно хранить и обрабатывать данные.

Суть программно определяемого ЦОД состоит в использовании «интеллекта» инфраструктуры ИТ для предоставления сервисов. В случае СХД это сервисы хранения данных. Однако, в отличие от программно конфигурируемых сетей (Software-Defined Networking, SDN), также играющих важную роль в программно определяемых ЦОД (см. статью Александра Барскова «SDN: кому и зачем это надо?» в декабрьском номере «Журнала сетевых решений/LAN» за 2012 год), программно определяемые (или централизованно конфигурируемые) системы хранения предполагают не разделение потоков данных и управления, а абстрагирование оборудования хранения данных от управляющего ПО. В результате объединенные в пул ресурсы хранения можно автоматически распределять на уровне программного обеспечения в соответствии с требованиями приложений.

При такой модели «интеллект» и функциональность СХД перемещаются на уровень программного обеспечения, позволяющего централизованно управлять разнородными ресурсами хранения — от высокопроизводительных дисковых массивов до недорогих систем хранения. Таким образом, SDS предполагает переход от жесткой архитектуры к программируемой, которая должна обеспечивать динамичность и высокую экономическую эффективность. При этом все основные функции (дедупликация, репликация, динамическое выделение ресурсов и создание мгновенных снимков) выполняются программно.

Благодаря разделению программного и аппаратного уровня можно покупать и развертывать разнородные системы хранения, не беспокоясь о проблемах совместимости, неполного использования ресурсов конкретной СХД и сложностях ручного администрирования ресурсов хранения: как и в SDDC, центральное место здесь занимает автоматизация (см. Таблицу 1).

SDS: назад в будущее

Таблица 1. Возможности программируемой интеллектуальной СХД (по данным IBM).

 

Стоит отметить, что уже сегодня основные изменения в области систем хранения связаны именно с ПО, а не с аппаратной частью, и это подтверждают последние анонсы ведущих вендоров СХД. «Интеллект» системы хранения реализуется на уровне программного обеспечения — ее функциональность «уходит в ПО».

ОТ ПУЛА РЕСУРСОВ К СТАНДАРТИЗАЦИИ

В соответствии с наиболее распространенной точкой зрения SDS будет способствовать максимально эффективному использованию имеющихся систем хранения и эффективному управлению разнородными ресурсами. Однако некоторые производители предлагают избавиться от унаследованных СХД и заменить их «стандартными» дисковыми массивами. В их представлении реализация концепции SDS означает не только виртуализацию и автоматизацию СХД, но и стандартизацию. Предполагается, что программное обеспечение SDS должно работать на открытом, типовом оборудовании (commodity), в то время как в традиционных системах микропрограммы разрабатываются для специализированных микросхем (ASIC), микропроцессоров или контроллеров.

Но что такое «стандартные СХД»? Практически то же самое, что и стандартные серверы. Так, по мнению некоторых экспертов, первым шагом к SDS стало внедрение в СХД флэш-памяти PCIe. Это позволило значительно повысить производительность приложений и заменить дорогостоящие проприетарные дисковые массивы более дешевыми стандартными серверами с флэш-накопителями. Не секрет, что многие дисковые массивы реализуются на платформе x86 и оснащаются стандартными интерфейсными модулями и накопителями. Например, компания EMC недавно выпустила дисковый массив XtremIO, построенный полностью на базе флэш-памяти. Его аппаратная платформа XtremIO фактически составлена из стандартных компонентов. Такая архитектура позволяет легко модернизировать систему — перейти на SSD большей емкости и более современные процессоры и интерфейсы.

Между тем большинство так называемых серверов хранения данных не обладают всеми признаками программно определяемого хранения и не являются решением уровня предприятия. К тому же «стандартизация» СХД означала бы замену имеющейся у заказчика инфраструктуры хранения, что связано с серьезными капитальными затратами. Поэтому в качестве первого практического шага предлагается другое решение, а именно виртуализация ресурсов хранения данных. Это позволяет объединить разнородные ресурсы в пул, что дает возможность по-новому использовать имеющиеся системы.

SDS часто путают с виртуализацией СХД, но виртуализация предполагает абстрагирование ресурсов хранения и их объединение в пул,
в то время как SDS — отделение функций и сервисов от аппаратного обеспечения.

Кроме того, SDS предполагает объединение ресурсов хранения на разных носителях (дисках, флэш-накопителях, магнитных лентах) и во внешних облаках. А при помощи системы управления администратор может получить целостное представление о том, что происходит во всей этой инфраструктуре, и централизованно управлять ею. IDC отмечает, что решение SDS должно поддерживать полный спектр сервисов хранения, эквивалентный традиционным аппаратным платформам, но охватывающий всю инфраструктуру хранения. В числе примеров — сервисы миграции данных, репликации и многоуровневого хранения.

SDS определяет, как организованы данные, где находится место их постоянного хранения (DAS, SAN, NAS, облачное или объектное хранилище), какой вид сервисов предлагается. Для заказчика SDS может выглядеть, как программный пакет, обеспечивающий виртуализацию ресурсов и управление, как специальная программно-аппаратная платформа (appliance) или даже как набор облачных сервисов. (Известные облачные сервисы хранения данных — еще один «пробный камень» на пути к программно определяемому хранению.)

Управление осуществляется на основе заданных правил, а виртуальным машинам присваиваются атрибуты хранения (VM Storage Policy) — например, емкость, производительность, доступность. Исходя из этих атрибутов, ВМ предоставляются сервисы хранения. Для этого используемая платформа виртуализации должна поддерживать специфические аппаратные функции СХД и обеспечивать операции ВМ с данными.

По мнению аналитиков Evaluator Group, SDS позволит распространить такие средства систем хранения, как снимки данных, репликация или RAID на разнородные дисковые массивы, и дополнить их новыми ценными функциями. Абстрагирование сервисов хранения открывает возможность для централизованного администрирования и управления, а в традиционной архитектуре это делается отдельно для каждого дискового массива.

В действительности программно определяемое хранение далеко не новое явление. Похожие подходы были реализованы еще десять лет назад: например, компанией IBM в ее продукте SUN Volume Controller (SVC) и HDS в Virtual Storage Product (VSP) — в этих решениях поддерживаются возможности подключения к «контроллеру» СХД систем хранения разных вендоров и объединения их в единый пул ресурсов. Однако реализуемая ими виртуализация систем хранения данных и предложенные средства оптимизации, например приоритизация ввода-вывода для конкретных приложений, — только первый шаг на пути к SDS, дальше удалось продвинуться лишь немногим вендорам.

К выгодам, получаемым от внедрения виртуализированных СХД, относят рациональное использование ресурсов хранения и их консолидацию, упрощенное управление, расширение функциональности и повышение производительности дисковых массивов, поддержку репликации и перемещения данных без остановки сервисов, добавление многоуровневого хранения к имеющимся ресурсам. Однако в такой архитектуре могут возникать узкие места и потенциальные точки отказа, а интеграция с приложениями осуществляется не в полной мере.

Конечная цель — переход к открытым платформам, настраиваемым в соответствии с требованиями приложений. Ее достижение возможно лишь в том случае, если будут приняты, одобрены и внедрены отраслевые стандарты, регламентирующие открытые решения, которые способны работать «поверх» проприетарных технологий.

ПРОБЛЕМЫ SDS

По существу, SDS — это еще один шаг на пути к облаку, но реализовать эту красивую идею непросто. Унаследованные традиционные СХД наряду с рисками перехода на полностью новую платформу — серьезные препятствия на пути к программно определяемым системам хранения. Да и виртуализация СХД пока отстает от виртуализации серверов и сетей, а функциональность систем хранения задействуется гипервизорами лишь отчасти.

Одна из причин — отсутствие стандартизации. В системах хранения обычно используется патентованное ПО контроллеров, а инфраструктурой хранения сложно управлять, да и масштабировать ее, как правило, непросто. Даже если в ЦОД применяются СХД одного вендора, для управления ими могут потребоваться разные программные средства. В разнородной среде задача оказывается еще более трудной.

Из-за наличия нескольких точек управления и разных подходов к управлению СХД усложняется управление виртуализированными облачными ЦОД и затрудняется получение единой целостной картины среды хранения данных, не говоря уже о дополнительных затратах, а выделение и высвобождение ресурсов хранения превращается в многоэтапный процесс, требующий участия администраторов серверов и администраторов систем хранения. Программно определяемые СХД призваны преодолеть эти проблемы на пути к облачным ЦОД.

В настоящее время в отрасли нет ни единого определения SDS, ни сложившейся вокруг вендоров экосистемы, ни явных лидеров.

Как уже пояснялось, SDS предполагает абстрагирование унаследованных ресурсов SAN и NAS и создание пула ресурсов. Но для этого потребуется объединить в пул системы с файловым и блочным доступом без потери функциональности соответствующих СХД, централизовать распределение ресурсов, доступ и управление, а также обеспечить возможность добавления новых типов систем хранения. Иногда эта модель охватывает и системы DAS. Однако эффективно управлять трафиком передачи данных в такой инфраструктуре непросто — неизбежно возникают узкие места, что ведет к потере производительности и снижению уровня доступности приложений.

Так называемые сервисы хранения данных должны представлять собой некую комбинацию сервисов репликации, снимков данных, шифрования, дедупликации и т. д., но интегрировать разнородные проприетарные API, назначать сервисы данных СХД разных вендоров и классов систем хранения и вдобавок полностью использовать возможности задействованных унаследованных СХД очень сложно.

Включение в архитектуру хранения дополнительных видов СХД нарушает целостность ее представления. Такая комбинация (например, DAS на границе инфраструктуры хранения и системы SAN/NAS в ее центре) позволит эффективно использовать имеющуюся емкость, но получить точную общую картину такой среды хранения вряд ли удастся. Кроме того, задача распределения ресурсов многократно усложняется, а увеличение количества точек управления и инструментальных средств ведет к появлению узких мест из-за технологических ограничений. Автоматизировать распределение ресурсов непросто, а при ручном управлении растет вероятность ошибок, возникающих по вине системных администраторов. А ведь именно этого вендоры стремятся избежать с помощью SDS.

Для реализации концепции SDS нужны единая точка управления, открытые API, простой процесс выделения ресурсов, сопоставимый по времени и трудоемкости с созданием виртуальной машины, централизованный мониторинг и управление. Служебные сервисы (аутентификации, учета потребляемых ресурсов и др.) могли бы помочь ИТ-подразделениям и провайдерам сконцентрировать силы для создания новых услуг.

ЧТО ПРЕДЛАГАЮТ ВЕНДОРЫ?

По мере появления новых разработок и продуктов понятие «программно определяемые системы хранения» стало приобретать все более четкие очертания. В числе примеров — системы хранения данных OpenStack, EMC ViPR, Nexenta (см. Рисунок 2) и HP StoreVirtual.

SDS: назад в будущее
Рисунок 2. ПО NexentaStor предназначено для консолидации разнородных ресурсов посредством стандартных протоколов.

 

Все больше производителей СХД называют свои решения «программно определяемыми», однако каждый из них вкладывает в понятие SDS свой смысл и сориентироваться в этом непросто. К тому же все больше функций СХД реализуется именно на программном уровне. Какие системы действительно относятся к классу SDS, а какие представляют уже известные ранее технологии «в новой обертке»? Главным в SDS считается абстрагирование сервисов хранения данных от аппаратного уровня — физического оборудования.

На новом рынке SDS уже можно выделить несколько групп вендоров. Первая по существу предлагает новое поколение средств виртуализации систем хранения: сервисы хранения абстрагируются от физического оборудования и могут применяться к аппаратным решениям разных производителей. Иногда они реализуются в виде открытых платформ, чтобы независимые разработчики могли добавлять новые сервисы хранения в свои продукты (по принципу магазина приложений). Данный подход избавляет заказчика от привязки к конкретной аппаратной платформе и программным сервисам.

Вторая группа вендоров идет еще дальше — по пути абстрагирования контроллеров систем хранения. Это позволяет задействовать ресурсы хранения уже имеющихся систем и упростить операции, однако весь ввод-вывод осуществляется через виртуализирующий контроллер, поэтому он должен иметь высокую пропускную способность и производительность. Кроме того, его требуется резервировать.

Третья группа разработчиков SDS абстрагирует управление СХД, но задействует уже реализуемые ими функции. Например, если нужно сделать снимок тома, на центральной консоли вводится соответствующая команда, которая передается для выполнения системе хранения. Хотя снимок тома разных дисковых массивов можно выполнять одной командой, все равно для этого используется сервис конкретной СХД. В результате упрощаются операции, к тому же, в отличие от второго подхода, не вносится дополнительная задержка из-за коммуникаций между СХД, а для выполнения операций не требуется высокая вычислительная мощность. А при отказе консоли управления SDS данные все равно будут доступными.

Как обычно, выбор оптимального варианта зависит от потребностей. Если необходимы дополнительные сервисы хранения данных и планируется закупка новых систем хранения, то первые два подхода предпочтительнее. Когда нужна консолидация ресурсов хранения и операций, поможет третий вариант. Если же требуется просто обновить инфраструктуру хранения и унифицировать ее, то максимальные выгоды от SDS можно получить в «облачных» ЦОД с высокой степенью виртуализации.

ПРИМЕРЫ SDS

Ряд ведущих производителей СХД уже «встали на путь SDS», а некоторые даже выпустили коммерческие продукты. Обычно разработки в области SDS базируются на развиваемых уже много лет системах виртуализации СХД, но иногда представляют и принципиально новые решения.

В IBM в качестве перспективной платформы для облачных и программно конфигурируемых сред рассматривается обновленное семейство систем хранения данных IBM Storwize. Выпущенная в октябре модель IBM Storwize V5000 (см. Рисунок 3) по производительности и функциональности заняла промежуточное положение между моделями начального уровня V3700 и старшими системами серии V7000.

SDS: назад в будущее
Рисунок 3. В IBM считают, что виртуализация и автоматическая оптимизация позволяют отнести новую систему Storwize V5000 к классу SDS.

 

V5000 может виртуализировать СХД разных вендоров, объединяя их в пул ресурсов. Эта технология знакома пользователям по IBM SVC. В числе ее функций — распределение данных по уровням хранения (Easy Tier), оптимизированное резервное копирование (FlashCopy), обеспечение катастрофоустойчивости (Metro Mirror и Global Mirror) и поддержка внешней виртуализации (External Virtualization), что позволяет перемещать в V5000 данные из дисковых массивов других производителей. Однако система не унифицирована, то есть поддерживается лишь блочный доступ.

Автоматическая оптимизация помогает сократить расходы и повысить отдачу от инвестиций, в частности, благодаря упрощению работы системного администратора за счет его разгрузки от рутинных операций. ПО SmartCloud Virtual Storage Center и Active Cloud Engine обеспечивают интеграцию в виртуальные среды, управление информацией и миграцию данных в соответствии с заданными правилами. Tivoli Storage Productivity Center ME осуществляет анализ и мониторинг системы, а IBM Tivoli Storage FlashCopy Manager — резервное копирование и восстановление данных.

В представлении IBM (см. Рисунок 4), в SDS рабочая нагрузка определяет требования к емкости систем хранения данных, их производительности и другим параметрам, средства оркестровки планируют распределение ресурсов для выполнения соглашений об уровнях обслуживания, а API поддерживает взаимодействие с компонентами инфраструктуры. Это предполагает разделение функций управления и хранения и применение более простых по функциональности систем хранения. Однако пока что производители, как считают в IBM, предлагают лишь фрагментарные решения, а сама компания находится на начальном этапе разработки программно конфигурируемого хранения, который характеризуется виртуализацией, консолидацией и оптимизацией СХД.

SDS: назад в будущее
Рисунок 4. В концепции IBM программно определяемые СХД являются частью программно определяемой инфраструктуры Software Defined Environment (SDE), которая предусматривает глубокую координацию приложений с системами хранения  / сетью, использование возможностей систем хранения для динамического выделения ресурсов с наиболее подходящими характеристиками, появление новой функциональности во взаимодействии систем хранения и ПО, интеграцию функциональности систем хранения в программное обеспечение. Управляющий слой отделяется от программного и аппаратного слоев, что позволяет абстрагироваться от ресурсов при сборке специализированных решений. Программируемые интерфейсы обеспечивают динамическую оптимизацию в соответствии с изменяющимися требованиями бизнеса.

 

Наряду с контроллерами виртуализации к SDS относится еще один класс решений — виртуальные устройства хранения (Virtual Storage Appliance, VSA). Ярким примером является HP StoreVirtual VSA — виртуальная программно определяемая система хранения, поддерживающая основные стандартные серверы и различные гипервизоры. HP развивает ее с 2007 года, и за это время было внедрено свыше 170 тыс. виртуальных систем хранения. HP StoreVirtual VSA представляет собой ПО с открытыми API для управления и оркестрации, устанавливаемое на стандартные серверы открытой архитектуры и позволяющее создавать общие системы хранения на базе внутренних или подключаемых к серверам дисков. Однако компания предлагает и готовые программно-аппаратные платформы x86 (Converged Storage Appliance, CSA).

Для управления и оркестрации горизонтально масштабируемых платформ CSA можно применять продукты HP или ее партнеров. VSA и CSA появились у HP в результате приобретения компании LeftHand. Новые версии продуктов данного семейства (например, система хранения HP StoreVirtual 4335) обладают адаптивными функциями оптимизации и автоматическим распределением нагрузок между подтомами разных классов.

Согласно оценкам HP, по сравнению с типовой архитектурой SDS на 80% снижает расходы на системы хранения, на 60% сокращает энергозатраты и на 50% уменьшает занимаемую системами площадь. К классу SDS относится также HP StoreOnce VSA — независимое от аппаратного обеспечения решение дедупликации и репликации резервных копий. Как утверждается, это программное решение значительно снижает расходы на защиту данных, особенно в случае использования его в ИТ-инфраструктуре крупных и средних предприятий. Оно позволяет обойтись без выделенного аппаратного обеспечения для резервного копирования и обеспечивает управление всей средой резервного копирования с помощью единой консоли. StoreOnce развертывается как виртуальная машина на сервере и поддерживает СХД разных вендоров.

Одной из наиболее резонансных новых разработок в области SDS стала платформа EMC ViPR, представленная на конференции EMC World в мае 2013 года. По замыслу ее создателей, платформа ViPR способна упростить работу заказчиков, обеспечив следующие преимущества:

  • абстрагирование ресурсов хранения от существующей инфраструктуры и объединение их в стандартизованные виртуальные пулы хранения;
  • автоматизацию процессов выделения ресурсов, защиты данных и управления изменениями;
  • предоставление доступа к ресурсам хранения по принципу самообслуживания;
  • высокую масштабируемость;
  • динамическую адаптацию к новым сценариям использования и нагрузкам.

Это решение предусматривает возможности интеграции с серверами, оснащенными ПО VMware, OpenStack и Microsoft, а также с массивами других производителей (например, NetApp), поддерживает программные интерфейсы REST API для интеграции с Amazon S3, OpenStack Swift и EMC Atmos, позволяет создавать сервисы управления данными, объединяющие блочные, файловые и объектные ресурсы хранения. В октябре EMC объявила о коммерческой доступности ViPR для заказчиков, разработчиков и партнеров по всему миру.

По существу ViPR — программный пакет, объединяющий средства виртуализации СХД с файловым, блочным и объектным доступом и средства управления хранением. Его характерные особенности — разделение «пути данных» и «пути управления», а также поддержка объектных СХД. Наиболее близкие решения — DataCore SANsymphony (платформа виртуализации, объединяющая СХД в среду Virtual SAN и поддерживающая при этом традиционные жесткие диски, флэш-накопители и облачные хранилища), HDS VSP, IBM SVC, NetApp V-Series, а также Melio SANbolic, StorMagic SvSAN и другие VSA.

С помощью API решение EMC ViPR осуществляет объединение СХД разных вендоров, создает виртуальные пулы ресурсов, управляет ими, предоставляет пользователям портал самообслуживания для заказа услуг, реализует распределение ресурсов по требованию. При этом «путь управления» отделен от «пути данных»: серверы и приложения могут обмениваться информацией с физическими устройствами напрямую, минуя слой виртуализации. Это позволяет использовать расширенные функции без снижения уровней надежности и производительности комплекса. «Путь данных» обеспечивает защиту информации, резервное копирование, катастрофоустойчивость, миграцию данных, поддержку различных дополнительных протоколов доступа и др. (см. статью автора «Виртуализированный ЦОД и технологии хранения данных» в «Журнале сетевых решений/LAN» за июль-август 2013 года).

Еще одна новинка 2013 года — новая версия операционной системы Clustered Data ONTAP, анонсированная компанией NetApp в июле. Одно из нововведений версии 8.2 — логически изолированные виртуальные машины хранения данных (Storage Virtual Machines, SVM), обеспечивающие управление качеством сервиса (QoS) для каждого пользователя (например, подразделения организации). Это решение рассматривается в NetApp как основа SDS (см. Рисунок 5). SVM напоминает прежнюю технологию NetApp vFiler (Virtual Filer), но виртуальные машины SVM полностью отделены от аппаратных платформ — их можно перемещать между системами с сохранением заданных параметров QoS.

SDS: назад в будущее
Рисунок 5. Clustered Data ONTAP: SDS согласно NetApp.

 

В области SDS работают немало недавно созданных компаний. По оценкам аналитиков, за последние два года венчурные инвестиции в этот сегмент мирового рынка превысили 300 млн долларов.

ЗАКЛЮЧЕНИЕ

Итак, SDS обычно трактуется как инфраструктурное программное обеспечение, предоставляющее набор взаимодействующих служб хранения данных, доступных приложениям и менеджерам рабочих нагрузок. Сервисы хранения данных призваны обеспечивать потребности основных типов приложений, могут использовать различные платформы и/или носители либо интегрироваться с серверами или выделенными системами хранения. Они доступны через каталог и управляются оркестратором. SDS обеспечивает автоматизированное управление хранением, QоS производительности (пропускная способность, IOPS, задержка), выбор правил резервного копирования и DR, необходимый уровень безопасности.

В ESG выделяют следующие преимущества SDS:

  • Простота, достигаемая благодаря централизованному управлению и мониторингу в реальном времени. Лучшие реализации SDS обеспечивают простую интеграцию и работу с разными системами хранения, серверами и гипервизорами.
  • Экономичность, обеспечиваемая за счет упрощенной поддержки и более полного использования ресурсов хранения из общего пула.
  • Эффективность, выражаемая в простом перемещении данных между системами хранения и выделении ресурсов хранения серверам.

Но SDS в конечном счете — всего лишь термин, обозначающий направление эволюции СХД. Известный уже не один год принцип абстрагирования сущностей и управления ими на разных уровнях с использованием автоматизации находит все более широкое применение. Неспроста в прошлом году стали говорить об SDE — Software-Defined Everything. Хотя «программно определяемое всё» — скорее, шуточный термин, но в каждой шутке есть доля правды.

SDS — одновременно и новый, и старый подход. Как считают аналитики The 451 Group, он способен оказать существенное влияние на корпоративную инфраструктуру хранения данных благодаря возможности выполнения многофункционального программного обеспечения на широко распространенных аппаратных платформах. Однако в то время как ряд вендоров, включая HP, IBM и NetApp, уже подхватили идею программно определяемых систем хранения и предлагают собственные решения, другие, в числе которых Fujitsu, предпочитают именовать свои СХД «бизнес-ориентированными», понимая под этим, в частности, возможность задания для приложений приоритетов (например, чтобы получить желаемое время отклика) — остальное система делает автоматически.

Независимо от терминологии отрасль движется в одном направлении, и этот путь не будет гладким. Идея разделения функций управления и хранения, а также применения более простых по функциональности систем хранения в конечном итоге может привести к конфликту между коммерческими интересами производителей и технологическими решениями, что уже можно наблюдать на примере SDN: некоторые вендоры вместо открытого подхода сегодня предлагают собственные проприетарные разработки.

Сергей Орлов — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: sorlov@lanmag.ru.