Самое простое — наше S3-хранилище. В этом случае мы предоставляем только пространство, без какой-то логики и организации копирования. Дёшево, просто, надёжно, как удар дубинкой в темноте. В S3 умеют копировать большинство продуктов бекапа — Veritas NetBackup/Backup Exec, CommVault, Veeam, EMC Networker и др. Такое решение разворачивается за 2 часа.
Второй подход — полноценная инфраструктура резервного копирования. Мы даём заказчику фактически в аренду часть программно-аппаратного комплекса. И в этом случае заказчик получает не просто хранилку, а сервис резервного копирования целиком, включая программную организацию логики копирования. Например, если заказчик размещается в дата-центре на Волочаевской и пользуется услугой, то комплекс Avamar собирает бекапы из его инфраструктуры и делает как копию в этом же ЦОДе, так и копию на другую площадку при необходимости. Помимо этого, в системе есть внутренние средства защиты самого Avamar — cлепок системы снимается два раза в сутки, дедуплицируется, сжимается.
Все, конечно, отлично, но по объективным причинам (кризис все успели почувствовать) мы стали искать более бюджетные, но при этом функциональные варианты.
Начнём с Авамара, раз уж упомянули
Для решения задач хранения резервных копий за пределами локальной инфраструктуры мы установили ПАК EMC Avamar. Схема классическая: на копируемые машины устанавливается клиентское приложение, оно интегрируется с операционной системой и программным обеспечением, собирает данные, дедуплицирует их и отправляет в наш ЦОД. Копирование всегда инкрементальное: вначале система делает полную копию данных, а потом только изменяющиеся блоки (обычно это 1-3% от общего объёма). Это позволяет значительно снизить нагрузку на канал и уменьшить окно резервного копирования. С точки зрения доступа — это синтетические полные резервные копии.
Плюсы:
- быстрое копирование за счёт дедупликации и сжатия;
- хорошая цена;
- возможность восстановления в инфраструктуре нашего дата-центра на виртуальные машины;
- гарантия восстановления: это массив на RAIN-архитектуре с защитами от выхода из строя дисков/полок и внутренними проверками консистентности данных. Это более надёжный носитель для хранения информации, чем обычный ленточный картридж — не в последнюю очередь поэтому он был выбран нами как основное облачное хранилище;
- затраты на бекап растут по мере роста требований, а не скачками с капитальными затратами;
- минимум беспокойства и работ по поддержке со стороны заказчика. Мы совместно с заказчиком осуществляем стартовую настройку, а также мониторим статус работы системы (это бесплатно);
- подходит для тех, кто не может покупать ПО и железо от иностранных поставщиков.
В ЦОДе «Компрессор» развёрнута инфраструктура, включающая ПАК Avamar и интегрированная с vcloud (одно из плеч облачной инфраструктуры КРОК) и облаком КРОК (облачное решение на основе KVM).
Минусы:
- резервное копирование и восстановление на локальной площадке полностью зависит от качества интернет-канала.
Заказчикам часто бывает нужно что-то маленькое в бекапе, например, отдельное удалённое вчера письмо, какой-то конкретный файл или что-то ещё. Довольно глупо раскатывать весь образ из-за файла «1.txt», который пользователь случайно перезаписал на своём рабочем столе. ПАК Авамар предоставляет администраторам ПО удобную консоль и хороший GUI для работы с файлами приложений и пользователей. Они сами могут находить и восстанавливать данные, не дёргая админа резервного копирования. Естественно, права доступа разграничены.
Дёшево и сердито
Оценивая разные варианты реализации, мы постепенно пришли к ещё одному решению — когда в инфраструктуру заказчика отдаём готовое бекапное решение под ключ:
CrocBackApp — это сервер с большой дисковой ёмкостью и возможностью подключения внешних дисковых полок, на который установлен CommVault, который мы OEM’им. По желанию заказчика серверы можно кластеризовать в одном шасси, да и вообще построить почти любое архитектурное решение под нужды заказчика.
По мере тестирования выяснилось ещё одно важное преимущество такого решения: простота настройки и интеграции в корпоративную среду. То есть заказчик берёт железо с нашим установленным CrocBackApp, просто ставит к себе на площадку, запускает, устанавливает с помощью визарда клиентов на защищаемые машины — и оно работает.
Плюс мы добиваемся вкусных скидок за счёт объёмов закупки железа и ПО — если пробовать собрать или приобрести у крупных вендоров такое решение самостоятельно, получится дороже.
Наравне с задачей хранения резервных копий на удалённой площадке еще одна часто встречающаяся задача — организация не только резервных копий, но и гибкой инфраструктуры в удалённом ЦОДе, которую в час икс можно оперативно поднять. И здесь мы предлагаем заказчику уже не «Backup-as-a-Service», а фактически «Disaster Recovery-as-a-Service». Привлекательность услуги в том, что в штатном режиме заказчик платит фактически только за хранение и передачу данных в удалённый ЦОД, а в случае необходимости — начинает потреблять инфраструктуру целиком, причем может восстановить её за считанные минуты.
Подобную услугу — «Disaster Recovery-as-a-Service» — мы делаем разными способами:
- Есть прямая репликация между нашими облаками и частным облаком или инфраструктурой заказчика. Есть облака VMware, Hyper-V и KVM, куда данные могут напрямую реплицироваться средствами гипервизоров (например vSphere Replication). Это самый простой и доступный метод репликации.
- Восстановление инфраструктуры из резервных копий в нашу облачную инфраструктуру. Здесь есть решения различных производителей. Есть Veeam Cloud Connect Replication, который позволяет реплицировать данные или бекапы по WAN-каналам в нашу инфраструктуру. В рамках нашего основного бекапного решения — Avamar — мы можем копировать и восстанавливать данные из разных сред — p2v, v2p, между разными облаками (например, Vmware в KVM, и наоборот).
- Третье решение интереснее:
Некоторые наши заказчики попросили реплицировать своё железо (ОС) в наше облако на наши же виртуальные машины. Это как раз задача «выпавшего» офиса, когда клиент может взять и запустить нечто из своего бекапа прямо из облака минут за 10. Репликация с помощью ПО Zerto и Double-Take позволяет зеркалировать данные операционной системы и приложений по IP с минимальной задержкой. С технической стороны это выглядит как сервис, который запускается внутри операционной системы или гипервизора ESX и передаёт все изменения к нам в облако. С практической стороны — это возможность для клиента восстановить работоспособность приложения в минимально короткие сроки.
При подобном подходе мы, помимо технического решения, прорабатываем с заказчиками и Disaster Recovery-планы на случай аварийного восстановления. Так, чтобы заказчик сам мог в случае необходимости протестировать или осуществить восстановление части своих машин или инфраструктуру целиком.
Практика
Решению на базе Avamar уже лет 5, а CrocBackApp — есть пара примеров. Как-то к нам пришла одна розничная сеть, у которой централизованного бекапа по всей инфраструктуре не было, а возможностей «маленького», рассчитанного на отдельные офисы, не хватало. Железо и ПО везде было разное, а когда что-то падало, начинался цирк и зоопарк в попытках накатить всё обратно. Нет, это, в целом, работало, но каждый отдельный случай требовал компетенций сисадмина, имеющего 8-летний опыт работы с этой средой и точно знающего, что на каком археологическом слое лежит. Именно он заказывал у нас «кубики» CrocBackApp, чтобы раз и навсегда избавиться от этих кошмаров в регионах.
Потом пришли правительственные учреждения: у них данные не самые большие, но важные. У них наши «кубики» просто втыкаются в коммутаторы FC или Ethernet, и устанавливаются клиенты на все локальные машины. Дальше нужно только настроить расписание бекапов и план хранилища.
В итоге образовалась очень простая схема:
- Если бизнес с большим количеством офисов или же, наоборот, SMB, и не хочет/не имеет возможности установить отдельное железо локально — внедряем резервное копирование Avamar. Там довольно низкая стоимость хранения и нулевые первоначальные затраты. То есть OPEX маленький, а CAPEX равен нулю.
- Для тех, у кого есть возможность размещать оборудование на своих площадках, мы предлагаем CrocBackApp. OPEX меньше, чем с Avamar, но есть CAPEX.
- И для тех, у кого уже есть своя бекапная инфраструктура, предлагаем воспользоваться нашим S3 для организации удалённого хранения.
Ссылки
- Как работает корпоративный бекап на Авамаре
- Моя почта — SerVerchenov@croc.ru
Комментарии (6)
tzong
26.05.2016 14:39Авамар всё-таки каждый раз делает Full бэкап (а не инкремент, как написано в статье), просто за счёт дедупликации на источнике и наличии локального для клиента кэша блоков, в сеть уходит только то, что отсутствует в кэше, что положительно сказывается на сетевом трафике и по логике больше похоже на инкремент.
SerVerchenov
26.05.2016 16:46Абсолютно верное замечание. Дело в вопросе наименования этого процесса. Формально это «full backup», но чтобы отделить это понятие от настоящего полного бэкапа, использующегося, например, в продукте EMC Networker, EMC стала использовать понятие «forever incremental», внеся этим некоторую путаницу. В данном случае название не столь важно, как понимание самого механизма резервного копирования.
ComputerPers
26.05.2016 14:48И не расписано как S3 построен :-(
SerVerchenov
26.05.2016 16:47Оба решения по резервному копированию не используют S3. Хранилище S3 — это отдельная тема, которую мы периодически освещаем. Например, из недавнего: https://habrahabr.ru/company/croc/blog/277011/статью.
navion
Как всегда без цен и скорости восстановления с deduplication appliance.
SerVerchenov
Для Avamar скорость восстановления фактически определяется каналом и сетью до заказчика. Скорость бэкапа, на которую тут можно ориентироваться — 1000000 файлов в час — это скорость обработки хэшей, скорость дедупа. А что касается цены – она сильно зависит от инфраструктуры и обстоятельств.