Программно-определяемые СХД: доступное решение для недоступных задач

В начале 2000-х годов, компания VMware представила миру первый программно-определяемый сервер, более известный как виртуальная машина. В этом сценарии виртуальное ПО работало не напрямую на железе, а помещалось внутри программных контейнеров, которые, в свою очередь, работали поверх некого промежуточного слоя, именуемого гипервизором. Такой подход давал огромные преимущества — как только что-то становилось программным, с ним сразу же становится очень легко работать. Виртуальные машины можно было перенастраивать щелчком мышки, их можно было легко перемещать, копировать и удалять. Программно-определяемый сервер обладал гибкостью и доступностью, который сложно или невозможно достичь на традиционных физических серверах. Более того, сделав серверы программными, появилась возможность автоматизировать большое количество рутинных задач администратора.

Что же происходит с физическими серверами? Из тщательно сконфигурированных под определенные задачи машин они стали просто обезличенным источниками ресурсов — commodity hardware. Администраторам осталось просто следить, чтобы этих ресурсов было достаточно.

Успех виртуализации совместно с усилиями маркетологов создал баззворд «Программно-Определяемый ЦОД» — концепция, которая распространяет принципы виртуализации серверов (абстрагирование, объединение и автоматизация) на все компоненты традиционного ЦОД, включая системы хранения данных. Так появился на свет еще один баззворд — Программно-определяемая СХД (Software Defined Storage — SDS). На каких принципах строится SDS? Примерно на тех же, что и серверная виртуализация: 

1. Аппаратная независимость, по сути, превратит железо в источник ресурсов и не более того. Весь интеллект должен быть реализован в ПО, которое также должно работать на любом обеспечении (например, на любом сервере с архитектурой х86).
2. Решения SDS должны основываться именно на ПО — как только любой функционал переносится на специфическое аппаратное обеспечение, например, специфические ASIC и FPGA, устройство перестает быть Software Defined. 
3. Поддержка автоматизации на базе политик.

Продвижение понятия Software Defined в мир СХД идет не так быстро, как в мир серверов. Дело в том, что объединить серверы в общий пул значительно проще, чем СХД. Серверы изначально более гибкие, чем системы хранения. На сервере можно легко заменить программную составляющую и тем самым изменить его назначение, например, достаточно заменить обычную ОС на гипервизор, и вы получите хост-сервер для среды виртуализации. С массивами такое не пройдет, так как установить на массив что-то, что изначально не предусмотрено производителем по большому счету, невозможно. Более того, массивы несовместимы друг с другом. Получается, что Software Defined Storage — это мифический зверь? Не совсем так. На текущий момент есть два путь достижения SDS: построение гипер-конвергентных систем или внедрение систем виртуализации СХД. 

Гипер-конвергентные системы (Hyper-Converged Infrastructure — HCI) используют в своей основе объединение узлы (серверы), каждый из которых одновременно является и сервером, и системой хранения данных. Система хранения строится на внутренних дисках каждого отдельного сервера, которые объединяются между собой в одно виртуальное дисковое пространство. Интеллект системы хранения размещается либо как компонент ядра гипервизора (например VMware vSAN) либо в виде отдельной виртуальной машины (например DataCore SANsymphony, Nutanix). Решения HCI во всех смыслах соответствуют концепции SDS: размещение интеллекта на программное обеспечение, использование в своей основе железа commodity hardware, поддержка автоматизации на основе политик. Но при использовании HCI остается одна проблема: что делать со всеми теми массивами, которые сейчас стоят в инфраструктуре? В них вложены инвестиции, многие из них еще далеки от морального устаревания, и на них еще лежат очень важные данные. Оставить их просто в стороне? Тогда мы просто получим существующие массивы плюс SDS. Выход? Не совсем…

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

Первое, что системы виртуализации СХД делают — это забирают на себя все интеллектуальное управление пространством, делая возможным использование «глупых» дисковых полок, т.е. commodity hardware, наравне с существующими дисковыми массивами. Второе, они абстрагируют данные от аппаратного обеспечения — данные получают возможность перемещаться фоном между различными массивами, не прерывая доступа, почти как живая миграция виртуальных машин между серверами. 
Вслед за возможностью двигать данные появляется возможность управления на базе политик. Администраторы могут назначить пространству с разных массивов разные характеристики, исходя из их скорости/емкости/цены, а также четко задать, какие данные могут пользоваться этим пространством и когда, т.е. появляется автоматизированное иерархическое хранение (Automated Tiered Storage). Концепция сама по себе не новая, но раньше она реализовывалась только в пределах одного массива. Системы виртуализации СХД позволяют реализовать ее в рамках всей инфраструктуры хранения данных. 

Так в чем подвох? Системы виртуализации СХД — это не коробочное решение. Внедрение подобной системы требует тщательной проработки и участия подготовленных профессионалов. Причем наличие у инженеров-внедренцев профессиональных сертификатов периодически является обязательным требованием (как в случае с внедрением Datacore SANsymphony — инженер должен обладать сертификатом Datacore Certified Implementation Engineer — DCIE). Сложность во внедрении зачастую подталкивает организации воспользоваться классическим способом решения проблем — купить еще железа. Но такой способ не всегда является оптимальным в долгосрочной перспективе. ИТ-инфраструктура — штука довольно динамическая, и вполне может оказаться, что через какое-то время существующее железо уже не будет удовлетворять новым требованиям организации. Что же тогда? Опять новое железо? А что делать со старым? Оно-то еще совсем даже и не старое… Подход SDS может дать ту гибкость, которая позволит ИТ-службам быстро реагировать на изменяющиеся требования организации, и при этом еще поместиться в бюджет.

Что же в итоге? Решения SDS, несмотря на свою видимую сложность, могут принести реальную выгоду организации, особенно в долгосрочной перспективе.