Private Service Connect: การย้ายข้อมูลการเพียร์ VPC ไปยัง Private Service Connect

1. บทนำ

การเพียร์ VPC เป็นวิธีทั่วไปที่ผู้ให้บริการใช้เพื่อเสนอการใช้บริการแก่ผู้ใช้ อย่างไรก็ตาม การใช้การเชื่อมต่อ VPC แบบเพียร์ทำให้เกิดความซับซ้อนในการกำหนดเส้นทางหลายอย่าง เช่น การเชื่อมต่อ VPC แบบเพียร์ที่ไม่สามารถส่งต่อได้ การใช้ที่อยู่ IP จำนวนมาก และการเปิดเผยทรัพยากรมากเกินไปใน VPC ที่เชื่อมต่อแบบเพียร์

Private Service Connect (PSC) เป็นวิธีการเชื่อมต่อที่ช่วยให้ผู้ผลิตแสดงบริการผ่านอุปกรณ์ปลายทางเดียวที่ผู้บริโภคจัดสรรใน VPC ของเวิร์กโหลด ซึ่งจะช่วยแก้ปัญหาต่างๆ ที่ผู้ใช้พบในการเพียร์ VPC ได้ แม้ว่าเราจะสร้างบริการใหม่ๆ จำนวนมากด้วย PSC แต่ก็ยังมีบริการอีกหลายอย่างที่ยังคงเป็นบริการเพียร์ VPC

Google Cloud ยินดีที่จะเปิดตัวเส้นทางการย้ายข้อมูลสำหรับบริการที่คุณสร้างผ่านการเพียร์ VPC เพื่อย้ายไปยังสถาปัตยกรรมที่ใช้ PSC เมื่อใช้วิธีการย้ายข้อมูลนี้ ที่อยู่ IP สำหรับบริการผู้ผลิตที่แสดงผ่านการ Peering VPC จะยังคงอยู่จนถึงสถาปัตยกรรมที่อิงตาม PSC ดังนั้นผู้บริโภคจึงต้องทำการเปลี่ยนแปลงน้อยที่สุด ทําตาม Codelab นี้เพื่อดูขั้นตอนทางเทคนิคในการย้ายข้อมูล

หมายเหตุ: เส้นทางการย้ายข้อมูลนี้ใช้ได้กับบริการที่ผู้ผลิตและผู้บริโภคอยู่ในองค์กร Google Cloud เดียวกันเท่านั้น สำหรับบริการของ Google Cloud หรือบริการของบุคคลที่สามที่ใช้การ Peering ของ VPC จะใช้วิธีการย้ายข้อมูลที่คล้ายกัน แต่จะปรับแต่งให้เหมาะกับบริการนั้นๆ โปรดติดต่อฝ่ายที่เกี่ยวข้องเพื่อสอบถามเกี่ยวกับเส้นทางการย้ายข้อมูลสำหรับบริการประเภทนี้

สิ่งที่คุณจะได้เรียนรู้

  • วิธีตั้งค่าบริการที่อิงตามการเพียร์ VPC
  • วิธีตั้งค่าบริการที่อิงตาม PSC
  • การใช้ Internal-Ranges API เพื่อทำการย้ายข้อมูลเครือข่ายย่อยผ่านการเชื่อมต่อแบบเพียร์ VPC เพื่อให้บรรลุการย้ายข้อมูลบริการการเชื่อมต่อแบบเพียร์ VPC ไปยัง PSC
  • ทำความเข้าใจเวลาที่ต้องหยุดทำงานเพื่อย้ายข้อมูลบริการ
  • ขั้นตอนการล้างข้อมูลหลังการย้ายข้อมูล

สิ่งที่คุณต้องมี

  • โปรเจ็กต์ Google Cloud ที่มีสิทธิ์เจ้าของ

2. โทโพโลยี Codelab

เพื่อความสะดวก Codelab นี้จะรวมทรัพยากรทั้งหมดไว้ในโปรเจ็กต์เดียว ใน Codelab จะมีการระบุการดำเนินการที่ต้องทำในฝั่งผู้ผลิตและการดำเนินการที่ต้องทำในฝั่งผู้บริโภคในกรณีที่ผู้ผลิตและผู้บริโภคอยู่ในโปรเจ็กต์ที่ต่างกัน

Codelab นี้จะมี 4 สถานะ

7dbf27cf215f9703.png

สถานะ 1 คือสถานะการเพียร์ VPC จะมี VPC 2 รายการ ได้แก่ consumer-vpc และ producer-vpc ซึ่งจะมีการเชื่อมต่อแบบเพียร์กัน Producer-vpc จะมีบริการ Apache อย่างง่ายที่เปิดเผยผ่านตัวจัดสรรภาระงานการส่งผ่านเครือข่ายภายใน Consumer-vpc จะมี consumer-vm เดียวเพื่อวัตถุประสงค์ในการทดสอบ

7f64427c0e59d417.png

สถานะ 2 คือสถานะการทดสอบ PSC เราจะสร้างกฎการส่งต่อใหม่และใช้กฎนี้เพื่อเชื่อมโยงกับ Service Attachment จากนั้นเราจะสร้างปลายทาง PSC สำหรับทดสอบใน consumer-vpc เพื่อทดสอบว่าบริการ PSC ของเราทำงานได้ตามที่คาดไว้

98c324c59c1fbf68.png

สถานะ 3 คือสถานะการย้ายข้อมูล เราจะจองช่วงเครือข่ายย่อยใน producer-vpc ซึ่งมีการทำให้บริการที่อิงตามการเพียร์ VPC ใช้งานได้เพื่อใช้ใน consumer-vpc จากนั้นเราจะสร้างปลายทาง PSC ใหม่ที่มีที่อยู่ IP เดียวกันกับกฎการส่งต่อที่มีอยู่ก่อนแล้วใน producer-vpc

a64ab7b69132c722.png

สถานะ 4 คือสถานะ PSC สุดท้าย เราจะล้างข้อมูลปลายทาง PSC สำหรับการทดสอบและลบการเพียร์ VPC ระหว่าง consumer-vpc กับ producer-vpc

3. การตั้งค่าและข้อกำหนด

การตั้งค่าสภาพแวดล้อมแบบเรียนรู้ด้วยตนเอง

  1. ลงชื่อเข้าใช้ Google Cloud Console แล้วสร้างโปรเจ็กต์ใหม่หรือใช้โปรเจ็กต์ที่มีอยู่ซ้ำ หากยังไม่มีบัญชี Gmail หรือ Google Workspace คุณต้องสร้างบัญชี

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

  • ชื่อโปรเจ็กต์คือชื่อที่แสดงสำหรับผู้เข้าร่วมโปรเจ็กต์นี้ ซึ่งเป็นสตริงอักขระที่ Google APIs ไม่ได้ใช้ คุณอัปเดตได้ทุกเมื่อ
  • รหัสโปรเจ็กต์จะไม่ซ้ำกันในโปรเจ็กต์ Google Cloud ทั้งหมดและเปลี่ยนแปลงไม่ได้ (เปลี่ยนไม่ได้หลังจากตั้งค่าแล้ว) Cloud Console จะสร้างสตริงที่ไม่ซ้ำกันโดยอัตโนมัติ ซึ่งโดยปกติแล้วคุณไม่จำเป็นต้องสนใจว่าสตริงนั้นคืออะไร ใน Codelab ส่วนใหญ่ คุณจะต้องอ้างอิงรหัสโปรเจ็กต์ (โดยทั่วไปจะระบุเป็น PROJECT_ID) หากไม่ชอบรหัสที่สร้างขึ้น คุณอาจสร้างรหัสแบบสุ่มอีกรหัสหนึ่งได้ หรือคุณอาจลองใช้ชื่อของคุณเองและดูว่ามีชื่อนั้นหรือไม่ คุณจะเปลี่ยนแปลงรหัสนี้หลังจากขั้นตอนนี้ไม่ได้ และรหัสจะคงอยู่ตลอดระยะเวลาของโปรเจ็กต์
  • โปรดทราบว่ายังมีค่าที่ 3 ซึ่งคือหมายเลขโปรเจ็กต์ที่ API บางตัวใช้ ดูข้อมูลเพิ่มเติมเกี่ยวกับค่าทั้ง 3 นี้ได้ในเอกสารประกอบ
  1. จากนั้นคุณจะต้องเปิดใช้การเรียกเก็บเงินใน Cloud Console เพื่อใช้ทรัพยากร/API ของ Cloud การทำตาม Codelab นี้จะไม่มีค่าใช้จ่ายมากนัก หรืออาจไม่มีค่าใช้จ่ายเลย หากต้องการปิดทรัพยากรเพื่อหลีกเลี่ยงการเรียกเก็บเงินนอกเหนือจากบทแนะนำนี้ คุณสามารถลบทรัพยากรที่สร้างขึ้นหรือลบโปรเจ็กต์ได้ ผู้ใช้ Google Cloud รายใหม่มีสิทธิ์เข้าร่วมโปรแกรมช่วงทดลองใช้ฟรีมูลค่า$300 USD

เริ่มต้น Cloud Shell

แม้ว่าคุณจะใช้งาน Google Cloud จากระยะไกลจากแล็ปท็อปได้ แต่ใน Codelab นี้คุณจะใช้ Google Cloud Shell ซึ่งเป็นสภาพแวดล้อมบรรทัดคำสั่งที่ทำงานในระบบคลาวด์

จาก Google Cloud Console ให้คลิกไอคอน Cloud Shell ในแถบเครื่องมือด้านขวาบน

55efc1aaa7a4d3ad.png

การจัดสรรและเชื่อมต่อกับสภาพแวดล้อมจะใช้เวลาเพียงไม่กี่นาที เมื่อเสร็จแล้ว คุณควรเห็นข้อความคล้ายกับตัวอย่างต่อไปนี้

7ffe5cbb04455448.png

เครื่องเสมือนนี้มาพร้อมเครื่องมือพัฒนาซอฟต์แวร์ทั้งหมดที่คุณต้องการ โดยมีไดเรกทอรีหลักแบบถาวรขนาด 5 GB และทำงานบน Google Cloud ซึ่งช่วยเพิ่มประสิทธิภาพเครือข่ายและการตรวจสอบสิทธิ์ได้อย่างมาก คุณสามารถทำงานทั้งหมดใน Codelab นี้ได้ภายในเบราว์เซอร์ คุณไม่จำเป็นต้องติดตั้งอะไร

4. ก่อนเริ่มต้น

เปิดใช้ API

ใน Cloud Shell ให้ตรวจสอบว่าได้ตั้งค่าโปรเจ็กต์และกำหนดค่าตัวแปรแล้ว

gcloud auth login
gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
export projectid=[YOUR-PROJECT-ID]
export region=us-central1
export zone=$region-a
echo $projectid
echo $region
echo $zone

เปิดใช้บริการทั้งหมดที่จำเป็น

gcloud services enable compute.googleapis.com
gcloud services enable networkconnectivity.googleapis.com
gcloud services enable dns.googleapis.com

5. สร้างเครือข่าย VPC ของผู้ผลิต (กิจกรรมของผู้ผลิต)

เครือข่าย VPC

จาก Cloud Shell

gcloud compute networks create producer-vpc \
    --subnet-mode=custom

สร้างซับเน็ต

จาก Cloud Shell

gcloud compute networks subnets create producer-service-subnet \
    --network=producer-vpc \
    --range=10.0.0.0/28 \
    --region=$region

gcloud compute networks subnets create producer-fr-subnet \
        --network=producer-vpc \
        --range=192.168.0.0/28 \
        --region=$region

สร้าง Cloud Router และ Cloud NAT ของผู้ให้บริการ

จาก Cloud Shell

gcloud compute routers create $region-cr \
   --network=producer-vpc \
   --region=$region

gcloud compute routers nats create $region-nat \
    --router=$region-cr \
    --region=$region \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips

สร้างนโยบายไฟร์วอลล์และกฎไฟร์วอลล์ของเครือข่ายผู้ผลิต

จาก Cloud Shell

gcloud compute network-firewall-policies create producer-vpc-policy --global

gcloud compute network-firewall-policies associations create \
    --firewall-policy producer-vpc-policy \
    --network producer-vpc \
    --name network-producer-vpc \
    --global-firewall-policy

หากต้องการอนุญาตให้ IAP เชื่อมต่อกับอินสแตนซ์ VM ให้สร้างกฎไฟร์วอลล์ที่มีลักษณะดังนี้

  • มีผลกับอินสแตนซ์ VM ทั้งหมดที่คุณต้องการให้เข้าถึงได้โดยใช้ IAP
  • อนุญาตการรับส่งข้อมูลขาเข้าจากช่วง IP 35.235.240.0/20 ช่วงนี้มีที่อยู่ IP ทั้งหมดที่ IAP ใช้สำหรับการส่งต่อ TCP

จาก Cloud Shell

gcloud compute network-firewall-policies rules create 1000 \
    --action ALLOW \
    --firewall-policy producer-vpc-policy \
    --description "SSH with IAP" \
    --direction INGRESS \
    --src-ip-ranges 35.235.240.0/20 \
    --layer4-configs tcp:22  \
    --global-firewall-policy

นอกจากนี้ เราจะสร้างกฎอีก 2 ข้อที่อนุญาตให้การตรวจสอบสถานะของ Load Balancer ไปยังบริการ รวมถึงอนุญาตการรับส่งข้อมูลเครือข่ายจาก VM ที่จะเชื่อมต่อจาก consumer-vpc

จาก Cloud Shell

gcloud compute network-firewall-policies rules create 2000 \
    --action ALLOW \
    --firewall-policy producer-vpc-policy \
    --description "LB healthchecks" \
    --direction INGRESS \
    --src-ip-ranges 130.211.0.0/22,35.191.0.0/16 \
    --layer4-configs tcp:80  \
    --global-firewall-policy


gcloud compute network-firewall-policies rules create 3000 \
    --action ALLOW \
    --firewall-policy producer-vpc-policy \
    --description "allow access from consumer-vpc" \
    --direction INGRESS \
    --src-ip-ranges 10.0.1.0/28 \
    --layer4-configs tcp:80  \
    --global-firewall-policy

6. การตั้งค่าบริการของผู้ผลิต (กิจกรรมของผู้ผลิต)

เราจะสร้างบริการผู้ผลิตที่มี VM เดียวที่เรียกใช้เว็บเซิร์ฟเวอร์ Apache ซึ่งจะเพิ่มลงในกลุ่มอินสแตนซ์ที่ไม่มีการจัดการซึ่งอยู่หน้าตัวจัดสรรภาระงานแบบส่งต่อภายในระดับภูมิภาค

สร้าง VM และกลุ่มอินสแตนซ์ที่ไม่มีการจัดการ

จาก Cloud Shell

gcloud compute instances create producer-service-vm \
    --network producer-vpc \
    --subnet producer-service-subnet \
    --zone $zone \
    --no-address \
    --metadata startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    a2enmod ssl
    sudo a2ensite default-ssl
    echo "I am a Producer Service." | \
    tee /var/www/html/index.html
    systemctl restart apache2'

จาก Cloud Shell

gcloud compute instance-groups unmanaged create prod-uig \
  --zone=$zone

gcloud compute instance-groups unmanaged add-instances prod-uig \
  --zone=$zone \
  --instances=producer-service-vm

สร้างตัวจัดสรรภาระงานการปล่อยผ่านสัญญาณเครือข่ายภายในระดับภูมิภาค

จาก Cloud Shell

gcloud compute health-checks create http producer-hc \
        --region=$region

gcloud compute backend-services create producer-bes \
  --load-balancing-scheme=internal \
  --protocol=tcp \
  --region=$region \
  --health-checks=producer-hc \
  --health-checks-region=$region

gcloud compute backend-services add-backend producer-bes \
  --region=$region \
  --instance-group=prod-uig \
  --instance-group-zone=$zone

gcloud compute addresses create producer-fr-ip\
  --region $region \
  --subnet producer-fr-subnet \
  --addresses 192.168.0.2

gcloud compute forwarding-rules create producer-fr \
  --region=$region \
  --load-balancing-scheme=internal \
  --network=producer-vpc \
  --subnet=producer-fr-subnet \
  --address=producer-fr-ip \
  --ip-protocol=TCP \
  --ports=80 \
  --backend-service=producer-bes \
  --backend-service-region=$region

7. สร้างเครือข่าย VPC ของผู้ใช้บริการ (กิจกรรมของผู้ใช้บริการ)

เครือข่าย VPC

จาก Cloud Shell

gcloud compute networks create consumer-vpc \
    --subnet-mode=custom

สร้างซับเน็ต

จาก Cloud Shell

gcloud compute networks subnets create consumer-vm-subnet \
    --network=consumer-vpc \
    --range=10.0.1.0/28 \
    --region=$region

สร้างนโยบายไฟร์วอลล์เครือข่ายสำหรับผู้บริโภคและกฎไฟร์วอลล์

เราจะสร้างนโยบายไฟร์วอลล์เครือข่ายอีกรายการสำหรับ consumer-vpc

จาก Cloud Shell

gcloud compute network-firewall-policies create consumer-vpc-policy --global

gcloud compute network-firewall-policies associations create \
    --firewall-policy consumer-vpc-policy \
    --network consumer-vpc \
    --name network-consumer-vpc \
    --global-firewall-policy

gcloud compute network-firewall-policies rules create 1000 \
    --action ALLOW \
    --firewall-policy consumer-vpc-policy \
    --description "SSH with IAP" \
    --direction INGRESS \
    --src-ip-ranges 35.235.240.0/20 \
    --layer4-configs tcp:22  \
    --global-firewall-policy

8. สร้างเพียร์ VPC

กิจกรรมของโปรดิวเซอร์

จาก Cloud Shell

gcloud compute networks peerings create producer-vpc-peering \
    --network=producer-vpc \
    --peer-project=$projectid \
    --peer-network=consumer-vpc

กิจกรรมของผู้บริโภค

จาก Cloud Shell

gcloud compute networks peerings create consumer-vpc-peering \
    --network=consumer-vpc \
    --peer-project=$projectid \
    --peer-network=producer-vpc

ยืนยันว่าสร้างการ Peering แล้วโดยตรวจสอบรายการเส้นทางใน consumer-vpc คุณควรเห็นเส้นทางสำหรับทั้ง consumer-vpc และ producer-vpc

กิจกรรมของผู้บริโภค

จาก Cloud Shell

gcloud compute routes list --filter="network=consumer-vpc"

ผลลัพธ์ที่คาดไว้

NAME: default-route-49dda7094977e231
NETWORK: consumer-vpc
DEST_RANGE: 0.0.0.0/0
NEXT_HOP: default-internet-gateway
PRIORITY: 1000

NAME: default-route-r-10d65e16cc6278b2
NETWORK: consumer-vpc
DEST_RANGE: 10.0.1.0/28
NEXT_HOP: consumer-vpc
PRIORITY: 0

NAME: peering-route-496d0732b4f11cea
NETWORK: consumer-vpc
DEST_RANGE: 192.168.0.0/28
NEXT_HOP: consumer-vpc-peering
PRIORITY: 0

NAME: peering-route-b4f9d3acc4c08d55
NETWORK: consumer-vpc
DEST_RANGE: 10.0.0.0/28
NEXT_HOP: consumer-vpc-peering
PRIORITY: 0

9. สร้างโซน DNS (กิจกรรมของผู้บริโภค)

เราจะสร้างโซนส่วนตัวของ Cloud DNS เพื่อเรียกใช้บริการ Producer ผ่าน DNS แทนที่จะผ่านที่อยู่ IP ส่วนตัวเพื่อแสดงตัวอย่างที่สมจริงยิ่งขึ้น

เราจะเพิ่มระเบียน A ไปยังโดเมน example.com ที่ชี้ service.example.com ไปยังที่อยู่ IP ของกฎการส่งต่อของ Network Passthrough Load Balancer ที่เราสร้างไว้ก่อนหน้านี้ ที่อยู่ IP ของกฎการส่งต่อคือ 192.168.0.2

จาก Cloud Shell

gcloud dns managed-zones create "producer-service" \
   --dns-name=example.com \
   --description="producer service dns" \
   --visibility=private \
   --networks=consumer-vpc

gcloud dns record-sets transaction start \
   --zone="producer-service"

gcloud dns record-sets transaction add 192.168.0.2 \
   --name=service.example.com \
   --ttl=300 \
   --type=A \
   --zone="producer-service"

gcloud dns record-sets transaction execute \
   --zone="producer-service"

10. ทดสอบบริการของผู้ผลิตผ่าน VPC Peer (กิจกรรมของผู้บริโภค)

ตอนนี้ได้สร้างสถาปัตยกรรมสถานะ 1 แล้ว

สร้าง VM ไคลเอ็นต์ผู้บริโภค

จาก Cloud Shell

gcloud compute instances create consumer-client \
   --zone=$zone \
   --subnet=consumer-vm-subnet \
   --no-address

ทดสอบการเชื่อมต่อ

จาก Cloud Shell

gcloud compute ssh \
    --zone "$zone" "consumer-client" \
    --tunnel-through-iap \
    --project $projectid

จาก VM ของไคลเอ็นต์ผู้บริโภค

curl service.example.com

ผลลัพธ์ที่คาดหวัง

I am a Producer Service. 

จาก VM ของไคลเอ็นต์ผู้บริโภค

exit

11. เตรียมบริการสำหรับ Private Service Connect (กิจกรรมของผู้ผลิต)

ตอนนี้เราได้ทำตามขั้นตอนการตั้งค่าเริ่มต้นทั้งหมดแล้ว เราจะเริ่มเตรียมบริการที่ Peering VPC สำหรับการย้ายข้อมูลไปยัง Private Service Connect ในส่วนนี้ เราจะทำการเปลี่ยนแปลง producer-vpc โดยกำหนดค่าบริการให้แสดงผ่าน Service Attachment เราจะต้องสร้างซับเน็ตใหม่และกฎการส่งต่อใหม่ภายในซับเน็ตนั้น เพื่อให้เราย้ายข้อมูลซับเน็ตที่มีอยู่ไปยัง consumer-vpc ได้เพื่อคงที่อยู่ IP ที่มีอยู่ของบริการไว้

สร้างเครือข่ายย่อยที่จะโฮสต์ IP ของกฎการส่งต่อตัวจัดสรรภาระงานใหม่

จาก Cloud Shell

gcloud compute networks subnets create producer-psc-fr-subnet \
    --network=producer-vpc \
    --range=10.0.2.64/28 \
    --region=$region

สร้างที่อยู่ IP ภายในของกฎการส่งต่อตัวจัดสรรภาระงาน

จาก Cloud Shell

gcloud compute addresses create producer-psc-ip \
  --region $region \
  --subnet producer-psc-fr-subnet \
  --addresses 10.0.2.66

สร้างกฎการส่งต่อของตัวจัดสรรภาระงานใหม่ กฎนี้ได้รับการกำหนดค่าให้ใช้บริการแบ็กเอนด์และการตรวจสอบสถานะเดียวกันกับที่เรากำหนดค่าไว้ก่อนหน้านี้

จาก Cloud Shell

gcloud compute forwarding-rules create psc-service-fr \
  --region=$region \
  --load-balancing-scheme=internal \
  --network=producer-vpc \
  --subnet=producer-psc-fr-subnet \
  --address=producer-psc-ip \
  --ip-protocol=TCP \
  --ports=80 \
  --backend-service=producer-bes \
  --backend-service-region=$region

ระบบจะเชื่อมโยง psc-nat-subnet กับการเชื่อมต่อบริการ PSC เพื่อวัตถุประสงค์ในการแปลที่อยู่เครือข่าย สำหรับกรณีการใช้งานจริง ซับเน็ตนี้ต้องมีขนาดที่เหมาะสมเพื่อรองรับจำนวนอุปกรณ์ปลายทางที่แนบมา ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบเกี่ยวกับการกำหนดขนาดเครือข่ายย่อย NAT ของ PSC

จาก Cloud Shell

gcloud compute networks subnets create psc-nat-subnet \
    --network=producer-vpc \
    --range=10.100.100.0/28 \
    --region=$region \
    --purpose=PRIVATE_SERVICE_CONNECT

เราต้องเพิ่มกฎไฟร์วอลล์อีกรายการหนึ่งลงในนโยบายไฟร์วอลล์เครือข่ายเพื่ออนุญาตการรับส่งข้อมูลจาก psc-nat-subnet เมื่อเข้าถึงบริการผ่าน PSC ซับเน็ต psc-nat คือตำแหน่งที่จะมีการส่งต่อการรับส่ง

จาก Cloud Shell

gcloud compute network-firewall-policies rules create 2001 \
    --action ALLOW \
    --firewall-policy producer-vpc-policy \
    --description "allow PSC NAT subnet" \
    --direction INGRESS \
    --src-ip-ranges 10.100.100.0/28 \
    --layer4-configs tcp:80  \
    --global-firewall-policy

สร้างไฟล์แนบบริการและจด URI ของไฟล์แนบบริการเพื่อกำหนดค่าปลายทาง PSC ในส่วนถัดไป

จาก Cloud Shell

gcloud compute service-attachments create producer-sa \
    --region=$region \
    --producer-forwarding-rule=psc-service-fr  \
    --connection-preference=ACCEPT_MANUAL \
    --consumer-accept-list=$projectid=5 \
    --nat-subnets=psc-nat-subnet

จาก Cloud Shell

gcloud compute service-attachments describe producer-sa --region=$region

เอาต์พุตตัวอย่าง

connectionPreference: ACCEPT_MANUAL
consumerAcceptLists:
- connectionLimit: 5
  projectIdOrNum: $projectid
creationTimestamp: '2025-04-24T11:23:09.886-07:00'
description: ''
enableProxyProtocol: false
fingerprint: xxx
id: 'xxx'
kind: compute#serviceAttachment
name: producer-sa
natSubnets:
- https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/subnetworks/psc-nat-subnet
pscServiceAttachmentId:
  high: 'xxx'
  low: 'xxx'
reconcileConnections: false
region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region
selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/serviceAttachments/producer-sa
targetService: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/forwardingRules/psc-service-fr

12. เชื่อมต่ออุปกรณ์ปลายทาง PSC ของผู้บริโภค "test" กับบริการของผู้ผลิตและทดสอบ (กิจกรรมของผู้บริโภค)

ตอนนี้สถาปัตยกรรมอยู่ในสถานะ 2

ในตอนนี้ บริการผู้ผลิตที่มีอยู่ซึ่งแสดงผ่านการเชื่อมต่อ VPC ยังคงใช้งานได้และทำงานได้อย่างถูกต้องในสถานการณ์การใช้งานจริง เราจะสร้างปลายทาง PSC "ทดสอบ" เพื่อให้แน่ใจว่าการเชื่อมต่อบริการที่เปิดเผยทำงานได้อย่างถูกต้องก่อนที่เราจะเริ่มช่วงหยุดทำงานเพื่อย้ายข้อมูลเครือข่ายย่อยการ Peering VPC ปัจจุบันไปยัง VPC ของผู้ใช้บริการ การเชื่อมต่อสถานะสุดท้ายจะเป็นปลายทาง PSC ที่มีที่อยู่ IP เดียวกันกับกฎการส่งต่อปัจจุบันสำหรับบริการที่อิงตามการเพียร์ VPC

สร้างปลายทาง PSC

จาก Cloud Shell

gcloud compute addresses create test-psc-endpoint-ip \
    --region=$region \
    --subnet=consumer-vm-subnet \
    --addresses 10.0.1.3

บริการเป้าหมายด้านล่างจะเป็น URI ของการเชื่อมต่อบริการที่คุณจดไว้ในขั้นตอนสุดท้าย

จาก Cloud Shell

gcloud compute forwarding-rules create test-psc-endpoint \
  --region=$region \
  --network=consumer-vpc \
  --address=test-psc-endpoint-ip \
  --target-service-attachment=projects/$projectid/regions/$region/serviceAttachments/producer-sa

ทดสอบปลายทาง PSC "test"

จาก Cloud Shell

gcloud compute ssh \
    --zone "$zone" "consumer-client" \
    --tunnel-through-iap \
    --project $projectid

จากผู้บริโภคที่เป็นลูกค้า

curl 10.0.1.3

ผลลัพธ์ที่คาดหวัง

I am a Producer Service. 

จากผู้บริโภคที่เป็นลูกค้า

exit

13. ย้ายข้อมูลซับเน็ตของกฎการส่งต่อของผู้ผลิตที่มีอยู่

การทำตามขั้นตอนเหล่านี้จะทำให้บริการ Producer ที่ใช้ VPC Peering แบบสดหยุดทำงาน ตอนนี้เราจะย้ายข้อมูลซับเน็ตของกฎการส่งต่อจาก producer-vpc ไปยัง consumer-vpc โดยใช้ Internal Ranges API ซึ่งจะล็อกซับเน็ตไม่ให้ใช้งานในช่วงเวลาชั่วคราวที่เราลบซับเน็ตใน producer-vpc และกำหนดให้ใช้เพื่อการย้ายข้อมูลเท่านั้นสำหรับการสร้างใน consumer-vpc

API ช่วงภายในกำหนดให้คุณต้องจองเครือข่ายย่อยของกฎการส่งต่อการ Peering VPC ที่มีอยู่ (producer-fr-subnet, 192.168.0.0/28) และกำหนดชื่อเครือข่ายย่อยเป้าหมายใน consumer-vpc (consumer-psc-subnet) เราจะสร้างซับเน็ตใหม่ใน consumer-vpc ด้วยชื่อนี้ในไม่กี่ขั้นตอน

จอง producer-fr-subnet สำหรับการย้ายข้อมูล

กิจกรรมของโปรดิวเซอร์

จาก Cloud Shell

gcloud network-connectivity internal-ranges create producer-peering-internal-range \
    --ip-cidr-range=192.168.0.0/28 \
    --network=producer-vpc \
    --usage=FOR_MIGRATION \
    --migration-source=projects/$projectid/regions/$region/subnetworks/producer-fr-subnet \
    --migration-target=projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet

เรียกใช้คำสั่งอธิบายในช่วงภายในที่เราสร้างขึ้นเพื่อดูสถานะของซับเน็ต

กิจกรรมของโปรดิวเซอร์

จาก Cloud Shell

gcloud network-connectivity internal-ranges describe producer-peering-internal-range

เอาต์พุตตัวอย่าง

createTime: '2025-04-24T19:26:10.589343291Z'
ipCidrRange: 192.168.0.0/28
migration:
  source: projects/$projectid/regions/$region/subnetworks/producer-fr-subnet
  target: projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet
name: projects/$projectid/locations/global/internalRanges/producer-peering-internal-range
network: https://www.googleapis.com/compute/v1/projects/$project/global/networks/producer-vpc
peering: FOR_SELF
updateTime: '2025-04-24T19:26:11.521960016Z'
usage: FOR_MIGRATION

ลบกฎการส่งต่อและเครือข่ายย่อยที่อิงตามการ Peering VPC

กิจกรรมของโปรดิวเซอร์

จาก Cloud Shell

gcloud compute forwarding-rules delete producer-fr --region=$region

gcloud compute addresses delete producer-fr-ip --region=$region

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

ย้ายข้อมูลซับเน็ต

ย้ายข้อมูลเครือข่ายย่อยไปยัง consumer-vpc โดยการสร้างเครือข่ายย่อยใหม่โดยใช้ช่วงภายในที่เราสร้างไว้ก่อนหน้านี้ ชื่อของซับเน็ตนี้ต้องเป็นชื่อเดียวกับที่เรากำหนดเป้าหมายไว้ก่อนหน้านี้ (consumer-psc-subnet) วัตถุประสงค์เฉพาะของ PEER_MIGRATION ระบุว่ามีการสงวนซับเน็ตไว้สำหรับการย้ายข้อมูลซับเน็ตระหว่าง VPC ที่เชื่อมต่อแบบเพียร์ เมื่อใช้แฟล็กวัตถุประสงค์นี้ ซับเน็ตนี้จะมีได้เฉพาะที่อยู่ IP แบบคงที่ที่สงวนไว้และปลายทาง PSC เท่านั้น

กิจกรรมของผู้บริโภค

จาก Cloud Shell

gcloud compute networks subnets create consumer-psc-subnet \
  --purpose=PEER_MIGRATION \
  --network=consumer-vpc \
  --range=192.168.0.0/28 \
  --region=$region

14. สร้างอุปกรณ์ปลายทาง PSC สถานะสิ้นสุด (กิจกรรมของผู้บริโภค)

ขณะนี้บริการ Producer ยังคงหยุดทำงาน ซับเน็ตที่เราเพิ่งสร้างยังคงล็อกอยู่และใช้ได้เฉพาะเพื่อวัตถุประสงค์ที่เฉพาะเจาะจงในการย้ายข้อมูลเท่านั้น คุณทดสอบได้โดยพยายามสร้าง VM ในซับเน็ตนี้ การสร้าง VM จะล้มเหลว

จาก Cloud Shell

gcloud compute instances create test-consumer-vm \
    --zone=$zone \
    --subnet=consumer-psc-subnet \
    --no-address

ผลลัพธ์ที่คาดหวัง

ERROR: (gcloud.compute.instances.create) Could not fetch resource:
 - Subnetwork must have purpose=PRIVATE.

เราใช้ซับเน็ตนี้เพื่อสร้างปลายทาง PSC ได้เท่านั้น โปรดทราบว่าที่อยู่ IP ที่เราสร้างจะใช้ IP เดียวกันกับกฎการส่งต่อที่บริการของผู้ให้บริการใช้ผ่าน VPC Peer

จาก Cloud Shell

gcloud compute addresses create psc-endpoint-ip \
    --region=$region \
    --subnet=consumer-psc-subnet \
    --addresses 192.168.0.2

อีกครั้งที่คุณต้องใช้ URI ของการเชื่อมต่อบริการเดียวกันกับที่จดไว้ก่อนหน้านี้ และใช้สร้างปลายทาง PSC "test" ด้วย

จาก Cloud Shell

gcloud compute forwarding-rules create psc-endpoint \
    --region=$region \
    --network=consumer-vpc \
    --address=psc-endpoint-ip \
    --target-service-attachment=projects/$projectid/regions/$region/serviceAttachments/producer-sa

15. ทดสอบปลายทาง PSC สถานะสิ้นสุด (กิจกรรมของผู้บริโภค)

ตอนนี้คุณอยู่ในสถาปัตยกรรมสถานะ 3

จาก Cloud Shell

gcloud compute ssh \
    --zone "$zone" "consumer-client" \
    --tunnel-through-iap \
    --project $projectid

จาก VM ของไคลเอ็นต์ผู้บริโภค

curl service.example.com

ผลลัพธ์ที่คาดหวัง

I am a Producer Service. 

จาก VM ของไคลเอ็นต์ผู้บริโภค

exit

ในตอนนี้ การหยุดทำงานได้สิ้นสุดลงแล้วและบริการกลับมาใช้งานได้อีกครั้ง โปรดทราบว่าเราไม่จำเป็นต้องเปลี่ยนแปลง DNS ที่มีอยู่ โดยคุณไม่จำเป็นต้องทำการเปลี่ยนแปลงฝั่งไคลเอ็นต์ของผู้บริโภค แอปพลิเคชันสามารถกลับมาดำเนินการต่อในบริการที่ย้ายข้อมูลได้เลย

16. การล้างข้อมูลหลังการย้ายข้อมูล

เราต้องทำตามขั้นตอนการล้างข้อมูล 2-3 ขั้นตอนเพื่อทำการย้ายข้อมูลให้เสร็จสมบูรณ์ เราต้องลบและปลดล็อกทรัพยากร

ปลดล็อกซับเน็ตช่วงภายใน

การดำเนินการนี้จะปลดล็อกเครือข่ายย่อยที่ย้ายข้อมูลเพื่อให้เปลี่ยนวัตถุประสงค์จาก "PEER_MIGRATION" เป็น "PRIVATE" ได้

กิจกรรมของโปรดิวเซอร์

จาก Cloud Shell

gcloud network-connectivity internal-ranges delete producer-peering-internal-range

กิจกรรมของผู้บริโภค

จาก Cloud Shell

gcloud compute networks subnets update consumer-psc-subnet \
    --region=$region \
    --purpose=PRIVATE

gcloud compute networks subnets describe consumer-psc-subnet --region=$region

เอาต์พุตตัวอย่าง

creationTimestamp: '2025-04-24T12:29:33.883-07:00'
fingerprint: xxx
gatewayAddress: 192.168.0.1
id: 'xxx'
ipCidrRange: 192.168.0.0/28
kind: compute#subnetwork
name: consumer-psc-subnet
network: https://www.googleapis.com/compute/v1/projects/$projectid/global/networks/consumer-vpc
privateIpGoogleAccess: false
privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS
purpose: PRIVATE
region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region
selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet

ลบการเพียร์ VPC

กิจกรรมของโปรดิวเซอร์

จาก Cloud Shell

gcloud compute networks peerings delete producer-vpc-peering \
    --network=producer-vpc

กิจกรรมของผู้บริโภค

จาก Cloud Shell

gcloud compute networks peerings delete consumer-vpc-peering \
        --network=consumer-vpc

ลบปลายทาง PSC "test"

กิจกรรมของผู้บริโภค

จาก Cloud Shell

gcloud compute forwarding-rules delete test-psc-endpoint --region=$region
gcloud compute addresses delete test-psc-endpoint-ip --region=$region

17. การทดสอบขั้นสุดท้ายหลังจากการล้างข้อมูลหลังการย้ายข้อมูล (กิจกรรมของผู้บริโภค)

ตอนนี้เราได้สถาปัตยกรรมสถานะ 4 (สถานะสุดท้าย) แล้ว

ทดสอบการเชื่อมต่อปลายทาง PSC อีกครั้งเพื่อให้แน่ใจว่าการล้างข้อมูลหลังการย้ายข้อมูลจะไม่ส่งผลเสีย

จาก Cloud Shell

gcloud compute ssh \
    --zone "$zone" "consumer-client" \
    --tunnel-through-iap \
    --project $projectid

จาก VM ของไคลเอ็นต์ผู้บริโภค

curl service.example.com

ผลลัพธ์ที่คาดหวัง

I am a Producer Service. 

จาก VM ของไคลเอ็นต์ผู้บริโภค

exit

สำเร็จ!

18. ขั้นตอนการล้างข้อมูล

จาก Cloud Shell

gcloud compute forwarding-rules delete psc-endpoint --region=$region -q

gcloud compute addresses delete psc-endpoint-ip --region=$region -q

gcloud compute instances delete consumer-client --zone=$zone --project=$projectid -q

gcloud dns record-sets delete service.example.com --zone="producer-service" --type=A -q

gcloud dns managed-zones delete "producer-service" -q

gcloud compute network-firewall-policies rules delete 1000 --firewall-policy consumer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies associations delete --firewall-policy=consumer-vpc-policy  --name=network-consumer-vpc --global-firewall-policy -q

gcloud compute network-firewall-policies delete consumer-vpc-policy --global -q

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

gcloud compute networks subnets delete consumer-vm-subnet --region=$region -q

gcloud compute networks delete consumer-vpc -q

gcloud compute service-attachments delete producer-sa --region=$region -q

gcloud compute forwarding-rules delete psc-service-fr --region=$region -q

gcloud compute addresses delete producer-psc-ip --region=$region -q

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

gcloud compute health-checks delete producer-hc --region=$region -q

gcloud compute instance-groups unmanaged delete prod-uig --zone=$zone -q

gcloud compute instances delete producer-service-vm --zone=$zone --project=$projectid -q

gcloud compute network-firewall-policies rules delete 3000 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 2001 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 2000 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 1000 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies associations delete --firewall-policy=producer-vpc-policy  --name=network-producer-vpc --global-firewall-policy -q

gcloud compute network-firewall-policies delete producer-vpc-policy --global -q

gcloud compute routers nats delete $region-nat --router=$region-cr --region=$region -q

gcloud compute routers delete $region-cr --region=$region -q

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

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

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

gcloud compute networks delete producer-vpc -q

19. ยินดีด้วย

ขอแสดงความยินดีที่ทำ Codelab เสร็จสมบูรณ์

สิ่งที่เราได้พูดถึง

  • วิธีตั้งค่าบริการที่อิงตามการเพียร์ VPC
  • วิธีตั้งค่าบริการที่อิงตาม PSC
  • การใช้ Internal-Ranges API เพื่อทำการย้ายข้อมูลเครือข่ายย่อยผ่านการเชื่อมต่อแบบเพียร์ VPC เพื่อให้บรรลุการย้ายข้อมูลบริการการเชื่อมต่อแบบเพียร์ VPC ไปยัง PSC
  • ทำความเข้าใจเวลาที่ต้องหยุดทำงานเพื่อย้ายข้อมูลบริการ
  • ขั้นตอนการล้างข้อมูลหลังการย้ายข้อมูล