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 สถานะ

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

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

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

สถานะ 4 คือสถานะ PSC สุดท้าย เราจะล้างข้อมูลปลายทาง PSC สำหรับการทดสอบและลบการเพียร์ VPC ระหว่าง consumer-vpc กับ producer-vpc
3. การตั้งค่าและข้อกำหนด
การตั้งค่าสภาพแวดล้อมแบบเรียนรู้ด้วยตนเอง
- ลงชื่อเข้าใช้ Google Cloud Console แล้วสร้างโปรเจ็กต์ใหม่หรือใช้โปรเจ็กต์ที่มีอยู่ซ้ำ หากยังไม่มีบัญชี Gmail หรือ Google Workspace คุณต้องสร้างบัญชี



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

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

เครื่องเสมือนนี้มาพร้อมเครื่องมือพัฒนาซอฟต์แวร์ทั้งหมดที่คุณต้องการ โดยมีไดเรกทอรีหลักแบบถาวรขนาด 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
- ทำความเข้าใจเวลาที่ต้องหยุดทำงานเพื่อย้ายข้อมูลบริการ
- ขั้นตอนการล้างข้อมูลหลังการย้ายข้อมูล