Google ACE: Надежность, резервное копирование и аварийное восстановление — Руководство по подготовке

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Часть Google Associate Cloud Engineer — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Google, или пройдите тесты на время на ExamRoll.io.

Обзор

Надежность, резервное копирование и аварийное восстановление в Google Cloud требуют продуманного проектирования с учетом доменов отказа, механизмов защиты данных, управления трафиком и эксплуатационной готовности. В этом разделе объясняется, как структурировать сервисы по зонам и регионам, как защищать и восстанавливать данные с отслеживанием состояния (stateful), а также как проверять целевые показатели восстановления с помощью четких инструкций (runbooks) и непрерывного тестирования отказоустойчивости. Также здесь рассматриваются компромиссы различных стратегий аварийного восстановления (DR) и планирование мощностей, чтобы гарантировать восстановление платформы в рамках заданных целевых показателей времени (RTO) и точки восстановления (RPO).

Домены отказа и региональное проектирование

• Зоны, регионы и мультирегиональные сервисы

  • Зоны — это наименьшие независимые домены отказа. Сбой в одной зоне не должен прерывать работу регионального сервиса.
  • Регионы объединяют независимые зоны с помощью каналов с низкой задержкой. Региональные архитектуры выдерживают сбои на уровне зон, но не всегда — полные сбои на уровне региона.
  • Мультирегиональные сервисы реплицируются между регионами, защищая от потери региона ценой более высокой стоимости и, возможно, более высокой задержки при записи.
  • Принцип проектирования: избегайте единых точек отказа на самом малом домене отказа, который для вас важен. Если ваши RTO/RPO требуют устойчивости к сбою зоны, развертывайте сервисы как минимум в двух зонах. Для обеспечения отказоустойчивости на уровне региона развертывайте активные компоненты в нескольких регионах или используйте мультирегиональные сервисы.

• Группы управляемых экземпляров (MIG) и самовосстановление

  • Предпочитайте региональные MIG для распределения экземпляров по зонам в одном регионе. Это смягчает последствия сбоев на уровне зоны без необходимости использовать отдельные инструменты.
  • Проверки работоспособности балансировщика нагрузки удаляют неработоспособные ВМ из трафика. Самовосстановление (autohealing) в MIG заменяет неработоспособные или не отвечающие ВМ. Используйте оба механизма.
  • Используйте проверки работоспособности уровня приложения (HTTP(S)), которые проверяют эндпоинты готовности и зависимости. Проверка по TCP подтверждает только доступность порта.
  • Сбой из-за неверной конфигурации самовосстановления: использование только проверки работоспособности от балансировщика нагрузки прекращает подачу трафика на неисправный экземпляр, но не пересоздает его. Настройте собственную проверку работоспособности для MIG, чтобы обеспечить замену, и установите начальную задержку, чтобы избежать преждевременных перезапусков во время загрузки.

Пример:

• Создайте проверку работоспособности приложения с интервалом 10 секунд и 3 порогами неработоспособности, чтобы запустить самовосстановление примерно через 30 секунд: gcloud compute health-checks create http hc-app
  –check-interval=10s –timeout=5s
  –unhealthy-threshold=3 –healthy-threshold=1 –request-path=/healthz

• Привяжите проверку работоспособности к региональной MIG для самовосстановления: gcloud compute instance-groups managed update my-rmig
  –region=us-central1 –health-check=hc-app –initial-delay=60

• Особенности мультирегиональной архитектуры

  • Global external HTTP(S) Load Balancing поддерживает бэкенды в нескольких регионах с автоматическим переключением при сбое на основе проверок работоспособности.
  • Синхронизация состояния между регионами — это ключевой компромисс. В режиме active-active пропускная способность высока, но необходимо продумать обеспечение согласованности данных и разрешение конфликтов. Режим active-passive проще, но имеет более медленное переключение при сбое и потенциально больший RPO.

Операции по обеспечению отказоустойчивости и непрерывное улучшение

• RTO, RPO, планы восстановления и раунбуки (runbooks)

  • RTO (целевое время восстановления) определяет, как быстро должен возобновиться сервис; RPO (целевая точка восстановления) определяет допустимый объем потери данных. Эти показатели выводятся из анализа влияния на бизнес.
  • Сопоставьте каждый компонент системы с конкретными механизмами, удовлетворяющими RTO/RPO: высокая доступность (HA) для сбоев на уровне зоны, межрегиональная репликация для сбоев на уровне региона, резервные копии для защиты от повреждения данных и класс хранения/репликация для обеспечения долговечности.
  • Поддерживайте раунбуки: точные шаги, команды, доступ к учетным данным, проверки работоспособности и деревья принятия решений. Храните их в репозитории с контролем версий и доступа и регулярно отрабатывайте.
  • Проверка восстановления: планируйте учения для измерения фактических RTO/RPO, проверки целостности данных и сбора мер по улучшению. Тестируйте как восстановление малого масштаба (таблица, диск), так и полное восстановление сайта.

• Стратегии аварийного восстановления (DR) и их компромиссы

  • Active-active: все регионы обслуживают трафик; минимальное RTO и низкое RPO при правильной настройке синхронизации данных. Более высокая сложность и стоимость; требует разрешения конфликтов и глобальной балансировки нагрузки.
  • Active-passive: основной регион активен; вторичный находится в «теплом» режиме и получает реплицированные данные. Умеренная стоимость; RTO от нескольких минут до десятков минут; ненулевое RPO в зависимости от репликации.
  • Pilot-light («пилотный свет»): во вторичном регионе запущены минимальные критически важные сервисы (репликация баз данных, минимальный след приложения). RTO — часы; экономически эффективно; требуется тщательная оркестрация для масштабирования вычислительных ресурсов во время переключения.
  • Cold-standby («холодный резерв»): инфраструктура определена как код, но не развернута. RTO — дни; самая низкая стоимость; риск сюрпризов из-за дрифта конфигурации, квот и нехватки мощностей.

• Хаос-инжиниринг и симуляция сбоев

  • Регулярно симулируйте сбои инстансов, зависания процессов, отказы проверок работоспособности, переполнение диска и сбои зависимостей. Используйте инструменты или скрипты для завершения инстансов, блокировки исходящего трафика к бэкендам или внесения задержек на уровне прокси.
  • Проверяйте автовосстановление MIG и удаление из балансировщика нагрузки, намеренно вызывая сбой эндпоинта проверки работоспособности. Подтвердите поведение замены и время восстановления.
  • Практикуйте эвакуацию региона: выводите трафик с бэкендов в одном регионе, наблюдайте за переключением глобального балансировщика нагрузки и проверяйте stateful-зависимости во вторичном регионе.
  • Непрерывное улучшение: записывайте метрики среднего времени до обнаружения, времени переключения и потери данных во время тестов. Приоритизируйте исправления, которые сокращают RTO/RPO и устраняют ручные шаги.

Практический сценарий

Компания Brightlane Retail управляет платформой электронной коммерции в регионе us-central1 со строгими требованиями к доступности и RPO в четыре часа для данных о заказах. Руководство требует обеспечить выживаемость при сбое зоны без простоя и при сбое региона с минимальным влиянием на клиентов.

Подход:

1. Внедрить региональную MIG с автовосстановлением по HTTP и глобальным HTTP(S) Load Balancer

   • Обоснование: Региональная MIG распределяет инстансы по зонам, а проверки работоспособности на уровне приложения (HTTP) обеспечивают самовосстановление после трех неудачных проверок с интервалом в 10 секунд. Глобальный балансировщик нагрузки автоматически удаляет неработоспособные ВМ и перенаправляет трафик в работоспособные зоны.
   • Команды: gcloud compute health-checks create http app-hc –check-interval=10s –timeout=5s –unhealthy-threshold=3 –request-path=/healthz gcloud compute instance-groups managed update web-rmig –region=us-central1 –health-check=app-hc –initial-delay=60

2. Включить Cloud SQL HA с межрегиональной репликой чтения и PITR

   • Обоснование: Региональный режим HA обеспечивает выживаемость на уровне зоны с автоматическим переключением. Реплика чтения в us-east1 обеспечивает региональное аварийное восстановление (DR) с ненулевым, но ограниченным RPO. Включение PITR (бинарного журнала для MySQL) решает проблему логического повреждения данных, позволяя восстановиться на определенный момент времени.
   • Команды: gcloud sql instances patch orders-mysql –enable-bin-log –backup-start-time=03:00 gcloud sql instances create orders-replica –master-instance-name=orders-mysql –region=us-east1

3. Защитить объектные ресурсы с помощью Dual-Region Cloud Storage и политик жизненного цикла

   • Обоснование: Изображения продуктов и статические ресурсы хранятся в бакете dual-region для обеспечения региональной отказоустойчивости. Политики жизненного цикла перемещают старые артефакты в Coldline для оптимизации затрат, а версионирование и политики хранения предотвращают случайное удаление критически важных ресурсов.
   • Шаги: Включить версионирование объектов (Object Versioning), установить 30-дневную политику хранения для критически важных бакетов и применить правила жизненного цикла для перемещения в Coldline через 90 дней и удаления через год для некритичных артефактов сборки.

4. Настроить расписание для снэпшотов PD и создавать образы машин для stateful-сервисов

   • Обоснование: Инкрементальные снэпшоты дисков ВМ предоставляют быстрые варианты crash-consistent восстановления. Образы машин захватывают загрузочную конфигурацию и настройки для ускорения «разогрева» серверов приложений во время переключения на другой регион. Расписания снэпшотов обеспечивают последовательное резервное копирование на основе политик.
   • Команды: gcloud compute resource-policies create snapshot-schedule daily-2am –max-retention-days=14 –on-source-disk-delete=apply-retention-policy –start-time=02:00 gcloud compute disks add-resource-policies app-disk-1 –resource-policies=daily-2am gcloud compute machine-images create app-mi-2024-09-01 –source-instance=app-vm-template

5. Определить RTO/RPO и кодифицировать раунбуки для DR и IaC

   • Обоснование: Установить RTO на уровне сервиса в 15 минут для веб/API и RPO в четыре часа для заказов. Раунбуки определяют процедуры переключения трафика, повышение реплики чтения Cloud SQL до основного инстанса, резервные планы для DNS и шаги проверки. Инфраструктура как код (Terraform/Deployment Manager) обеспечивает детерминированные перестроения и снижает количество ручных ошибок.

6. Выделить мощности и квоты во вторичном регионе

   • Обоснование: Создать резервирования для критически важных типов ВМ, предварительно развернуть резервный бэкенд балансировщика нагрузки, SSL-сертификаты, мощности NAT и проверить квоты для Compute, SQL, правил пересылки и KMS в регионе us-east1. Это предотвращает нехватку мощностей во время переключения.

7. Проверять восстановление с помощью учений по хаос-инжинирингу и документировать улучшения

   • Обоснование: Ежеквартальные учения по сбою зоны проверяют поведение MIG и LB; полугодовая эвакуация региона включает повышение реплики чтения в us-east1, перенаправление глобального LB на бэкенды в us-east1 и измерение RTO/RPO. Полученные результаты стимулируют улучшения, такие как сокращение ручных шагов или увеличение мощности реплики.

Следуя этим шагам, Brightlane Retail достигает высокой доступности на уровне зоны с автоматическим самовосстановлением и готовности к региональному аварийному восстановлению с определенными, протестированными раунбуками, гарантируя, что данные о заказах соответствуют RPO в четыре часа, а сервисы приложений восстанавливаются в пределах целевых показателей RTO.

← Безопасность · Все домены · Управление затратами →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Google →