Дедупликация на уровне хранилища: 12:1 на реальном клиенте

В марте мы писали про дедупликацию в Veeam 4.0 - соотношение 2:1 на виртуальной среде среднего клиента, подход на уровне репозитория ПО. Это была история про небольшую инфраструктуру. Теперь совсем другой масштаб: клиент с 10 ТБ ежедневного инкремента, старое ленточное хозяйство, которое перестало справляться, и решение на аппаратном дедупликаторе EMC Data Domain.

Результат вышел неожиданно убедительным даже для нас: соотношение дедупликации 12:1. Хранилище резервных копий перестало расти.

Откуда взялась задача

Клиент - крупная производственная компания, смешанная среда: физические серверы Windows и Linux, несколько хостов VMware ESX, корпоративные базы данных. Ежедневный инкремент резервных копий - около 10 ТБ. Backup-агенты от Symantec Backup Exec, целевое хранилище - ленточные библиотеки плюс дисковый пул на прямом NAS.

Проблема накапливалась несколько лет. Ленты - это RotaCycle раз в квартал, смена кассет, проверка читаемости, потеря на выходные и праздники, когда ленточник не приходит. Дисковый пул рос линейно: каждые полгода разговор про расширение. Объём данных стал таким, что окно бэкапа не укладывалось в ночь: инкременты заходили на рабочее время и нагружали боевые серверы.

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

Почему Data Domain, а не программная дедупликация

На рынке несколько подходов к дедупликации резервных копий. Программная - как в Veeam или в том же Backup Exec 2010 с опцией дедупликации - работает на уровне репозитория, требует ресурсов сервера и даёт приличный результат на однородных виртуальных средах. На смешанной среде с физическими серверами, базами данных и разнородным ПО эффект менее предсказуем.

Аппаратные дедупликаторы - EMC Data Domain, HP StoreOnce, Quantum DXi - выступают как target-устройство: backup-агент на сервере ничего не знает про дедупликацию, пишет данные как на обычный диск или ленту, а аппарат разбирает поток на сегменты и убирает дубликаты на лету. Это inline-дедупликация: данные не записываются, а потом дедуплицируются, а сразу при записи.

Для среды с разными backup-агентами и физическими серверами это важно: не надо пересобирать схему резервного копирования, менять агентов или настройку заданий. Data Domain подключается как VTL (Virtual Tape Library) или CIFS/NFS, и Backup Exec видит его как обычное дисковое хранилище или ленточную библиотеку.

Как разворачивали

Data Domain DD690 - mid-range модель, подходящая под нагрузку клиента. Подключили как VTL через FC к существующей SAN-инфраструктуре: для Backup Exec это выглядит как ленточная библиотека, задания переключились с минимальной реконфигурацией.

Параллельно оставили часть заданий на физических лентах - для long-term retention и вывоза за пределы площадки. Это принципиальный момент: Data Domain не заменяет ленту полностью там, где требуется физический вынос носителей. Он берёт на себя ежедневные и недельные резервные копии; ленты остаются для месячных и квартальных архивов.

Первые несколько дней после подключения - период «прогрева»: дедупликатор ещё не накопил базу сегментов, соотношение дедупликации невысокое. Нас предупреждали об этом заранее, но первые числа в отчёте всё равно выглядели скромно - 2:1, 3:1. Клиент смотрел с сомнением.

Что получилось

Через две недели соотношение стабилизировалось в районе 10:1-12:1. После полного цикла из нескольких полных бэкапов вышли на 12:1 и держимся там.

Объясняется это несколькими факторами одновременно:

• Схожие данные на разных серверах. Несколько десятков Windows-серверов с одинаковой ОС, одинаковым набором пакетов - системные файлы, библиотеки, бинарники идентичны блок в блок. Дедупликатор схлопывает это между серверами.
• Инкременты повторяют прошлые инкременты. В большой среде значительная часть «изменённых» данных на самом деле меняется по паттерну: логи, временные файлы, журналы транзакций БД. Сегменты совпадают с уже сохранёнными.
• Нулевые блоки. Незанятое место на дисках - огромный источник одинаковых сегментов. В виртуальных дисках его особенно много.

10 ТБ ежедневного инкремента - это примерно 833 ГБ реально записанных уникальных данных на дедупликаторе. Ёмкость, которая раньше сжиралась за неделю, теперь тянет почти три месяца.

Где неожиданности

Базы данных дедуплицируются хуже всего. Транзакционные логи меняются непредсказуемо, в блоках данных много случайности. Для одного из серверов с PostgreSQL соотношение вышло около 3:1 - против 14-15:1 для Windows-файловых серверов. Это не проблема, это просто физика: рассчитывать на 12:1 по всем данным без разбора не стоит.

Производительность записи снизилась по сравнению с прямым NAS - inline-дедупликация требует вычислительных ресурсов самого устройства. DD690 справляется, но пиковые нагрузки при одновременном запуске нескольких заданий дают очереди. Пришлось расставить задания по приоритетам и сдвинуть часть на разные временные слоты.

Практический итог

Хранилище перестало расти - это главный результат. Разговор про расширение дискового пула снят с повестки как минимум на ближайшие год-полтора. Окно бэкапа вернулось в ночное время. Ленточная библиотека разгрузилась до роли архива.

Что осталось несделанным: мониторинг соотношения дедупликации в автоматическом режиме с алертами при деградации. Data Domain умеет слать SNMP-трапы, но интеграция с Nagios клиента пока стоит в очереди задач. Если соотношение начнёт падать - это сигнал о том, что характер данных изменился или появился новый тип нагрузки.

Решение недешёвое. DD690 стоит серьёзных денег, и это честный разговор с клиентом: срок окупаемости считается через экономию на расширении хранилища и стоимость человеко-часов на обслуживание лент. В данном случае математика сошлась, но не у каждого клиента с похожим объёмом данных она сойдётся одинаково.