Эта страница переведена с помощью Cloud Translation API.

База данных Agentspace to Zonal NEG, размещенная на собственном сервере

1. Введение

В этом практическом задании вы развернете внутренний балансировщик нагрузки TCP-прокси и группу зональных сетевых конечных точек (NEG), опубликованную как служба производителя PSC. Группа NEG будет состоять из одного или нескольких вычислительных экземпляров в GCP, самостоятельно размещающих базу данных, например, JIRA, Confluence или SharePoint.

Private Service Connect — это функция сетевых возможностей Google Cloud, которая позволяет потребителям получать доступ к управляемым сервисам в частном порядке из своей сети VPC. Аналогичным образом, она позволяет производителям управляемых сервисов размещать эти сервисы в своих собственных сетях VPC или межоблачных сетях, предлагая своим потребителям частное соединение. Например, при использовании Private Service Connect для доступа к Zonal NEG вы являетесь производителем сервиса, а Google (Agentspace) — потребителем сервиса.

Что вы узнаете

Сетевые требования для Agentspace
Передовые методы организации сетевого взаимодействия в Agentspace
Создайте сервис Private Service Connect Producer.

Что вам понадобится

Проект Google Cloud с правами владельца.

2. Что вы построите

Вам потребуется создать сеть Producer, agentspace-psc-demo, для развертывания внутреннего балансировщика нагрузки TCP-прокси и Zonal NEG, опубликованных в качестве сервиса через Private Service Connect (PSC).

3. Требования к сети

Ниже приведено описание сетевых требований для сети производителя, а потребителем в данном практическом задании является Agentspace.

Компоненты	Описание
VPC (agentspace-psc-demo)	Пользовательский режим VPC
Подсеть NAT PSC	Пакеты из сети VPC потребителя преобразуются с помощью NAT источника (SNAT), так что их исходные IP-адреса преобразуются в IP-адреса из подсети NAT в сети VPC производителя. PSC NAT поддерживает подсеть /29 для каждого сервисного подключения.
подсеть правил пересылки PSC	Используется для выделения IP-адреса для регионального внутреннего балансировщика нагрузки TCP-прокси . Подсеть правила пересылки считается обычной подсетью.
Подсеть NEG	Используется для выделения IP-адреса группе сетевых конечных точек из обычной подсети.
Подсеть только для прокси	Каждому прокси-серверу балансировщика нагрузки назначается внутренний IP-адрес. Пакеты, отправляемые с прокси-сервера на виртуальную машину бэкэнда или группу сетевых конечных точек, имеют исходный IP-адрес из подсети, предназначенной только для прокси. Рекомендуется использовать подсеть /23, хотя поддерживается и минимальная подсеть /26. Для каждого региона требуется одна региональная подсеть прокси.
Бэкенд-сервис	Бэкенд-сервис выступает в качестве связующего звена между вашим балансировщиком нагрузки и вашими бэкенд-ресурсами. В данном руководстве бэкенд-сервис связан с Zonal NEG.

4. Передовые методы

Зональные NEG поддерживают один или несколько зональных экземпляров GCE в зависимости от параметра GCE_VM_IP_PORT.
Перед созданием сервисного вложения включите глобальный доступ к правилу пересылки производителя.
Включите глобальный доступ при создании конечной точки Agentspace.
Внутренний TCP-прокси-балансировщик нагрузки также поддерживает управляемые и неуправляемые группы экземпляров.
Существующие TCP-прокси или балансировщики нагрузки Google Cloud Passthrough можно использовать в качестве сервиса производителя.

5. Топология Codelab

6. Настройка и требования

Настройка среды для самостоятельного обучения

Войдите в консоль Google Cloud и создайте новый проект или используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .

Название проекта — это отображаемое имя участников данного проекта. Это строка символов, не используемая API Google. Вы всегда можете его изменить.
Идентификатор проекта уникален для всех проектов Google Cloud и является неизменяемым (его нельзя изменить после установки). Консоль Cloud автоматически генерирует уникальную строку; обычно вам неважно, какая она. В большинстве практических заданий вам потребуется указать идентификатор вашего проекта (обычно обозначается как PROJECT_ID ). Если сгенерированный идентификатор вас не устраивает, вы можете сгенерировать другой случайный идентификатор. В качестве альтернативы вы можете попробовать свой собственный и посмотреть, доступен ли он. После этого шага его нельзя изменить, и он сохраняется на протяжении всего проекта.
К вашему сведению, существует третье значение — номер проекта , которое используется некоторыми API. Подробнее обо всех трех значениях можно узнать в документации .

Далее вам потребуется включить оплату в консоли Cloud для использования ресурсов/API Cloud. Выполнение этого практического задания не потребует больших затрат, если вообще потребует. Чтобы отключить ресурсы и избежать дополнительных расходов после завершения этого урока, вы можете удалить созданные ресурсы или удалить проект. Новые пользователи Google Cloud имеют право на бесплатную пробную версию стоимостью 300 долларов США .

Запустить Cloud Shell

Хотя Google Cloud можно управлять удаленно с ноутбука, в этом практическом занятии вы будете использовать Google Cloud Shell — среду командной строки, работающую в облаке.

В консоли Google Cloud нажмите на значок Cloud Shell на панели инструментов в правом верхнем углу:

Подготовка и подключение к среде займут всего несколько минут. После завершения вы должны увидеть что-то подобное:

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

7. Прежде чем начать

Включить API

Внутри Cloud Shell убедитесь, что идентификатор вашего проекта указан правильно:

gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
project=[YOUR-PROJECT-ID]
region=[YOUR-REGION]
zone1a=[YOUR-ZONE1a]
zone1b=[YOUR-ZONE1b]
echo $project
echo $region
echo $zone1a
echo $zone1b

Включите все необходимые службы:

gcloud services enable compute.googleapis.com

8. Создайте сеть VPC для производителей.

Сеть VPC

Внутри Cloud Shell выполните следующие действия:

gcloud compute networks create agentspace-psc-demo --subnet-mode custom

Создание подсетей

Подсеть PSC будет связана с подключением к сервису PSC для целей преобразования сетевых адресов.

Внутри Cloud Shell создайте подсеть PSC NAT:

gcloud compute networks subnets create producer-psc-nat-subnet --network agentspace-psc-demo --range 172.16.10.0/28 --region $region --purpose=PRIVATE_SERVICE_CONNECT

Внутри Cloud Shell создайте подсеть для правила пересылки Producer:

gcloud compute networks subnets create producer-psc-fr-subnet --network agentspace-psc-demo --range 172.16.20.0/28 --region $region --enable-private-ip-google-access

Внутри Cloud Shell создайте подсеть Network Endpoint Group:

gcloud compute networks subnets create neg-subnet --network agentspace-psc-demo --range 172.16.30.0/28 --region $region --enable-private-ip-google-access

Внутри Cloud Shell создайте региональную подсеть Producer, доступную только через прокси.

gcloud compute networks subnets create $region-proxy-only-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=$region \
  --network=agentspace-psc-demo \
  --range=10.10.10.0/24

Зарезервировать IP-адрес балансировщика нагрузки

Внутри Cloud Shell зарезервируйте внутренний IP-адрес для балансировщика нагрузки:

gcloud compute addresses create zonal-neg-lb-ip \
  --region=$region \
  --subnet=producer-psc-fr-subnet

Внутри Cloud Shell можно просмотреть зарезервированный IP-адрес.

gcloud compute addresses describe zonal-neg-lb-ip \
  --region=$region | grep -i address:

Пример выходных данных:

gcloud compute addresses describe zonal-neg-lb-ip --region=$region | grep -i address:
address: 172.16.20.2

Настройте зональный NEG

В следующем разделе вы создадите группу конечных точек зональной сети, содержащую один или несколько IP-адресов или комбинаций IP-адреса и целевого порта:

Основной внутренний IPv4-адрес сетевого интерфейса виртуальной машины.
Основной внутренний IPv4-адрес сетевого интерфейса виртуальной машины плюс номер целевого порта.
Внутренний IPv4-адрес из диапазона псевдонимов IP-адресов, назначенный сетевому интерфейсу виртуальной машины.
Внутренний IPv4-адрес из диапазона псевдонимов IP-адресов, назначенный сетевому интерфейсу виртуальной машины, плюс номер целевого порта.

Сетевой интерфейс, содержащий конечную точку GCE_VM_IP_PORT, должен находиться в подсети NEG. Если номер порта не указан в конечной точке GCE_VM_IP_PORT, Google Cloud использует номер порта NEG по умолчанию для этой конечной точки.

В эталонной архитектуре экземпляры GCE, связанные с зональной NEG, состоят из следующих элементов:

database-us-central1-a | us-central1-a | IP: 100.100.10.2 | Порт: 443
database-us-central1-a | us-central1-b | IP: 100.100.10.3 | Порт: 443
Название подсети: database-subnet-1

Создайте зональный NEG для зоны 1a.

В следующем разделе вы создадите группу сетевых конечных точек для каждой зоны, например, us-central1-a, и укажете имя подсети, используемой для создания экземпляра GCE. В эталонной архитектуре имя подсети — database-subnet-1.

Внутри Cloud Shell создайте Zonal NEG:

gcloud compute network-endpoint-groups create us-central-zonal-neg-1a \
    --zone=$zone1a \
    --network=agentspace-psc-demo \
    --subnet=database-subnet-1 \
    --default-port=443

Внутри Cloud Shell обновите Zonal NEG, указав IP-адрес и порт экземпляра GCE, развернутого в зоне 1a. В эталонной архитектуре экземпляр GCE имеет IP-адрес 100.100.10.2 и порт 443, развернут в зоне us-central1-a.

gcloud compute network-endpoint-groups update us-central-zonal-neg-1a --zone=$zone1a --add-endpoint instance=database-us-central1-a,port=443

Создайте зональный NEG для зоны 1b.

В следующем разделе вы создадите группу сетевых конечных точек для каждой зоны, например, us-central1-b, и укажете имя подсети, используемой для создания экземпляра GCE. В эталонной архитектуре имя подсети — database-subnet-1.

Внутри Cloud Shell создайте Zonal NEG:

gcloud compute network-endpoint-groups create us-central-zonal-neg-1b \
    --zone=$zone1b \
    --network=agentspace-psc-demo \
    --subnet=database-subnet-1 \
    --default-port=443

Внутри Cloud Shell обновите Zonal NEG, указав IP-адрес и порт экземпляра GCE, развернутого в зоне 1b. В эталонной архитектуре экземпляр GCE имеет IP-адрес 100.100.10.3, порт 443 и развернут в зоне us-central1-b.

gcloud compute network-endpoint-groups update us-central-zonal-neg-1b --zone=$zone1b --add-endpoint instance=database-us-central1-b,port=443

Создайте региональную проверку состояния здоровья.

Внутри Cloud Shell создайте проверку работоспособности, которая будет проверять порт локальной базы данных, 443:

gcloud compute health-checks create tcp zonal-443-healthcheck \
    --region=$region \
    --port=443

Создание политики и правил сетевого брандмауэра

Внутри Cloud Shell выполните следующие действия:

gcloud compute network-firewall-policies create agentspace-psc-demo-policy --global

gcloud compute network-firewall-policies associations create --firewall-policy agentspace-psc-demo-policy --network agentspace-psc-demo --name agentspace-psc-demo --global-firewall-policy

Следующее правило брандмауэра разрешает трафик из диапазона подсетей NAT PSC ко всем экземплярам в сети.

Внутри Cloud Shell выполните следующие действия:

gcloud compute network-firewall-policies rules create 2001 --action ALLOW --firewall-policy agentspace-psc-demo-policy --description "allow traffic from PSC NAT subnet to GCE" --direction INGRESS --src-ip-ranges 172.16.10.0/28 --global-firewall-policy --layer4-configs=tcp

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

Внутри Cloud Shell выполните следующие действия:

gcloud compute network-firewall-policies rules create 2002 --action ALLOW --firewall-policy agentspace-psc-demo-policy --description "allow internal probe health check range to GCE" --direction INGRESS --src-ip-ranges 35.191.0.0/16,130.211.0.0/22 --global-firewall-policy --layer4-configs=tcp:443

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

Внутри Cloud Shell выполните следующие действия:

gcloud compute network-firewall-policies rules create 2003 --action ALLOW --firewall-policy agentspace-psc-demo-policy --description "allow internal tcp proxy health check range to GCE" --direction INGRESS --src-ip-ranges 10.10.10.0/24 --global-firewall-policy --layer4-configs=tcp:443

9. Создать сервис для производителей.

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

Внутри Cloud Shell создайте серверную службу:

gcloud compute backend-services create producer-backend-svc --region=$region --load-balancing-scheme=INTERNAL_MANAGED --protocol=TCP --region=$region --health-checks=zonal-443-healthcheck --health-checks-region=$region

Внутри Cloud Shell свяжите зональный NEG, us-central-zonal-neg-1a, с бэкэнд-сервисом:

gcloud compute backend-services add-backend producer-backend-svc \
   --network-endpoint-group=us-central-zonal-neg-1a  \
   --network-endpoint-group-zone=$zone1a \
   --balancing-mode=CONNECTION \
   --max-connections-per-endpoint=100 \
   --region=$region

Внутри Cloud Shell свяжите Zonal NEG, us-central-zonal-neg-1b, с бэкэнд-сервисом:

gcloud compute backend-services add-backend producer-backend-svc \
   --network-endpoint-group=us-central-zonal-neg-1b  \
   --network-endpoint-group-zone=$zone1b \
   --balancing-mode=CONNECTION \
   --max-connections-per-endpoint=100 \
   --region=$region

В Cloud Shell создайте целевой TCP-прокси для маршрутизации запросов к вашему бэкэнд-сервису:

gcloud compute target-tcp-proxies create producer-lb-tcp-proxy \
      --backend-service=producer-backend-svc  \
      --region=$region

В приведенном ниже синтаксисе создайте правило пересылки (внутренний балансировщик нагрузки TCP-прокси) с включенным глобальным доступом.

В оболочке Cloud Shell выполните следующие действия:

gcloud compute forwarding-rules create producer-zonal-neg-fr \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network-tier=PREMIUM \
     --network=agentspace-psc-demo \
     --subnet=producer-psc-fr-subnet \
     --address=zonal-neg-lb-ip \
     --target-tcp-proxy=producer-lb-tcp-proxy \
     --target-tcp-proxy-region=$region \
     --region=$region \
     --allow-global-access \
     --ports=443

Проверка работоспособности бэкэнда

Проверьте работоспособность (зеленый статус) серверной службы и связанных с ней вычислительных экземпляров с помощью облачной консоли, описанной в следующем разделе. Перейдите по следующей ссылке:

Сетевые сервисы → Балансировка нагрузки → Сервис бэкенда производителя

Создать вложение услуги

Для публикации сервиса необходимо создать вложение сервиса в Private Service Connect. Публикацию сервиса можно осуществить как с автоматическим, так и с явным подтверждением.

Чтобы опубликовать сервис и автоматически разрешить любому потребителю подключаться к нему, следуйте инструкциям по ссылке «Публикация сервиса с автоматическим подтверждением» .
Чтобы опубликовать сервис с явным согласием потребителя , в настройках подключения сервиса выберите «Принимать подключения для выбранных проектов» и оставьте поле «Принятые проекты» пустым.
После создания подключения к сервису конечные точки потребителя, запрашивающие доступ к сервису производителя, первоначально перейдут в состояние ожидания. Для авторизации подключения производитель должен принять проект, от которого поступил запрос к конечной точке потребителя.

Внутри Cloud Shell создайте вложение службы cc-database1-svc-attachment с автоматическим подтверждением:

gcloud compute service-attachments create zonal-database1-svc-attachment --region=$region --producer-forwarding-rule=producer-zonal-neg-fr --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=producer-psc-nat-subnet

Далее получите и запишите вложение службы, указанное в URI selfLink, начинающемся с projects, чтобы настроить конечную точку PSC в Agentspace.

selfLink: projects/<your-project-id>/regions/<your-region>/serviceAttachments/zonal-database1-svc-attachment

Внутри Cloud Shell выполните следующие действия:

gcloud compute service-attachments describe zonal-database1-svc-attachment --region=$region

Пример ожидаемого результата:

connectionPreference: ACCEPT_AUTOMATIC
creationTimestamp: '2025-07-12T16:00:22.429-07:00'
description: ''
enableProxyProtocol: false
fingerprint: zOpeRQnPWSc=
id: '1784245893044590569'
kind: compute#serviceAttachment
name: zonal-database1-svc-attachment
natSubnets:
- https://www.googleapis.com/compute/v1/projects/$project-svc4/regions/us-central1/subnetworks/producer-psc-nat-subnet
pscServiceAttachmentId:
  high: '119824781489996776'
  low: '1784245893044590569'
reconcileConnections: false
region: https://www.googleapis.com/compute/v1/projects/$project-svc4/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/$project-svc4/regions/us-central1/serviceAttachments/zonal-database1-svc-attachment
targetService: https://www.googleapis.com/compute/v1/projects/$project-svc4/regions/us-central1/forwardingRules/producer-zonal-neg-fr

В консоли Cloud перейдите по следующему пути:

Сетевые службы → Подключение к частной службе → Опубликованные службы

10. Установите соединение с конечной точкой PSC в Agentspace.

Свяжите URI подключения сервиса Producers с Agentspace, убедившись, что выбран глобальный доступ. Ниже приведен пример включения глобального доступа с использованием сервиса подключения эталонной архитектуры.

Для завершения настройки частной сети обратитесь к сторонним источникам данных Agentspace за дальнейшими инструкциями.

Проверьте конечную точку PSC в Cloud Console.

Для подтверждения успешного подключения PSC между Agentspace (потребителем) и производителем проверьте проект арендатора Agentspace, связанный со службой производителя. Его можно найти в разделе «Подключенные проекты». Идентификатор проекта арендатора присваивается случайным образом, но всегда заканчивается на «tp».

В консоли Cloud Console вы можете проверить подключение к PSC. В консоли Cloud Console перейдите по следующему пути:

Сетевые службы → Подключение к частной службе → Опубликованная служба, затем выберите службу zonal-database1-svc-attachment.

11. Уборка

Из одного терминала Cloud Shell удалите компоненты лаборатории.

gcloud compute service-attachments delete zonal-database1-svc-attachment --region=$region -q

gcloud compute forwarding-rules delete producer-zonal-neg-fr --region=$region -q

gcloud compute target-tcp-proxies delete producer-lb-tcp-proxy --region=$region -q

gcloud compute backend-services delete producer-backend-svc --region=$region -q

gcloud compute network-firewall-policies rules delete 2001 --firewall-policy agentspace-psc-demo-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 2002 --firewall-policy agentspace-psc-demo-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 2003 --firewall-policy agentspace-psc-demo-policy --global-firewall-policy -q

gcloud compute network-firewall-policies associations delete --firewall-policy=agentspace-psc-demo-policy  --name=agentspace-psc-demo --global-firewall-policy -q

gcloud compute network-firewall-policies delete agentspace-psc-demo-policy --global -q

gcloud compute network-endpoint-groups delete us-central-zonal-neg-1a --zone=$zone1a -q

gcloud compute network-endpoint-groups delete us-central-zonal-neg-1b --zone=$zone1b -q

gcloud compute addresses delete zonal-neg-lb-ip --region=$region -q

gcloud compute networks subnets delete $region-proxy-only-subnet --region=$region -q

gcloud compute networks subnets delete producer-psc-nat-subnet --region=$region -q

gcloud compute networks subnets delete producer-psc-fr-subnet --region=$region -q

gcloud compute networks subnets delete neg-subnet --region=$region -q

gcloud compute health-checks delete zonal-443-healthcheck --region=us-central1 -q

gcloud compute networks delete agentspace-psc-demo -q

12. Поздравляем!

Поздравляем, вы успешно настроили и опубликовали службу Producer с использованием Private Service Connected.

Вы создали инфраструктуру для производителей, научились создавать зональные NEG, сервисы для производителей и связывать подключение сервиса с Agentspace.

Cosmopup считает, что Codelabs — это круто!!

Что дальше?

Посмотрите некоторые из этих практических занятий по программированию...

Дополнительная литература и видеоматериалы

Обзор Private Service Connect

1. Введение

Что вы узнаете

Что вам понадобится

2. Что вы построите

3. Требования к сети

4. Передовые методы

5. Топология Codelab

6. Настройка и требования

Настройка среды для самостоятельного обучения

Запустить Cloud Shell

7. Прежде чем начать

Включить API

8. Создайте сеть VPC для производителей.

Сеть VPC

Создание подсетей

Зарезервировать IP-адрес балансировщика нагрузки

Настройте зональный NEG

Создайте зональный NEG для зоны 1a.

Создайте зональный NEG для зоны 1b.

Создайте региональную проверку состояния здоровья.

Создание политики и правил сетевого брандмауэра

9. Создать сервис для производителей.

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

Проверка работоспособности бэкэнда

Создать вложение услуги

10. Установите соединение с конечной точкой PSC в Agentspace.

Проверьте конечную точку PSC в Cloud Console.

11. Уборка

12. Поздравляем!

Что дальше?

Дополнительная литература и видеоматериалы

Справочная документация