В СМИ снова заговорили о строительстве подземных центров обработки данных. По информации «Ведомостей», Ростелеком рассматривает создание заглублённых ЦОДов с повышенной защитой от внешних угроз. А несколькими неделями ранее заместитель главы компании Валерий Ермаков говорил о необходимости резервных площадок, которые позволят восстанавливать цифровые сервисы даже при серьёзных повреждениях основной инфраструктуры.
Сама идея защищённого ЦОДа не нова. Подземные дата-центры существуют в разных странах, а вопросы их строительства упираются не только в стоимость, но и в особенности организации охлаждения, энергоснабжения и связи.
Однако в этой дискуссии нас заинтересовало другое. Для обеспечения катастрофоустойчивости всё больше внимания уделяется не только физической защите инфраструктуры, но и её распределённости, модульности и возможности быстро перераспределять нагрузку между независимыми площадками.
Защищённый ЦОД не гарантирует доступность сервисов
Даже самый защищённый дата-центр остаётся отдельной точкой инфраструктуры со своими зависимостями: энергоснабжением, внешними каналами связи, сетевым оборудованием, системами хранения данных и вычислительными мощностями.
Можно построить несколько уровней физической защиты, продублировать питание и сетевые подключения, но полностью исключить отказ всё равно невозможно.
Причём причиной недоступности может стать не только серьёзная авария. Ошибка при изменении маршрутизации, неудачное обновление, сбой системы хранения или нарушение сетевой связанности способны привести к остановке сервисов даже при полностью исправном оборудовании самого ЦОДа.
Поэтому при проектировании отказоустойчивой инфраструктуры важно ответить не только на вопрос «как предотвратить отказ?», но и на другой: «Что произойдёт с сервисами, если часть инфраструктуры всё-таки перестанет работать?»
Именно здесь возникает принципиальное различие между резервированием оборудования и катастрофоустойчивой архитектурой.
Резервное оборудование позволяет заменить вышедший из строя компонент. Распределённая архитектура при правильном проектировании позволяет продолжать обработку запросов на оставшихся ресурсах, не дожидаясь восстановления отказавшей части системы.
Модульность как основа устойчивой инфраструктуры
Традиционная модель построения ИТ-инфраструктуры часто предполагает концентрацию вычислительных ресурсов на нескольких крупных площадках. Такой подход удобен для управления и эксплуатации, но требует особенно тщательной проработки сценариев отказа.
Распределённая модель устроена иначе: инфраструктура состоит из отдельных компонентов, которые могут работать независимо друг от друга.
В случае отказа одного модуля остальные продолжают выполнять свои задачи. При необходимости нагрузку можно перераспределить между доступными узлами, а для увеличения мощности — добавить новые ресурсы.
При этом модульность сама по себе не гарантирует отказоустойчивость. Если все модули зависят от одного сетевого устройства, общей системы хранения или единого управляющего компонента, такая архитектура всё равно сохраняет критические точки отказа.
По-настоящему устойчивая система требует не только разделения компонентов, но и независимости их работы.
Именно поэтому при проектировании Балансировщика 5А мы с самого начала заложили два принципа: централизованное управление и децентрализованную обработку трафика.
Все кластеры балансировки управляются из единого интерфейса, при этом обработка трафика происходит непосредственно на независимых модулях балансировки. Управляющий контур не участвует в передаче каждого пользовательского запроса, поэтому его временная недоступность не останавливает работу уже настроенных сервисов.
Модули балансировки можно размещать на разных физических серверах, в виртуальной среде, на отдельных площадках и объединять в кластеры в зависимости от задач конкретной инфраструктуры.
Это позволяет независимо масштабировать обработку трафика и снижать зависимость доступности сервисов от состояния управляющей системы.
Что происходит с трафиком, когда выходит из строя целая площадка?
Представим инфраструктуру компании с двумя территориально распределёнными ЦОДами.
В каждом размещены собственные серверы приложений и модули балансировки. Для пользователей оба ЦОДа предоставляют доступ к одним и тем же корпоративным сервисам.
В нормальном режиме трафик может распределяться между площадками или направляться преимущественно в одну из них.
Но что произойдёт, если один ЦОД станет недоступен?
Наличие резервной площадки само по себе ещё не решает задачу. Необходимо определить, что основной сервис перестал работать, исключить недоступное направление из обработки запросов и перенаправить новые подключения туда, где сохранились работоспособные ресурсы.
Эту часть задачи решают механизмы балансировки и управления маршрутизацией.
В Балансировщике 5А для построения отказоустойчивых конфигураций предусмотрено несколько инструментов.
BGP и RHI (Route Health Injection) позволяют связывать доступность сервисов с сетевой маршрутизацией. Например, при недоступности обслуживаемого ресурса соответствующий маршрут может быть отозван, а трафик направлен по альтернативному пути.
VRRP используется для резервирования виртуального IP-адреса и переключения между узлами в подходящей сетевой топологии. Поддержка Unicast и Multicast расширяет варианты развёртывания в сетях с различными ограничениями.
GSLB (Global Server Load Balancing) решает задачу на уровне географически распределённой инфраструктуры. Система может учитывать состояние площадок, результаты проверок доступности, приоритеты и другие параметры, выбирая подходящее направление для новых клиентских подключений.
Эти механизмы работают на разных уровнях и не заменяют друг друга. Например, VRRP решает задачу резервирования внутри соответствующей сетевой среды, а GSLB помогает управлять распределением запросов между удалёнными площадками.
Балансировщик не делает всю инфраструктуру катастрофоустойчивой автоматически. Но он обеспечивает один из ключевых элементов такой архитектуры — управление тем, куда направляется пользовательский трафик при изменении доступности ресурсов.
Отказоустойчивость начинается с корректной диагностики
Для автоматического переключения мало определить, что сервер перестал отвечать на сетевом уровне.
В некоторых случаях сервер продолжает принимать соединения, но приложение уже не способно корректно обрабатывать запросы. Например, веб-сервер возвращает HTTP 200, хотя связанная с ним база данных недоступна или внутренний сервис работает с ошибками.
Если ориентироваться только на доступность порта, балансировщик будет продолжать направлять трафик на фактически неисправное приложение.
Поэтому для построения отказоустойчивых систем важны проверки состояния на разных уровнях.
В Балансировщике 5А для этого используется набор Health Checks — от сетевых проверок до анализа ответов приложений.
В том числе поддерживаются проверки HTTP/HTTPS, TCP, DNS, XML и SIP. Можно задавать критерии работоспособности сервиса и определять, когда узел следует исключить из балансировки или вернуть обратно.
Это позволяет учитывать не только состояние инфраструктурного компонента, но и способность приложения выполнять свою функцию.
И здесь есть важный момент: чем точнее система определяет отказ, тем меньше риск переключить трафик без необходимости или, наоборот, продолжить направлять запросы на неисправный сервис.
Катастрофоустойчивость — это ещё и вопрос экономики
Распределённая инфраструктура требует дополнительных ресурсов. Резервные узлы, площадки, сетевые подключения и системы хранения увеличивают стоимость проекта.
Поэтому при проектировании важно найти баланс между требованиями к доступности и затратами на её обеспечение.
Программная архитектура даёт больше вариантов размещения ресурсов. Вместо приобретения отдельного аппаратного балансировщика для каждого небольшого сервиса можно развернуть программные модули на доступных вычислительных мощностях и распределить их между нужными площадками.
В Балансировщике 5А такой подход дополнен моделью лицензирования по суммарной среднемесячной полезной пропускной способности.
Количество развернутых модулей и кластеров балансировки не определяет стоимость лицензии. Поэтому заказчик может изменять топологию, добавлять резервные узлы и перераспределять вычислительные ресурсы без приобретения отдельных лицензий на каждый новый экземпляр балансировщика.
Конечно, резервирование по-прежнему требует серверных и сетевых ресурсов. Но сама модель лицензирования не заставляет выбирать между дополнительным модулем отказоустойчивости и дополнительной лицензией на него.
Для территориально распределённых систем, где число точек размещения может увеличиваться, это особенно актуально.
От защиты инфраструктуры — к устойчивости сервисов
Обсуждение подземных ЦОДов хорошо показывает, как меняется подход к инфраструктурной надёжности.
Физическая защищённость площадок остаётся важной, особенно для критически значимых систем. Но даже хорошо защищённая инфраструктура должна быть готова к отказам отдельных компонентов, потере сетевой связанности и недоступности целых площадок.
И здесь всё большее значение приобретает архитектура: независимость компонентов, распределённая обработка нагрузки, автоматическое обнаружение отказов и управление маршрутизацией.
Мы придерживались этих принципов ещё в 2023 году, когда начинали разработку Балансировщика 5А. За прошедшее время существенно расширили возможности кластеризации, маршрутизации и построения отказоустойчивых конфигураций, сохранив основную идею — единое управление распределённой системой, отдельные компоненты которой способны работать независимо друг от друга.
Сегодня этот подход позволяет использовать Балансировщик 5А как один из компонентов отказоустойчивой инфраструктуры — от отдельных корпоративных сервисов до территориально распределённых систем с несколькими ЦОДами.
Если вы проектируете такую инфраструктуру, модернизируете существующие схемы резервирования или рассматриваете переход на программную балансировку, команда 5А готова помочь подобрать архитектуру под ваши требования к доступности, производительности и эксплуатации.
Подробнее о возможностях Балансировщика 5А можно узнать на нашем сайте и в технической документации.