По мере роста активности программ-вымогателей, таких как Petya или BadRabbit, а также в связи с ужесточением требований законодательства (например, как раз вступившим в силу №187-ФЗ «О защите критической информационной инфраструктуры») объемы данных для резервного копирования постоянно увеличиваются. В результате растет стоимость инфраструктуры хранения резервных копий. Такие технологии как Erasure Coding могут кардинально снизить затраты на их хранение. Сегодня мы расскажем насколько именно и о том, как построить Backup на базе Erasure Coding.
Про коды Рида-Соломона, как наиболее эффективный метод хранения больших объемов информации в программно-определяемых СХД (software-defined storage — SDS), говорили и писали уже очень много. Но резервное копирование – это один из идеальных сценариев для использования Erasure Coding (EC), так как резервная копия представляет собой большой по объему файл, который записывается и читается последовательно. Несмотря на все большее распространение SDS, их не так часто используют для хранения резервных копий, так как SDS по умолчанию используют традиционную репликацию для защиты пользовательских данных, что требует в 2 или 3 раза больше места на дисках по сравнению с «чистым» объемом информации. Как следствие, такое решение задачи крайне неэффективно.
В распределенных системах хранения, к которым относится и наш Virtuozzo Storage, а также любые современные программно-определяемые СХД, для каждого блока данных создается одна или две копии, и все они размещаются на разных серверах в зависимости от нагрузки, близости к источнику данных и других факторов, влияющих на производительность и отказоустойчивость. При использовании Erasure Coding данные разбиваются на несколько блоков, распределяются между узлами кластера. Кроме этого создаются две или три контрольные суммы, что дает возможность так же, как и при использовании реплик, сохранить данные даже при отказе двух серверов или дисков одновременно, но при этом сэкономив дисковое пространство, уменьшая избыточную емкость в несколько раз.
Например, при наличии кластера из 5 северов, для того, чтобы обезопасить себя от выхода из строя двух из них, вам потребуется использовать либо 3 реплики в случае репликации, либо Erasure Coding по схеме 3 (блока) +2 (хеша). Допустим, вы сохраняете 100ГБ, тогда ваши данные вместе с репликами займут целых 300ГБ, а при использовании EC эта емкость будет сокращена примерно до 170ГБ. И чем больше в вашем кластере серверов, тем больше вы экономите места. Например, в случае кластера из 20 серверов, избыточное использование диска будет всего лишь около 20%.
Да, в некоторых сценариях использование Erasure Coding ведет к снижению производительности приложений, но, как оказалось, в случае резервного копирования все наоборот – это приводит к увеличению скорости создания резервной копии. И учитывая, что в коммерческих решениях Erasure Coding часто является платной опцией, а производительность его все еще остается под вопросом, далеко не все решаются попробовать программно-определяемую СХД для хранения резервных копий. И мы сейчас покажем, что совершенно напрасно.
И все же, что там с производительностью?
Мы провели тестирование скорости резервного копирования при использовании Erasure Coding в двух конфигурациях – на кластере #1, состоящем из 6 узлов и на кластере #2, составленном из 12 узлов. Применение схемы Erasure Coding происходило на базе стандартного функционала Virtuozzo Storage, а конфигурации серверов были следующими:
В первом кластере, который был запущен на 6 узлах, разместились 42 жестких диска (chunk service), по 7 дисков в каждом сервере. Мы использовали стандартные диски SATA со скоростью вращения шпинделя 7200 об/мин. Для каждого из них был создан журнал на SSD дисках NVMe по 32 Гб (всего 224 ГБ на сервер), а размер клиентского кэша для данного кластера составил 64 ГБ на каждую точку монтирования. В качестве ПО резервного копирования мы использовали встроенное решение из Virtuozzo 7.
Результаты измерений показали, что пропускная способность такого кластера из 6 узлов для задачи резервного копирования при использовании Erasure Coding оказывается в 1,6 раза выше по сравнению с традиционной репликацией.
По мере увеличения кластера эффект только усиливается, даже если вы берете более производительные жесткие диски. Так, кластер #2 состоял уже из 12 узлов, в каждом из которых было расположено по 11 высокоскоростных дисков SAS со скоростью вращения шпинделя 15 000 об/мин. В связи с этим был уменьшен размер журналов на SSD дисках NVMe (16 ГБ на chunk service или 176 ГБ на узел). Однако результаты показали, что пропускная способность (а значит и скорость) резервного копирования в кластере оказалась втрое выше при использовании EC, чем при репликации данных.
Почему так происходит? На самом деле ответ прост: в отличие от других, быть может, более сложных задач, резервное копирование представляет собой фактически последовательную запись данных (Sequential write). И в случае с EC кластеру нужно записать меньше лишних данных. При использовании стандартной схемы репликации с 3 репликами требуется трижды записать информацию (оригинальный блок и две копии), а Erasure Coding записывает всего на 20% больше данных, чем размер исходного файла. И чем больше будут потоки данных, тем более заметным окажется эффект от использования Erasure Coding.
Более того, в распределенных системах хранения именно сетевые интерфейсы часто оказываются самым узким местом. Ведь канал в 1 Гбит/с может обеспечить передачу данных со скоростью 110-120 Мбайт/с, что приблизительно соответствует возможностям только одного жесткого диска при последовательной записи/чтении. Поэтому использование EC оправдывает себя как средство повышения эффективности кластера, снижая нагрузку на сетевую подсистему именно в сценариях резервного копирования. Для хранения небольших объемов не высоко востребованных данных можно использовать сетевые адаптеры 1 Гбит/с, хотя для продуктивных нагрузок мы, конечно, рекомендуем сетевые адаптеры 10 Гбит/с.
Используйте бесплатно
Вопрос с производительностью решен – Erasure Coding действительно справляется с резервным копированием быстрее, чем репликация, при этом существенно экономя дисковое пространство, а значит – ресурсы серверов, дисков и сетевых портов. Сколько это стоит? В случае с Virtuozzo Storage вы можете использовать Erasure Coding бесплатно – он включен в нашу стандартную лицензию. Erasure Coding это всего лишь опция при создании тома данных для контейнеров и виртуальных машин Virtuozzo, iSCSI, NFS или объектного хранилища. Если у вас уже используется Virtuozzo Storage, включить EC можно моментально и сразу же получить все преимущества от использования технологии. А если вы используете Virtuozzo вместе с Virtuozzo Storage, то и само ПО резервного копирования уже включено в вашу лицензию.
Как мы смогли убедиться на примерах, приведенных выше, при необходимости защищать большие объемы данных, Erasure Coding помогает одновременно и сэкономить, и уменьшить время, затрачиваемое на создание резервных копий. Если же вы активно используете объектное хранение, например, Amazon S3-совместимый Object Storage, то Erasure Coding тем более становится лучшим выбором для такого рода нагрузок. И не забывайте, никто не отменял возможность одновременно использовать репликацию для наиболее горячих данных.
Про коды Рида-Соломона, как наиболее эффективный метод хранения больших объемов информации в программно-определяемых СХД (software-defined storage — SDS), говорили и писали уже очень много. Но резервное копирование – это один из идеальных сценариев для использования Erasure Coding (EC), так как резервная копия представляет собой большой по объему файл, который записывается и читается последовательно. Несмотря на все большее распространение SDS, их не так часто используют для хранения резервных копий, так как SDS по умолчанию используют традиционную репликацию для защиты пользовательских данных, что требует в 2 или 3 раза больше места на дисках по сравнению с «чистым» объемом информации. Как следствие, такое решение задачи крайне неэффективно.
В распределенных системах хранения, к которым относится и наш Virtuozzo Storage, а также любые современные программно-определяемые СХД, для каждого блока данных создается одна или две копии, и все они размещаются на разных серверах в зависимости от нагрузки, близости к источнику данных и других факторов, влияющих на производительность и отказоустойчивость. При использовании Erasure Coding данные разбиваются на несколько блоков, распределяются между узлами кластера. Кроме этого создаются две или три контрольные суммы, что дает возможность так же, как и при использовании реплик, сохранить данные даже при отказе двух серверов или дисков одновременно, но при этом сэкономив дисковое пространство, уменьшая избыточную емкость в несколько раз.
Например, при наличии кластера из 5 северов, для того, чтобы обезопасить себя от выхода из строя двух из них, вам потребуется использовать либо 3 реплики в случае репликации, либо Erasure Coding по схеме 3 (блока) +2 (хеша). Допустим, вы сохраняете 100ГБ, тогда ваши данные вместе с репликами займут целых 300ГБ, а при использовании EC эта емкость будет сокращена примерно до 170ГБ. И чем больше в вашем кластере серверов, тем больше вы экономите места. Например, в случае кластера из 20 серверов, избыточное использование диска будет всего лишь около 20%.
Да, в некоторых сценариях использование Erasure Coding ведет к снижению производительности приложений, но, как оказалось, в случае резервного копирования все наоборот – это приводит к увеличению скорости создания резервной копии. И учитывая, что в коммерческих решениях Erasure Coding часто является платной опцией, а производительность его все еще остается под вопросом, далеко не все решаются попробовать программно-определяемую СХД для хранения резервных копий. И мы сейчас покажем, что совершенно напрасно.
И все же, что там с производительностью?
Мы провели тестирование скорости резервного копирования при использовании Erasure Coding в двух конфигурациях – на кластере #1, состоящем из 6 узлов и на кластере #2, составленном из 12 узлов. Применение схемы Erasure Coding происходило на базе стандартного функционала Virtuozzo Storage, а конфигурации серверов были следующими:
В первом кластере, который был запущен на 6 узлах, разместились 42 жестких диска (chunk service), по 7 дисков в каждом сервере. Мы использовали стандартные диски SATA со скоростью вращения шпинделя 7200 об/мин. Для каждого из них был создан журнал на SSD дисках NVMe по 32 Гб (всего 224 ГБ на сервер), а размер клиентского кэша для данного кластера составил 64 ГБ на каждую точку монтирования. В качестве ПО резервного копирования мы использовали встроенное решение из Virtuozzo 7.
Результаты измерений показали, что пропускная способность такого кластера из 6 узлов для задачи резервного копирования при использовании Erasure Coding оказывается в 1,6 раза выше по сравнению с традиционной репликацией.
По мере увеличения кластера эффект только усиливается, даже если вы берете более производительные жесткие диски. Так, кластер #2 состоял уже из 12 узлов, в каждом из которых было расположено по 11 высокоскоростных дисков SAS со скоростью вращения шпинделя 15 000 об/мин. В связи с этим был уменьшен размер журналов на SSD дисках NVMe (16 ГБ на chunk service или 176 ГБ на узел). Однако результаты показали, что пропускная способность (а значит и скорость) резервного копирования в кластере оказалась втрое выше при использовании EC, чем при репликации данных.
Почему так происходит? На самом деле ответ прост: в отличие от других, быть может, более сложных задач, резервное копирование представляет собой фактически последовательную запись данных (Sequential write). И в случае с EC кластеру нужно записать меньше лишних данных. При использовании стандартной схемы репликации с 3 репликами требуется трижды записать информацию (оригинальный блок и две копии), а Erasure Coding записывает всего на 20% больше данных, чем размер исходного файла. И чем больше будут потоки данных, тем более заметным окажется эффект от использования Erasure Coding.
Более того, в распределенных системах хранения именно сетевые интерфейсы часто оказываются самым узким местом. Ведь канал в 1 Гбит/с может обеспечить передачу данных со скоростью 110-120 Мбайт/с, что приблизительно соответствует возможностям только одного жесткого диска при последовательной записи/чтении. Поэтому использование EC оправдывает себя как средство повышения эффективности кластера, снижая нагрузку на сетевую подсистему именно в сценариях резервного копирования. Для хранения небольших объемов не высоко востребованных данных можно использовать сетевые адаптеры 1 Гбит/с, хотя для продуктивных нагрузок мы, конечно, рекомендуем сетевые адаптеры 10 Гбит/с.
Используйте бесплатно
Вопрос с производительностью решен – Erasure Coding действительно справляется с резервным копированием быстрее, чем репликация, при этом существенно экономя дисковое пространство, а значит – ресурсы серверов, дисков и сетевых портов. Сколько это стоит? В случае с Virtuozzo Storage вы можете использовать Erasure Coding бесплатно – он включен в нашу стандартную лицензию. Erasure Coding это всего лишь опция при создании тома данных для контейнеров и виртуальных машин Virtuozzo, iSCSI, NFS или объектного хранилища. Если у вас уже используется Virtuozzo Storage, включить EC можно моментально и сразу же получить все преимущества от использования технологии. А если вы используете Virtuozzo вместе с Virtuozzo Storage, то и само ПО резервного копирования уже включено в вашу лицензию.
Как мы смогли убедиться на примерах, приведенных выше, при необходимости защищать большие объемы данных, Erasure Coding помогает одновременно и сэкономить, и уменьшить время, затрачиваемое на создание резервных копий. Если же вы активно используете объектное хранение, например, Amazon S3-совместимый Object Storage, то Erasure Coding тем более становится лучшим выбором для такого рода нагрузок. И не забывайте, никто не отменял возможность одновременно использовать репликацию для наиболее горячих данных.
Комментарии (6)
claymen
22.01.2018 23:30А вот какая программа может использовать дедупликацию на уровне создания домашнего архива? Сделал архив, добавляем несколько изменившихся файлов(помним про Петю) нам нужны несколько версий, так вот что бы дописалось дедуплицированное изменеие?
Пользовал Duplicati, но хочется проще и забросили они её…
rahs
24.01.2018 18:50Лучше напишите, как бэкапить сам virtuozzo storage.
Gummio_7 Автор
24.01.2018 18:50Не сталкивались с задачей бекапить Virtuozzo Storage. Обычно все-таки есть задача бекапить инстансы, которые на нем работают. В этом случае есть варианты, зависящие от того, от чего вы защищаетесь. Если вы предоставляете backup-as-a-service для ваших пользователей, то можно бекапить на сам Storage, но на специально выделенный для этого datastore. Если вы защищаетесь от потери данных в результате собственных проблем, то тогда нужно бекапить, либо на отдельный Virtuozzo Storage, либо на любую внешнюю отдельную СХД. Второй вариант бекапа мы рекомендуем делать всегда и его всегда и делают, а backup-as-a-service – по желанию. Обе задачи можно реализовать с помощью нашего встроенного бекапа.
rahs
26.01.2018 12:08«Бэкапить инстансы» — имеется ввиду, как физические узлы, с агентом и заданием для каждого?
Встроенный бэкап настолько убог по функционалу, что я с трудом представляю ситуации, когда его действительно можно использовать
rt3879439
В тэгах не хватает ceph.