Катастрофоустойчивость

Катастрофоустойчивость — это способность инфраструктуры на базе Deckhouse Kubernetes Platform (DKP) сохранять работоспособность при масштабных сбоях. Такой результат достигается благодаря распределённому развёртыванию компонентов, автоматическому переключению трафика и репликации критически важных сервисов.

Платформа DKP поддерживает две основные модели обеспечения катастрофоустойчивости:

• Геораспределённость (Multi-AZ / Multi-Region): Подразумевает размещение элементов инфраструктуры в нескольких зонах доступности (AZ) или географических регионах. Такой подход минимизирует влияние локальных сбоев (например, отказа ЦОД) на работу приложений. Детальное описание доступно в разделе «Геораспределённость».
• Георезервирование (Multi-Cluster): Основывается на использовании двух и более независимых кластеров Kubernetes, объединённых в мультикластерную среду. В случае недоступности одного кластера пользовательский трафик автоматически перенаправляется в другой (резервный). Подробности изложены в разделе «Георезервирование».

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

Геораспределённость — это архитектурный подход в Deckhouse Kubernetes Platform (DKP), направленный на обеспечение катастрофоустойчивости. Он подразумевает размещение компонентов кластера в нескольких зонах доступности (Multi-AZ) или географических регионах (Multi-Region), что гарантирует бесперебойную работу даже при масштабных сбоях инфраструктуры.

Deckhouse Kubernetes Platform (DKP) поддерживает распределение узлов кластера по зонам доступности (Availability Zones). Это повышает отказоустойчивость приложений: даже при выходе из строя целой зоны в ЦОД или облаке сервисы продолжают работать.

Зона доступности (AZ) — фундаментальный элемент катастрофоустойчивой архитектуры. AZ представляет собой логическое объединение одного или нескольких дата-центров, расположенных на удалении в несколько километров друг от друга. Хотя физически это распределённая инфраструктура, с точки зрения управления AZ воспринимается как изолированный виртуальный ЦОД. Зоны доступности являются составной частью регионов.

Зоны доступности обладают следующими характеристиками:

• разнесение ЦОДов внутри одной AZ на достаточное расстояние (обычно ≤10 км) для защиты от локальных инцидентов (наводнение, пожар) при сохранении низкой сетевой задержки;
• независимое электроснабжение для компонентов, образующих зону доступности (разные электрические подстанции, дизель-генераторы и т.д.);
• использование компонентами зоны разных провайдеров и маршрутов;
• относительно низкая задержка внутри зоны.

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

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

Регион (Region) — это обособленная географическая территория, объединяющая несколько (минимум три) изолированных зон доступности (AZ). Несмотря на физическую распределённость, все AZ внутри региона управляются как единое целое и используют общую инфраструктуру управления. Регионы являются фундаментом глобальной архитектуры облачных провайдеров.

Мультирегиональные развёртывания (Multi-Region) эффективны только для приложений, способных работать автономно в каждом регионе, без необходимости частых обращений к серверам в других локациях. Причина — неизбежно высокие задержки (latency) между регионами. Типичные сценарии: размещение кеширующих серверов для CDN или узлов распределённого мониторинга.

Регионы характеризуются следующими особенностями:

• Задержки (latency): Внутри региона передача данных между зонами доступности (AZ) занимает около 5 мс. При обмене между регионами задержка возрастает до 50–200 мс.
• Географическая распределённость: Расстояние между регионами может достигать тысяч километров. Например, от europe-west3 (Франкфурт) до us-east-1 (Вирджиния) — примерно 6500 км.
• Физическая безопасность: Площадки для регионов выбираются с учётом сейсмической и политической стабильности.
• Энергонезависимость: Регионы обычно подключены к нескольким независимым национальным энергосетям. Например, me-central-1 (ОАЭ) запитаны от четырёх разных источников.

Для распределения узлов по регионам необходимо:

• маркировать каждый узел лейблом, указывающим регион;
• обеспечить стабильные каналы связи между регионами.

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

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

Георезервирование в Deckhouse Kubernetes Platform (DKP) — это метод обеспечения катастрофоустойчивости, при котором несколько независимых кластеров Kubernetes, разнесённых по разным географическим локациям, объединяются в единую мультикластерную систему.

Для организации такого объединения DKP предоставляет два основных инструмента:

• Встроенный сервисный mesh (Service Mesh) на базе Istio.
• Сетевые возможности платформы, основанные на Cilium.

Эти механизмы обеспечивают автоматическую маршрутизацию трафика (как внешнего, так и внутреннего) между кластерами: если приложение становится недоступно в одном регионе, запросы перенаправляются в другой, где работает его копия.

Чтобы воспользоваться этой функцией, необходимо развернуть кластер DKP в каждом задействованном регионе и объединить их через декларативный API. Ключевые условия для работы схемы:

Приложение должно поддерживать параллельную работу в нескольких регионах.

Между регионами требуется организовать стабильный сетевой канал.

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

Для обеспечения катастрофоустойчивости в мультикластере может быть реализована балансировка входящего трафика внешним балансировщиком по одной из схем: active-active или active-standby. Балансировка настраивается администратором кластера.

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

Особенности балансировки по схеме active-active:

• Все кластеры в мультикластере обрабатывают трафик одновременно.
• Трафик направляется в ближайший к клиенту, наименее загруженный кластер или используются иные правила.
• Общие данные реплицируются между кластерами.
• При сбое одного кластера трафик переключается на работающие (автоматический failover).

При использовании схемы active-standby внешний балансировщик направляет трафик в кластер, который активен в данный момент. Неактивный кластер является резервным, трафик в него будет направлен, если основной кластер будет недоступен.

Особенности балансировки по схеме active-standby:

• Активный кластер принимает весь трафик.
• Резервный кластер бездействует до момента сбоя основного.
• Переключение трафика с активного на резервный кластер (failover) происходит автоматически при обнаружении проблем.

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