Не бывает компаний, которые за время существования не пришли бы к гетерогенной структуре хранения. При этом проприетарные аппаратно-программные комплексы характеризуются высокой стоимостью владения, которая объясняется использованием дорогостоящих коммутаторов, массивов памяти и прочих элементов, сложностью в обслуживании. В этом случае масштабирование под потребности компании означает приобретение и конфигурирование дополнительного устройства с автономным управлением, то есть структура недостаточно эластична и зачастую не успевает за запросами бизнеса. Решить перечисленные проблемы можно с помощью технологий SDS (Software-defined storage, программно-определяемые системы хранения данных), которые повышают производительность инфраструктуры, облегчают ее масштабирование, позволяют задействовать все накопленные серверы, централизуют управление и помогают снизить TCO (Total cost of ownership, совокупная стоимость владения).
Задача преобразования классической инфраструктуры хранения в нечто новое «программно-определяемое» поначалу может включать даже нюансы психологического барьера восприятия. С одной стороны – отчетливо понятные элементы гетерогенной архитектуры, каждый из которых имеет свой номер и место в стойке, с другой стороны – эфемерные пространства-хранилища с эластичными характеристиками, почти безразмерные, с непонятно откуда взявшейся невероятной производительностью, надежностью и отказоустойчивостью.
Заманчиво? Чрезвычайно! Но до принятия решения о переходе на SDS бизнесу очень важно ответить на два простых вопроса: в чем основная суть физического смысла программно-определяемого хранилища и почему гетерогенные инфраструктуры, еще вчера считавшиеся верхом технологических инноваций, сегодня по всем параметрам безнадежно отстают от SDS-инфраструктур. Для того чтобы оттолкнуться, подойдет простая аналогия между SDS и классической маркетинговой подачей «облачного сервиса». Тем не менее для успешного преобразования имеющейся системы хранения данных (СХД) в SDS-платформу нужно нечто большее.
Возможность централизованного управления хранением с использованием доступного серийного оборудования – по большому счету это и есть одно из определений SDS-технологий, которые стали мейнстримом на рынке СХД. Со временем их популярность будет только расти. Так, по прогнозам аналитиков IDC, суммарный рынок SDS вырастет с $1,41 млрд в 2014 г. до $6,22 млрд в 2019 г., при этом среднегодовой прирост составит примерно 34,6%. Наряду с растущими как грибы после дождя многочисленными стартапами в области SDS, огромные суммы в этот бизнес также инвестируют гиганты отрасли. К примеру, совсем недавно, уже в 2015 г., одна только корпорация IBM вложила в развитие SDS около $1 млрд.
Единое понимание программно-определяемых систем хранения данных сегодня, увы, отсутствует. Равно как и четкое определение разницы между SDS и виртуализацией СХД. Несмотря на многолетний и разносторонний опыт, накопленный множеством компаний в этой области, разнообразие частных случаев архитектурной организации традиционных СХД слишком велико, чтобы подвести их под один «знаменатель» и создать единую «волшебную формулу» перехода к SDS-инфраструктуре.
Тем не менее задачу использования уже имеющихся на предприятии хранилищ данных для создания SDS-инфраструктуры для начала очень полезно свести к простому пониманию сути SDS-технологии. И уже от этого понимания строить дальнейшую логику реорганизации СХД.
Чтобы понять принципы SDS, можно оттолкнуться от классики – программно-определяемых сетей (Software defined network, SDN). По аналогии, в SDS должно присутствовать разделение системы на два ключевых уровня, где уровень управления (Control plane) передает соответствующие команды устройствам, сосредоточенным на уровне данных (Data plane).
Разумеется, логика работы современных SDS-инфраструктур значительно сложнее и многообразнее, нежели утрированное двухуровневое разделение для конфигурирования потоков данных с помощью управляющего программного обеспечения. В этом заключается главное отличие SDS от традиционных «аппаратных» (HD) систем, и этого вполне достаточно, чтобы приступить к разработке архитектуры будущей SDS-системы.
Разнообразие существующих систем хранения, несхожесть архитектурных решений и, наконец, огромное количество финальных вариантов на базе не полностью стандартизированных решений могут значительно усложнить процесс внедрения SDS на имеющуюся инфраструктуру хранения. Если в случае с сетями внедрение программно-ориентируемых Control path и Data path упрощается за счет строгой стандартизации заголовков, IP, портов, атрибутов и т.п., то в случае внедрения SDS необдуманное разделение на Control plane и Data plane может оказаться неэффективным в силу указанных выше причин.
Современные дисковые массивы, нужно отдать им должное, достаточно «интеллектуальны» в силу длительной эволюции в жесткой конкурентной среде. Многие из них работают под управлением операционной системы хранения, поддерживающей свой собственный программный комплекс API и жизненно важные функции вроде многоуровневого кэширования (Cache tiering), синхронной репликации (Synchronous replication), самовосстановления (Self healing), обновления без потери работоспособности (Non-disruptive upgrade) и тому подобное. В процессе интеграции такой «умной» системы в SDS-комплекс придется лишить ее всех внутренних функциональных преимуществ, передав их уровню управления, и, таким образом, превратить систему хранения в обычный комплект накопителей JBOD (Just a bunch of disks).
Базовая концепция SDS-инфраструктуры
Внедрение SDS-технологии подразумевает, как минимум, повышение функциональности системы хранения. Именно поэтому при выборе подходящего SDS-решения для уже существующей инфраструктуры очень важно определиться, во-первых, с пошаговой стратегией перехода, и, во-вторых, с тем набором функций, передача которых в область ведения Control plane на каждом этапе действительно разумна и эффективна. В большинстве случаев для формирования SDS-инфраструктуры вполне достаточно вынести за скобки и передать на уровень Control plane такие базовые функции как формирование логических разделов, образование RAID-массивов, кодирование избыточности данных (Erasure coding), распределение нагрузки (Load balancing), динамический контроль производительности (Quality of service), ведение отчетов состояния (Status reporting) и произвольного ряда других опций.
Иногда выбор такого компромиссного пошагового преобразования системы хранения в SDS-структуру оптимален с точки зрения баланса разумного уровня расходов при сохранении высокой работоспособности предприятия. Таким, например, был выбор ИТ-службы голландской образовательной компании Van Dijk Education, которая еще в 2012 г. не смогла найти подходящую для своих целей законченную SDS-платформу с функцией дедупликации и сжатия данных, и выбрала комбинированное решение на базе традиционной и SDS-систем. Через два года, после дополнительного исследования рынка, была найдена SDS-платформа, полностью удовлетворяющая всем требованиям компании к производительности, поддержке множества протоколов и расширенной функциональности объединенной корпоративной системы хранения.
В другом случае некоммерческая общественная больница Hanover Hospital в Пенсильвании, являющаяся частью медицинской системы Hanover HealthCare PLUS Network, была вынуждена перевести весь свой ИТ-комплекс под управление SDS-платформы, что сразу обеспечило избыточность конфигурации с синхронным зеркалированием, сократило время доступа к данным и время на их резервирование. Кроме появившейся возможности быстрого масштабирования объемов хранения и более эффективного их использования по сравнению с традиционными SAN (Storage Area Network, сеть хранения данных), внедрение SDS-платформы также обеспечило более эффективную работу второго дата-центра предприятия, функционирующего отныне по «активно-активной» схеме с одновременным упрощением управления и снижением TCO всей СХД предприятия.
При наличии существующей инфраструктуры на базе конвергентной системы с несколькими типичными серверами и системой хранения класса DAS
(Direct-attached storage, система хранения данных с прямым подключением), для создания SDS-структуры для начала можно использовать единую для каждого
из них файловую систему. В то же время для инфраструктуры на базе горизонтально-масштабируемых систем класса NAS (Network-attached storage,
сетевые хранилища данных) или SAN можно задействовать как программно-определяемые, так и аппаратные Appliance-решения. Наконец,
управление сложными комплексными инфраструктурами систем хранения можно возложить на SDS-технологии с виртуализацией (Storage virtualization) или на
технологии управления ресурсами (Storage resource management, SRM).
Руководитель отдела технической поддержки продаж систем хранения данных IBM в России и СНГ
