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

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

Итак, если вам нужен надёжный бэкап, приходите к нам, у нас есть EMC Avamar и печеньки.

Автор: MBerezin