Компания
244,20
рейтинг
9 августа 2012 в 14:03

Разное → Правильный бэкап в ЦОДе


EMC Avamar в ЦОД КРОК

Вот этот здоровенный шкаф из нескольких серверов называется EMC Avamar. Он стоит у нас в дата-центре, занимается резервным копированием, и делает это очень интересно.

Что внутри шкафа?


Технологически – это блок x86-серверов, сейчас их 10 штук. Архитектура следующая: есть запасной узел и узел управления, а на остальные 8 пишутся данные. Учитывая избыточность (принцип кода Хэмминга, равномерное распределение RAIN – Redundant Array of Independent Nodes), при выходе из строя любого из узлов, данные сохраняются. Запасной узел в этот момент заменяет убитый. Итого в системе непосредственно используется только 50% каждого узла — резервный узел, узел четности и вторая половина уходит на нужды обеспечения сохранности данных. Физическая ёмкость массива 200 Тб превращается в 62,5 Тб.

На каждом из узлов стоит ОС SUSE Linux и специализированное проприетарное ПО — серверная часть комплекса. Узлы объединены между собой внутренними коммутаторами, изолирующими внешний трафик резервного копирования от внутреннего служебного трафика.

Структура одиночного узла — 12 дисков, 6 из которых содержат основные данные, ещё 6 — зеркалируют их (RAID1), плюс ssd диск для ОС.



Откуда бэкапим?


Основное назначение EMC Avamar – «горячий» бэкап боевой системы из разных источников:
  1. Из «облака» («облако» в ЦОДе, в «облаке» виртуальные сети, а с них можно бэкапиться).
  2. Физических серверов в других стойках.
  3. С виртуальных машин и физических серверов инфраструктуры заказчика, протянувшего свой кабель в ЦОД или через Интернет.




Какие преимущества у Avamar?


Особые приметы шкафа таковы:

1. Дедупликация. Данные хранятся мелкими блоками, и повторяющиеся данные сохраняются как ссылки на блок. Если вы грузите 50 разных текстовых документов, которые по сути своей являются разными версиями одного документа, или сделаны на базе единого шаблона, то в процессе дедупликации документы бьются на большое кол-во блоков переменной длины. Причем большинство их этих блоков повторяются, так как в основу каждого из документов вошло много информации из родственных документов. Все повторяющиеся блоки заменяются ссылка, которые практически “невесомы”. Это позволяет сжимать резервные копии файлов до 500 раз, как заявляет производитель. На практике у наших заказчиков мы наблюдаем показатель 15-20 кратной компрессии файлов за счет дедупликации.

2. Одна из самых крутых вещей именно этого программно-аппаратного комплекса – дедупликация на источниках. То есть если с вашего сервера делается бэкап, определение тех кусков, которые надо по факту переслать, выполняется не после анализа «прилетевших» данных уже на Avamar, а непосредственно на месте, на самих хостах. Это значит что первый бэкап составляет 100% объёма базы (например, 2 Тб), а второй, третий и последующий на практике – около 0,1% — то есть примерно по 200 Мб (фактически — инкрементальная копия). Бэкап удалённого офиса, огромной базы или ещё чего-то подобного за минуту – это просто сказка.

3. Совместимость с разным ПО. Конкретно – с основными ОС и прикладным ПО. Зачем она нужна? Представьте себе боевую базу данных, где в минуту проводятся тысячи транзакций. Если начать копировать её «в лоб», то от момента начала копирования до момента конца копирования база изменится — и в бэкап попадут неактуальные, ошибочные и удалённые данные. За час может пройти миллион транзакций – и вы получите отличную кашу из данных, которую не восстановить даже руками. Поэтому нужна софтина-агент, которая сделает слепок базы («заморозит» её для бэкапа) и начнёт копировать этот слепок. Кроме того, агент сжимает данные и шифрует их при передаче. Волшебный шкаф, как у нас, приезжает сразу с полным набором агентов.

Общая схема решения:


С чем конкретно есть совместимость?


Системное ПО:
  • Microsoft Windows;
  • HP-UX;
  • IBM AIX;
  • Oracle Solaris;
  • Novell Netware;
  • SUSE Linux;
  • Red Hat Enterprise Linux;
  • Apple Macintosh OS X;
  • Free BSD;
  • VMware ESX/ESXi.
Прикладное ПО:
  • Oracle и Oracle RAC;
  • Microsoft SQL Server;
  • Microsoft Share Point;
  • Microsoft Exchange;
  • IBM DB2;
  • IBM Lotus Domino и т.д.

Как это можно использовать?


  • Дополнительный бэкап. Поставляется как услуга ещё одного резервного бэкапа: учитывая удобство, переход всех капитальных затрат в операционные, географическую удалённость и полную автоматизацию — пользуется большим спросом для хранения почти любых данных.
  • Основной бэкап (с ограничениями). Для такого применения нужны или широкие каналы, или не очень большие объёмы данных — в противном случае придётся жертвовать скоростью восстановления (ведь на накатывании бэкапа 100% базы пойдёт по каналам обратно, что может быть очень долго для удалённых боевых систем).
  • Основной бэкап без ограничений. Это достаточно необычное решение КРОКа. Работает так: в вашем ЦОДе развёрнута инфраструктура, в нашем ЦОДе стоит EMC Avamar. Бэкап на него делается по вашему стандартному каналу интернета. Мы ставим в ваш ЦОД ещё один сервер – «мини-Avamar» — виртуальный appliance. «Мелкий» будет синхронизироваться с «папой» и хранить у себя последнии копии (самые актуальные для откатывания). Более старые копии (редко нужные для быстрого бэкапа) хранятся на основной площадке. Этот appliance не надо покупать: он тоже оплачивается per use, то есть все затраты — операционные. Схема работы решения приведена ниже.



Возвращаясь к стоимости всего решения у нас на площадке — да, она действительно высокая. Но эта стоимость делится на много заказчиков, и из-за такого «коммунального» режима стоимость для отдельного заказчика снижается. Данные полностью изолированы друг от друга: вы видите только свои бэкапы.


Скриншот интерфейса заказчика

Кто и как применяет?


У нас есть несколько интересных кейсов. Названия компаний упоминать, к сожалению, не могу, пока вот так:
  • Одна коммерческая компания, часто делающая финансовые транзакции, бэкапит у нас Oracle.
  • Крупная госкомпания хранит бэкапы виртуальных машин из своего «облака».
  • Страховая компания тестирует решение в качестве основного бэкапа.


Почему это надежно и удобно?


  1. Удалённое хранение. Эта штука находится далеко от основной инфраструктуры (может быть в другом машзале, в другом ЦОДе (в случае подключения инфраструктуры к нашему ЦОДу), то есть, как минимум, не там, где развёрнуты боевые машины). Это значительное снижение риска потери всей информации разом.
  2. Данные хранятся на дисках. EMC Avamar – не традиционная ленточная библиотека, используемая в таких случаях, а дисковый массив, то есть сохранность информации – выше.
  3. Продаётся это как сервис pay-per-use, то есть погигабайтно за хранилище. В конце месяца делается выгрузка по объёму данных в учетке заказчика — получается сумма к оплате. Это «облачный подход» и это удобно: капитальные затраты переходят в операционные.
  4. Техподдержка аутсорсится. Причём это нормальная поддержка интегратора: не «FAQ-линия», а полноценное решение рабочих вопросов до результата.


Итак, если вам нужен надёжный бэкап, приходите к нам, у нас есть EMC Avamar и печеньки.
Автор: @MBerezin
КРОК
рейтинг 244,20

Комментарии (27)

  • +3
    А что будет с бэкапами, если что-то случится с EMC Avamar у вас в цоде — взрыв/пришельцы/цунами...?
    Есть ли резервирование самой EMC-шки?
    • 0
      Сейчас мы запускаем второе наше облако во втором ЦОД. Планируем установить второй рядом со вторым облаком. Это позволит размещать основные данные в облаке, а резервные в удаленном ЦОД на втором Авамаре и даст репликацию между двумя Авмарами.
  • –1
    EMC Avamar может делать только блочную дедупликацию или файловую тоже?
    • +2
      А зачем делать файловую (высокоуровневую) если делается блочная (низкоуровневая)?
      Блочная предоставляет в большинстве случаев гораздо более высокое качество сжатия, чем файловая.
    • +2
      Сначала делает файловую, потом блочную.
      • 0
        А дедупликация inline или offline?
        • 0
          Inline с переменным размером блока.
  • 0
    Интересно, зачем такая избыточность? И еще интересно, почему на узлах Raid 1 а не 10? При той же избыточности он по-моему даст бОльшую надежность.
    • +1
      А по моему в посте как раз описан Raid10:
      Структура одиночного узла — 12 дисков, 6 из которых содержат основные данные (Raid0?), ещё 6 — зеркалируют их (RAID1)
  • +1
    Пробовали ли уже восстанавливаться из этих бэкапов? Как скорость восстановления, если что-то сломалось?
    • 0
      Да, делается полный откат, время восстановления зависит от пропускной способности каналов. Если объект в том же ЦОДе — достаточно быстро.
  • +4
    А как на счет шифрования бэкапа? Ведь вроде как получается решение не индивидуальное, да еще и удаленное, имеет смысл шифровать бэкапы, нет?

    И, если я правильно понимаю, то в случае, если бэкап шифруется, дедупликация, по сути своей, перестает работать?
    • +1
      Шифрование, действительно, крайне негативно сказывается на дедупликации, поэтому нет смысла ее применять – вся фишка пропадает и решение будет дорогим. Да и смысла в этом нет – сохраняются блоки данных, из которых, при хищении дисков, на практике невозможно собрать что-то без функционала Avamar. Однако, есть возможность шифрования данных при передаче уже после дедупликации во избежание их кражи из канала.
  • 0
    Дорого и неэффективно. НетАпп выглядит более привлекательно на этом фоне.
    • +3
      Нетапп для другого совсем, это неправильно сравнивать.
  • +1
    1) Какой размер блока для дедупликации? Если он переменный, то как определяются блоки, которые уже имеют дубликаты?
    2) Дедупликация на источниках — какой footprint возникает на источнике?
    • 0
      Длина блока переменная. Алгоритм разбиения на блоки работает таким образом, что результат разбиения одних и тех же данных идентичен. Новые данные образуют новые блоки. На источнике хранится кэш уже переданных файлов и блоков, сначала сравнение идет с ним, потом с глобальным кэшем (на сервере), если данные не найдены ни там ни там, то они передаются по сети. Размер кэша изменяется по итогам каждого бэкапа. Использование оперативной памяти в момент бэкапа для выполнения расчетов по умолчанию ограничено, так как решение рассчитано в том числе для бэкапа рабочих станций.
      • 0
        Получается, что дедупликация выполняется «поклиентно», а не к примеру в рамках вольюма (от всех клиентов)?
        Если да, то получается дубликаты отсутствуют среди данных одного клиента, а если смотреть глобально, то присутствуют?
    • 0
      Средний размер 24К. Точки «разреза» потока данных определяются патентованным алгоритмом, который при вставлении в середину новых данных с большой вероятностью разрежет блоки так, что новые данные образуют один или несколько новых блоков, а границы старых при этом не изменяются, поэтому их не нужно заново бэкапить.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Наши сервисы, в основном, рассчитаны на юридических лиц.
  • +2
    Денег-то сколько?
  • –3
    Не нашел в топике случаев успешного и сверхудачного восстановления.
    Можно зарейдить-1 хоть миллион зеркал, но смысла из этого будет ноль, если нет методики восстановления. Вы базу MSSQL забэкапите? А MySQL? А редулоги? А накатите обратно? А контроллер домена авторитативно? А виртуальные машины vSphere, Hyper-V? А 1С в конце-то концов?
    Миллион скорости и миллиард емкости это прекрасно, но не тогда, когда под рукой нет дизэстер рекавери плана.
    • 0
      Тут всё-таки упор на платофрму, а не прикладное ПО, которое позволит автоматизировать план фйеловера и фейлбэка. У ЕМС есть клиенты для разного типа ПО для обеспечения правильного бекапа и восстановления.
  • 0
    Сколько денег хотите?
    • 0
      Новое поколение, смотрю, на Dell PowerEdge делается? На фотографии справа R510 сервер.
      • 0
        Абсолютно верно, в данной конфигурации в качестве узлов хранения используются Dell PowerEdge R510.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное