Руслан Заединов
Заместитель директора департамента вычислительных систем
компании «Крок».
С ним можно связаться по е­mail: rzaedinov@croc.ru

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

Начальный вариант программной виртуализации хранения данных хорошо знаком всем пользователям локальных сетей. Пользователь ПК не должен указывать, где именно находится его файл, — достаточно задать букву дисковода и путь в дереве каталогов, а файловая система сама определит физическое местоположение данных. Сетевые файловые системы, такие как NFS (Network File System) в Unix или CIFS (Common Internet File System) в Windows, расширяют этот подход, позволяя серверам, подключенным к одной и той же локальной сети, обращаться к файловым системам друг друга. Обе эти разработки, так же как и программный шлюз Samba, обеспечивающий взаимодействие между Unix­ и Windows­серверами, существуют с 90­х годов и представляют собой самый простой и прямолинейный, хотя и неполный вариант виртуализации: пользователь может работать с «чужим» файлом как со своим, но только зная имя того сервера, на котором он находится. В дальнейшем появлялись и более специализированные решения, в частности, для Windows была создана DFS (Distributed File System — распределенная файловая система), дающая возможность абстрагироваться от конкретного местоположения группы файлов (доступ к которой получен по CIFS). Если в CIFS мы обращаемся к совершенно определенному серверу, где хранится нужный файл, то в DFS указывается условное имя файловой группы, так что системный администратор может подменять серверы или перемещать данные между ними прозрачным для пользователей образом.

Следующим этапом стало создание файловых систем уже не для локальных сетей, а для сетей хранения данных (SAN), т. е. с высоко­скоростным доступом. А так как этот доступ не блочный, а именно файловый, с одними и теми же данными могут одновременно работать все серверы, на которых установлено соответствующее ПО. Схема работы такой системы сводится, грубо говоря, к следующему. Среди серверов, потребляющих данные, выделяются серверы метаданных, отвечающие за размещение файлов на дисковых массивах в рамках SAN. При обращении к файлу сервер­потребитель запрашивает сервер метаданных о его размещении и, получив ответ, находит файл по указанному физическому адресу. Решения такого рода предлагает целый ряд компаний, среди которых есть производители как аппаратных средств (IBM, HP), так и операционных систем (SuSe); однако в России они сегодня практически не применяются.

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

Задачи аппаратной виртуализации

Чтобы сервер мог работать с дисковым массивом, его операционная система должна этот массив поддерживать, что бывает не всегда. Два разных массива иногда не удается подключить к одному и тому же серверу из­за несовместимости их драйверов. Чтобы решить такого рода проблему, можно ввести виртуализационную прослойку, которая будет абстрагировать серверы и системы хранения друг от друга. Все соответствующие решения — аппаратные, это устройства с набором интерфейсов, часть которых обеспечивает стыковку с серверами, потребляющими данные, а часть — с дисковыми массивами, эти данные поставляющими. Со стороны дисковых массивов поддерживается некий набор аппаратуры (EMC, HP, IBM, NetApp...), со стороны серверов — набор операционных систем (Solaris, HP­UX, AIX, Linux, Windows, Novell...).
Для чего может пригодиться такая схема? Решаемые с ее помощью задачи условно можно разделить на три группы.

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

2. Объединение «зоопарка». Многие компании подходили к построению своих хранилищ данных эволюционным путем. Представим себе, например, что пять лет назад фирма приобрела дисковый массив производства EMC, три года назад — производства IBM, а позавчера ей понадобилось быстро «заткнуть» некую брешь, и она купила недорогую систему начального уровня от HP. Со стороны выглядит диковато, но в реальности случается даже такое. Вообще же «зоопарк» — это то, с чем все мы, к сожалению, живем. Не стоит метать громы и молнии по поводу подобных ситуаций, надо принять как факт то, что они существуют, и решать связанные с ними проблемы. Теперь представим себе, что у компании есть три попарно несовместимых дисковых массива емкостью соответственно X, Y и Z терабайт и массив данных объемом примерно X+Y+Z. Как обеспечить работу с этими данными? На помощь снова приходят средства виртуализации: с их использованием дисковые массивы объединяются в пул, совершенно прозрачный для серверов с точки зрения доступа, и таким образом образуется хранилище данных достаточной емкости. При этом виртуализация не только устраняет «зоопарк», но и позволяет управлять полученным хранилищем как единым целым, что удобно для системных администраторов.

3. Репликация в распределенных сетях. При слиянии предприятий или в ходе исторического развития инфраструктуры в одной большой территориально разнесенной компании иногда появляется необходимость в интеграции двух или многих дисковых массивов, расположенных в разных местах, — например, для репликации. Скажем, объединились две компании — из Москвы и Екатеринбурга. У каждой из них имеется готовый (или почти готовый) ЦОД, и они решили один из них сделать основным, а второй резервным. Соответственно необходимо организовать репликацию данных между ними. Однако если для хранения данных в компаниях используется разная техника — к примеру, EMC и HP, — то прямая их репликация на аппаратном уровне невозможна: эти массивы «живут в разных вселенных» и не в состоянии непосредственно реплицировать данные друг друга. А виртуализационная прослойка, поддерживающая оба типа массивов, позволит организовать такой перенос.

Основные решения

Функциональность виртуализаторов всегда одна и та же — они обеспечивают совместимость систем хранения разных типов и серверов с разными ОС. Однако аппаратные платформы, на которых они базируются, различны, поэтому технические характеристики и цена тоже различаются.

Если говорить о российском рынке виртуализаторов, то из работающих на нем поставщиков наибольшую активность проявляет, видимо, IBM. Ее решение, которое называется SVC (Storage Virtualization Controller), компании «Крок» знакомо лучше всего: мы тестировали его в своей лаборатории. SVC — это отказоустойчивый кластер из двух серверов стандартной (x86) архитектуры: при сбое в одном из них связь с массивом обеспечит другой, и работа продолжится. Кластеры можно каскадировать, устанавливая два, три или четыре устройства SVC, что позволяет увеличить пропускную способность виртуализационной системы.

Решение по виртуализации, предлагаемое HP, построено на иных принципах, хотя раньше HP, как и IBM, выпускала виртуализатор на базе обычного сервера, в который устанавливалось нужное количество FC­адаптеров для связи с источниками и потребителями данных. Сейчас HP предлагает устройство SVS­200 (Storage Virtual Server), которое производится компанией Hitachi в рамках OEM­соглашения. OEM­продуктами Hitachi являются и старшие модели систем хранения корпоративного класса от HP (семейство StorageWorks XP), а SVS­200 — это, собственно говоря, такой же дисковый массив, только без дисков. Со стороны серверов он (как и StorageWorks XP) поддерживает практически все существующие ныне операционные системы, а со стороны дисковых массивов добавлены дополнительные интерфейсы для поддержки систем других производителей (отличных от HP/Hitachi).

Таким образом, в варианте HP мы имеем дело со специализированным продуктом — это не просто программа, поставленная на выделенный сервер, а устройство, созданное как система хранения с соответствующей архитектурой, а значит, и производительностью. Если в случае IBM SVC для обеспечения необходимого быстродействия может потребоваться несколько экземпляров устройства (предварительно нужно оценить, сколько именно), то здесь мы покупаем готовый «ящик», о котором заранее известно, что его пропускная способность и другие характеристики — такие же, как и у дискового массива корпоративного класса, т. е. вопрос о производительности не стоит. Однако это решение дороже, а реализация проекта с его применением сложнее.

У EMC есть два решения по виртуализации, причем оба они совсем недавно приобретены компанией вместе с фирмами­разработчиками и на российском рынке пока представлены очень ограниченно. Первое — Rainfinity — является программным решением для виртуализации NAS­доступа. Второе — Invista — аппаратное, по функциям аналогичное устройствам от IBM и HP и сконструированное на основе выделенных серверов и коммутаторов SAN­сети.

В заключение заметим, что в России внедрения систем аппаратной виртуализации хранения данных сегодня исчисляются единицами. В основном подобными решениями интересуются предприятия с разветвленной структурой и исторически сложившимся «зоопарком» систем хранения (эти два свойства взаимосвязаны). Они вложили в оборудование большие деньги, поэтому не могут устранить несовместимость, просто отказавшись от каких­то устройств и заменив их другими. В этом случае более целесообразно применение виртуализации для обеспечения использования всех систем хранения как единого пула, централизованного управления им и репликации данных.