Docker Swarm на трёх континентах: высокая доступность, рассчитанная на аптайм 100 %

Сервер в одном дата-центре остаётся единой точкой отказа, какими бы хорошими ни были оборудование и сеть. Если площадка выходит из строя, например из-за проблем с электропитанием, сбоя сети или просто ошибки во время технического обслуживания, приложение становится недоступным. Docker Swarm в нескольких дата-центрах решает именно эту проблему: контейнеры работают на трёх независимых площадках, в идеале на трёх континентах, и если одна из них полностью отказывает, работу берут на себя две другие, а пользователи ничего не замечают.

В этой статье пошагово показано, как построить кластер Docker Swarm, рассчитанный на аптайм 100 %: по одному серверу в Северной Америке, Европе и Азии, зашифрованная сеть WireGuard между узлами, кворум менеджеров, который переживает отказ целого континента, своя точка входа в каждом регионе и DNS-failover, автоматически направляющий пользователей на ближайшую исправную площадку. Кроме того, мы честно объясняем, что может отказать даже при такой архитектуре и как закрыть и эти риски.

Можно ли с Docker Swarm достичь аптайма 100 %?

Docker Swarm на трёх континентах рассчитан на аптайм 100 %: ни отдельный сервер, ни отдельный дата-центр, ни отдельный континент не может в одиночку остановить приложение. И всё же абсолютную доступность не может гарантировать никто, даже крупные облачные провайдеры, которые в лучшем случае обещают от 99,99 до 99,999 %. Причина не в дата-центрах, а в том, что у всех площадок общее. Именно это статья тоже разбирает, чтобы вы приблизились к 100 % настолько, насколько это технически возможно.

Что означает доступность в цифрах

Расчёт сделан для 8760 часов в году и 730 часов в месяце. Каждая дополнительная девятка сокращает допустимое время простоя в десять раз, и именно здесь начинается работа, которая одному серверу уже не под силу.

Почему три континента дают так много

Три независимые друг от друга площадки с доступностью 99,9 % каждая по расчёту отказывают одновременно только тогда, когда все три выходят из строя в одно и то же время: произведение 0,1 % × 0,1 % × 0,1 % равно 0,0000001 %. Чем дальше площадки друг от друга, тем независимее они на самом деле: свои энергосети, свои сетевые подключения, своя погода, свои окна обслуживания. Поэтому распределение по Северной Америке, Европе и Азии представляет собой самую сильную форму отказоустойчивости, которую можно построить на серверах.

Что может отказать даже при трёх континентах

Оставшиеся риски связаны с зависимостями, общими для всех площадок, и против каждой из них есть контрмера:

• Ошибочное обновление кластер разносит по всем площадкам так же надёжно, как и удачное. Контрмера: health checks и автоматический откат, а также обновление регион за регионом.
• DNS остаётся той единственной точкой, через которую приходят все пользователи. Контрмера: DNS-провайдер с распределённой по всему миру сетью и failover, короткий TTL.
• База данных должна содержать одни и те же данные на всех площадках. Контрмера: репликация с автоматическим переключением, подробнее в разделе о данных.
• Истёкшие сертификаты и домены затрагивают все площадки одновременно. Контрмера: автоматическое продление и контроль сроков действия.
• Само переключение длится, пока не отреагируют health checks и DNS, обычно от одной до двух минут, и за это время отдельные запросы могут завершаться ошибкой. Контрмера: короткие интервалы проверки, короткий TTL и клиенты, которые повторяют неудачные запросы.

Обзор архитектуры

Docker Swarm на нескольких континентах состоит из шести компонентов. Каждый из них устраняет определённую точку отказа:

Сколько менеджеров и где?

Узлы-менеджеры в Swarm управляют состоянием кластера по алгоритму консенсуса Raft. Любое изменение требует согласия большинства менеджеров, так называемого кворума. Если большинство потеряно, уже запущенные контейнеры продолжают работать, но кластер не может ни перераспределять задачи, ни компенсировать отказы, ни раскатывать обновления.

Docker рекомендует нечётное число менеджеров и распределение минимум по трём зонам: при трёх менеджерах в соотношении 1-1-1, при пяти в соотношении 2-2-1. Отсюда следует главное правило этой статьи: двух площадок недостаточно. При двух площадках на одной из них неизбежно оказывается больше менеджеров, и если откажет именно она, большинство будет потеряно. Только с тремя площадками кворум переживает отказ любого дата-центра, а при трёх континентах, соответственно, отказ целого континента.

Три континента или один: взвешиваем варианты

Любое изменение в кластере, любое развёртывание и любое перепланирование контейнера ждут подтверждения от большинства менеджеров. Между Европой, Северной Америкой и Азией каждое такое подтверждение занимает время прохождения пакета, примерно от 80 до 250 миллисекунд. Для пользователей это не имеет значения, потому что их запросы обрабатываются локально; однако развёртывания и перепланирования занимают заметно больше времени, чем в кластере с короткими маршрутами.

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

Какие локации KernelHost подходят

KernelHost эксплуатирует серверы в дата-центре maincubes во Франкфурте-на-Майне и предлагает виртуальные серверы в других локациях в Европе, Северной Америке и Азиатско-Тихоокеанском регионе, в том числе в трёх локациях в США, в Канаде, Лондоне, Страсбурге, Варшаве, Хельсинки, Сингапуре, Японии, Сиднее и Мумбаи. Полный список с картой находится на странице Локации серверов. Для примера в этой статье мы берём Франкфурт-на-Майне для Европы, восточное побережье США для Северной Америки и Сингапур для Азии.

Руководство: как построить Docker Swarm на трёх континентах

В примере используются три сервера: swarm-eu во Франкфурте-на-Майне, swarm-us на восточном побережье США и swarm-asia в Сингапуре. Публичные адреса взяты из сети для документации 203.0.113.0/24, сеть WireGuard использует 10.10.0.0/24. Замените и то и другое своими значениями. Все три узла одновременно работают и как менеджеры, и как worker-узлы; для большей производительности позже добавьте в каждом регионе узлы, работающие только как worker.

Шаг 1: разворачиваем серверы на трёх континентах

Закажите три сервера с Debian 12 или 13 в трёх регионах и настройте базовую защиту: SSH только по ключу, автоматические обновления безопасности, отдельные учётные записи пользователей. Всё это охватывает чек-лист для нового root-сервера. Задайте говорящие имена хостов, чтобы в docker node ls сразу было видно, какой узел где находится.

hostnamectl set-hostname swarm-eu

Шаг 2: устанавливаем Docker на все узлы

Установите Docker Engine из официального репозитория Docker на все три сервера, как описано в статье Установка Docker в Debian и Ubuntu. Затем проверьте версию на каждом узле, у всех трёх должна быть одна и та же мажорная версия:

docker version --format '{{.Server.Version}}'

Шаг 3: строим сеть WireGuard между континентами

Узлы общаются друг с другом через публичный интернет. Чтобы весь трафик кластера был зашифрован, а порты Swarm никогда не были доступны извне, три сервера соединяет сеть WireGuard. Сначала создайте на каждом узле пару ключей:

apt-get install -y wireguard
umask 077
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key

Затем на каждом узле создаётся файл /etc/wireguard/wg0.conf. На swarm-eu он выглядит так, на двух других узлах он устроен зеркально:

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = ЗАКРЫТЫЙ_КЛЮЧ_SWARM_EU
MTU = 1420

[Peer]
PublicKey = ОТКРЫТЫЙ_КЛЮЧ_SWARM_US
Endpoint = 203.0.113.12:51820
AllowedIPs = 10.10.0.2/32
PersistentKeepalive = 25

[Peer]
PublicKey = ОТКРЫТЫЙ_КЛЮЧ_SWARM_ASIA
Endpoint = 203.0.113.13:51820
AllowedIPs = 10.10.0.3/32
PersistentKeepalive = 25

systemctl enable --now wg-quick@wg0
ping -c 3 10.10.0.2

Если все узлы отвечают по своим адресам 10.10.0.x, сеть готова. PersistentKeepalive держит соединение открытым даже за файрволами с отслеживанием состояния. Задержки, которые ping сейчас показывает между континентами, и есть то время ожидания, которого стоит каждое изменение в кластере.

Шаг 4: файрвол пропускает только узлы Swarm

Для работы Docker Swarm между узлами нужны порт 2377/TCP для управления кластером, порт 7946/TCP и UDP для связи узлов друг с другом и порт 4789/UDP для overlay-сети. Эти порты разрешайте исключительно на интерфейсе WireGuard, публично открытым остаётся только сам WireGuard, и то лишь для других узлов. С ufw на swarm-eu это выглядит так:

ufw allow from 203.0.113.12 to any port 51820 proto udp
ufw allow from 203.0.113.13 to any port 51820 proto udp
ufw allow in on wg0 to any port 2377 proto tcp
ufw allow in on wg0 to any port 7946
ufw allow in on wg0 to any port 4789 proto udp

Важно: порты, которые Docker публикует для контейнеров, обходят ufw, потому что Docker прописывает собственные правила iptables. Поэтому публикуйте только порты точки входа (80 и 443) и никогда не публикуйте порты баз данных или управления.

Шаг 5: инициализируем Swarm и добавляем менеджеры

На swarm-eu инициализируйте Swarm так, чтобы и управление, и трафик данных шли через WireGuard:

docker swarm init --advertise-addr 10.10.0.1 --data-path-addr 10.10.0.1
docker swarm join-token manager

Вторая команда выводит команду присоединения для дополнительных менеджеров. Выполните её на swarm-us и swarm-asia, каждый раз с собственным адресом WireGuard узла, ниже пример для swarm-us:

docker swarm join --token SWMTKN-1-... --advertise-addr 10.10.0.2 --data-path-addr 10.10.0.2 10.10.0.1:2377
docker node ls

После этого docker node ls показывает три узла: один со статусом Leader, два других со статусом Reachable. Токен присоединения является секретом: тот, кто его знает, может внедрить в ваш кластер собственный менеджер. После завершения настройки обновите его командой docker swarm join-token --rotate manager.

Шаг 6: включаем Autolock

Менеджеры хранят состояние кластера вместе с ключами, которыми зашифрованы журналы Raft, в каталоге /var/lib/docker/swarm/. С Autolock шифруются и сами эти ключи, а перезапущенный менеджер снова присоединяется к кластеру только после ввода ключа разблокировки:

docker swarm update --autolock=true
docker swarm unlock

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

Шаг 7: назначаем узлам метки регионов

Метки сообщают планировщику, где находится узел. На них опираются правила размещения в следующих шагах:

docker node update --label-add region=eu swarm-eu
docker node update --label-add region=us swarm-us
docker node update --label-add region=asia swarm-asia

Шаг 8: создаём overlay-сеть с подходящим MTU

Контейнеры на разных площадках общаются друг с другом через overlay-сеть. Поскольку она проходит через туннель WireGuard, её MTU должен быть меньше: WireGuard работает с 1420 байт, из них overlay-сеть (VXLAN) забирает 50 байт на собственные заголовки, остаётся 1370 байт:

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1370 appnet

Слишком большой MTU проявляет себя коварно: маленькие запросы проходят, а большие ответы зависают. Если вы обходитесь без WireGuard, overlay-сеть можно вместо этого зашифровать с помощью --opt encrypted; тогда между узлами нужно дополнительно разрешить IP-протокол 50 (ESP), а Docker прямо предупреждает о заметном снижении производительности. Мы рекомендуем WireGuard, потому что он охватывает весь трафик, включая управление.

Шаг 9: запускаем приложение в каждом регионе

Обычный сервис Swarm распределяет запросы, приходящие на его адрес, по всем репликам в кластере, то есть и на другие континенты. При трёх континентах каждый второй или третий запрос отправлялся бы через полмира. Поэтому в каждом регионе создаётся собственный сервис, который правило размещения удерживает в пределах его региона. Благодаря настройкам обновления новые версии раскатываются контейнер за контейнером, а при ошибках автоматически откатываются:

for r in eu us asia; do
  docker service create --name web-$r --replicas 2 --network appnet \
    --constraint node.labels.region==$r \
    --update-parallelism 1 --update-delay 30s \
    --update-failure-action rollback \
    registry.example.com/web:1.0
done

Чтобы Swarm понимал, действительно ли контейнер работает, а не просто запущен, в образ нужно встроить health check, например такой строкой в Dockerfile вашего приложения:

HEALTHCHECK --interval=10s --timeout=3s --retries=3 CMD wget -qO- http://127.0.0.1:8080/health || exit 1

Контейнер, у которого health check трижды подряд завершается неудачей, заменяется, а во время обновления неудачный health check останавливает раскатку.

Шаг 10: своя точка входа в каждом регионе

Роль точки входа выполняет reverse proxy, например Caddy, Traefik или nginx. Он тоже работает в каждом регионе как отдельный сервис и передаёт запросы только приложению своего региона. В режиме host он публикует порты 80 и 443 прямо на сервере своего региона. Достаточно одной общей конфигурации, потому что Caddy берёт адрес назначения из переменной окружения:

example.com {
    reverse_proxy {$UPSTREAM}:80
}

docker config create caddyfile ./Caddyfile
for r in eu us asia; do
  docker service create --name edge-$r --network appnet \
    --constraint node.labels.region==$r \
    --env UPSTREAM=web-$r \
    --config source=caddyfile,target=/etc/caddy/Caddyfile \
    --publish mode=host,target=80,published=80 \
    --publish mode=host,target=443,published=443 \
    caddy:2
done

Всем регионам нужен TLS-сертификат для одного и того же домена. Поэтому получайте сертификаты через DNS-challenge, который работает независимо от того, на какой регион сейчас указывает DNS-запись; для этого Caddy нужен модуль вашего DNS-провайдера. Основы работы с прокси описаны в статье Настройка nginx как reverse proxy.

Шаг 11: настраиваем Geo-DNS с failover

Последний компонент направляет пользователей в нужный регион. DNS-сервис с геомаршрутизацией и health checks отправляет пользователей из Европы во Франкфурт-на-Майне, из Америки на восточное побережье США, а из Азии в Сингапур. Если регион отказывает, health check обнаруживает это за время от 30 до 60 секунд и направляет его пользователей в ближайший исправный регион. Задайте для записей время жизни (TTL) 60 секунд, чтобы резолверы быстро подхватывали переключение. Несколько A-записей без health check годятся лишь как вынужденная мера: браузеры, правда, часто пробуют следующий адрес, но так поступает не каждый клиент, а отказавший регион остаётся в ответе.

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

Шаг 12: тестируем отказ региона

Failover, который ни разу не проверяли на практике, в настоящей аварии срабатывает редко. Смоделируйте отказ региона, выведя его узел из работы, и понаблюдайте, как реагируют кластер и DNS:

docker node update --availability drain swarm-asia
docker node ls
docker service ls
docker node update --availability active swarm-asia

Поскольку сервисы региона привязаны правилом размещения к своему узлу, они не переезжают, а приостанавливаются; пользователей региона берёт на себя DNS-failover. Поэтому в этом тесте проверяйте прежде всего, убирает ли health check регион из ответов и выдерживает ли соседний регион дополнительную нагрузку. Для более жёсткого теста полностью отключите узел от сети, например остановив WireGuard. Повторяйте тест после крупных изменений и не реже одного раза в квартал.

Данные: самая сложная часть высокой доступности

Docker Swarm реплицирует контейнеры, а не данные. Том всегда лежит на узле, на котором запущен контейнер. Поэтому сервисы без состояния, такие как веб-фронтенды и API, без проблем работают в каждом регионе, а для всего, что хранит данные, нужна собственная репликация.

Репликация баз данных между континентами

У баз данных есть собственная репликация, и она всегда предпочтительнее общего хранилища, растянутого между дата-центрами. Между континентами хорошо зарекомендовала себя схема с первичным экземпляром в одном регионе и асинхронными репликами в двух других: для PostgreSQL, например, потоковая репликация с инструментом вроде Patroni для автоматического переключения, для MariaDB и MySQL встроенная репликация. Запросы на чтение тогда каждый регион обслуживает локально, а запись идёт на первичный экземпляр. Честно говоря, асинхронность означает и вот что: если первичный регион отказывает, записи за последние секунды могут быть потеряны. Кому нужно писать по всему миру и ничего не терять, тот выбирает базы данных, созданные для работы в нескольких регионах, например CockroachDB или YugabyteDB. Узлы баз данных жёстко привяжите правилом размещения к их региону, чтобы Swarm никогда не перенёс их без их данных:

docker service create --name db-asia --constraint node.labels.region==asia ...

Файлы и загрузки

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

Сессии и кэши

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

Резервные копии по-прежнему обязательны

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

Эксплуатация: обновления, обслуживание и мониторинг

Обновления регион за регионом

Раскатывайте новые версии не во всех регионах одновременно, а по очереди, и немного понаблюдайте за каждым регионом, прежде чем переходить к следующему. Так ошибка, которую не распознаёт ни один health check, затронет не больше одного региона, а два других продолжат обслуживать его пользователей:

for r in asia us eu; do
  docker service update --image registry.example.com/web:1.1 web-$r || break
  sleep 300
done

Если обновление завершается неудачей, Swarm благодаря настройкам из шага 9 автоматически откатывает его, а || break прерывает цикл, как только команда сообщает об ошибке. Обновление, проблемы которого обнаружились позже, откатите вручную командой docker service rollback web-asia.

Обслуживание региона

Если сервер нужно перезагрузить или обновить, выведите его из работы командой docker node update --availability drain, заранее позволив DNS-failover перенаправить его пользователей в соседние регионы. После обслуживания верните его в работу с помощью --availability active. Прежде чем браться за следующий менеджер, подождите, пока docker node ls снова не покажет все три как доступные, чтобы никогда не отсутствовали два менеджера одновременно.

Мониторинг извне

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

Безопасное распространение секретов

Паролям и ключам место не в переменных окружения или файлах Compose, а в Docker Secrets. Они хранятся в зашифрованном виде в журнале Raft и передаются только тем сервисам, которым вы их явно назначили:

printf '%s' 'ВАШ_ПАРОЛЬ_ОТ_БАЗЫ_ДАННЫХ' | docker secret create db_password -
docker service update --secret-add db_password web-eu

Почему KernelHost для Swarm на нескольких континентах

Кластер на нескольких континентах предъявляет к провайдеру иные требования, чем отдельный сервер. На практике решающими оказываются следующие пункты:

Обзор всех облачных тарифов с ценами и сравнение расходов с крупными облачными провайдерами вы найдёте на странице Аренда облачного сервера.

Частые ошибки и как их избежать

• Менеджеры только на двух площадках. Если отказывает площадка с большинством, кластер останавливается. Решение: три площадки, распределение 1-1-1 или 2-2-1.
• Чётное число менеджеров. Четыре менеджера выдерживают не больше отказов, чем три, но увеличивают накладные расходы на согласование. Решение: 3, 5 или 7.
• Запросы путешествуют между континентами. Один адрес сервиса на все регионы гоняет пользователей через полмира. Решение: свой сервис и своя точка входа в каждом регионе.
• Порты Swarm доступны публично. Порту 2377 и overlay-сети никогда не место в открытом интернете. Решение: только через WireGuard, публично только 80, 443 и WireGuard для других узлов.
• Забыли про MTU. Большие ответы зависают, маленькие проходят. Решение: MTU overlay-сети 1370 при WireGuard с 1420.
• Расчёт на ufw для портов контейнеров. Для опубликованных портов Docker обходит ufw. Решение: публиковать только точку входа.
• База данных в томе без репликации. Если регион отказывает, данные недоступны. Решение: репликация базы данных, жёсткая привязка размещения к региону.
• Обновление во всех регионах одновременно. Тогда ошибка затрагивает всех пользователей по всему миру. Решение: раскатывать регион за регионом.
• Большой TTL в DNS. С TTL в один день failover сработает только на следующий день. Решение: 60 секунд.
• Репликация вместо резервного копирования. Ошибка реплицируется точно так же, как и корректные данные. Решение: дополнительно проверенные резервные копии в независимом месте.

Коротко о главном

• Docker Swarm на трёх континентах рассчитан на аптайм 100 %: целая площадка или континент может отказать, а приложение при этом не остановится.
• Абсолютную доступность не может гарантировать никто; оставшиеся риски связаны с DNS, ошибочными обновлениями, базой данных и сертификатами, и против каждого из них есть контрмера.
• Три менеджера на трёх площадках составляют минимум, а двух площадок для отказоустойчивого кворума недостаточно.
• Каждый запрос остаётся в своём регионе: свой сервис и своя точка входа в каждом регионе, плюс Geo-DNS с health checks и коротким TTL.
• WireGuard шифрует трафик кластера, порты Swarm остаются невидимыми, MTU overlay-сети снижается до 1370.
• Swarm реплицирует контейнеры, а не данные: базам данных нужна собственная репликация, а резервные копии остаются обязательными.
• KernelHost предлагает локации в Европе, Северной Америке и Азиатско-Тихоокеанском регионе, безлимитный трафик, защиту от DDoS в каждой локации и оплату по модели PrePaid без минимального срока.