Термин «виртуализация» совсем не нов для ИТ – соответствующие технологии давно и успешно применяются в самых разных областях. Новый импульс в своем развитии виртуализация получила благодаря взрывному росту объемов обрабатываемых и пересылаемых данных: возникла потребность в инструментах эффективного использования и управления ресурсами с целью реализации схем их выделения строго под потребности конкретной задачи.
Сегодня производители предлагают решения по виртуализации вычислительных ресурсов, ресурсов хранения (решения от «тонкого распределения» до полной виртуализации систем хранения, подобно технологиям Hitachi Universal Volume Manager (UVM) и IBM Storage Volume Controller (SVC)), подсистем ввода-вывода (решения Virtual Connect, Open Fabric Manager) и подсистем взаимодействия с приложениями (Citrix XenApp). Не пытаясь объять необъятное, рассмотрим теоретические и практические аспекты использования решений по виртуализации ресурсов хранения.
Существует два актуальных подхода к виртуализации ресурсов хранения: виртуализация систем хранения целиком и виртуализация дисковой емкости.
Суть первого подхода состоит в объединении ресурсов различных систем хранения под управлением одной системы. Фактически создается общий пул ресурсов, имеющий централизованное управление, единые механизмы взаимодействия с потребителями ресурсов (серверами), единые механизмы поддержания целостности данных и т.д. Администраторы получают возможность наглядно оценивать использование ресурсов различными системами, а также проводить планомерную модернизацию, не прерывая работы прикладных систем.
Второй подход – технология динамического, или тонкого распределения дисковой емкости (thin provisioning), или предоставление дисковой емкости по требованию. Идея виртуализации в этом случае состоит в том, что представление дисковой емкости серверам отделено от физического расположения данных на дисках. Данные пишутся на диски только по требованию, оставшееся свободное пространство не резервируется, а остается в динамическом пуле дисковой емкости.
Рассмотрим два реальных проекта, иллюстрирующих применение этих подходов.
Первый проект – построение резервного центра обработки данных и обеспечение репликации данных с основной площадки на резервную. Дополнительно ставилась задача получения целостных резервных копий данных на резервной площадке. В качестве основы системы хранения заказчик использовал дисковые массивы Hitachi Data Systems старшего уровня: USP-V и USP-VM. Репликация данных между массивами осуществлялась при помощи программного продукта Hitachi Universal Volume Replicator. Для того чтобы обеспечить передачу трафика Fibre Channel между площадками по IP-каналам, в состав сети хранения были включены мультипротокольные маршрутизаторы Brocade.
Задача создания резервной копии накладывала дополнительные требования на схему репликации. Дело в том, что нельзя создавать резервную копию непосредственно с тома, на который производится репликация, так как на такой том постоянно дописываются данные, и поэтому речи о создании целостной копии быть не может. Здесь возможны два варианта: останавливать репликацию на время копирования или же использовать на резервной площадке зеркальные копии реплицируемых томов (клоны) и копировать с одного из них.
Вариант с остановкой репликации для заказчика был неприемлем, поскольку существенно увеличивался промежуток времени, за который данные теоретически могли быть потеряны. За время, пока репликация не работала, вторая площадка сильно отставала от первой по актуальности данных. Процесс синхронизации также накладывал дополнительные требования на канал передачи данных, в связи с чем был выбран вариант с использованием клонов реплицируемых томов на резервной площадке. Однако это автоматически удваивает требования к доступному дисковому пространству, поэтому необходимо было найти компромисс между производительностью и стоимостью размещения клонов под резервные копии. Исходя из этих соображений заказчику было предложено задействовать имеющийся дисковый массив среднего класса IBM DS4700, но передать его под управление основного массива Hitachi USP-VM и виртуализовать ресурсы среднего массива средствами встроенного программного обеспечения Hitachi Universal Volume Manager. Такой подход позволил реализовать схему многоуровневого хранения, а также эффективнее использовать ресурсы имеющегося оборудования. На массиве DS4700 из всех имеющихся дисков было сформировано несколько томов, переданных массиву USP-VM. С точки зрения основной системы хранения появилось еще несколько RAID-групп, которые и были задействованы для получения клонов реплицируемых данных.
Важно отметить, что задачи управления логикой хранения и представления ресурсов были переданы USP-VM. Массивы Hitachi обладают рядом возможностей по обеспечению необходимого уровня производительности и контроля для данных на внешних системах:
- кэширование данных выполняет основной массив USP-VM, при этом кэш на DS4700 не используется;
- технология inflow control позволяет контролировать состояние внешнего массива и, к примеру остановить запись в кэш, если внешний массив не может произвести запись;
- технологии разделения кэш-памяти позволяют гарантировать производительность группы внешних томов и исключить их влияние на другие дисковые ресурсы в рамках системы;
- поддержка доступа по нескольким путям (multipathing) с учетом архитектурных особенностей виртуализованного массива гарантирует высокую доступность.
Особенностью второго проекта была необходимость динамического управления дисковыми ресурсами в рамках одной системы хранения. Заказчик использовал среду виртуализации VMware VI3, и требовалось обеспечить возможность гибкого выделения дискового пространства по требованию, а также предусмотреть возможность безостановочной модернизации ресурсов системы хранения.
В качестве решения использовался дисковый массив, поддерживающий технологию динамического распределения дисковой емкости. Представление дисковой емкости серверам отделено от физического расположения данных на дисках – данные пишутся на диски только по требованию, а оставшееся свободное пространство остается в динамическом пуле дисковой емкости. Основная идея состояла в том, чтобы однократно настроить взаимодействие виртуальной среды VMware с системой хранения, создав «тонкие» тома, размер которых существенно бы превышал текущие потребности и возможные прогнозы. Такая связка позволила реализовать возможность гибкой поэтапной модернизации системы, не внося изменений в уже работающие компоненты и подсистемы. «Тонкие» или виртуальные тома, выданные серверам ESX, используют дисковую емкость по мере необходимости. При заполнении дискового пространства, реально доступного на системе хранения, выше некоторого порогового значения, администратору выдается предупреждение. При этом добавление в систему хранения новых дисков никак не влияет на работу среды виртуализации VMware.
Дисковый массив обслуживается инженерами сервисного подразделения компании-производителя и не требует привлечения персонала заказчика. Важной особенностью VMware при работе с динамическими массивами является то, что файловая система VMFS3, в которую форматируются тома под управлением ESX, пишет на диски только заголовки, а не размечает все доступное пространство. Это позволяет сохранить дисковую емкость виртуальной. Более того, поддерживается возможность создания «тонких» дисков для виртуальных машин – vmdk-файлов. Дополнительным аспектом использования механизмов динамического выделения дисковой емкости является хорошая масштабируемость данного решения по производительности при росте объема доступных ресурсов.
При создании виртуальной машины дисковый массив автоматически выделяет необходимое количество дисковой емкости, и благодаря технологии динамического ее распределения этот процесс прозрачен для сервера ESX – автоматически выделяются не только вычислительные ресурсы, но и ресурсы системы хранения. Однако при удалении виртуальной машины картина не такая радужная – система виртуализации VMware, удаляя vmdk-файл, никак не отмечает, что блоки данных на устройстве хранения больше не используются, соответственно система хранения не может в автоматическом режиме вернуть фактически неиспользуемое пространство в пул дисковых ресурсов. Но больших неудобств это не доставляет: при создании новых объектов в среде VMware это место будет использовано вновь.
В отличие от первого проекта, в данном случае имеются нюансы при совместном использовании технологий виртуализации на серверах и в системе хранения. С одной стороны, управление выделением ресурсов прикладным задачам упростилось – фактически администратор работает только со средствами управления VMware VI3, а сама инфраструктура легко модернизируется. С другой стороны, существуют особенности работы механизма возврата освобожденного дискового пространства в пул свободных ресурсов. Суть проблемы в том, что не во всех случаях имеется возможность автоматически определить, что какие-то блоки данных более не используются и могут быть перемещены в пул общих ресурсов. И это обязательно должно учитываться на этапе проектирования в соответствии с требованиями к подсистеме хранения.
***
Технологии виртуализации ресурсов хранения обладают большим потенциалом, позволяя в полной мере решать задачи консолидации, повышения доступности и упрощения управления. Однако, несмотря на упрощение процессов эксплуатации, наблюдается рост сложности проектирования интегрированных конфигураций. Сегодня даже небольшие ИТ-проекты уже не являются «проектами одной технологии» или одного продукта, и практически каждый из них требует учета различных требований по взаимодействию подсистем. Упрощение эксплуатации во многом достигается за счет усложнения процесса разработки и внедрения.
Валерий Рыжков (VRyzhkov@nvisiongroup.ru) – ведущий инженер, отдел проектирования вычислительных систем и комплексов «Энвижн Груп» (Москва).
Неизбежность динамического резервирования
Динамическое резервирование позволяет отказаться от действующей сегодня парадигмы выделения ресурсов при введении системы в эксплуатацию в пользу новой – выделение при записи, рассчитанной на то, что пространство из имеющегося резерва отдается только по мере необходимости. В результате администратору не приходится отслеживать динамику потребностей, а нужно лишь контролировать состояние общего резерва.
http://www.osp.ru/os/2009/08/10742564
