Настройка Failover между облачными провайдерами

Настройка Failover между облачными провайдерами

Failover между облачными провайдерами — экстремальный вариант защиты от vendor outage. Исторически крупные облачные провайдеры падали: AWS us-east-1 (многократно), GCP (2019, 2020), Cloudflare (2019). Если SLA требует 99.99%+, одного провайдера недостаточно.

Предпосылки для cross-cloud failover

Без выполнения этих условий cross-cloud failover не имеет смысла:

1. Cloud-agnostic архитектура — приложение не использует proprietary API конкретного провайдера
2. Контейнеризация — Kubernetes обеспечивает единообразную среду выполнения
3. Синхронизация данных — механизм репликации данных между провайдерами
4. Infrastructure as Code — инфраструктура обоих провайдеров описана в Terraform

DNS как точка переключения

Cloudflare — оптимальный выбор для управления failover между провайдерами: работает с обоими, не принадлежит ни одному.

import CloudFlare

cf = CloudFlare.CloudFlare(token=CF_TOKEN)

def switch_to_provider(zone_id: str, record_name: str, new_ip: str):
    records = cf.zones.dns_records.get(zone_id, params={'name': record_name})
    record_id = records[0]['id']
    
    cf.zones.dns_records.put(
        zone_id,
        record_id,
        data={
            'type': 'A',
            'name': record_name,
            'content': new_ip,
            'ttl': 60,  # Низкий TTL для быстрого распространения
            'proxied': True
        }
    )

Cloudflare Load Balancing с health checks автоматизирует переключение без ручного вмешательства.

Синхронизация данных между AWS и GCP

PostgreSQL с логической репликацией через pglogical:

Источник (AWS RDS): настройка publication

SELECT pglogical.create_node(
    node_name := 'provider',
    dsn := 'host=aws-rds.example.com dbname=mydb'
);
SELECT pglogical.create_replication_set('default');
SELECT pglogical.replication_set_add_all_tables('default', ARRAY['public']);

Приёмник (GCP Cloud SQL): настройка subscription

SELECT pglogical.create_node(
    node_name := 'subscriber',
    dsn := 'host=gcp-cloudsql.example.com dbname=mydb'
);
SELECT pglogical.create_subscription(
    subscription_name := 'from_aws',
    provider_dsn := 'host=aws-rds.example.com dbname=mydb'
);

Лаг репликации мониторится. При активации failover — GCP PostgreSQL промотируется через pglogical.alter_subscription_disable + ручной promote.

Объектное хранилище: rclone sync S3 → GCS каждые 5 минут для критических данных, ежечасно для остальных.

rclone sync s3:production-bucket gcs:dr-bucket \
  --transfers 32 \
  --checkers 16 \
  --s3-upload-cutoff 50M \
  --log-level INFO

Автоматический детектор провайдерского outage

Внешние health checks с нескольких географических точек:

import asyncio
import httpx

PROVIDERS = {
    'aws': 'https://aws-endpoint.example.com/health',
    'gcp': 'https://gcp-endpoint.example.com/health',
}

async def check_provider_health(provider: str, url: str) -> bool:
    async with httpx.AsyncClient(timeout=10) as client:
        try:
            resp = await client.get(url)
            return resp.status_code == 200
        except Exception:
            return False

async def monitor_and_failover():
    while True:
        results = await asyncio.gather(*[
            check_provider_health(p, u) for p, u in PROVIDERS.items()
        ])
        
        aws_ok, gcp_ok = results
        current_active = get_current_active_provider()
        
        if not aws_ok and current_active == 'aws' and gcp_ok:
            trigger_failover_to_gcp()
        
        await asyncio.sleep(30)

Failover процедура пошагово

1. Детектировать сбой (автоматически или вручную подтвердить)
2. Остановить запись в primary provider DB (предотвратить split-brain)
3. Промотировать DR DB в GCP как новый primary
4. Обновить Cloudflare DNS / Load Balancer на GCP endpoints
5. Запустить масштабирование GCP кластера до production-мощности (если warm standby)
6. Проверить health всех компонентов в GCP
7. Снять maintenance page / восстановить пользовательский трафик

Весь процесс: 5-15 минут при automated failover, 15-30 минут при manual.

Обратный failover (failback)

Часто сложнее прямого. При восстановлении основного провайдера:

• Не переключаться немедленно — убедиться в стабильности
• Синхронизировать данные обратно (GCP → AWS за время outage)
• Переключить трафик в maintenance window
• Проверить полноту данных

Сроки реализации

• Предварительный аудит на cloud-agnostic готовность — 2-3 дня
• Terraform для второго провайдера — 5-10 дней
• Настройка репликации данных — 5-10 дней
• Автоматизация failover + детектор — 3-5 дней
• Тестирование полного failover cycle — 3-5 дней