Как устроены бекапы заказчиков в нашем дата-центре TierIII

Самое простое — наше 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» — мы делаем разными способами:

1. Есть прямая репликация между нашими облаками и частным облаком или инфраструктурой заказчика. Есть облака VMware, Hyper-V и KVM, куда данные могут напрямую реплицироваться средствами гипервизоров (например vSphere Replication). Это самый простой и доступный метод репликации.
2. Восстановление инфраструктуры из резервных копий в нашу облачную инфраструктуру. Здесь есть решения различных производителей. Есть Veeam Cloud Connect Replication, который позволяет реплицировать данные или бекапы по WAN-каналам в нашу инфраструктуру. В рамках нашего основного бекапного решения — Avamar — мы можем копировать и восстанавливать данные из разных сред — p2v, v2p, между разными облаками (например, Vmware в KVM, и наоборот).
3. Третье решение интереснее:

Некоторые наши заказчики попросили реплицировать своё железо (ОС) в наше облако на наши же виртуальные машины. Это как раз задача «выпавшего» офиса, когда клиент может взять и запустить нечто из своего бекапа прямо из облака минут за 10. Репликация с помощью ПО Zerto и Double-Take позволяет зеркалировать данные операционной системы и приложений по IP с минимальной задержкой. С технической стороны это выглядит как сервис, который запускается внутри операционной системы или гипервизора ESX и передаёт все изменения к нам в облако. С практической стороны — это возможность для клиента восстановить работоспособность приложения в минимально короткие сроки.

При подобном подходе мы, помимо технического решения, прорабатываем с заказчиками и Disaster Recovery-планы на случай аварийного восстановления. Так, чтобы заказчик сам мог в случае необходимости протестировать или осуществить восстановление части своих машин или инфраструктуру целиком.

Практика

Решению на базе Avamar уже лет 5, а CrocBackApp — есть пара примеров. Как-то к нам пришла одна розничная сеть, у которой централизованного бекапа по всей инфраструктуре не было, а возможностей «маленького», рассчитанного на отдельные офисы, не хватало. Железо и ПО везде было разное, а когда что-то падало, начинался цирк и зоопарк в попытках накатить всё обратно. Нет, это, в целом, работало, но каждый отдельный случай требовал компетенций сисадмина, имеющего 8-летний опыт работы с этой средой и точно знающего, что на каком археологическом слое лежит. Именно он заказывал у нас «кубики» CrocBackApp, чтобы раз и навсегда избавиться от этих кошмаров в регионах.
Потом пришли правительственные учреждения: у них данные не самые большие, но важные. У них наши «кубики» просто втыкаются в коммутаторы FC или Ethernet, и устанавливаются клиенты на все локальные машины. Дальше нужно только настроить расписание бекапов и план хранилища.

В итоге образовалась очень простая схема:

• Если бизнес с большим количеством офисов или же, наоборот, SMB, и не хочет/не имеет возможности установить отдельное железо локально — внедряем резервное копирование Avamar. Там довольно низкая стоимость хранения и нулевые первоначальные затраты. То есть OPEX маленький, а CAPEX равен нулю.
• Для тех, у кого есть возможность размещать оборудование на своих площадках, мы предлагаем CrocBackApp. OPEX меньше, чем с Avamar, но есть CAPEX.
• И для тех, у кого уже есть своя бекапная инфраструктура, предлагаем воспользоваться нашим S3 для организации удалённого хранения.

Ссылки

• Как работает корпоративный бекап на Авамаре ^[1]
• Моя почта — SerVerchenov@croc.ru

Автор: КРОК

Источник ^[2]