Отказоустойчивость между облаками: автоматическое переключение AWS и GCP

Отметим: когда облачный провайдер перестает отвечать, бизнес теряет $10 000 в час. По данным Gartner, средняя стоимость минуты простоя в enterprise — $5 600, а 90% компаний, переживших часовой сбой, теряют более $1 млн. Мультирегиональное развертывание не спасает — vendor outage выводит из строя все зоны доступности. Единственный надежный сценарий — автоматическое переключение между AWS и GCP, cross-cloud failover. Мы проектируем cloud-agnostic архитектуру, которая гарантирует доступность 99.99%+ и переключение за минуты.

Наше решение использует контейнеризацию на Kubernetes, Terraform для управления инфраструктурой обеих облаков, логическую репликацию PostgreSQL для синхронизации данных и автоматический детектор сбоев. В отличие от мультирегионального подхода, cross-cloud исключает единую точку отказа на уровне провайдера. Приложение продолжает работать, даже если AWS us-east-1 полностью недоступен. Cloudflare DNS failover переключает трафик за 60 секунд, а warm standby сокращает затраты на резервирование до 30% по сравнению с полным копированием.

Ограничения одного провайдера

Привязка к одному облаку — единая точка отказа. Даже мультирегиональная отказоустойчивость не спасает от глобального сбоя плоскости управления (IAM, DNS). Логическая репликация PostgreSQL позволяет держать данные синхронизированными с минимальным лагом.

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

Без этих условий failover не сработает:

• Cloud-agnostic архитектура — приложение не использует DynamoDB, SQS, Lambda. Только PostgreSQL, Redis, объектное хранилище через совместимый API.
• Контейнеризация — Kubernetes обеспечивает единообразную среду. Helm-чарты для обеих областей.
• Синхронизация данных — механизм репликации с лагом в секунды.
• Infrastructure as Code — Terraform описывает инфраструктуру обоих провайдеров. Без этого восстановление затягивается на часы.

Как работает DNS failover?

Cloudflare — оптимальный выбор для переключения между провайдерами. Он не принадлежит ни одному из облачных гигантов и поддерживает health checks + load balancing. Cloudflare обновляет DNS записи за 60 секунд, что в два раза быстрее стандартных NS-серверов.

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, 'proxied': True } ) 

Cloudflare Load Balancing с health checks автоматизирует переключение. Мониторинг нескольких эндпоинтов с разных точек мира.

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

PostgreSQL с логической репликацией через pglogical — держим две базы почти в реальном времени. Источник (AWS RDS) — публикация:

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) — подписка:

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' ); 

Лаг репликации мониторится через pg_stat_replication. При активации failover промотируем GCP: отключаем подписку и выполняем pg_promote().

Объектное хранилище: rclone синхронизирует S3 → GCS каждые 5 минут для критических данных. GCP Cloud Storage обходится на 15% дешевле AWS S3, что делает его экономичным выбором для DR.

rclone sync s3:production-bucket gcs:dr-bucket --transfers 32 --checkers 16 --log-level INFO 

Автоматический детектор сбоя

Внешние health checks с нескольких геоточек обнаруживают outage.

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)?

Failback сложнее переключения. При восстановлении основного провайдера:

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

Объем работ по внедрению failover

Мы выполняем полный цикл: аудит архитектуры на cloud-agnostic, проектирование Terraform-модулей для второго провайдера, настройка репликации PostgreSQL и объектного хранилища, автоматизация failover через Cloudflare и мониторинг. Результат — документация, скрипты и инструкции для вашей команды.

Наши инженеры имеют сертификации AWS и GCP, более 7 лет опыта в multi-cloud проектах. Оценка вашей архитектуры — бесплатно. Свяжитесь с нами для консультации. Закажите аудит текущей инфраструктуры.