Как спасти серверную от падения метеорита?⁠⁠

Итак, мои дорогие любители высоких технологий, сегодня мы поговорим с вами о возможности спасти свои любимые серверы от КАТАСТРОФЫ, такой, например, как пожар, наводнение или уборщица. Рассмотрим мы, пожалуй, самый четкий вариант, чтоб все как у людей, гипервизор там, репликация данных, георезервирование и все такое. Но обо всем по порядку.

За каким хером нужен этот геморрой, спросите вы меня? Все очень просто. Представьте, что вы работаете одмином в компании, основным видом деятельности которой является, например, доставка еды или мониторинг запуска ракет из КНДР. Понятное дело, что сервисы такой серьезной конторы должны работать 24\7\365, и за падение сервака, на котором вся эта джигурда крутится, вас как минимум четвертуют. Оправданием для босса не станет даже то, что на серверную наступила Годзилла. Как быть в таком случае, ведь тут не спасет ни бэкап, ни запасной сервак. Правильно! Надо стоить DRS (Disaster Recovery System). Если по-русски, то это система аварийного восстановления.

По сути, все это стало возможным благодаря виртуализации, репликации и скорости сетей передачи данных. Давайте рассмотрим сценарий реализации катастрофоустойчивости на примере решения от VMware, тупо потому что это best practice. Если объяснять на пальцах, то выглядит все примерно так. Есть серверная или, например, стойка в ЦОДе, где крутится невообразимое количество архиважных виртуальных серверов. Есть другая серверная, которая, находится в далекой, далекой, галактике на удаленной площадке. Они соединены сетью, по которой в режиме реального времени происходит репликация данных. То есть в каждый момент времени удаленная площадка является близнецом основной рабочей. И тут происходит Unglücksfall!!! Метеорит попадает в здание ЦОДа! Доблестный Одмин просыпается среди ночи, бежит к ноуту, по удаленке заходит на живую резервную площадку, нажимает кнопку аварийного восстановления и через 10 минут все сервисы работают в штатном режиме, с того места где остановились. Magic! Что нужно чтобы реализовать такую красоту у себя? Как всегда, нужно немножко денег и мозгов (но это не точно).

Для примера возьмем стандартную схему, два кластера, каждый из которых состоит из двух серверов и одной СХД (Системы Хранения Данных). Чтобы на базе этого железа построить DRS, нам нужно соблюсти следующие условия:

- Разумеется, его святейшество, гипервизор ESXI должен стоять на всех серверах. Также необходимо чтобы в каждом кластере стоял Vcenter (то есть, в нашем случае их должно быть два).

- Должен быть установлен и настроен SRM (Site Recovery Manager), который и дает возможность организовать восстановление, если все пойдет через то самое место.

- Между СХД должна быть настроена репликация тех разделов, на которых хранятся виртуальные машины.

Если с установкой гипервизора и vCenter проблем скорее всего не будет, то при настройке SRM и СХД скорее всего придется плясать с бубном немного повозиться.

Начнем с СХД. На обоих девайсах лучше сделать одинаковую настройку, в том числе количество и размер разделов. Это не то чтобы необходимо, просто так будет удобнее. И, конечно, надо настроить репликацию и лучше, чтобы она была синхронной, если позволяет канал. После настройки СХД надо как-то познакомить ее с DRS, для этого на обе ВМ с vCenter устанавливается специальный драйвер SRA (Storage Replication Adapter). Делается это затем, чтобы SRM смог останавливать репликацию в момент запуска плана восстановления.

Самое интересное это настройка SRM. По сути это последний шаг, после многочисленных приготовлений. Вся настройка, конечно же, производится в vSphere (будь проклят веб клиент ее), необходимо будет:

Настроить менеджеры репликации, которые с помощью SRA получат доступ к СХД. Надо указать пароль, логин и адрес доступа.

- Прописать сопоставление ресурсов. Для того чтобы ВМ, переехав на другую площадку, оказались на своих местах и смогли пользоваться сетями и другими ништяками, короче, чтоб не потеряли связь с миром.

-Создать план восстановления, указав нужные ВМ.

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

Вот и все! Любой дурак справится!

Помимо борьбы с катастрофами, у этого инструмента есть еще один метод применения. Можно назвать это плановой миграцией. Например, при работах в ЦОДе, о которых известно заранее. При таком раскладе, админ все также заходит в vSphere, и запускает план восстановления. Машинки выключаются, репликация останавливается, и все это мирно запускается на удаленной площадке. Красота.

На последок.

Можно конечно устроить резервную площадку в облаке, у какого-нибудь сервис-провайдера, но это будет дешево и быстро, а значит бездуховно и лишено авантюризма и задора, в общем, не тру. Еще можно сделать руками все то, что делает SRM, но это займет гораздо больше времени, да и прокатит такая тема, когда ВМ всего штук десять, потом уже будет сложнее.

Я прям кармой чувствую негодование айтишников, которые говорят, что я много чего не написал. Ясен красен, цель была просто описать возможность, в общих, так сказать, чертах.!. Если будет интересно, буду дальше писать левой ногой о высоких (и не очень) технологиях.