#1 - Проект создания резервного ЦОДа для министерства здравоохранения Республики Бурятия.#топпроектов
В текущих реалиях уже не получится детально обсудить техническую начинку проекта - время такое. Но основные ключевые технологии и принципы указать можно.
На этапе проектирования задача была поставлена в создании резервной площадки, на которую можно переключиться в случае недоступности основной не более чем за Х минут. Т.е. режим работы “Active-Standby”.
Забегая вперед скажу, что защищали и резервировали ресурсы только под конкретно обозначенные сервисы, поэтому часть ресурсов резервного ЦОДа могла использоваться под другую нагрузку, и мы не получили простаивающий большее время и пыхтящий в пустоту резервный ЦОД.
Ключевые технологические задачи, которые предстояло решить в рамках проекта:🔊
синхронизация данных - репликация дисковой подсистемы
🔊
оркестрация площадок, перевод активной нагрузки - исключение режима “split-brain”, чтобы работа с данными велась только на одной площадке и всегда с актуальной версией данных
🔊
обеспечение сетевой связности внутренних и внешних пользователей до каждой площадки, и площадок между собой
🔊
управление потоками пользователей, чтобы они автоматически перенаправлялись на действующую в данный момент площадку.
Синхронизация данныхДля репликации между двумя СХД мы использовали внешнее устройство реплицирования, с оптимизацией передачи трафика по выделенному закрытому каналу между площадками. Для этого ставился специальный агент-сплиттер на SAN-коммутаторе, который каждую операцию записи на СХД отправлял на репликатор. На второй площадке аналогично.
Впервые я применял этот метод, но в итоге он себя полностью оправдал и отработал как часы.
ОркестрацияВ качестве системы виртуализации на тот момент использовалась VMware vSphere, поэтому выбор VMware Site Recovery Manager в качестве оркестратора был вполне естественен. Собственно на нем были сынтегрированы все механизмы переключения, включая направления репликации СХД.
Обеспечение сетевой связностиСеть в больших организациях всегда представляет из себя большой клубок связей 🙂
Поэтому задача хоть и сложная, но понятная.
Сложности здесь доставили различные защищенные сертифицированные системы туннелирования, и наличие мобильных пользователей со специфичными устройствами.
Главное помните, если соберетесь делать резервную площадку - не забудьте про дублирование всех каналов связи с основной 😉
Управление потоками пользователейНу и самый лакомый кусочек - это перенаправление пользователей, в том числе туннельных, на резервную площадку в автоматическом режиме, без изменения их настроек. Здесь мы задействовали класс DNS-балансировщиков с условными проверками и триггерами действий.
Вот где пришлось попотеть. Некоторые кастомные сервисы совсем не предполагают, что кто-то захочет их резервировать на разных площадках. А кто-то оставляет возможность работать только по 1му ip-адресу… Фу, такими быть 👎
В общем проект состоялся, и на тот момент это был один из самых сложных моих интеграционных проектов. Который получилось с нуля запроектировать и реализовать.
Надо отдать должное действующей на тот момент ИТ-команде в заказчике - проектирование, согласование и реализация такого масштабного проекта без оперативного, ответственного и постоянного глубокого взаимодействия со специалистами заказчика - была бы невозможна. 🤝
—
Давайте об IT - @lets_about_it 
