Google ACE: Compute Engine и операции с виртуальными машинами — Руководство по подготовке

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

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

Хранилище, образы и производительность

Постоянные диски

• Типы: Standard (HDD) для последовательной пропускной способности по низкой цене; Balanced (pd-balanced) для общих задач; SSD (pd-ssd) для высоких IOPS/низкой задержки; Extreme (pd-extreme) для выделенных IOPS и пропускной способности на высоких уровнях производительности. Региональные PD обеспечивают синхронную репликацию между зонами для повышения доступности.
• Производительность дисков Standard, Balanced и SSD масштабируется с их размером; заранее выбирайте размер для пиковых IOPS/пропускной способности или используйте Extreme для явного выделения ресурсов.
• Множественное подключение в режиме “только для чтения” позволяет совместно использовать наборы данных на многих ВМ; соответствующим образом координируйте доступ и уровни кэширования.

Локальный SSD

• Эфемерный, подключается напрямую к хосту, очень высокие IOPS/низкая задержка. Данные теряются при остановке/удалении/миграции. Используйте для временных файлов, кэшей и реплицируемых слоев данных. Обеспечьте репликацию или контрольные точки на уровне приложения.

Моментальные снимки и образы

• Моментальные снимки — это инкрементные резервные копии постоянных дисков на определенный момент времени; планируйте их создание с помощью Resource Manager или gcloud для соблюдения RPO. Межрегиональное хранение поддерживает аварийное восстановление (DR).
• Образы содержат загрузочные диски и конфигурацию. Поддерживайте конвейер для создания защищенных образов с управляемыми исправлениями. Проверяйте гостевые агенты (для логирования/мониторинга) в ваших “золотых” образах.
• Паттерны восстановления: для быстрого восстановления используйте небольшие базовые образы, а остальную настройку выполняйте через скрипты запуска или cloud-init; это уменьшает расхождение конфигураций и ускоряет обновления.

Выбор диска: компромиссы и сценарии сбоев

• Недостаточно выделенные ресурсы диска снижают пропускную способность приложения; избыточное выделение ведет к лишним затратам. Измеряйте фактические характеристики ввода-вывода и выбирайте наименьший диск, удовлетворяющий пиковым потребностям с запасом.
• Для баз данных рассмотрите региональные PD и pd-ssd/pd-extreme; проверяйте поведение fsync и глубину очереди. Избегайте использования локальных SSD для хранения долговременных данных, если они не реплицируются.

Доступ, безопасность, сеть и специализированные рабочие нагрузки

Администрирование Linux и Windows

• Linux SSH: Предпочитайте OS Login для централизации авторизации SSH и привязки доступа к удостоверениям. Предоставляйте роли compute.osLogin или compute.osAdminLogin группам, а не отдельным пользователям.
• Windows RDP: Установите учетные данные Windows в консоли или через gcloud; убедитесь, что правила брандмауэра разрешают TCP 3389 только с доверенных IP-адресов. Используйте IAP TCP forwarding, чтобы избежать доступа из публичной сети.
• Последовательная консоль: Включите как путь для аварийного доступа; используйте gcloud compute connect-to-serial-port для отладки загрузки. Ограничивайте доступ с помощью IAM и проводите аудит.

SSH, OS Login и управление ключами

• Включите OS Login на уровне проекта или экземпляра с помощью метаданных enable-oslogin=TRUE. Пользователи добавляют свой публичный SSH-ключ в свой аккаунт Google; IAM контролирует доступ на основе ролей.
• Для получения прав sudo/root используйте роль compute.osAdminLogin. Отключите SSH-ключи на уровне проекта при использовании OS Login, чтобы предотвратить расхождение конфигураций.

Метаданные, скрипты запуска и cloud-init

• Сервер метаданных предоставляет данные экземпляра/проекта и токены сервисного аккаунта. Используйте только токены с четко определенной областью действия; никогда не прописывайте секреты в коде.
• Скрипты запуска и cloud-init: Загружайте агентов, получайте конфигурации и регистрируйте сервисы. Делайте скрипты идемпотентными и записывайте логи в последовательную консоль для диагностики.
• Метаданные на уровне экземпляра могут переопределять настройки шаблона; используйте их осторожно, чтобы избежать расхождения конфигураций.

Сервисные аккаунты и области доступа

• Назначайте выделенный сервисный аккаунт для каждой рабочей нагрузки с IAM-ролями по принципу минимальных привилегий для требуемых ресурсов (например, storage.objectCreator для конкретного бакета).
• Предпочитайте широкие области доступа к Cloud API только тогда, когда доступ жестко контролируется IAM; в противном случае ограничивайте области доступа до минимально необходимых API.

Сеть и адреса

• Сетевые интерфейсы (NIC) могут иметь только внутренние или внешние IP-адреса. Предпочитайте частные ВМ с Cloud NAT или IAP для исходящего трафика и административного доступа.
• Резервируйте статические внутренние IP-адреса для стабильных конечных точек, таких как серверы лицензий; избегайте зависимости от эфемерных адресов.
• Внешний балансировщик нагрузки HTTP(S) терминирует TLS на границе сети; используйте управляемые сертификаты и проверки работоспособности для бэкенд-групп MIG. Согласуйте готовность бэкенда с проверкой работоспособности и начальной задержкой MIG.

Специализированные рабочие нагрузки и изоляция

• Shielded VMs: Безопасная загрузка, vTPM и мониторинг целостности снижают риск руткитов; включайте по умолчанию, если не требуются несовместимые драйверы.
• Confidential VMs: Шифрование памяти с помощью AMD SEV защищает используемые данные; обычно накладные расходы на производительность минимальны, но проверяйте для приложений, чувствительных к задержкам.
• Узлы с одним арендатором (Sole-tenant nodes): Выделенные физические хосты для соответствия требованиям, изоляции от “шумных соседей” и привязки лицензий. Планируйте с учетом фрагментации емкости и более высокой стоимости.

Устранение неполадок и операции по восстановлению

Общая диагностика

• Сетевое подключение: Проверьте правила брандмауэра, разрешения сервисного аккаунта и маршруты. Используйте тесты подключения Network Intelligence Center.
• Проблемы с загрузкой: Изучите логи последовательной консоли, сделайте снимок экрана и проверьте вывод стартового скрипта. Временно отключите безопасную загрузку (secure boot), если неподписанные драйверы блокируют загрузку, а затем устраните проблему.
• Блокировка доступа: При проблемах с SSH через OS Login убедитесь в наличии ролей IAM и ключей в аккаунтах пользователей; используйте последовательную консоль для добавления пользователя в качестве аварийного доступа (break-glass).
• Повреждение диска: Отключите загрузочный диск, подключите его к аварийной ВМ (rescue VM), восстановите файловые системы, смените учетные данные и создайте образ после устранения проблемы.

Поведение MIG и балансировщика нагрузки

• Избыточное выделение ресурсов (Overprovisioning): Если экземплярам требуется длительный «прогрев», увеличьте начальную задержку (initial delay) для MIG и время восстановления (cooldown) для автомасштабирования; в противном случае вы можете столкнуться с горизонтальным масштабированием из-за ошибок 4xx/5xx, пока приложение еще инициализируется.
• Циклы автоматического восстановления (Autohealing): Проверьте семантику конечной точки проверки работоспособности и готовность зависимостей; распределите запуск зависимостей по времени или добавьте повторные попытки.

Паттерны восстановления

• Воссоздание экземпляра из шаблона или образа; неизменяемые (immutable) паттерны сокращают MTTR.
• Восстановление данных из последнего успешного снимка; проверьте соответствие RPO/RTO требованиям бизнеса.
• При региональных сбоях выполняйте переключение на другую зону или регион, используя региональные MIG и межрегиональную репликацию снимков.

Операционные меры предосторожности

• Резервирование для критически важных мощностей; используйте оповещения на основе мониторинга потребления резервов и квот.
• Аудит и логирование: Включите логи действий администратора и доступа к данным для критически важных сервисов. Атрибутируйте доступ через OS Login и сервисные аккаунты.

Краткие примеры

• Зарезервировать статический внутренний IP-адрес:

undefined

• Включить OS Login на уровне проекта:

undefined

• Создать проверку работоспособности HTTP и привязать ее к MIG с автоматическим восстановлением:

undefined

undefined

Практический сценарий проблемы

Компания Northwind Analytics использует API, чувствительный к задержкам, на базе Compute Engine. Инциденты показывают частое избыточное выделение ресурсов во время развертываний, периодическую путаницу с доступом по SSH среди администраторов и лицензированный сервер телеметрии, который должен оставаться доступным по адресу 10.0.3.21. Цель — стабилизировать масштабирование, усилить контроль доступа и обеспечить стабильность конечной точки лицензирования.

Подход

1. Создать шаблон экземпляра с кастомным типом машины подходящего размера и начальной загрузкой (bootstrapping)

• Обоснование: Шаблон обеспечивает неизменяемость (immutability). Кастомная конфигурация 6 vCPU / 20 ГБ ОЗУ соответствует измеренным P95 для CPU и памяти, избегая при этом избыточных ядер, которые увеличивают стоимость лицензирования. Стартовый скрипт регистрирует API в балансировщике нагрузки только после прохождения проверок работоспособности, что снижает влияние «прогрева».

2. Развернуть региональную управляемую группу экземпляров (MIG) за внешним HTTP(S) Load Balancer

• Обоснование: Региональная MIG распределяет экземпляры по зонам для отказоустойчивости на уровне зоны. HTTP(S) load balancer терминирует TLS на границе сети и выполняет проверки работоспособности для каждого экземпляра, направляя трафик только на готовые бэкенды.

3. Настроить автомасштабирование по CPU с временем восстановления (cooldown) и автоматическое восстановление (autohealing) с реалистичной начальной задержкой

• Обоснование: Нагрузка на CPU сильно коррелирует с насыщением этого API. Время восстановления в 90 секунд предотвращает частые колебания (thrash) при кратковременных всплесках. Начальная задержка в 200 секунд соответствует времени «прогрева» контейнера и JIT-компиляции, не позволяя автомасштабированию интерпретировать холодные старты как нехватку мощностей.

4. Настроить проверку работоспособности и добавить конечную точку /healthz на уровне приложения

• Обоснование: Проверка работоспособности по HTTP, которая валидирует зависимости (кэш, подключение к БД), обнаруживает скрытые сбои (gray failures). Использование интервалов в 10 секунд и 3 порогов неработоспособности обеспечивает баланс между скоростью обнаружения и риском ложных срабатываний.

5. Включить OS Login и предоставить права администратора группе IAM

• Обоснование: OS Login централизует авторизацию и атрибуцию доступа по SSH. Администраторы добавляют свои публичные SSH-ключи в свои аккаунты Google; предоставление роли compute.osAdminLogin дежурной группе обеспечивает доступ с правами sudo, сохраняя при этом аудиторские следы. Это устраняет расхождение ключей на отдельных ВМ.

6. Зарезервировать статический внутренний IP-адрес сервера лицензий и привязать его к небольшой выделенной ВМ

• Обоснование: Резервирование адреса 10.0.3.21 гарантирует его доступность и предотвращает случайное повторное использование. Назначьте его сетевому интерфейсу (NIC) ВМ с лицензиями, чтобы зависимые приложения не требовали изменений в конфигурации. Ограничьте правила брандмауэра только разрешенными исходными подсетями.

7. Назначить выделенный сервисный аккаунт шаблону API с минимально необходимыми правами IAM

• Обоснование: Принцип наименьших привилегий уменьшает радиус поражения (blast radius). Сервисному аккаунту предоставляются только необходимые роли (например, доступ на чтение к определенным секретам и топикам Pub/Sub). Использование шаблона гарантирует, что все экземпляры унаследуют правильную идентификацию.

8. Усилить защиту экземпляров с помощью Shielded VM и обеспечить аварийный доступ через последовательную консоль

• Обоснование: Secure Boot и мониторинг целостности предотвращают подмену ядра/загрузчика. Ограничьте доступ к последовательной консоли с помощью IAM и логируйте доступ для аудита; сохраняйте его для восстановления в случае сбоя SSH.

9. Внедрить расписания создания снимков для дисков с состоянием (stateful) и тестировать восстановление

• Обоснование: Хотя API не хранит состояние (stateless), создайте расписание снимков для сервера лицензий и любых конфигурационных дисков для соблюдения RPO. Периодические тесты восстановления проверяют инструментарий и инструкции (runbooks).

10. Проверить и развернуть

• Обоснование: «Сине-зеленые» (blue/green) или «канареечные» (canary) обновления с использованием настроек плавающего обновления (rolling update) в MIG снижают риски. Дашборды мониторинга подтверждают стабилизацию количества экземпляров во время развертываний, улучшенную атрибуцию доступа администраторов и бесперебойную доступность адреса 10.0.3.21.

← Иерархия ресурсов · Все домены · Контейнеры →

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

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