Google PCA: Сетевое взаимодействие, гибридная связность и архитектура трафика — Руководство по подготовке

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Обзор

Сетевое взаимодействие, гибридное подключение и архитектура трафика в Google Cloud строятся вокруг безопасного и масштабируемого дизайна Virtual Private Cloud (VPC), надежных гибридных соединений, интеллектуального управления трафиком и мощных средств наблюдаемости. Цель состоит в том, чтобы предоставлять отказоустойчивые сервисы с низкой задержкой, четкой сегментацией, контролируемым исходящим трафиком (egress) и предсказуемыми режимами отказа. В этом разделе рассматриваются практические шаблоны проектирования, компромиссы и операционные рекомендации по основным сетевым сервисам Google Cloud.

Архитектура и сегментация VPC

• Планирование адресного пространства и подсети

  • Используйте VPC в пользовательском режиме (custom-mode), чтобы контролировать создание подсетей и IP-адресацию. Избегайте VPC по умолчанию в производственных средах.
  • Заранее выделяйте непересекающиеся блоки RFC1918. Учитывайте будущий рост, высокодоступные топологии и гибридные расширения. Резервируйте диапазоны для сервисов (например, для конечных точек Private Service Connect) и для пиринга/Interconnect.
  • Предпочитайте более мелкие подсети для каждой функции или среды, а не большие плоские сети, чтобы минимизировать радиус поражения при сбое и упростить настройку межсетевых экранов.

• Маршруты

  • Каждая VPC имеет системную таблицу маршрутов; маршруты оцениваются по совпадению с самым длинным префиксом, а затем по приоритету. Маршруты, управляемые Google, включают маршрут в интернет по умолчанию (если существуют внешние IP-адреса) и маршруты подсетей. Динамические маршруты обмениваются с локальной средой (on-premises) через Cloud Router.
  • Используйте пользовательские статические маршруты экономно; по возможности полагайтесь на динамическую маршрутизацию для обеспечения отказоустойчивости. Избегайте blackhole-маршрутов, за исключением случаев, когда это является преднамеренным средством контроля.

• Правила межсетевого экрана

  • Межсетевой экран VPC работает с отслеживанием состояния (stateful), правила оцениваются по приоритету, с неявным запретом в конце. Нацеливайте правила на сетевые теги или сервисные аккаунты; нацеливание на сервисные аккаунты обеспечивает более строгие гарантии идентификации, чем теги.
  • Разделяйте разрешающие правила по назначению (проверки работоспособности, внутриуровневое взаимодействие, администрирование) и ограничивайте их область действия исходными сервисными аккаунтами или диапазонами IP.
  • Логгируйте решения межсетевого экрана для критически важных правил в Cloud Logging для помощи в расследовании инцидентов и анализе производительности.

• Иерархические политики межсетевого экрана и политики организации

  • Иерархические политики межсетевого экрана применяются на уровне организации или папки и оцениваются до правил уровня VPC. Используйте их для установки глобальных защитных барьеров (например, запрет SSH с 0.0.0.0/0), которые проекты не могут переопределить. Политики pre и post обеспечивают гибкость, но запреты на более высоких уровнях не могут быть отменены.
  • Дополняйте их ограничениями политик организации (например, ограничение на создание внешних IP-адресов, запрет на создание VPC-пиринга проектами) для обеспечения управления.

• Shared VPC и сегментация

  • Используйте Shared VPC для централизации сетевых ресурсов в хост-проектах (Host Projects) при изоляции рабочих нагрузок в сервисных проектах (Service Projects). Этот шаблон сокращает количество дублирующихся путей для исходящего трафика, стандартизирует средства контроля и упрощает гибридный транзит.
  • Изолируйте среды (prod, non-prod) в отдельных хост-проектах или папках; обеспечивайте сегментацию с помощью иерархических политик и отдельных подсетей. Ограничьте IAM таким образом, чтобы только команды NetOps могли управлять ресурсами хост-проекта.

• VPC Network Peering

  • Пиринг является приватным, масштабируемым и имеет низкую задержку, но он нетранзитивен. Он лучше всего подходит для соединения автономных сетей или управляемых сторонних сервисов. Избегайте создания транзитных хабов с помощью пиринга; используйте Network Connectivity Center для транзита или централизованную Shared VPC.
  • Ограничения: отсутствие пересекающихся IP-адресов; определенные маршруты (например, маршрут в интернет по умолчанию) и некоторые сервисы не распространяются. При проектировании учитывайте импорт/экспорт пользовательских маршрутов.

Компромиссы и режимы отказа:

• Пересекающиеся диапазоны IP-адресов блокируют пиринг и обмен гибридными маршрутами; решается перенумерацией или с помощью NAT.
• Чрезмерно разрешающие правила межсетевого экрана или отсутствующие правила для проверок работоспособности вызывают сбои и трудно диагностируемое поведение.
• Статические маршруты создают хрупкие зависимости; для обеспечения отказоустойчивости предпочитайте Cloud Router.

Управление трафиком, DNS и безопасность на периметре сети

• Паттерны Cloud Load Balancing

  • Внешний HTTP(S) Load Balancer — это глобальный anycast-балансировщик с единым anycast VIP, межрегиональным переключением при сбоях, маршрутизацией по пути и хосту, а также интеграцией с CDN/Armor. Используйте для веб-приложений и API, доступных из интернета.
  • Внутренний HTTP(S) Load Balancer — региональный, для трафика между сервисами внутри VPC или через Private Service Connect.
  • Внешний/внутренний сетевой TCP/UDP Load Balancer — региональный L4; используйте для протоколов, отличных от HTTP, или там, где требуется сохранение исходного IP-адреса.
  • Бэкенд-сервисы и группы сетевых конечных точек (NEGs): используйте зональные группы экземпляров в качестве бэкендов для пулов ВМ; используйте зональные, региональные или бессерверные NEGs для GKE, гибридных бэкендов или Cloud Run. Создавайте отдельные бэкенд-сервисы для каждого класса трафика, профиля проверки работоспособности или политики управления мощностью. Пример: обслуживайте старую и новую версии API под одним именем хоста, используя маршрутизацию по пути к разным бэкенд-сервисам, что позволяет развертывать и масштабировать каждую версию независимо.

• Проверки работоспособности и распространенные ошибки

  • Проверки работоспособности должны быть разрешены правилами брандмауэра. Для внешних проверок работоспособности HTTP(S) разрешите доступ к бэкендам с диапазонов 130.211.0.0/22 и 35.191.0.0/16. Отсутствие правила приведет к тому, что бэкенды будут помечены как неработоспособные, а автомасштабирование, реагируя на сигналы балансировщика, вызовет частые перезапуски ВМ.
  • Согласуйте пути и порты проверок работоспособности с эндпоинтами готовности контейнеров; настройте тайм-ауты и пороговые значения так, чтобы сбалансировать быстрое переключение при сбоях и ложные срабатывания.

• Архитектура DNS

  • Используйте Cloud DNS для авторитативных зон. Создавайте частные зоны для внутренних имен; создавайте публичные зоны для имен в интернете.
  • Split-horizon DNS: отдавайте разные ответы для внутренних и внешних запросов, создав отдельные публичную и частную зоны с одинаковыми именами. Это позволяет безопасно поддерживать имена хостов для частных сервисов и публичные записи.
  • Зоны пересылки и пиринга: интегрируйтесь с локальным DNS с помощью политик DNS и серверных политик для пересылки запросов к определенным доменам; используйте условную пересылку, чтобы избежать циклов рекурсии.
  • Обнаружение сервисов: придерживайтесь единых соглашений об именовании для каждого окружения и сервиса. Для GKE рассмотрите использование headless-сервисов с Cloud DNS или сопоставление эндпоинтов сервисов через внутренний HTTP(S) Load Balancer и частные DNS-имена.

• Кэширование и защита на периметре сети

  • Cloud CDN разгружает исходный сервер, кэшируя контент на периметре сети, что снижает задержку и затраты на исходящий трафик. Тщательно настраивайте ключи кэширования, TTL и негативное кэширование; отключайте кэширование для персонализированных или динамических эндпоинтов.
  • Cloud Armor предоставляет WAF, ограничение частоты запросов и контроль доступа на основе геолокации/IP-адреса. Применяйте политики безопасности к балансировщикам нагрузки; отслеживайте логи срабатывания правил. Используйте преднастроенные правила для распространенных CVE и пользовательские сигнатуры для угроз, специфичных для вашего приложения.
  • Терминирование TLS на балансировщике нагрузки централизует управление сертификатами; по возможности включайте автоматическую выдачу и управляемое обновление сертификатов.

Рекомендации по эксплуатации:

• Версионирование API: реализуйте маршрутизацию на основе пути или хоста к разным бэкенд-сервисам, чтобы каждая версия выкатывалась независимо с использованием blue-green или canary-паттернов.
• Используйте заголовки запросов и cookie для A/B-тестирования с помощью политик управления трафиком; всегда проверяйте, что логи и метрики соотносятся с правильным идентификатором бэкенда.

Гибридное подключение, частный доступ и транзит

• Cloud Router и BGP

  • Cloud Router динамически обменивается маршрутами с локальной средой по протоколу BGP для туннелей Cloud VPN и подключений Interconnect. Используйте режим глобальной динамической маршрутизации в VPC, когда требуется подключение периферийных сетей (spoke) в нескольких регионах.
  • Анонсируйте только необходимые префиксы; используйте фильтрацию для предотвращения утечек маршрутов. Понимайте взаимодействие MED и приоритетов при проектировании основных/резервных путей.

• Cloud VPN, Dedicated и Partner Interconnect

  • HA VPN предоставляет резервированные туннели по IPsec с гарантированным SLA, поддерживает динамическую маршрутизацию через Cloud Router и подходит для гибридных производственных сред с умеренными требованиями к пропускной способности.
  • Dedicated Interconnect предоставляет физические каналы 10/100 Гбит/с в одной или нескольких точках присутствия; Partner Interconnect предлагает аналогичное решение через поставщика услуг. Для высокой доступности используйте как минимум два подключения Interconnect в разных городских агломерациях или разных пограничных зонах.
  • Резервные пути и отказоустойчивость: проектируйте схему active/active с BGP через два Cloud Router на регион и два локальных маршрутизатора; проверяйте устойчивость к асимметричной маршрутизации. Регулярно тестируйте переключение при сбое; настраивайте таймеры BFD и пороги работоспособности для достижения желаемой скорости сходимости.
  • Режимы отказа: несоответствие MTU вызывает фрагментацию и снижение производительности; обеспечьте поддержку jumbo-кадров на всем пути для Interconnect. Неправильно настроенные фильтры маршрутов могут привести к «черным дырам» для подсетей. Каналы от партнеров с одним подключением (single-homed) являются частой единой точкой отказа.

• Cloud NAT, Private Google Access и Private Service Connect

  • Cloud NAT обеспечивает исходящий доступ в интернет для частных ВМ без внешних IP-адресов. Правильно рассчитывайте количество IP-адресов и портов для NAT под пиковые нагрузки, чтобы избежать исчерпания портов; включите логирование для диагностики.
  • Private Google Access позволяет частным ВМ обращаться к API Google, используя внутренние IP-адреса; включите его в подсетях для доступа ВМ и на узлах GKE для локального доступа к API с узла. Для локальных клиентов используйте Private Service Connect for Google APIs, чтобы предоставить доступ к частным VIP, которые проксируют API Google.
  • Private Service Connect для сервисов-производителей/потребителей предоставляет частные конечные точки с внутренними IP для публикации сервисов между проектами или организациями; комбинируйте с частным DNS для управления трафиком без раскрытия сетей.

• Network Connectivity Center (NCC) и транзит

  • NCC позволяет создавать топологии «звезда» (hub-and-spoke), где лучами (spokes) являются VPC, HA VPN или подключения Interconnect. Используйте центральный узел (hub) для упрощения распределения маршрутов и транзита между несколькими VPC, особенно между проектами или организациями.
  • Предпочитайте Shared VPC для транзита внутри организации, если это позволяет политика управления; используйте NCC, когда вам нужен гибкий транзит между несколькими доменами или интеграция с SD-WAN.
  • Помните, что VPC Peering не является транзитивным; не полагайтесь на него для организации транзита. NCC или централизованная VPC с брандмауэром/балансировщиком нагрузки формирует ядро транзитной сети.

Выбор между регионами, задержки и стоимость исходящего трафика:

• Размещайте вычислительные ресурсы ближе к пользователям и stateful-бэкендам, чтобы минимизировать RTT. External HTTP(S) Load Balancing обеспечивает глобальный входящий трафик с интеллектуальной маршрутизацией, но задержка репликации баз данных и согласованность данных остаются ограничениями на уровне приложения.
• Трафик между зонами внутри региона платный; межрегиональная репликация добавляет плату за исходящий трафик и задержку. Используйте Cloud CDN для сокращения исходящего интернет-трафика и нагрузки на источник, а также размещайте сервисы с интенсивным обменом данными в одном месте.
• Для аварийного восстановления взвешивайте затраты на исходящий трафик и сложность эксплуатации «теплого» резерва в другом регионе. Используйте глобальную балансировку нагрузки с политиками переключения при сбое и проверками работоспособности, охватывающими несколько регионов, только если плоскость данных и плоскость управления могут выдержать изоляцию региона.

Наблюдаемость, обеспечение надежности и средства контроля

• Наблюдаемость сети

  • VPC Flow Logs: включайте на уровне подсети и настраивайте параметры выборки и метаданных. Используйте для определения базового уровня трафика, анализа исходящего трафика и поиска угроз. Экспортируйте в BigQuery для долгосрочной аналитики.
  • Логирование правил брандмауэра: включайте для критически важных правил, чтобы фиксировать разрешенный и запрещенный трафик; сопоставляйте с журналами потоков для выявления неверных конфигураций.
  • Connectivity Tests: моделируйте пути от источника к назначению для проверки доступности, выбора маршрута и оценки правил брандмауэра. Интегрируйте в CI/CD для обнаружения отклонений от конфигурации перед развертыванием.
  • Панели мониторинга состояния: отслеживайте состояние бэкендов балансировщика нагрузки, утилизацию портов Cloud NAT, статус BGP-сессий Cloud Router и утилизацию Interconnect. Настройте оповещения об отклонениях.

• Шаблоны обеспечения надежности и распространенные режимы отказа

  • Отказоустойчивость на уровне зон: распределяйте бэкенды как минимум по двум зонам; используйте управляемые группы инстансов или многозональные пулы узлов GKE. Убедитесь, что проверки состояния и теги брандмауэра применяются ко всем зонам.
  • Отказоустойчивость маршрутизации: используйте глобальную динамическую маршрутизацию и несколько Cloud Routers для обеспечения связности между регионами. Тестируйте сценарии «черной дыры» и убедитесь, что мониторинг охватывает отзыв маршрутов.
  • Отказоустойчивость DNS: развертывайте несколько серверов имен по умолчанию с помощью Cloud DNS; для гибридных сред убедитесь, что перенаправляющие серверы (forwarders) избыточны, и избегайте единых точек отказа в локальных резолверах. Предотвращайте неверные конфигурации split-horizon, которые возвращают немаршрутизируемые ответы с неверной стороны.
  • Безопасность на периметре: применяйте ограничения скорости Cloud Armor для защиты исходных серверов от флуда; невыполнение этого требования может спровоцировать штормы автомасштабирования и резкий рост затрат.

• Контроль затрат

  • Минимизируйте межрегиональные вызовы, отдавайте предпочтение внутренним балансировщикам нагрузки для трафика внутри VPC и рассмотрите использование PSC для трафика между производителем и потребителем, чтобы избежать исходящего трафика через NAT.
  • Используйте Cloud CDN для статических и полустатических ресурсов; настраивайте кэшируемость. Подбирайте пропускную способность Interconnect, чтобы не переплачивать за простаивающий резерв; используйте данные о трафике для правильного определения обязательств (commits).

Примеры операционных команд:

• Разрешить проверки состояния от балансировщика нагрузки к приватным бэкендам:

undefined

• Включить Private Google Access для подсети:

undefined

• Создать Cloud Router для HA VPN:

undefined

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

Компания Contoso Retail планирует запустить глобальный e-commerce API с версионированием без простоев, строгой приватной связностью с бэк-офисными системами и без публичных IP-адресов на виртуальных машинах приложений. Решение должно обеспечивать защиту от DDoS-атак, кэширование на периметре и надежный гибридный доступ из двух центров обработки данных.

Подход:

1. Проектирование VPC и сегментации

• Создайте Shared VPC Host Project в режиме custom с выделенными подсетями для каждого уровня (web, api, data) в двух регионах. Обоснование: Shared VPC централизует управление, в то время как сервисные проекты изолируют команды. Подсети для каждого уровня обеспечивают брандмауэр с минимальными привилегиями и уменьшают домены отказа.
• Примените иерархические политики брандмауэра на уровне организации, чтобы запретить входящий SSH из интернета и ограничить исходящий трафик до разрешенных назначений. Обоснование: Глобальные защитные барьеры снижают риск неверной конфигурации в проектах.

2. Реализация глобального входящего трафика на основе путей и версионирования API

• Разверните внешний HTTP(S) Load Balancer с одним anycast IP и терминированием HTTPS. Настройте карты URL (URL maps) для маршрутизации /v1/* и /v2/* на отдельные бэкенд-сервисы, использующие региональные зональные NEG. Обоснование: Раздельные бэкенд-сервисы позволяют независимо развертывать и откатывать каждую версию API под одним именем хоста и TLS-сертификатом.
• Подключите Cloud Armor WAF и ограничения скорости; включите Cloud CDN для кэшируемых эндпоинтов (например, изображений продуктов). Обоснование: Защищает исходные серверы, снижает задержку и затраты на исходящий трафик.

3. Обеспечение доступности и работоспособности бэкендов

• Создайте правило брандмауэра, разрешающее проверки состояния от балансировщика нагрузки к группам инстансов API на ожидаемых портах. Обоснование: Без этого правила проверки состояния будут завершаться неудачей, и автомасштабировщики могут работать нестабильно (thrash), считая инстансы неработоспособными.
• Распределите инстансы по двум зонам в каждом регионе; установите пороги проверки состояния консервативно, чтобы избежать ложных срабатываний (flapping). Обоснование: Разнообразие зон и стабильные политики проверки состояния повышают доступность.

4. Построение DNS со split-horizon и обнаружением сервисов

• Создайте публичную зону Cloud DNS для contoso.com и приватную зону с тем же именем для записей, предназначенных только для внутреннего использования (например, db.internal.contoso.com). Обоснование: Split-horizon предотвращает утечку внутренних имен, сохраняя при этом единообразную схему именования.
• Настройте политики DNS для перенаправления запросов к локальной зоне corp.local на корпоративные DNS-серверы и импортируйте приватные зоны в проекты приложений. Обоснование: Обеспечивает бесшовное разрешение имен через гибридные границы без петель рекурсии.

5. Установка гибридной связности с резервированием

• В каждом регионе подготовьте по два туннеля HA VPN к каждому центру обработки данных, каждая пара на отдельных Cloud Routers с BGP. Если требования к пропускной способности и SLA это оправдывают, добавьте Partner Interconnect с резервными подключениями (attachments) в разных пограничных зонах (edge zones). Обоснование: Множество разнообразных путей обеспечивают отказоустойчивость; BGP позволяет быстро сходиться и динамически обмениваться маршрутами.
• Используйте глобальную динамическую маршрутизацию в Shared VPC и применяйте фильтры маршрутов, чтобы предотвратить распространение нежелательных префиксов из локальной сети. Обоснование: Обеспечивает согласованную маршрутизацию между регионами, снижая риск утечки маршрутов.

6. Обеспечение приватного доступа к Google API и исходящего доступа в интернет

• Включите Private Google Access на подсетях приложений и настройте эндпоинты Private Service Connect для Google API, используемых пакетными заданиями. Используйте Cloud NAT для исходящего трафика, не связанного с API, где это необходимо. Обоснование: Бэкенды не имеют публичных IP-адресов, но при этом могут обращаться к необходимым сервисам; PSC упрощает разрешение имен с помощью приватного DNS.

7. Централизация транзита и подключений к сторонним сетям

• Создайте хаб Network Connectivity Center в Host Project; подключите к нему туннели HA VPN, подключения Interconnect и любые SD-WAN spokes. Обоснование: Транзитная модель «звезда» (hub-and-spoke) упрощает распределение маршрутов между несколькими VPC и внешними сетями по сравнению с полносвязными топологиями пиринга (peering meshes).

8. Внедрение наблюдаемости и защитных барьеров

• Включите VPC Flow Logs на всех подсетях с соответствующей выборкой; включите логирование брандмауэра для критически важных правил; экспортируйте данные в BigQuery. Используйте Connectivity Tests в CI/CD перед применением новых изменений в брандмауэре или маршрутизации. Обоснование: Глубокая видимость помогает в поиске неисправностей, планировании мощностей и аудите.
• Настройте оповещения о разрывах BGP-сессий Cloud Router, исчерпании портов Cloud NAT, снижении работоспособности бэкендов и срабатывании правил Cloud Armor. Обоснование: Раннее обнаружение сбоев и атак сокращает среднее время восстановления (MTTR).

9. Оптимизация производительности и затрат

• Размещайте сервисы с отслеживанием состояния (stateful) вместе с вычислительными ресурсами в одном регионе; кэшируйте статический контент на периметре с помощью Cloud CDN. Обоснование: Минимизирует время кругового пути (RTT) и затраты на межрегиональный исходящий трафик.
• Периодически анализируйте журналы потоков для выявления избыточного трафика между зонами и корректируйте размещение или границы сервисов. Обоснование: Сокращает ненужный исходящий трафик и задержки.

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

← Хранение данных · Все домены · Безопасность →

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

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