Когда интернет отключается — как выжить ЦОДу

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

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

Как отключение мобильного интернета влияет на связь между узлами в распределенных ЦОД?

Если используются LTE/5G как резервные или основные каналы, то связь между узлами просто теряется. Это нарушает синхронную репликацию, повышает риск split-brain — состояния, когда связь между узлами нарушается, каждый из них считает себя единственным и работает независимо. Такое разделение может привести к несогласованности данных, что снижает устойчивость кластеров в целом. 

Какие еще риски возникают для инфраструктуры и бизнеса при длительных отключениях?

Потеря связи означает недоступность удаленных филиалов, edge-серверов — тех, что находятся на периферии, максимально близко к пользователям, а также IoT-устройств. Пропадает out-of-band-доступ — резервный канал для администрирования, из-за чего невозможно управлять оборудованием. Администраторы вынуждены искать иные пути и нештатные решения. Например, подключают сторонние модемы, а это — риск утечки конфиденциальной информации и нарушения политики ИБ. Нарушается SLA, то есть договоренный уровень доступности сервисов, который компания обязана обеспечивать. Это особенно критично, если резервные каналы строились на мобильных сетях.

Какие в таком случае есть альтернативы?

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

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

Для бизнеса это значит, что сервисы продолжают работать без перебоев, а клиенты — получать услуги даже при нестабильной связи. Таким образом, критически важные функции не зависят от постоянного подключения, что повышает отказоустойчивость и обеспечивает непрерывность бизнес-процессов.

Какие еще особенности существуют у асинхронной репликации?

Синхронная перестает работать, так как требует постоянного подтверждения от вторичного узла. Асинхронная репликация позволяет задавать реалистичный RPO, то есть максимально допустимый объем потерянных данных в случае сбоя, не более 5-10 минут потерь, и продолжать работу даже в том случае, если канал недоступен часами и днями. Это особенно важно для регионов с нестабильной инфраструктурой — нагрузка на сеть снижается, а передача дельтов не нарушается. Получается компромисс между целостностью и доступностью.

Что значит «устойчивость» применительно к репликации в условиях обрывов связи?

Устойчивость — это про способность системы продолжать работу при потере соединения между узлами. Синхронная репликация при обрыве канала блокирует операции записи, поэтому система встает. При асинхронной узлы просто согласуют даные позже. Это и есть устойчивость — система живет дальше, даже если канал восстановят только через несколько часов. В конечно счете, асинхронная репликация не блокирует работу, гибко переносит сетевые перегрузки и задержки, будет работать даже при полном отсутствии канала. Это значит, что бизнес-процессы не останавливаются: сотрудники и клиенты продолжают работать с сервисами. 

Как на практике будет работать асинхронная репликация при отключении канала?

Для примера возьмем распределенный ЦОД и представим, что в регионе отключили связь. При синхронной репликации СХД не сможет подтвердить запись на вторичном узле. Основная площадка начнет ждать, приложение зависнет, нагрузка возрастет. Без альтернативного канала с низкой задержкой система может остановиться полностью. Как итог — нарушается SLA, а бизнес-процессы встают. 

При асинхронной репликации, напротив, запись на основной площадке подтверждается сразу. Как только связь восстановится, вторичный узел «догонит» основной. Таким образом, бизнес-процессы не блокируются.

Как устроена асинхронная репликация и за счет чего она обеспечивает непрерывность работы при потере связи?

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

В каких случаях арбитр может быть нужен даже при асинхронной репликации?

Арбитр необходим, когда есть риск split-brain. Например, при обрыве канала оба ЦОДа могут попытаться стать активными. Мы в ARGO.TECH подробно изучили российскую практику и пришли к выводу, что наличие арбитра даже при асинхронной репликации обязательно, так как это предотвращает разделение кластеров. Суть в том, что может потребоваться аварийный перевод нагрузки на DR-площадку. Арбитр, размещенный отдельно, например, в третьем дата-центре, дает однозначное решение, какая сторона имеет право активироваться. Это критично для автоматического failover в решениях вроде VMware SRM или HPE Peer Persistence. Таким образом, обеспечивается целостность группы.

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