Эффективность дедупликации хранилища на примере StarWind iSCSI SAN

Статья опубликована в журнале «Системный Администратор»

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

Во времена стремительного развития технологий виртуализации достаточно широко рассматриваются вопросы эффективности использования ресурсов выделяемых под нужды виртуальных серверов и рабочих станций. Одним из важных направлений на сегодняшний день является оптимизация использования дискового пространства на системах хранения занимаемого виртуальными машинами (далее ВМ). Сегодня уже существуют хорошо зарекомендовавшие форматы «тонких дисков» (Thin provisioning) которые увеличиваются в объеме по мере заполнения данными. При виртуализации рабочих станций применяется технология «золотого образа» позволяющая использовать один единственный виртуальный диск как основу для множества ВМ, сохраняя для каждой лишь отличия от «золотого» образа. Но особой популярностью в последнее время пользуется технология дедупликации данных. Сама по себе технология не молода[1], но на сцену виртуализации вышла не так давно, хорошо зарекомендовав себя в системах резервного копирования. Дедупликация работает на уровне блоков данных абсолютно не взирая на типы файлов и их содержимое. Поток данных, разделяется на блоки определенного размера, после чего выполняется их сравнение с уже записанными блоками. Сравнение блоков выполняется специальными алгоритмами исключающими коллизии стандартных-хеш функций, способных привести в последствии к разрушению данных. Фактически, на диск записываются только уникальные блоки данных, а там где они повторяются просто создаются на них ссылки.

Немного о StarWind iSCSI SAN

Что бы задействовать дедупликацию в продуктах StarWind, необходимо использовать хранилища специального типа. Включить дедупликацию для уже созданных ранее хранилищ нельзя, так же как и отключить эту функцию у хранилищ с дедупликацией. В продуктах StarWind, дедупликация всегда выполняется на лету (online), прозрачно для клиентских приложений и ВМ не требуя установки агентов и прочих настроек.
Рис 1. Схема дедупликации данных.

Используемый в качестве примера StarWind iSCSI SAN является реализацией программной СХД (Software SAN) который будучи установленным на Windows Server * превращает его в полноценный iSCSI-SAN с множеством удобных возможностей одной из которых и является тестируемая в данной статье дедупликация данных. Продукт StarWind iSCSI SAN представлен в нескольких редакциях одна из которых является бесплатной (StarWind FREE Edition). Весь демонстрируемый в данной статье функционал без каких либо ограничений доступен в бесплатной версии. Стоит отметить, что кроме  дедупликации, бесплатная версия позволяет создавать простые «тонкие» хранилища (Thin provisioning) и хранилища с поддержкой снапшотов. Не имеет ограничений на количество и объем используемых в сервере жестких дисков и хранилищ. Лицензия позволяет применять бесплатную версию в производственной среде и в коммерческой деятельности. При желании можно легко перейти на одну из платных редакций и получить возможность локальной (Synchronous Mirroring) и удаленной (Remote Replication) репликации хранилищ, отказоустойчивость (Automatic Failover), использование в качестве хранилищ «сырые диски» (RAW Device) целиком вместо файлов и конечно же техническую поддержку.
Оценить эффективность дедупликации данных я решил следующим способом:

1. На сервере StarWind iSCSI SAN, создаем два новых «тонких» (расширяющихся по мере заполнения) iSCSI-хранилища (iSCSI Targets), на одном из которых будет включена дедупликация.
2. Подключаем оба хранилища к разным, однотипным виртуальным машинам в предпочитаемой платформ виртуализации. В моем случае использовался Citrix XenServer 6.0.2
3. Устанавливаем одинаковые операционные системы на созданные однотипные ВМ с дисками на разных хранилищах.
4. Сравниваем объемы занятого хранилищами места. Делаем выводы.

1. Создание и экспорт новых хранилищ на сервере StarWind iSCSI SAN

В левой части StarWind Management Console, выделив предпочитаемый сервер, (в нашем случае он один — локальный) жмем доступную на панели быстрого запуска кнопку Deduplicated disk после чего запустится мастер создания нового хранилища на выбранном сервере. На первом этапе мастера, необходимо указать имя, объем файла и расположение будущего хранилища на одном из локальных дисков сервера. Кроме того можно в ручную указать размер блока дедупликации (Deduplication block size in bytes). Чем меньше блок, тем меньше может быть максимальный объем хранилища, но при этом будет максимально эффективна дедупликация. Увеличение объема блока, уменьшает эффективность дедупликации, но позволяет создавать хранилища до 1024 Тб. Размер блока дупликации так же влияет на ресурсопотребление процессора и памяти. Уменьшение размера блока повышает нагрузку на процессор. С оперативной памятью, по официальным данным ситуация примерно следующая; блок в 4к = 3 Мб памяти на 1 Гб хранилища, блок 16 кб = 768  кб на 1 Гб хранилища. В нашем случае, хранилище создается для установки одной ВМ, по этому размер блока был выбран поменьше (16 кб). На втором шаге, мастер предложит настроить репликацию создаваемого хранилища на другой сервер, но в рамках данного эксперимента нам это не к чему, поэтому его пропускаем. Следующим этапом будет выбор режима кеширования (Write-back — быстрее, Write-through — безопаснее или No caching). В рамках эксперимента кеширование не использовалось (No caching) и создаем новый iSCSI Target.

В терминологии iSCSI, Target — это своего рода виртуальный контроллер имеющий уникальное сетевое имя (IQN — iSCSI Qualified Name) формата «iqn.2008-08.com.starwindsoftware:<произвольноеПонятноеИмя>». На стороне StarWind-сервера, к Target может быть подключен один или несколько дисков(Attach device) как физических так и виртуальных (в виде файла), как в нашем случае. Каждый привязанный к Target диск называется LUN’ом (Logical Unit Number). LUN — это конечный адрес диска, а точнее дискового устройства. Нумерация LUN’ов начинается с «нуля». Что бы создать новый Target, на текущем этапе мастера необходимо лишь придумать Target Alias (псевдоним) — уникальное в пределах сервера, понятное, короткое имя латинскими буквами и без пробелов. После введения Target Alias, будет автоматически сгенерирован IQN нового Target доступный для дополнительного редактирования в поле Target name. Далее знакомимся с информацией собранной мастером и подтверждаем операцию. Если ошибок не возникло, то теперь мы имеем iSCSI-хранилище доступное для iSCSI-клиентов в моем случае под именем «iqn.2008-08.com.starwindsoftware:dc01-iscsi-01-03-dedupon». А т.к к Target прикреплен только один виртуальный диск, номер LUN будет равен «0».

Рис. 2. Создание нового хранилища с включенной дедупликацией.

Теперь, создаем еще одно iSCSI-хранилище с таким же объемом, но обычного типа — без дедупликации. Для этого, в левой части StarWind Management Console выделяем сервер и на верхней панели инструментов выбираем Add Device после чего запустится мастер создания нового устройства. На первом шаге выбираем Virtual Hard Disk (Виртуальный жесткий диск), указываем, что это будет Snapshot and CDP device, просим создать новый Create new virtual disk, задаем имя, объем и расположение нового файла-виртуального диска. На следующем шаге предлагается выбрать Operation mode — оставляем Growing Image (Thin Provisioning) то есть диск будет «тонким», выключаем кеш Normal(no caching) и наконец задаем имя (Alias) для нового iSCSI-Target к которому будет подключено вновь созданное хранилище.

Рис. 3. Объем пустых, свеже созданных хранилищ с включенной (1) и выключенной (2) дедупликацией.

2. Подключение хранилищ к предпочитаемой платформе виртуализации и создание одинаковых по конфигурации виртуальных машин.

В моем случае использовался Citrix XenServer 6.0.2 с бесплатной лицензией. Для подключения нового хранилища, в левой части консоли Citrix XenCenter выбираем отдельный хост или пул (кластер в терминологии Citrix) к которому хотим подключить новое хранилище и жмем в верхней панели инструментов New Storage. На первом шаге мастера, выбираем Software iSCSI, после чего вводим понятное имя для отображения нового хранилища в списке. Далее в поле Target Host указываем доменное имя или IP-адрес StarWind iSCSI SAN сервера, а напротив поля Target IQN нажимаем Discover IQNs (поиск доступных IQN). После быстрого поиска Target IQN превратится в выпадающий список из которого можно выбрать один из созданных нами ранее Target. Теперь, когда указан желаемый Target, жмем Discover LUNs (Поиск LUN — устройств на указанном Target). Т.к. устройство одно, оно буде автоматически подставлено.

Рис. 4. Подключение нового iSCSI-хранилища к Citrix XenServer.

Новые хранилища Citrix XenServer не отдает целиком виртуальным машинам, а выполняет их разметку с помощью LVM (Logical volume manager) и хранит образы виртуальных машин в виде файлов внутри хранилища.

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

3. Установка одинаковых ОС на новые виртуальные машины.

В моем случае, был установлен Windows Server 2003 SP2 Enterprise x86-64, работа на котором была завершена сразу же после первого входа в систему.

4. Сравнение объема хранилища после установки на них ОС.

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

Рис. 5. Объемы хранилищ после установки ОС. Дедупликация(1), без дедупликации(2)

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

Рис. 6. Объем хранилища после клонирования ВМ

Выводы

С уверенностью можно сказать, что программная дедупликация на примере продуктов StarWind не зависимо от используемых платформ виртуализации, работает и реально экономит значительные объемы (в случае с одной ВМ) на системе хранения. К сожалению, теория[2] о повышенной эффективности при большем объеме идентичных данных (клонирование ВМ) не была подтверждена. Хотя, на мой взгляд, показатель эффективности может сильно разнится даже в очень типичных конфигурациях.  Что касается производительности, программной дедупликации, то она конечно же будет зависит от производительности процессора и объема памяти на системе хранения и от размера блока дедупликации. В случае с мощным сервером, накладные расходы на дедупликацию могут быть и вовсе незначительны по сравнению с объемами сэкономленного дискового пространства.
Стоит отметить, что дедупликация безразлична к типам файлов и файловой системе, но она так как и стандартные компрессоры/архиваторы не эффективна с мультимедиа файлами в силу минимального дублирования данных.

Ссылки

1. Немного про историю технологии дедупликации и о технической реализации в различных продуктах —  http://www.i-teco.ru/article198.html
2. Калькулятор эффективности дедупликации StarWind, который даже определяет сумму сэкономленных средст — http://www.starwindsoftware.com/iscsi-san-deduplication-calculato

Помогла ли вам статья?