Windows Server 8 Preview: встроенная дедупликация файловых шар на BUILD 2011

На BUILD 2011 в конце сентября Microsoft показала Developer Preview Windows Server 8 (внутреннее обозначение, официального имени пока нет - мы здесь будем называть его WS8). Среди прочих новинок - роль Data Deduplication прямо в операционной системе, без покупки отдельного продукта или лицензии дополнения. Это любопытно, и вот почему мы обратили внимание именно на неё.

Что показали на BUILD

Data Deduplication в WS8 - это не дедупликация бэкапов, как у Veeam или Data Domain. Это дедупликация на уровне файловой шары, работающая в фоне после записи данных. Схема похожа на то, что умеют некоторые NAS-устройства уровня NetApp или Isilon, но здесь это часть Windows Server как стандартной роли.

Принцип работы, насколько можно понять из демо и первых описаний Preview: система периодически сканирует тома, разбивает файлы на блоки переменного размера, вычисляет хэши, и одинаковые блоки хранит в единственном экземпляре в специальном chunk-store, а вместо оригинальных данных оставляет ссылки. Всё это прозрачно для пользователей и приложений - SMB-шара выглядит и работает как обычно.

Заявленные цифры экономии:

• 50-80% на файловых серверах с офисными документами и похожим контентом
• 30-50% на серверах разработки с исходниками и дистрибутивами
• от 5% на серверах с уникальным медиаконтентом или зашифрованными данными

Числа взяты из презентации Microsoft - насколько они соответствуют реальности в production, узнаем только в боевых тестах. По опыту с thin provisioning от NetApp и Veeam дедупликацией бэкапов, маркетинговые цифры часто берутся из идеальных сценариев, но в реальных средах всё зависит от характера данных.

Почему это важно именно для файловых серверов

У нас под сопровождением несколько клиентов, где файловые серверы на Windows Server 2008 R2 хранят годами накапливающийся архив документов: договоры, проекты, отчёты. На таких серверах типичная картина - у одного клиента порядка 40-60% пространства занимают документы, которые существуют в десятках копий под разными именами в разных папках. Версионирование через «_v2», «_финальный», «_финальный_правки» - национальный вид спорта.

Именно этот паттерн - самый выигрышный для дедупликации. Одинаковое содержимое в разных файлах хэшируется в общие блоки, и вместо десяти копий 2-мегабайтного договора на диске хранится один экземпляр.

Раньше для решения этой задачи на Windows-серверах нужно было либо ставить дополнительный продукт (например, специализированные решения типа StorageCraft или идти на аппаратный NAS с дедупликацией), либо смиряться с ростом хранилища. WS8 обещает убрать эту прослойку.

Что смущает в Preview

Это Developer Preview, то есть сырой предрелизный билд, который Microsoft раздаёт разработчикам для знакомства с API и новыми возможностями. На Production ставить нельзя, поддержки нет, стабильность не гарантируется. Дата GA Windows Server 8 не объявлена.

Несколько вопросов, которые остаются открытыми после изучения материалов BUILD:

• Производительность на операциях чтения. Дедуплицированный том требует дополнительных I/O при чтении для реконструкции файлов из чанков. Насколько это заметно в сценарии с высокой нагрузкой на файловый сервер - презентация не раскрывает.
• Поведение VSS. Теневые копии на дедуплицированных томах - потенциально нетривиальная вещь. Непонятно, как они взаимодействуют и не ломается ли экономия при включённом VSS.
• Потребление CPU. Фоновое сканирование и хэширование - это нагрузка. На нагруженных файловых серверах это может быть ощутимо.
• Поддерживаемые рабочие нагрузки. В Preview заявлено, что дедупликация работает для File Server, но не поддерживается для томов с Hyper-V VHD или SQL-данными. Граница разумная, но стоит убедиться, что ограничение документировано чётко.

Наш план

Пока WS8 остаётся Preview, в production его, конечно, никто не ставит. Но есть смысл развернуть тестовую среду и прогнать реальные данные с одного из клиентских файловых серверов, чтобы к выходу GA иметь уже измеренные цифры, а не опираться на слайды из Анахайма.

Конкретный план такой: берём клиента с типичным архивом документов на Windows Server 2008 R2, делаем snapshot данных, разворачиваем WS8 Preview в Hyper-V, наливаем туда тот же объём и смотрим, что реально получается после недели работы дедупликации. Параллельно меряем CPU и I/O, чтобы понять, какой ценой даётся экономия.

Если цифры окажутся близки к заявленным - это меняет экономику планирования файловых серверов для нескольких клиентов, которым мы сейчас помогаем решать вопрос расширения хранилища. Вместо докупки дисков или перехода на NAS с встроенной дедупликацией можно будет обойтись меньшим объёмом за счёт WS8.

Результаты теста - когда будет что измерить. По срокам - ориентируемся на ближайшие несколько недель.

Если вам интересно оценить, насколько дедупликация может помочь на вашем файловом сервере уже сейчас - в рамках сопровождения ИТ-инфраструктуры проводим аудит хранилищ и считаем потенциал экономии по текущим данным.