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

1. Введение

ПРИМЕЧАНИЕ: Эта практическая работа содержит рекомендации по настройке доступа к существующей базе данных, размещенной на GCE, с использованием зонального NEG, опубликованного через Private Service Connect. При необходимости измените практическую работу в соответствии с требованиями вашей организации.

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

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

Чему вы научитесь

• Сетевые требования для Agentspace
• Лучшие практики сетевого взаимодействия Agentspace
• Создайте частную службу Connect Producer

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

• Проект Google Cloud с разрешениями владельца

2. Что вы будете строить

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

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

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

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

4. Лучшие практики

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

5. Топология кодлаб-программы

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

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

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

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

Внимание: Идентификатор проекта уникален в глобальном масштабе и не может быть использован кем-либо ещё после того, как вы его выбрали. Вы являетесь единственным пользователем этого идентификатора. Даже если проект будет удалён, этот идентификатор нельзя будет использовать повторно.

Примечание: Если вы используете учётную запись Gmail, вы можете оставить местоположение по умолчанию « Нет организации» . Если вы используете учётную запись Google Workspace, выберите местоположение, подходящее для вашей организации.

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

Запустить Cloud Shell

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

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

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

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

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 Regional Proxy Only.

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 создайте зональный 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 обновите зональный NEG, указав IP:порт экземпляра GCE, развернутого в зоне 1a; в эталонной архитектуре экземпляр GCE — это порт 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 создайте зональный 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 обновите зональный NEG, указав IP:порт экземпляра GCE, развернутого в зоне 1b; в эталонной архитектуре экземпляр GCE — это порт 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

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

Внутри 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 свяжите зональный 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

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

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

Сетевые службы → Балансировка нагрузки → Producer-backend-svc

Создать приложение к услуге

Чтобы опубликовать услугу, необходимо создать вложение к Private Service Connect. Вы можете опубликовать услугу с автоматическим или явным одобрением.

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

Внутри 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, начиная с проектов по настройке конечной точки 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 Console перейдите к:

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

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

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

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

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

Чтобы убедиться в успешном подключении PSC между Agentspace (потребителем) и Producer, проверьте проект клиента Agentspace, связанный со службой Producer. Его можно найти в разделе «Подключенные проекты». Идентификатор проекта клиента назначается случайным образом, но всегда заканчивается на «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 с подключенной частной службой.

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

Cosmopup считает, что лабораторные занятия — это здорово!

Что дальше?

Ознакомьтесь с некоторыми из этих практикумов...

• Использование Private Service Connect для публикации и потребления услуг
• Доступ ко всем опубликованным практическим занятиям Private Service Connect

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

• Обзор Private Service Connect

Справочные документы

• Обзор внутреннего прокси-балансировщика сетевой нагрузки
• Настройка регионального внутреннего прокси-сервера балансировки сетевой нагрузки с зональными NEG-серверами
• Как опубликовать услугу с помощью Private Service Connect