내부 패스 스루 네트워크 부하 분산기를 다음 홉(태그 포함)으로 설정

이 튜토리얼에서는 예를 사용하여 패킷이 최종 대상까지의 경로를 따라 전달되는 내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 배포하는 방법을 보여줍니다. 네트워크 태그를 사용하여 경로가 적용되는 특정 클라이언트 인스턴스를 구성합니다.

이 가이드에서는 사용자가 내부 패스 스루 네트워크 부하 분산기, 방화벽 규칙 및 상태 확인과 같은 관련 구성요소, 그리고 경로를 따라 패킷을 전달할 다음 홉으로 내부 패스 스루 네트워크 부하 분산기를 사용하는 방식에 익숙하다고 가정합니다.

내부 패스 스루 네트워크 부하 분산기를 다음 홉 기능으로 사용하면 가용성이 높은 수평 확장 방식으로 타사 어플라이언스를 통합할 수 있습니다. 이를 위해서는 커스텀 정적 경로를 구성하고 다음 홉을 부하 분산기로 설정해야 합니다. 그러면 대상 프리픽스의 트래픽을 상태가 확인된 타사 VM 어플라이언스 풀에 배포합니다. 이러한 타사 어플라이언스의 고가용성을 지원하기 위한 다음 홉을 선택할 때 몇 가지 옵션이 있습니다.

IP 주소를 다음 홉으로 지정: 전달 규칙과 연결된 내부 IP 주소를 다음 홉으로 사용합니다. 이 로드 밸런서의 가상 IP 주소는 해당 피어를 통해 커스텀 경로를 내보낼 필요 없이 피어 전체에서 학습할 수 있습니다.
네트워크 태그 사용: 다음 홉 경로로 내부 패스 스루 네트워크 부하 분산기가 태그로 구성된 클라이언트 인스턴스에만 적용되도록 네트워크 태그를 지정할 수 있습니다. 이렇게 하면 다음 홉 경로로 태그가 지정된 내부 패스 스루 네트워크 부하 분산기와 트래픽을 라우팅할 어플라이언스 세트로 채워질 클라이언트 인스턴스를 선택할 수 있습니다. 서로 다른 클라이언트 인스턴스를 각각 어플라이언스 집합을 프런트엔드하는 선호하는 내부 패스 스루 네트워크 부하 분산기를 가리키도록 별도의 VPC로 분리할 필요는 없습니다. 참고: 태그 지정된 경로는 VPC 네트워크 피어링을 통해 내보내기 또는 가져오기를 수행하지 않습니다.
동일한 대상 프리픽스에 대한 여러 경로 구성: 태그를 사용하면 다른 내부 로드 밸런서를 다음 홉으로 사용하여 동일한 대상에 대한 여러 경로를 지정할 수 있습니다. ECMP는 지원되지 않지만(동일한 대상 프리픽스, 동일한 태그, 서로 다른 다음 홉) 동일한 대상 경로에 대해 다른 태그 또는 다른 우선순위를 사용할 수 있습니다.

설정 개요

단일 NIC가 포함된 VM을 사용하는 관리형 인스턴스 그룹은 인터넷에 대한 모든 아웃바운드 트래픽(North-South 아웃바운드 트래픽 흐름)을 SNAT 변환하도록 구성된 Linux 인스턴스와 함께 다른 리전에서 정의됩니다. 리전 장애 조치는 수동으로 트리거됩니다. 또한 이 튜토리얼에서는 내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 사용하여 대칭 해싱을 사용하는 East-West 연결을 보여줍니다.

이 섹션의 단계에서는 다음을 구성하는 방법을 설명합니다.

커스텀 서브넷이 있는 샘플 VPC 네트워크
백엔드 VM에 대한 수신 연결을 허용하는 방화벽 규칙
NAT 게이트웨이를 배포하는 백엔드 관리형 인스턴스 그룹
연결을 테스트하기 위한 클라이언트 VM
다음 내부 패스 스루 네트워크 부하 분산기 구성요소:
- 백엔드 서비스의 상태 확인
- 내부 백엔드 서비스
- 부하 분산기의 프런트엔드에 대한 내부 전달 규칙 및 IP 주소

이 예시의 아키텍처는 다음과 같습니다.

이 튜토리얼의 단계에 따라 REGION_A 및 REGION_B을 이 예시에서 사용할 각 리전으로 바꿉니다.

VPC 네트워크 및 서브넷 만들기

hub-vpc라는 VPC 네트워크를 만듭니다.

gcloud compute networks create hub-vpc --subnet-mode custom

REGION_A의 hub-vpc에 서브넷을 만듭니다.

gcloud compute networks subnets create hub-subnet-a \
    --network hub-vpc \
    --range 10.0.0.0/24 \
    --region REGION_A

region B의 hub-vpc에 서브넷을 만듭니다.

gcloud compute networks subnets create hub-subnet-b \
    --network hub-vpc \
    --range 10.0.1.0/24 \
    --region REGION_B

spoke1-vpc라는 VPC 네트워크를 만듭니다.

gcloud compute networks create spoke1-vpc --subnet-mode custom

spoke1-vpc에 서브넷을 만듭니다.

gcloud compute networks subnets create spoke1-subnet1 \
    --network spoke1-vpc \
    --range 192.168.0.0/24 \
    --region REGION_A

spoke2-vpc라는 VPC 네트워크를 만듭니다.

gcloud compute networks create spoke2-vpc --subnet-mode custom

spoke2-vpc에 서브넷을 만듭니다.

gcloud compute networks subnets create spoke2-subnet1 \
    --network spoke2-vpc \
    --range 192.168.1.0/24 \
    --region REGION_A

방화벽 규칙 구성

TCP, UDP, ICMP 트래픽이 지정된 소스 범위의 인스턴스에 도달할 수 있도록 다음 방화벽 규칙을 구성합니다.

gcloud compute firewall-rules create hub-vpc-web-ping-dns \
    --network hub-vpc \
    --allow tcp:80,tcp:443,icmp,udp:53 \
    --source-ranges 10.0.0.0/24,10.0.1.0/24,192.168.0.0/24,192.168.1.0/24

gcloud compute firewall-rules create spoke1-vpc-web-ping-dns \
    --network spoke1-vpc \
    --allow tcp:80,tcp:443,icmp,udp:53 \
    --source-ranges 10.0.0.0/24,10.0.1.0/24,192.168.0.0/24,192.168.1.0/24

gcloud compute firewall-rules create spoke2-vpc-web-ping-dns \
    --network spoke2-vpc \
    --allow tcp:80,tcp:443,icmp,udp:53 \
    --source-ranges 10.0.0.0/24,10.0.1.0/24,192.168.0.0/24,192.168.1.0/24

상태 점검 프로버가 hub-vpc의 인스턴스에 액세스할 수 있도록 방화벽 규칙을 만듭니다.

gcloud compute firewall-rules create hub-vpc-health-checks \
    --network hub-vpc \
    --allow tcp:80 \
    --target-tags natgw \
    --source-ranges 130.211.0.0/22,35.191.0.0/16

모든 서브넷의 인스턴스에서 SSH 액세스를 허용하는 방화벽 규칙을 만듭니다. TCP 전달에 IAP(Identity-Aware Proxy)를 사용하려면(권장) 다음 단계에 따라 SSH를 사용 설정합니다.

gcloud compute firewall-rules create hub-vpc-allow-ssh \
    --network hub-vpc \
    --allow tcp:22

gcloud compute firewall-rules create spoke1-vpc-allow-ssh \
    --network spoke1-vpc \
    --allow tcp:22

gcloud compute firewall-rules create spoke2-vpc-allow-ssh \
    --network spoke2-vpc \
    --allow tcp:22

VPC 네트워크 피어링 구성하기

hub-vpc에서 spoke1-vpc로 피어링을 만듭니다.

gcloud compute networks peerings create hub-to-spoke1 \
    --network hub-vpc \
    --peer-network spoke1-vpc \
    --peer-project PROJECT_ID \
    --export-custom-routes

spoke1-vpc에서 hub-vpc로 피어링을 만듭니다.

gcloud compute networks peerings create spoke1-to-hub \
    --network spoke1-vpc \
    --peer-network hub-vpc \
    --peer-project PROJECT_ID \
    --import-custom-routes

hub-vpc에서 spoke2-vpc로 피어링을 만듭니다.

gcloud compute networks peerings create hub-to-spoke2 \
    --network hub-vpc \
    --peer-network spoke2-vpc \
    --peer-project PROJECT_ID \
    --export-custom-routes

spoke2-vpc에서 hub-vpc로 피어링을 만듭니다.

gcloud compute networks peerings create spoke2-to-hub \
    --network spoke2-vpc \
    --peer-network hub-vpc \
    --peer-project PROJECT_ID \
    --import-custom-routes

리전 A에 NAT 게이트웨이 VM 및 부하 분산 리소스 만들기

REGION_A에서 관리형 인스턴스 그룹 백엔드를 만듭니다. 그런 다음 부하 분산 리소스와 다음 홉 경로를 만듭니다.

관리형 인스턴스 그룹 만들기

region A에서 NAT 게이트웨이를 배포할 인스턴스 템플릿을 만듭니다.

gcloud compute instance-templates create hub-natgw-region-a-template \
    --network hub-vpc \
    --subnet hub-subnet-a \
    --region REGION_A \
    --machine-type n1-standard-2 \
    --can-ip-forward \
    --tags natgw \
    --metadata startup-script='#! /bin/bash
# Enable IP forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
# iptables configuration
iptables -t nat -F
sudo iptables -t nat -A POSTROUTING ! -d 192.168.0.0/16 -j MASQUERADE
iptables-save
# Use a web server to pass the health check for this example.
# You should use a more complete test in production.
apt-get update
apt-get install apache2 tcpdump -y
a2ensite default-ssl
a2enmod ssl
echo "Example web page to pass health check" | \
tee /var/www/html/index.html \
systemctl restart apache2'

REGION_A에 인스턴스 그룹을 만듭니다.

gcloud compute instance-groups managed create hub-natgw-region-a-mig \
    --region REGION_A \
    --size=2 \
    --template=hub-natgw-region-a-template

부하 분산기 만들기

REGION_A에서 부하 분산기를 만들려면 다음 단계를 수행하세요.

상태 확인을 만듭니다.

gcloud compute health-checks create http natgw-ilbnhop-health-check \
    --port=80

백엔드 서비스를 만듭니다.

gcloud compute backend-services create hub-natgw-region-a-be \
    --load-balancing-scheme=internal \
    --protocol tcp \
    --region REGION_A\
    --health-checks=natgw-ilbnhop-health-check

관리형 인스턴스 그룹을 백엔드로 추가합니다.

gcloud compute backend-services add-backend hub-natgw-region-a-be \
    --instance-group=hub-natgw-region-a-mig \
    --instance-group-region=REGION_A

전달 규칙을 만듭니다.

gcloud compute forwarding-rules create hub-natgw-region-a \
    --load-balancing-scheme=internal \
    --network=hub-vpc \
    --subnet=hub-subnet-a \
    --address=10.0.0.10 \
    --ip-protocol=TCP \
    --ports=all \
    --allow-global-access \
    --backend-service=hub-natgw-region-a-be \
    --backend-service-region=REGION_A

다음 홉 경로 만들기

사전 정의된 네트워크 태그 ilbanh-region-a를 사용하여 다음 홉 경로인 내부 패스 스루 네트워크 부하 분산기를 만듭니다.

gcloud compute routes create spoke1-natgw-region-a \
    --network=spoke1-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.0.10 \
    --tags=ilbanh-region-a \
    --priority 800

gcloud compute routes create spoke2-natgw-region-a \
    --network=spoke2-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.0.10 \
    --tags=ilbanh-region-a \
    --priority 800

연결 테스트

클라이언트 인스턴스를 만들어 연결을 테스트합니다.

spoke1-vpc에서 테스트 클라이언트 인스턴스를 만듭니다.

gcloud compute instances create spoke1-client \
    --subnet=spoke1-subnet1 --no-address --zone ZONE_A \
    --tags=ilbanh-region-a \
    --metadata startup-script='#! /bin/bash
apt-get update
apt-get install tcpdump -y'

spoke2-vpc에서 테스트 클라이언트 인스턴스를 만듭니다.

gcloud compute instances create spoke2-client \
    --subnet=spoke2-subnet1 --no-address --zone ZONE_A \
    --tags=ilbanh-region-a \
    --metadata startup-script='#! /bin/bash
apt-get update
apt-get install tcpdump -y'

North-South 및 East-West 트래픽 흐름 검증

NAT 게이트웨이 VM이 실행 중인지 확인하고 할당된 외부 IP 주소를 기록합니다.
```
gcloud compute instances list --filter="status:RUNNING AND name~natgw"
```

부하 분산기가 정상 상태이고 경로가 예상대로 만들어졌는지 확인합니다.

gcloud compute backend-services get-health hub-natgw-region-a-be --region REGION_A

backend: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/instanceGroups/hub-natgw-region-a-mig
status:
  healthStatus:
  - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/forwardingRules/hub-natgw-region-a
    forwardingRuleIp: 10.0.0.10
    healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-central1-b/instances/<INSTANCE_NAME>
    ipAddress: 10.0.0.5
    port: 80
  - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/forwardingRules/hub-natgw-region-a
    forwardingRuleIp: 10.0.0.10
    healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-central1-f/instances/<INSTANCE_NAME>
    ipAddress: 10.0.0.6
    port: 80
  kind: compute#backendServiceGroupHealth

다음 홉 경로인 내부 패스 스루 네트워크 부하 분산기가 예상 우선순위가 있는 스포크 VPC에 추가되고 내부 패스 스루 네트워크 부하 분산기의 IP 주소를 타겟팅하는지 확인합니다.
```
gcloud compute routes list --filter="name~natgw"
```
Google Cloud 콘솔로 이동하여 다른 탭에서 NAT 게이트웨이 VM에 대한 SSH 연결을 설정합니다.
다음 명령어를 사용하여 각 SSH 세션에서 tcpdump를 시작합니다.
```
sudo tcpdump -n net 192.168.0.0/16
```
Google Cloud 콘솔로 이동하여 spoke1-client VM에 대한 새 SSH 연결을 설정합니다. 그런 후 다음 명령어를 사용하여 spoke2-client 내부 IP 주소를 핑합니다.
```
ping SPOKE2_CLIENT_INTERNAL_IP
```
NAT 게이트웨이 SSH 창으로 전환하고 다음과 같이 ICMP 패킷을 볼 수 있는지 확인하세요.
```
16:51:28.411260 IP 192.168.0.2 > 192.168.1.2: ICMP echo request, id 1684, seq 492, length 64
16:51:28.411676 IP 192.168.1.2 > 192.168.0.2: ICMP echo reply, id 1684, seq 492, length 64
```
다음을 보여주는 클라이언트 VM을 성공적으로 핑할 수 있어야 합니다.
- East-West 트래픽은 NAT 게이트웨이를 통해 사용 설정됩니다. 스포크 VPC 간 전환 피어링은 지원되지 않습니다.
- 클라이언트가 SNAT 변환 없이 소스 IP 주소를 사용하여 통신할 수 있으므로 대칭 해싱이 사용 설정되어 예상대로 작동합니다.
- 모든 프로토콜은 내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 지원합니다.
NAT 게이트웨이 VM에서 tcpdump 출력을 중지하고 iptables 통계를 확인합니다.
```
watch sudo iptables -t nat -nvL
```
spoke1-client VM으로 다시 전환하고 다음 명령어를 여러 번 실행합니다. 출력에는 웹사이트에 연결하는 데 사용되는 공개 소스 IP 주소가 표시됩니다.
```
curl ifconfig.io
```
두 NAT 게이트웨이 VM의 IP 주소가 소스 IP 주소로 표시되어야 합니다. 이는 내부 패스 스루 네트워크 부하 분산기가 기본 어피니티(5튜플 해싱)에 따라 트래픽을 분산함을 보여줍니다.

NAT 게이트웨이 VM으로 다시 전환하여 패킷 카운터가 증가했는지 확인합니다.

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  105 11442 MASQUERADE  all  --  *      *       0.0.0.0/0           !192.168.0.0/16

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

리전 B에 NAT 게이트웨이 VM 및 부하 분산 리소스 만들기

region B에서 관리형 인스턴스 그룹 백엔드를 만듭니다. 그런 다음 부하 분산 리소스와 다음 홉 경로를 만듭니다.

관리형 인스턴스 그룹 만들기

region B에서 NAT 게이트웨이를 배포할 인스턴스 템플릿을 만듭니다.

gcloud compute instance-templates create hub-natgw-region-b-template \
    --network hub-vpc \
    --subnet hub-subnet-b --region REGION_B \
    --machine-type n1-standard-2 --can-ip-forward \
    --tags natgw \
    --metadata startup-script='#! /bin/bash
# Enable IP forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
# iptables configuration
iptables -t nat -F
sudo iptables -t nat -A POSTROUTING ! -d 192.168.0.0/16 -j MASQUERADE
iptables-save
# Use a web server to pass the health check for this example.
# You should use a more complete test in production.
apt-get update
apt-get install apache2 tcpdump -y
a2ensite default-ssl
a2enmod ssl
echo "Example web page to pass health check" | \
tee /var/www/html/index.html \
systemctl restart apache2'

region B에 인스턴스 그룹을 만듭니다.

gcloud compute instance-groups managed create hub-natgw-region-b-mig \
    --region REGION_B \
    --size=2 \
    --template=hub-natgw-region-b-template

부하 분산기 만들기

다음 단계를 수행하여 리전 B에 부하 분산기를 만듭니다.

백엔드 서비스를 만듭니다.

gcloud compute backend-services create hub-natgw-region-b-be \
    --load-balancing-scheme=internal \
    --protocol tcp \
    --region REGION_B\
    --health-checks=natgw-ilbnhop-health-check

관리형 인스턴스 그룹을 백엔드로 추가합니다.

gcloud compute backend-services add-backend hub-natgw-region-b-be \
    --instance-group=hub-natgw-region-b-mig \
    --instance-group-region=REGION_B

전달 규칙을 만듭니다.

gcloud compute forwarding-rules create hub-natgw-region-b \
    --load-balancing-scheme=internal \
    --network=hub-vpc \
    --subnet=hub-subnet-b \
    --address=10.0.1.10 \
    --ip-protocol=TCP \
    --ports=all \
    --allow-global-access \
    --backend-service=hub-natgw-region-b-be \
    --backend-service-region=REGION_B

다음 홉 경로 만들기

사전 정의된 네트워크 태그 ilbanh-region-a를 사용하여 다음 홉 경로인 내부 패스 스루 네트워크 부하 분산기를 만듭니다.

gcloud compute routes create spoke1-natgw-region-b \
    --network=spoke1-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.1.10 \
    --tags=ilbanh-region-a \
    --priority 900

gcloud compute routes create spoke2-natgw-region-b \
    --network=spoke2-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.1.10 \
    --tags=ilbanh-region-a \
    --priority 900

리전 장애 조치 검사하기

NAT 게이트웨이 VM이 실행 중인지 확인하고 할당된 외부 IP를 기록합니다.
```
gcloud compute instances list --filter="status:RUNNING AND name~natgw"
```

부하 분산기가 정상 상태이고 경로가 예상대로 만들어졌는지 확인합니다.

gcloud compute backend-services get-health hub-natgw-region-b-be --region REGION_B

backend: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/instanceGroups/hub-natgw-region-b-mig
status:
  healthStatus:
  - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/forwardingRules/hub-natgw-region-b
    forwardingRuleIp: 10.0.1.10
    healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-west2-a/instances/<INSTANCE_NAME>
    ipAddress: 10.0.1.3
    port: 80
  - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/forwardingRules/hub-natgw-region-b
    forwardingRuleIp: 10.0.1.10
    healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-west2-b/instances/<INSTANCE_NAME>
    ipAddress: 10.0.1.2
    port: 80
  kind: compute#backendServiceGroupHealth

다음 홉 경로인 내부 패스 스루 네트워크 부하 분산기가 예상 우선순위가 있는 스포크 VPC에 추가되고 내부 패스 스루 네트워크 부하 분산기의 IP 주소를 타겟팅하는지 확인합니다.
```
gcloud compute routes list --filter="name~natgw"
```
이제 우선순위가 높은 경로를 삭제하고 발생하는 상황을 기록하여 리전 장애 조치를 검사할 수 있습니다. spoke1-client VM으로 전환하고 다음 명령어를 실행하여 1초마다 curl 요청을 보냅니다. 이 명령어는 사용 중인 외부 IP 주소도 보고합니다.
```
while true; do echo -n `date` && echo -n ' - ' && curl ifconfig.io --connect-timeout 1; done
```
region A의 NAT 게이트웨이에 할당된 우선 순위가 높은 경로인 외부 IP 주소만 표시되어야 합니다. curl 명령어를 실행 중인 상태로 두고 Cloud Shell로 전환하여 region A에서 내부 패스 스루 네트워크 부하 분산기 경로를 삭제하여 결과를 확인합니다.
```
gcloud -q compute routes delete spoke1-natgw-region-a
```
region B에서 NAT 게이트웨이 VM에 할당된 외부 IP 주소는 최소한의 다운타임으로 나타나며, 이는 리전 장애 조치가 성공적임을 보여줍니다.

리소스 삭제

다음 홉 경로인 내부 패스 스루 네트워크 부하 분산기를 삭제합니다.

gcloud -q compute routes delete spoke1-natgw-region-b

gcloud -q compute routes delete spoke2-natgw-region-a

gcloud -q compute routes delete spoke2-natgw-region-b

내부 패스 스루 네트워크 부하 분산기 리소스 및 백엔드를 삭제합니다.

gcloud -q compute forwarding-rules delete hub-natgw-region-a \
  --region REGION_A

gcloud -q compute backend-services delete hub-natgw-region-a-be \
  --region REGION_A

gcloud -q compute instance-groups managed delete hub-natgw-region-a-mig \
  --region REGION_A

gcloud -q compute instance-templates delete hub-natgw-region-a-template

gcloud -q compute forwarding-rules delete hub-natgw-region-b \
  --region REGION_B

gcloud -q compute backend-services delete hub-natgw-region-b-be \
  --region REGION_B

gcloud -q compute instance-groups managed delete hub-natgw-region-b-mig \
  --region REGION_B

gcloud -q compute instance-templates delete hub-natgw-region-b-template

gcloud -q compute health-checks delete natgw-ilbnhop-health-check

클라이언트 VM 삭제:

gcloud -q compute instances delete spoke1-client \
  --zone=ZONE_A

gcloud -q compute instances delete spoke2-client \
  --zone=ZONE_A

VPC 네트워크 피어링, 방화벽 규칙, 서브넷, VPC 삭제:

gcloud -q compute networks peerings delete spoke2-to-hub \
  --network spoke2-vpc

gcloud -q compute networks peerings delete spoke1-to-hub \
  --network spoke1-vpc

gcloud -q compute networks peerings delete hub-to-spoke1 \
  --network hub-vpc

gcloud -q compute networks peerings delete hub-to-spoke2 \
  --network hub-vpc

gcloud -q compute firewall-rules delete spoke2-vpc-web-ping-dns

gcloud -q compute firewall-rules delete spoke1-vpc-web-ping-dns

gcloud -q compute firewall-rules delete hub-vpc-web-ping-dns

gcloud -q compute firewall-rules delete hub-vpc-health-checks

gcloud -q compute firewall-rules delete hub-vpc-allow-ssh

gcloud -q compute firewall-rules delete spoke1-vpc-allow-ssh

gcloud -q compute firewall-rules delete spoke2-vpc-allow-ssh

gcloud -q compute networks subnets delete spoke1-subnet1 \
  --region REGION_A

gcloud -q compute networks subnets delete spoke2-subnet1 \
  --region REGION_A

gcloud -q compute networks subnets delete hub-subnet-a \
  --region REGION_A

gcloud -q compute networks subnets delete hub-subnet-b \
  --region REGION_B

gcloud -q compute networks delete spoke1-vpc

gcloud -q compute networks delete spoke2-vpc

gcloud -q compute networks delete hub-vpc

다음 단계

장애 조치에 대한 중요한 정보는 내부 패스 스루 네트워크 부하 분산기의 장애 조치 개념을 참조하세요.
내부 패스 스루 네트워크 부하 분산기의 Logging 및 Monitoring 구성에 대한 자세한 내용은 내부 패스 스루 네트워크 부하 분산기의 Logging 및 Monitoring을 참조하세요.
VPC 네트워크에 연결된 피어 네트워크에서 내부 패스 스루 네트워크 부하 분산기에 액세스하는 방법은 내부 패스 스루 네트워크 부하 분산기 및 연결된 네트워크를 참조하세요.
내부 패스 스루 네트워크 부하 분산기 문제 해결 방법은 내부 패스 스루 네트워크 부하 분산기 문제 해결을 참조하세요.