Data footprint

В различной англоязычной литературе я регулярно встречал термин data footprint. Недавно, увидев его в очередной раз, я понял, что не понимаю до конца его значение и попробовал разобраться. Оказывается, этот очень емкий термин описывает достаточно актуальную проблему практически всех комплексов хранения данных. Давайте немного порассуждаем об этом...

Для начала задумаемся, каким образом потребляется емкость хранения. К примеру, рассмотрим полезные данные размером 10GB. Помещенные в некую абстрактную СУБД за счет разреженности они могут занимать заметно больший объем, скажем, 20GB. Количество данных со временем растет, и администратор СХД просто обязан выделять тома с неким запасом емкости. Допустим, в текущий момент утилизация выделенных томов равна 50%, что в итоге приводит к потреблению 40GB. Для защиты информации применяется RAID. При использовании зеркалирования нам потребуются 80GB физической емкости. Катастрофоустойчивое решение предполагает реализацию репликации на удаленный дисковый массив и потреблению дополнительных 80GB. Полное и инкрементальное резервное копирование за неделю потребует не менее 25GB, а для его выполнения в горячем режиме необходимо использовать функциональность мгновенных снимков, что в среднем увеличивает потребление ресурсов хранения еще на 20% от полезного объема. Средам тестирования и разработки также необходима физическая емкость, скажем 5GB. Итого, в нашем достаточно консервативном примере при хранении 10GB полезной информации придется выделить объем более 190GB(!).

Для обозначения такого потребляемого брутто-объема данных как раз и используется термин data footprint. Заметим, что даже небольшое сокращение объема полезных данных приведет к значительному снижению data footprint. А если потребность в данных исчезает совсем, единовременно освобождаются огромные емкости на системах хранения различного уровня (диски различных типов и RAID, ленточные библиотеки).

Большие объемы data footprint требуют значительных капитальных и оперативных затрат на приобретение и модернизацию оборудования, его сервисную поддержку, управление комплексом, энергообеспечение и т. д. Поэтому сокращение пропорции потребляемого и полезного объемов является одной из основных задач оптимизации хранения данных.
Каковы же основные методы уменьшения data footprint? В первую очередь, это сокращение объема полезных данных за счет архивирования их неактивных или устаревших частей. Когда это возможно, отличным устройством для архивирования является /dev/null, т. е. просто удаление ненужной информации ;) . Архивирование может выполняться как средствами самих приложений и СУБД (например, выгрузка информации в другую базу данных), либо такими программными продуктами, как EMC DiskXtender или SourceOne.

Другими достаточно эффективными методами являются дедупликация и компрессия данных. В настоящий момент многие системы хранения поддерживают эту функциональность в автоматическом режиме и совершенно прозрачно для пользователя. Так в дисковых массивах EMC Clariion на уровне томов можно настроить сжатие данных, а при миграции информации на “ тонкие ” тома происходит автоматическое изъятие блоков заполненных нулями (space reclamation). NAS устройства Celerra работают с компрессией и дедупликацией данных на уровне файлов (на момент написания этого поста). Заметное влияние на data footprint оказывает использование технологии мгновенных снимков вместо полных копий/клонов томов.

Очень большая часть потребляемого объема составляют емкости, выделенные “на вырост”, в расчете на увеличение количества информации в перспективе ближайших лет. Наиболее эффективный метод сокращения этих объемов является динамическое выделение ресурсов (virtual provisioning). Это функциональность позволяет не резервировать заранее дисковое пространство, а автоматически выделять его из общего пула ресурсов по мере роста данных.

Общая утилизация дисковых ресурсов и значительно оптимизируется при использовании единого консолидированного хранилища вместо нескольких обособленных дисковых массивов. Конечно такой подход благотворно влияет на оптимизацию data footprint.

И еще одно замечание напоследок. Как и любая другая, задача уменьшения потребляемого объема данных не является абсолютной самоцелью. Не стоит увлекаться и забывать о требованиях производительности, надежности и управляемости комплекса. Поиск оптимального сочетания является действительно трудной задачей... Зато не скучно…   ;)