Рынок ориентированных на хранение резервных копий дисковых СХД измеряется миллиардами долларов. На этом рынке работает довольно много известных компаний, выпускающих продукты, которые уже стали хорошо известны во всем мире: EMC DataDomain, Symantec NetBackup, HP StoreOnce, IBM ProtectTier, ExaGrid и другие. C чего начинался этот рынок, и в каком технологическом направлении он развивается сейчас, как сравнивать разные программные продукты и устройства дедупликации между собой?
Первые СХД с дедупликацией появились в начале 2000-х. Они были созданы для решения проблемы резервного копирования экспоненциально растущих данных. Рост данных в продуктивных системах компаний приводил к тому, что продолжительность резервного копирования на ленты увеличивалась настолько сильно, что полные резервные копии уже не «помещались» в окно резервного копирования, а применение в качестве бэкап-хранилища существовавших в то время дисковых СХД было затруднено из-за их недостаточной емкости. В результате бэкапы могли «обрываться» либо из-за недостатка времени (для случая лент), либо из-за недостатка места (для случая дисков). Проблему места на диске можно было решить покупкой СХД большой емкости, однако в этом случае возникала проблема высокой стоимости хранения.
Программные продукты резервного копирования изначально проектировались из расчета, что хранилищем резервных копий является накопитель на лентах, а алгоритм создания резервных копий — алгоритм «отец-сын-внук»:
- «отец» (полная резервная копия раз в неделю),
- «сын» (инкрементальные копии шесть дней в неделю),
- «внук» (старая полная резервная копия, обычно отправляемая на внеофисное хранение).
Этот подход порождал генерацию довольного большого количества бэкап-данных и обходился компаниям сравнительно недорого при использовании лент, но при использовании дисков стоимость этого подхода существенно возрастала.
В те времена лишь небольшое количество программных продуктов резервного копирования предоставляли возможность встроенной дедупликации данных резервных копий. СХД со встроенной дедупликацией появились именно для решения этой проблемы — снижения стоимости хранения данных на дисках (в перспективе вплоть до уровня лент). Ключевым фактором успеха этих новых устройств являлся тот факт, что дедупликация хранилища работала прозрачно и не требовала никаких модификаций существующего программного обеспечения резервного копирования.
Однако за прошедшее время практически все программные продукты резервного копирования обзавелись встроенной дедупликацией, да и стоимость дисков (изначальная проблема дисковых СХД) существенно снизилась. Более того, теперь многие продукты резервного копирования умеют делать дедупликацию на стороне оригинальных данных, то есть данные резервных копий дедуплицируются еще до их передачи на хранение в репозиторий резервных копий. Это позволяет снизить нагрузку на канал, увеличить скорость работы и уменьшить окно резервного копирования. По этой причине в функционал многих дисковых СХД теперь входят функции интеграции с такими программными продуктами.
В настоящее время СХД, которые позиционируются как хранилища резервных копий, испытывают дополнительное конкурентное давление со стороны СХД, предназначенных для работы в качестве основных серверов продуктивной сети (Primary Storage), так как в них функционал дедупликации часто входит бесплатно.
Возникает логичный вопрос: а зачем тогда в настоящее время нужны специализированные Backup Target СХД и как их правильно применять? Если обобщить информацию от различных производителей таких СХД, они используют следующие три стратегии:
- Утверждают, что (в определенных условиях) дедупликация на Backup Target СХД имеет преимущества перед дедупликацией, встроенной в продукты резервного копирования;
- Позиционируют свои СХД не только как место хранения репозитория резервных копий, но и как возможное место хранения архива электронных документов организации;
- Включают программное обеспечение резервного копирования в комплект поставки своего СХД, или просто выполняют интеграцию своих СХД с программными продуктами резервного копирования (в том числе других производителей).
Рассмотрим первый пункт (какая дедупликация лучше?)
При сравнении аргументы производителей сводятся к сравнительному анализу коэффициентов дедупликации, продолжительности окон резервного копирования, итоговой эквивалентной емкости хранилищ и эффективности репликации. Однако фактически этот анализ сильно зависит от «факторов окружения» (то есть от условий эксперимента, и, если фактические условия у клиента будут отличаться от экспериментальных, то и результат измерения коэффициентов будет другой).
Например, возьмем коэффициент дедупликации. Здесь нужно правильно определить, что и как мы измеряем. Некоторые производители указывают, что их продукты обладают коэффициентом дедупликации уровня «30 к 1». Звучит, конечно, впечатляюще. Однако, в тоже время, другие производители указывают, что их продукт дает коэффициент дедупликации на порядок меньше, например, «3 к 1». Означает ли это, что продукты первых производителей лучше вторых? Нет, поскольку при расчетах оценивались разные наборы данных, в результате чего и получились такие разные коэффициенты дедупликации. То есть «коэффициент дедупликации», указанный как константа, — это скорее маркетинговый термин, так как у разных производителей он показывает дедупликацию разных данных, и на его основании нельзя сравнивать продукты, если только вы сами не можете попробовать на практике применить разные продукты на специально подготовленной одинаковом тестовом наборе данных. При этом в настоящий момент не существует какого-либо отраслевого (или хотя бы де-факто) стандарта для оценки коэффициента дедупликации. Скажем, в анти-вирусной индустрии есть т.н. стандартный эталонный тестовый вирус EICAR, который должен определяться любым антивирусом. Также и здесь мог бы быть создан тестовый эталонный набор данных, на котором и вычисляется коэффициент дедупликации у разных программных продуктов и СХД, но в реальности такого эталона нет.
Расхождение в сравнении коэффициентов дедупликации может наблюдаться также по причине существования разницы в алгоритмах самого процесса резервного копирования при использовании разных продуктов. Предположим используется программный продукт резервного копирования, и применяется схема с полной копией раз в неделю и инкрементальными копиями в остальные дни. Продукт выполняет дедупликацию и компрессию резервных копий. Теперь сравним это со случаем применения Backup Target СХД, которое, скажем, каждый раз получает полную копию дискового тома для сохранения, и которое выполняет дедупликацию перед сохранением данных на диск. Во втором случае коэффициент дедупликации будет значительно больше, а фактическая экономия дискового пространства репозитория резервных копий,- наоборот, значительно меньше.
Вместе с тем, именно сэкономленное за некий период времени дисковое пространство репозитория резервных копий (а не коэффициент дедупликации) и является в конечном счете самым правильным критерием сравнения средств дедупликации. Однако, заранее (перед покупкой) это выяснить, обычно, увы, нельзя.
"Эквивалентная емкость хранилища" (или размер хранилища, который требуется для сохранения данных без применения дедупликации) — это другой, но также чисто маркетинговый критерий, так как он основан на все том же коэффициенте дедупликации и вычисляется через него (производители просто умножают фактическую полезную емкость хранилища на коэффициент дедупликации). В итоге, используя один спорный коэффициент, получают другой спорный коэффициент.
Иногда используется коэффициент "эквивалентная производительность резервного копирования". Идея этого коэффициента подразумевает, что пользователь использует специальный программный клиент, который выполняет первичную дедупликацию на стороне исходных данных (для минимизации сетевого трафика), а потом отсылает данные на Backup Target СХД, где производится глобальная дедупликация этих данных (для минимизации занимаемого дискового пространства). Такие клиенты обычно устанавливаются на сервера баз данных, сервера приложений и на сервера резервного копирования. Эквивалентная производительность резервного копирования измеряемая в террабайтах в час, определяется как объем данных, фактически сохраненных на СХД за час и умноженных на… коэффициент дедупликации. Очевидно, что и в этом случае сравнение разных СХД по этому коэффициенту, если он указан в материалах на продукт, будет некорректным. Вместе с тем сама идея совмещения двух видов дедупликации (на стороне исходных данных и на стороне хранилища) является очень хорошей и может применяться ИТ-провайдерами при работе с разными клиентами, или внутри компании при централизованном резервном копировании распределенных серверов.
Только скорость передачи оригинальных данных может считаться объективной метрикой.
Стратегия №2 (Backup Target СХД как электронный архив)
Перепозиционирование Backup Target СХД как СХД, которые могут применяться не только для хранения репозитория резервных копий, но также и для хранения электронных архивов организации, — является хорошей идеей. Однако требования к СХД в этих двух случаях существенно различаются. Архивы, в отличие от бэкапов, в силу своей природы редко содержат дубликаты информации. Архивы должны предоставлять возможность быстрого поиска индивидуальных элементов, тогда как обращения к резервным копиям происходит сравнительно редко. Эти различия в требованиях указывают на то, что СХД для выполнения этих задач должны все же иметь разную архитектуру. Производители делают шаги в этом направлении, — например, меняют архитектуру файловой системы своих СХД, однако, тем самым, они двигаются по сути в сторону универсальной файловой системы и универсального СХД (а о конкуренции с универсальными СХД было уже указано выше).
Стратегия №3 (интеграция СХД с программными продуктами резервного копирования)
Что же касается идеи интегрировать программные продукты резервного копирования c СХД, то она выглядит очень разумной, если интеграция осуществляется не просто в маркетинговых материалах, а включает интеграцию на технологическом уровне. Например, СХД максимально эффективно делают аппаратные снапшоты своих дисков (получая минимально возможное на практике RPO, так как любая программная реализация от стороннего поставщика будет, скорее всего, медленнее). Вместе с тем, программные бэкап-продукты хорошо выполняют другие важные функции резервного копирования: построение репозитария и организацию длительного хранения резервных копий, выполнение процедуры тестирования бэкапов и быстрого восстановления данных в случае сбоя (минимизируя RTO). Такой технологический «симбиоз» между производителями программных продуктов резервного копирования и аппаратными СХД позволяет получать максимально эффективные для пользователя решения.
В качестве заключения
- За 10 лет произошла технологическая эволюция рынка продуктов и устройств с дедупликацией — они стали выгодно дополнять друг друга по функционалу. Произошло смещение от дедупликации на репозитории резервных копий к дедупликации на стороне исходных данных, или к комбинации подходов.
- Не нужно сравнивать эффективность дедупликации по «коэффициентам дедупликации» и производным от них метрикам, так как они сильно зависят от исходных данных, от характера их ежедневных изменений, от пропускной способности сети и других факторов «окружения».
- В настоящий момент при создании архитектуры инфраструктуры резервного копирования оптимально смотреть не отдельно на "аппаратные СХД с дедупликацией" и отдельно на "программные продукты резервного копирования", а на их интегрированные взаимодополняющие связки ПО+СХД
Дополнительные ссылки
- Введение в дедупликацию
- Дедупликация и компрессия резервных копий
- Veeam Explorer for SAN Snapshots: восстановление из аппаратных снимков HP SAN
- Deduplication 2013: Using target and source deduplication together
- Deduplication 2013: Source deduplication
- Deduplication 2013: Target deduplication
- WAN акселератор, встроенный в Backup & Replication v7.5
Автор: sysmetic
