#1 - Проект создания резервного ЦОДа для министерства здравоохранения Республики Бурятия.
#топпроектов

В текущих реалиях уже не получится детально обсудить техническую начинку проекта - время такое. Но основные ключевые технологии и принципы указать можно.

На этапе проектирования задача была поставлена в создании резервной площадки, на которую можно переключиться в случае недоступности основной не более чем за Х минут. Т.е. режим работы “Active-Standby”.
Забегая вперед скажу, что защищали и резервировали ресурсы только под конкретно обозначенные сервисы, поэтому часть ресурсов резервного ЦОДа могла использоваться под другую нагрузку, и мы не получили простаивающий большее время и пыхтящий в пустоту резервный ЦОД.

Ключевые технологические задачи, которые предстояло решить в рамках проекта:
🔊 синхронизация данных - репликация дисковой подсистемы
🔊 оркестрация площадок, перевод активной нагрузки - исключение режима “split-brain”, чтобы работа с данными велась только на одной площадке и всегда с актуальной версией данных
🔊 обеспечение сетевой связности внутренних и внешних пользователей до каждой площадки, и площадок между собой
🔊 управление потоками пользователей, чтобы они автоматически перенаправлялись на действующую в данный момент площадку.

Синхронизация данных
Для репликации между двумя СХД мы использовали внешнее устройство реплицирования, с оптимизацией передачи трафика по выделенному закрытому каналу между площадками. Для этого ставился специальный агент-сплиттер на SAN-коммутаторе, который каждую операцию записи на СХД отправлял на репликатор. На второй площадке аналогично.

Впервые я применял этот метод, но в итоге он себя полностью оправдал и отработал как часы.

Оркестрация
В качестве системы виртуализации на тот момент использовалась VMware vSphere, поэтому выбор VMware Site Recovery Manager в качестве оркестратора был вполне естественен. Собственно на нем были сынтегрированы все механизмы переключения, включая направления репликации СХД.

Обеспечение сетевой связности
Сеть в больших организациях всегда представляет из себя большой клубок связей 🙂
Поэтому задача хоть и сложная, но понятная.
Сложности здесь доставили различные защищенные сертифицированные системы туннелирования, и наличие мобильных пользователей со специфичными устройствами.

Главное помните, если соберетесь делать резервную площадку - не забудьте про дублирование всех каналов связи с основной 😉

Управление потоками пользователей
Ну и самый лакомый кусочек - это перенаправление пользователей, в том числе туннельных, на резервную площадку в автоматическом режиме, без изменения их настроек. Здесь мы задействовали класс DNS-балансировщиков с условными проверками и триггерами действий.

Вот где пришлось попотеть. Некоторые кастомные сервисы совсем не предполагают, что кто-то захочет их резервировать на разных площадках. А кто-то оставляет возможность работать только по 1му ip-адресу… Фу, такими быть 👎


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

Надо отдать должное действующей на тот момент ИТ-команде в заказчике - проектирование, согласование и реализация такого масштабного проекта без оперативного, ответственного и постоянного глубокого взаимодействия со специалистами заказчика - была бы невозможна. 🤝

—
Давайте об IT - @lets_about_it