Как создать резервную площадку? Какие технологии использовать? Как обойти ограничения бюджета? С этими вопросами мне пришлось столкнуться на деле в процессе организации площадки для аварийного восстановления.

А не построить ли нам… DRS

Наша компания занимается сервисным обслуживанием банковского оборудования (банкоматы, терминалы и т.п.), и в работе использует систему учета заявок. Скажем, у одного из клиентов вышел из строя банкомат – они создают заявку на нашем портале, и инженеры приступают к ремонту. Все инциденты и запросы на обслуживание стекаются в единую БД MySQL, там же отмечаются статусы работ и результат.

Все работало исправно, но однажды мы задумались о надежности системы в целом — если выйдет из строя серверная или случится еще какой катаклизм. Тут, понятно, все уже давно придумано, и нужно лишь подобрать удобное именно нам DR-решение. Но непросто выбрать что-либо без четкого понимания, с какими рисками боремся и где та грань, за которой спасительное DRS (Disaster Recovery Solution) превращается в бесполезный расход средств. Потому мы собрались с руководством на несколько встреч с целью понять, какой объем информации мы готовы потерять относительно безболезненно (RPO), и как долго можем заниматься восстановлением работоспособности сервисов (RTO).

На обсуждениях проекта было установлено, что максимальный допустимый RPO для бизнеса – не более суток; RTO – два часа. Меньше – лучше. Так как наша инфраструктура была в свое время полностью виртуализована на vSphere, решили использовать это преимущество и смотреть в сторону технологий репликации VM.

Больше DR, хороших и разных

Небольшое исследование показало, что работающих решений на рынке не так много, и наиболее известные из них – это VMware SRM и Veeam B&R. Первое подкупало мощными сценариями аварийного восстановления, зато второе было уже когда-то закуплено и не требовало от нашей сети слишком многого (не нужны СХД с аппаратной репликацией, толстые каналы WAN и прочие излишества). К тому же, последняя версия Veeam умела самостоятельно перенастраивать адресацию для Windows-машин и допускала некоторую автоматизацию сценария через PowerShell. В любом случае, продвинутые сценарии восстановления интересовали исключительно гипотетически, «на вырост».

Критичный участок инфраструктуры состоял из одного сервера ESXi в нашем ЦОД, на котором было запущено около десятка виртуальных машин. Все они должны были ежедневно реплицироваться на удаленную площадку, а одна из них – даже ежечасно. Дело в том, что на этой машине размещались базы MySQL со всей информацией по заявкам от клиентов. Так как на сервисные операции из всего интернет-канала приходилось около 10Mbps, то организовать ежечасную репликацию VM объемом ~40ГБ было непросто. К тому же, репликация VM предполагает дополнительные манипуляции с удалением снэпшотов, что подтормаживает виртуальную машину. Для исключения этих неудобств решили создавать дампы средствами MySQL. Тогда получался бы архив с БД, которую можно восстановить где угодно, даже без виртуализации.

В качестве резервной площадки решили попробовать облако IaaS. Технология на рынке уже довольно давно, и даже самые скептики у нас согласны с тем, что большинство «детских болезней» IaaS перерос. Для простоты интеграции с инфраструктурой искали поставщика, который тоже работал бы на VMware и при этом запрашивал разумный ценник. После продолжительного «гугления» остановились на облаке «ИТ-ГРАДа», где среди стандартных предложений по IaaS была услуга «Резервная площадка (DRS)».

А вот и Яндекс

Но дамп SQL все же с трудом пролезал в 10-мегабитный канал. Мрачные мысли о способах «выбить бюджет» на канал потолще прервал один коллега. Он вспомнил, что у нашего интернет-провайдера как раз доступен 100Mbps канал до сервисов Яндекса, и совершенно бесплатно. А что есть у Яндекса? Я.Диск – отличный промежуточный кэш для загрузки резервных копий в облако. Так мы сможем передавать 20ГБ архив на серверы Яндекса менее чем за полчаса! А забрать оттуда файлы в облако ИТ-ГРАД уже проще, благо канал у них практически не ограничен. Схему получившейся инфраструктуры можно посмотреть на рисунке:

Конечно, при реализации не обошлось без «граблей». Как выяснилось, любой удаляемый через клиент Я.Диска файл автоматически переносится в облачную корзину и занимает общий объем. Чтобы избежать переполнения, пришлось бы чуть ли не ежедневно чистить диск вручную. Решение подсказала документация на их API. Оказывается, при работе через WebDAV корзина не используется, и все удаления происходят безвозвратно. На всякий случай, привожу здесь наш скрипт с пояснениями:

echo off     rem Удаляем диски net use X: /DELETE /Y     rem Монтируем диски net use X: https://webdav.yandex.ru PASSWORD /USER:LOGIN     rem Перемещаем с Yandex на E     rem Удаляем файлы старше двух дней forfiles /P E:\BSS\backup1cpgsql /s /d -2 /c "CMD /c del /Q @FILE"     rem Перемещаем файлы с яндекса в it-grad move X:\backup1cpgsql\*.* E:\BSS\backup1cpgsql\     rem На всякий случай чистим папку, где хранятся временные файлы webdav - часто забивается del /F /Q "C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV\*"     rem Удаляем диски net use X: /DELETE /Y 

Еще с клиентом Яндекса на сервере-источнике порой случается странное, и он подвисает из-за перерасхода по месту. Причем, даже после очистки всего диска синхронизация не возобновляется. Чтобы это побороть, перезапускаем сервис Я.Диска скриптом:

echo off taskkill /IM YandexDisk.exe /F call: sleep 5 C:\Users\user\AppData\Roaming\Yandex\YandexDisk\YandexDisk.exe exit 

А в остальном связка вполне работоспособна и каких-то дополнительных сложностей не вызывает. Если Яндекс поправит подвисания клиента, то будет вообще здорово.

Nested виртуализация

При выборе DR решения мы в первую очередь интересовались технологиями репликации и программными решениями, сама площадка не особенно смущала. Но когда было выбрано ПО, нарисованы схемы и написана альфа-версия скриптов для MySQL и API Яндекса, выяснился один занятный нюанс. Наш IaaS-провайдер предоставляет доступ к инфраструктуре через VMware vCloud Director. Эту схему подключения поддерживает и Veeam B&R… вот только права на доступ к инфраструктуре нужны административные, для работы с vSphere на инфраструктурном уровне.

Здесь-то и родилась проблема: ни один провайдер в здравом уме не даст подобных прав своим клиентам. В общем, изящность решения была несколько нарушена Nested ESXi. Фактически, мы арендовали у ИТ-ГРАДа одну большую виртуальную машину, и в ней уже развернули собственный ESXi с инфраструктурой. По выделенным в облаке ресурсам эта VM равнялась сумме наших реплицируемых машин. Неудобств тут несколько:

1. Фактически, машине с Nested ESXi выделено меньше ресурсов, чем требуется. Из-за этого при аварии сначала потребуется выделить больше процессоров и памяти в облаке, а потом уже все запускать;
2. Нет большой кнопки «перенести все и сразу» — да, тот самый Recovery Plan у SRM. Что ж, мы об этом знали и пожертвовали в угоду простоте и бюджету;
3. Решение не такое изящное как хотелось бы — внутренний перфекционист негодует.

Еще пару слов стоит сказать о сетевом доступе к резервной площадке. Помните, к ней должны иметь возможность подключаться самые разные организации, без всяких перенастроек. Здесь мы решили вопрос так: внешний адрес портала привязан к сервису DynDNS, что позволяет получать корректный IP даже при его внезапной смене. Некоторые издержки из-за локальных DNS-кэшей клиентов все равно есть, но их время жизни обычно укладывается в наш RTO. Ах да, еще есть MX-записи, для которых так не сделать. Здесь решили проблему «в лоб» – создали дополнительные записи MX для адресов ИТ-ГРАД, с минимальным приоритетом.

Что дальше

Как и любой проект, наша резервная площадка предполагает некоторое развитие в будущем, возможны варианты.

• Прямое подключения к IaaS инфраструктуре через Veeam. Хотелось бы избежать вложенности, да и потери производительности при работе «VM из VM» все же наблюдаются.
• Перенести в облако копии наших бэкапов, дабы не хранить все в одном месте. Изучаем функциональность Veeam Cloud Connect, которую уже поддерживает наш IaaS-провайдер. Особенно интересно то, что в таком варианте можно использовать облачное хранилище в качестве части своей инфраструктуры — делать бэкапы прямо в облако, где они будут явно в большей сохранности. А восстановление возможно как на свою площадку, так и в то же облако (если это аварийное восстановление и основная площадка лежит).
• Прорабатываем вариант бюджетного выделенного канала до облака, чтобы исключить кэширующее звено Яндекса и сделать систему проще.

Вот такой опыт внедрения Disaster Recovery площадки на основе IaaS-решения у нас получился. Надеюсь, кому-то он поможет в аналогичной ситуации, или же натолкнет на дельные мысли.

Валентин Семенов, системный администратор BSS

ссылка на оригинал статьи http://habrahabr.ru/post/261757/