Темой нашего очередного опроса экспертов по системам хранения данных стала дедупликация — сравнительно недавно появившаяся технология, которая сокращает объем резервных копий за счет устранения повторного копирования одних и тех же наборов данных. Как отмечают наши эксперты, к настоящему времени российские компании широко используют дедупликацию при внедрении решений резервного копирования на базе дисковых системы D2D (disk-to-disk).

Михаил Винарский, ведущий инженер сектора Unix-систем компании “Техносерв” уверен, что “отечественные компании идут вровень с ведущими мировыми технологическими трендами. В 95% новых проектов или проектов по модернизации систем резервного копирования такая функция закладывается теперь изначально. Те же предприятия, что еще не используют дедупликацию, наверняка анализируют возможности ее применения”. По оценке Юрия Барабанщикова, руководителя направления систем обработки и хранения данных департамента сетевой интеграции “Ланит”, “в настоящее время практически все устанавливаемые D2D системы резервного копирования используют функционал дедупликации”.

Павел Карнаух, технический руководитель направления “Системы резервного копирования и восстановления” московского представительства EMC, утверждает, что “заказчики практически отказались от внедрения новых систем копирования на диск без поддержки дедупликации. Большинство организаций переходит к использованию специализированных устройств резервного копирования PBBA (purpose built backaup appliance) с поддержкой дедупликации”.

Более осторожную оценку темпов внедрения дедупликации дал Александр Меледин, технический консультант IBM System Storage. Он полагает, что, даже несмотря на частое использование дедупликации, “объем резервных копий, постоянно хранимых на жестких дисках очень мал по сравнению с таковым на лентах. Причина — дороговизна как приобретения, так и содержания. С точки зрения IBM, которую разделяет большое число заказчиков, D2D отлично дополняет систему резервного копирования на ленты”. Таким образом, IBM в отличие от EMC не рассматривает дисковые системы резервного копирования D2D с применением дедупликации как конкурента традиционных ленточных библиотек (стоит отметить, что в бизнесе IBM System Storage значительная доля приходится на продажи ленточных СХД, в то время как EMC производит только дисковые СХД).

Большинство экспертов согласны с тем, что дедупликация стала серьезным стимулом для внедрения резервного копирования на жесткие диски. Михаил Винарский подчеркнул, что “сегодня возможность использования дедупликации является одним из важнейших аргументов в пользу дисков при выборе между ними и лентами. Особую силу такому аргументу придает синергетический эффект от дедупликации. При ее правильном использовании можно не только экономить пространство хранилищ, но и получать выигрыш в скоростях резервного копирования, а также снижать требования к сетевой инфраструктуре и строить более эффективные катастрофоустойчивые решения с репликацией только уникальных данных”. Юрий Барабанщиков считает, что “системы резервного копирования D2D стали играть значительную роль на рынке СХД после появления дедупликации”.

Однако каков реальный эффект от внедрения дедупликации, т. е. насколько значительно эта технология позволяет уменьшить объем резервных копий на практике? Павел Карнаух приводит такие цифры: “Технологии дедупликации на уровне блоков переменной длины, используемые в продуктах EMC, обеспечивают ежедневную дедупликацию на уровне 15—500:1 в зависимости от скорости изменения данных. Общий коэффициент дедупликации составляет от 6:1 при еженедельном полном копировании быстроизменяющихся баз данных и до 25:1 при ежедневном полном копировании виртуальных инфраструктур”. Таким образом, на практике дедупликация уменьшает объем резервных копий в 6—25 раз.

Александр Меледин полагает, что применение дедупликации при “резервном копировании типичной инфраструктуры (SAP, Oracle, Exchange, Windows- и Linux-серверы приложений) дает средний коэффициент уменьшения резервных копий в 12—15 раз”. Роман Володин, руководитель отдела СХД компании “Инфосистемы Джет”, указывает, что “коэффициент сжатия может сильно варьироваться в зависимости от того, какие системы копируются и как они копируются. В устоявшихся инфраструктурах с обычными системами (почта, базы данных), сжатие может варьироваться от 6 до 10 раз. В виртуальных средах коэффициент сжатия может достигать 20 и больше в зависимости от “сходства” виртуальных машин”. Юрий Барабанщиков отмечает, что хотя “анализ удовлетворенности клиентов показывает, что эффект от внедрения решений соответствует их ожиданиям, а значит, коэффициент сжатия оказывается близким к прогнозируемому вендорами”.

Михаил Винарский считает, что “если давать среднюю оценку, то она укладывается в диапазон от единиц до нескольких десятков. Характер самих данных, в первую очередь, определяет итоговый коэффициент. Так, текст даст лучшие коэффициенты сжатия, чем сжатое видео. Также очень сильно на итоговый эффект влияет архитектура решения: использование глобальной дедупликации и длительное хранение большого числа полных копий могут позволить коэффициенту достичь очень больших значений”.

Логичным шагом в развитии технологий дедупликации могло бы стать ее применение для сокращения объемов не только резервных копий, но и первичных данных, т. е. тех постоянно используемых приложениями и пользователями данных, которые хранятся на основной дисковой системе хранения, однако большинство экспертов сдержанно оценивают перспективы такого варианта дедупликации. Хотя EMC уже поддерживает дедупликацию для своих дисковых СХД VFCache, Павел Карнаух предупреждает, что при дедупликации первичных данных выигрыш за счет уменьшения объемов будет в несколько раз меньше, чем при дедупликации заведомо избыточных резервных копий. Александр Меледин подчеркивает, что “для экономии места на продуктивных томах лучше использовать не дедупликацию, а сжатие в реальном времени. Это решение гарантирует, что продуктивная система получит достаточную для работы производительность даже на текущей СХД, в то время как дедупликация приведет к сильной деградации производительности”.

Роман Володин считает перспективной применение дедупликации при хранении первичных данных на носителях с высокой стоимостью за терабайт объема, таких, как твердотельные диски (SSD), а Юрий Барабанщиков — при хранении образов виртуальных машин. Наконец, Михаил Винарский указывает, что “целесообразность подобного подхода должна определяться в каждом конкретном случае, поскольку в отличие от резервного копирования, где мы манипулируем с запасной копией, в “продуктиве” могут играть более важную роль другие факторы, например производительность. Когда оперируешь первичными данными, то экономия пространства не всегда стоит на первом месте”.

Мы также попросили наших экспертов назвать основные проблемы, которые, по их мнению, возникают сегодня при внедрении дедупликации. Михаил Винарский считает, что это в основном “детские болезни”, типичные для большинства относительно молодых технологий, переживающих период бурного развития, включая недоверие консервативно настроенных ИТ-специалистов, отвечающих за эксплуатацию СХД и склонных “не трогать ничего, если все и так уже хорошо работает”. Александр Меледин полагает, что основной проблемой является нецелевое применение дедупликации, что связано с непониманием принципов дедупликации: “Задачи продуктивных систем и систем резервного копирования отличаются настолько, что решать их одним и тем же инструментом одинаково эффективно невозможно. Отсюда и негативные отзывы о дедупликации в целом”.

Роман Володин указывает, что для дедупликации требуется дисковая система, обладающая большой вычислительной мощностью (в противном случае применение этой технологии сильно снизит скорость обращения к данным), что ведет к повышению общей стоимости решения для резервного копирования. Кроме того, “повышаются и требования к качеству ПО систем резервного копирования — ошибка в алгоритмах обработки может привести к логическому разрушению всей хранимой информации. То же самое относится и к самим носителям — отказ двух дисков может привести к полной потере данных, следовательно, необходимо применять более высокие уровни резервирования”.

Юрий Барабанщиков считает, что внедрение дедупликации “требует более тщательного планирования процедур восстановления, чтобы доступные резервные копии можно было восстановить за требуемое время”.

Павел Карнаух обращает внимание на то, что при внедрении дедупликации могут возникнуть “вопросы взаимодействия между ПО и дисковыми системами, особенно разных производителей. Заказчиками востребованы интегрированные решения, а их в большинстве случаев можно получить только приобретая все компоненты у одного вендора”. Михаил Винарский также указывает, что “активное внедрение дедупликации различными производителями аппаратного и программного обеспечения в свои продукты приводит к ее фрагментации. Кроме того, реализации разных вендоров несовместимы, что ограничивает выбор для потребителей и в будущем может несколько замедлить распространение этой удачной технологии”.

Таким образом, компания, которая хочет внедрить дедупликацию, должна крайне ответственно подойти к выбору конкретного решения, поскольку, если в будущем она по какой-то причине захочет перейти на системы D2D c поддержкой дедупликации от другого вендора, то потребуется сначала прочитать все резервные копии со старой системы, а затем заново дедуплицировать их и записать на новую. Понятно, что такой проект потребует тщательного планирования и больших затрат времени, а также наличия значительной свободной дисковой емкости для временного хранения старых резервных копий. В этом отношении классические ленточные библиотеки оставляют намного больше гибкости для смены вендора оборудования резервного копирования — если в новой библиотеке используются приводы того же стандарта, что и в старой (сейчас фактическим стандартом для лент стал LTO), то при необходимости она сможет без каких-либо манипуляцией прочитать записанные на лентах старые резервные копии.