פריסת רשת מסוג Hub-and-Spoke באמצעות מאזן עומסים כקפיצה הבאה

במדריך הזה מתואר איך להשתמש בקישור בין רשתות VPC שכנות (peering) כדי לפרוס ארכיטקטורת רכזת וחישורים.

המדריך הזה מיועד למהנדסי רשתות בענן ולמומחי תפעול שרוצים להטמיע ארכיטקטורת רכזת וחישורים בסביבתGoogle Cloud שלהם באמצעות מכשירים מרכזיים שמורכבים ממכונות וירטואליות של Compute Engine. במדריך הזה, תפרסו את המכונות הווירטואליות האלה כשערי NAT, אבל תוכלו להשתמש באותה גישה לפונקציות אחרות, כמו חומות אש מהדור הבא. במדריך הזה אנחנו מניחים שאתם מכירים רשתות VPC ו-Compute Engine.

ארכיטקטורה

בארכיטקטורה הזו, קבוצה של רשתות VPC מסוג Spoke מתקשרת עם העולם החיצוני דרך רשת VPC מסוג Hub, שבה תעבורת הנתונים מנותבת דרך מאגר מרכזי של מכשירים, ובמקרה הזה, שערים של תרגום כתובות רשת (NAT). המסלולים הרלוונטיים מיוצאים מרשת ה-VPC המרכזית לרשתות ה-VPC המשניות. שערי ה-NAT מוגדרים כרכיבי בק-אנד של מאזן עומסים פנימי עם מסלול ברירת מחדל חדש, שכולל מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי מ-Cloud Load Balancing בתור הדילוג הבא.

אפשר להשיג את אותו סוג של חלוקת עומסים וזמינות גבוהה באמצעות כמה נתיבים עם ניתוב במסלולים מרובים בעלות שווה (ECMP). עם זאת, לשימוש במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי יש את היתרונות הבאים:

• כשמסתמכים על בדיקות תקינות, התנועה מועברת רק למכונות תקינות. עם ECMP, תעבורת נתונים מועברת לכל המופעים הפעילים שאליהם מצביעה הנתיב. שימוש במאזן עומסי רשת פנימי מבטל את האפשרות של נתיבים שלא נעשה בהם שימוש. בנוסף, אין צורך לנקות את המסלולים כשמפסיקים או מפעילים מחדש מכונות.
• יכול להיות שהמעבר לגיבוי יתבצע מהר יותר כי אפשר לכוונן את טיימרים של בדיקת תקינות. אם אתם משתמשים בקבוצות מופעי מכונה מנוהלים ובתיקון תוכנה אוטומטי (autohealing), אתם עדיין יכולים להתאים אישית את טיימרים של בדיקות תקינות, אבל הם משמשים ליצירה מחדש של המכונה, ולא לניתוב תעבורת נתונים.

‫Google מציעה גם את Cloud NAT כשירות מנוהל, שמספק זמינות גבוהה ללא ניהול משתמשים והתערבות שלהם. עם זאת, לא ניתן להשתמש ב-Cloud NAT בתרחיש השימוש הזה כי הגדרת ה-NAT לא מיובאת לרשת שנוצרה בה שותפות.

התרשים הבא מציג את הטופולוגיה שתיצרו במדריך הזה.

הטופולוגיה מורכבת מרשת VPC מרכזית ושתי רשתות VPC מסוג Spoke שמקושרות לרשת ה-VPC המרכזית באמצעות קישור בין רשתות VPC שכנות (peering). ברשת ה-VPC המרכזית יש שני מופעים של שער NAT מאחורי מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי. מסלול סטטי שמוגדר כברירת מחדל (0/0 NAT-GW-ILB) מצביע על מאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי בתור הצעד הבא. נתיב ברירת המחדל הסטטי הזה מיוצא דרך קישור רשתות VPC באמצעות נתיבים בהתאמה אישית.

מטרות

• יצירת כמה רשתות VPC וביצוע פעולת Peering ביניהן באמצעות ארכיטקטורת Hub and Spoke.
• יוצרים ומגדירים שערי NAT ברשת ה-VPC של הרכזת.
• מגדירים ומגדירים את מאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי כנקודת הקפיצה הבאה.
• מוודאים שיש קישוריות מרשתות ה-VPC המקושרות לאינטרנט הציבורי.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

• Compute Engine

בעזרת מחשבון העלויות אתם יכולים להעריך את העלויות בהתאם לשימוש הצפוי.

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

כשמסיימים את המשימות שמתוארות במסמך הזה אפשר למחוק את המשאבים שיצרתם כדי להימנע מחיובים נוספים. מידע נוסף זמין בקטע הסרת המשאבים.

לפני שמתחילים

נכנסים לחשבון Google Cloud . אנחנו ממליצים למשתמשים חדשים ב- Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Compute Engine API, if it is not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the API

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Compute Engine API, if it is not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the API

1. מפעילים את Cloud Shell במסוף Google Cloud .

   הפעלת Cloud Shell

   בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

במדריך הזה, מריצים את כל הפקודות מ-Cloud Shell.

הגדרת הסביבה

1. ב-Cloud Shell, מוודאים שאתם עובדים בפרויקטGoogle Cloud שיצרתם או בחרתם. מחליפים את project-id בפרויקט שלכם ב- Google Cloud .

   gcloud config set project project-id
   
   export PROJECT_ID=`gcloud config list --format="value(core.project)"`
   

2. מגדירים את אזור החישוב ואת התחום (zone) שמוגדרים כברירת מחדל.

   gcloud config set compute/region us-central1
   gcloud config set compute/zone us-central1-c
   export REGION=us-central1
   export ZONE=us-central1-c
   

   במדריך הזה, האזור הוא us-central1 והתחום הוא us-central1-c.

יצירת רשתות VPC ורשתות משנה

1. יוצרים ב-Cloud Shell את רשת ה-VPC של ה-Hub ואת התת-רשת:

   gcloud compute networks create hub-vpc --subnet-mode custom
   
   gcloud compute networks subnets create hub-subnet1 \
       --network hub-vpc --range 10.0.0.0/24
   

2. יוצרים את רשתות ה-VPC מסוג Spoke, שנקראות spoke1-vpc ו-spoke2-vpc, עם תת-רשת אחת לכל אחת:

   gcloud compute networks create spoke1-vpc --subnet-mode custom
   
   gcloud compute networks create spoke2-vpc --subnet-mode custom
   
   gcloud compute networks subnets create spoke1-subnet1 \
       --network spoke1-vpc --range 192.168.1.0/24
   
   gcloud compute networks subnets create spoke2-subnet1 \
       --network spoke2-vpc --range 192.168.2.0/24
   

3. יוצרים כללי חומת אש ברשת ה-VPC המרכזית וברשתות ה-VPC המקושרות. הכללים האלה מאפשרים תעבורת נתונים פנימית (TCP/80 ו-443, UDP/53 ו-ICMP) מטווחי RFC 1918 שצוינו:

   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,192.168.1.0/24,192.168.2.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,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,192.168.2.0/24
   

4. יוצרים כללי חומת אש ברשת ה-VPC המרכזית וברשתות ה-VPC המשניות כדי לאפשר ל-IAP for SSH לגשת לכל המכונות הווירטואליות:

   gcloud compute firewall-rules create hub-vpc-iap \
       --network hub-vpc --allow tcp:22 \
       --source-ranges 35.235.240.0/20
   
   gcloud compute firewall-rules create spoke1-vpc-iap \
       --network spoke1-vpc --allow tcp:22 \
       --source-ranges 35.235.240.0/20
   
   gcloud compute firewall-rules create spoke2-vpc-iap \
       --network spoke2-vpc --allow tcp:22 \
       --source-ranges 35.235.240.0/20
   

   במדריך הזה נעשה שימוש בשרת proxy לאימות זהויות (IAP) עבור SSH. מידע נוסף זמין במאמר התחברות למכונות שאין להן כתובות IP חיצוניות.

5. יוצרים כלל של חומת אש שמאפשר בדיקות תקינות של קבוצות של מכונות עם תיקון אוטומטי ברשת ה-VPC של הרכזת:

   gcloud compute firewall-rules create hub-vpc-health-checks \
       --network hub-vpc --allow tcp:443 --target-tags nat-gw \
       --source-ranges 35.191.0.0/16
   

יצירת המכונות והמסלולים הנדרשים

1. ב-Cloud Shell, יוצרים את תבנית של הגדרות מכונה לשער NAT עם סקריפט לטעינה בזמן ההפעלה שמגדיר את שער NAT:

   gcloud compute instance-templates create \
     hub-nat-gw-ilbnhop-template \
     --network hub-vpc \
     --subnet hub-subnet1 \
     --machine-type n1-standard-2 --can-ip-forward \
     --tags nat-gw --scopes default,compute-rw \
     --metadata startup-script='#! /bin/bash
   apt-get update
   # Enable IP forwarding:
   echo 1 > /proc/sys/net/ipv4/ip_forward
   echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf
   # Read VM network configuration:
   md_vm="http://metadata.google.internal/computeMetadata/v1/instance/"
   md_net="$md_vm/network-interfaces"
   nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google")"
   nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")"
   nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")"
   nic0_id="$(ip addr show | grep $nic0_addr | tail -c 5)"
   # Use a web server to pass the health check for this example.
   # In production, use a more complete test.
   sudo apt-get update
   sudo apt-get install apache2 -y
   sudo a2ensite default-ssl
   sudo a2enmod ssl
   echo "Example web page to pass health check" | \
   tee /var/www/html/index.html
   sudo systemctl restart apache2
   # Enable IP masquerading
   iptables -t nat -A POSTROUTING -o $nic0_id -j MASQUERADE'
   

   במדריך הזה משתמשים ב-n1-standard-2 כסוג המכונה, אבל אתם יכולים להשתמש בכל מספר או גודל אחר של שער שתרצו. חשוב להביא בחשבון גורמים כמו רוחב הפס המקסימלי של תעבורת הנתונים היוצאת (egress) לכל מכונה וירטואלית.

2. יוצרים בדיקת תקינות HTTP:

   gcloud compute health-checks create http nat-gw-ilbnhop-health-check \
       --region us-central1 \
       --port 80
   

3. יוצרים קבוצת מופעי מכונה אזורית עם שני מופעים שמפוזרים באזור אחד:

   gcloud compute instance-groups managed create \
       hub-nat-gw-ilbnhop-mig \
       --region us-central1 --size=2 \
       --template=hub-nat-gw-ilbnhop-template \
       --health-check nat-gw-ilbnhop-health-check \
       --initial-delay 15
   

   במדריך הזה, ההשהיה הראשונית מוגדרת ל-15 שניות. בפריסה בסביבת הייצור, צריך להתאים אישית את ההגדרה הזו בהתאם לדרישות. במדריך הזה לא נעשה שימוש במדיניות של שינוי גודל אוטומטי.

4. יוצרים שירות לקצה העורפי ומוסיפים את קבוצת המכונות:

   gcloud compute backend-services create hub-nat-gw-ilbnhop-backend \
       --load-balancing-scheme=internal \
       --protocol=tcp \
       --health-checks=nat-gw-ilbnhop-health-check
   
   gcloud compute backend-services add-backend \
       hub-nat-gw-ilbnhop-backend \
       --instance-group=hub-nat-gw-ilbnhop-mig \
       --instance-group-region=us-central1
   

5. יוצרים כלל העברה:

   gcloud compute forwarding-rules create \
       hub-nat-gw-ilbnhop \
       --load-balancing-scheme=internal \
       --network=hub-vpc \
       --subnet=hub-subnet1 \
       --address=10.0.0.10 \
       --ip-protocol=TCP \
       --ports=all \
       --backend-service=hub-nat-gw-ilbnhop-backend \
       --backend-service-region=us-central1 \
       --service-label=hub-nat-gw-ilbnhop
   

   למרות שכלל ההעברה מוגדר רק עם TCP, כשמשתמשים במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי כצעד הבא, כלל ההעברה מעביר את כל התעבורה לכל היציאות במכונות הווירטואליות של ה-backend. מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי הוא מאזן עומסים אזורי.

6. יוצרים נתיב חדש עם כלל ההעברה בתור הדילוג הבא:

   gcloud compute routes create hub-nat-gw-ilbnhop \
       --network=hub-vpc \
       --destination-range=0.0.0.0/0 \
       --next-hop-ilb=hub-nat-gw-ilbnhop \
       --next-hop-ilb-region=us-central1 \
       --priority=800
   

   אתם יכולים לציין תגי רשת כדי שהמסלול של הדילוג הבא יחול רק על מכונות של לקוחות שהוגדרו עם התג, אבל התגים לא מיוצאים או מיובאים דרך קישור VPC בין רשתות שכנות (Peering).

7. מוחקים את מסלול ברירת המחדל מרשת ה-VPC של הרכזת:

   export hub_default_route=$(gcloud compute routes list \
       --format="value(name)" --filter="network:hub-vpc AND \
       nextHopGateway:default-internet-gateway" | head -n 1)
   gcloud compute routes delete $hub_default_route -q
   

8. יוצרים נתיב מתויג חדש שמאפשר תעבורת נתונים רק משערי ה-NAT:

   gcloud compute routes create hub-default-tagged \
       --network hub-vpc --destination-range 0.0.0.0/0 \
       --next-hop-gateway default-internet-gateway \
       --priority 700 --tags nat-gw
   

9. מוחקים את נתיבי ברירת המחדל לאינטרנט מה-VPC של כל רשת Spoke:

   export spoke1_default_route=$(gcloud compute routes list \
       --format="value(name)" --filter="network:spoke1-vpc AND \
       nextHopGateway:default-internet-gateway")
   
   gcloud compute routes delete $spoke1_default_route -q
   
   export spoke2_default_route=$(gcloud compute routes list \
       --format="value(name)" \
       --filter="network:spoke2-vpc AND nextHopGateway:default-internet-gateway")
   
   gcloud compute routes delete $spoke2_default_route -q
   

   במקרה של התנגשות בין מסלולים מקומיים למסלולים מיובאים, תמיד תינתן עדיפות למסלולים המקומיים. מידע נוסף זמין במאמר בנושא סדר הניתוב.

10. יוצרים מכונות וירטואליות של לקוחות:

    gcloud compute instances create spoke1-client \
        --subnet=spoke1-subnet1 --no-address \
        --metadata startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'
    
    gcloud compute instances create spoke2-client \
        --subnet=spoke2-subnet1 --no-address \
        --metadata startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'
    

יצירת חיבורים של קישור בין רשתות VPC שכנות (peering)

קישור בין רשתות VPC שכנות (peering) הוא דו-כיווני, ולכן צריך להגדיר אותו בשני הצדדים. רשת VPC יכולה להתחבר לכמה רשתות VPC שכנות, אבל יש מגבלות. כדי להגיע לנתיב ברירת המחדל דרך קישור בין רשתות VPC שכנות, משתמשים בתכונה ייבוא וייצוא של נתיבים בהתאמה אישית דרך קישור בין רשתות VPC שכנות.

במדריך הזה, יוצרים את כל רשתות ה-VPC באותוGoogle Cloud פרויקט.

1. ב-Cloud Shell, יוצרים את חיבורי ה-VPC מרשת ה-VPC המרכזית לרשתות ה-VPC המקושרות, כשדגל ייצוא המסלולים מופעל:

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

2. יוצרים קישור בין רשתות VPC שכנות (peering) מרשת ה-VPC של spoke1 לרשת ה-VPC של הרכזת, כשהדגל של ייבוא הנתיבים מופעל:

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

3. יוצרים קישור בין רשתות VPC שכנות (peering) מרשת ה-VPC‏ spoke2 לרשת ה-VPC המרכזית, עם הפעלת הדגל של ייבוא מסלולים:

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

אימות של הפצת הנתיבים והקישוריות

1. ב-Cloud Shell, מוודאים שהמסלולים הסטטיים נוצרו בצורה נכונה כחלק מסקריפטים לטעינה בזמן ההפעלה.

   gcloud compute routes list --filter="network:hub-vpc"
   

   מוודאים שהנתיבים hub-default-tagged ו-hub-nat-gw-ilbanhop מופיעים בפלט:

   NAME                            NETWORK  DEST_RANGE      NEXT_HOP                  PRIORITY
   default-route-13a4b635b5eab48c  hub-vpc  10.0.0.0/24     hub-vpc                   1000
   hub-default-tagged              hub-vpc  0.0.0.0/0       default-internet-gateway  700
   hub-nat-gw-ilbanhop             hub-vpc  0.0.0.0/0       10.0.0.10                 800
   peering-route-3274f1257a9842a0  hub-vpc  192.168.2.0/24  hub-to-spoke2             1000
   peering-route-798c5777f13094bc  hub-vpc  192.168.1.0/24  hub-to-spoke1             1000
   

2. בודקים את spoke1-vpc טבלת הניתוב כדי לוודא שנתיב ברירת המחדל יובא בצורה נכונה:

   gcloud compute routes list --filter="network:spoke1-vpc"
   

   מוודאים שיש מסלול שמתחיל ב-peering-route עם 0.0.0.0/0 כערך DEST_RANGE בפלט:

   NAME                            NETWORK     DEST_RANGE      NEXT_HOP       PRIORITY
   default-route-75f6ea8f5fc54813  spoke1-vpc  192.168.1.0/24  spoke1-vpc     1000
   peering-route-6c7f130b860bfd39  spoke1-vpc  10.0.0.0/24     spoke1-to-hub  1000
   peering-route-9d44d362f98afbd8  spoke1-vpc  0.0.0.0/0       spoke1-to-hub  800
   

3. מתחברים לאחד מהלקוחות באמצעות SSH דרך IAP:

   gcloud compute ssh spoke1-client --tunnel-through-iap
   

4. כדי לבדוק את הקישוריות, בודקים את ה-DNS הציבורי של Google דרך שער ה-NAT:

   sudo hping3 -S -p 80 -c 3 dns.google
   

   מאחר שמאזן העומסים הפנימי של רשת להעברת סיגנל ללא שינוי תומך ב-TCP וב-UDP, אי אפשר לאמת את הקישוריות לאינטרנט באמצעות פינג מבוסס-ICMP, ולכן צריך להשתמש בכלי כמו hping3.

   הפלט אמור להיראות כך:

   HPING dns.google (eth0 8.8.4.4): S set, 40 headers + 0 data bytes
   len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=0 win=65535 rtt=4.6 ms
   len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=1 win=65535 rtt=4.4 ms
   len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=2 win=65535 rtt=4.3 ms
   
   --- dns.google hping statistic ---
   3 packets transmitted, 3 packets received, 0% packet loss
   round-trip min/avg/max = 4.3/4.4/4.6 ms
   

5. בודקים את כתובת ה-IP הציבורית שבה אתם משתמשים כדי לתקשר עם האינטרנט:

   curl ifconfig.co
   

   בפלט מוצגת כתובת IP ציבורית של אחת מהמופעים של שער ה-NAT. אם תריצו את הפקודה שוב, יכול להיות שבפלט תוצג כתובת IP ציבורית אחרת, כי החיבורים מופצים באמצעות הזיקה לסשן (session affinity) של איזון העומסים הפנימי שהוגדר (כברירת מחדל, כתובת ה-IP, הפרוטוקול והיציאה של הלקוח).

   קישור בין רשתות VPC שכנות (peering) הוא לא טרנזיטיבי, ולכן אין קישוריות בין רשתות ה-VPC המקושרות באמצעות קישור בין רשתות VPC שכנות (peering).

שיקולים לגבי סביבת ייצור

ההגדרה שתיצרו במדריך הזה מספקת שני שערי NAT באזור אחד. עם זאת, איזון העומסים של ECMP לא מושלם, וזרימה בודדת לא מתפרסת על פני כמה קישורים, וזה מה שאתם רוצים כשאתם משתמשים במכשירים עם שמירת מצב (stateful), כמו חומות אש מהדור הבא.

כדי לפרוס את ההגדרה הזו בסביבת הייצור, כדאי לשים לב לנקודות הבאות:

• ההגדרה הזו מתאימה במיוחד לקישורים זמניים או לקישורים לאתרים אחרים שלא שומרים את המצב. אם הגודל של מאגר שער ה-NAT משתנה, יכול להיות שחיבורי ה-TCP יאזנו את עצמם מחדש, וזה עלול לגרום לאיפוס של חיבור קיים.
• הצמתים לא מתעדכנים באופן אוטומטי, ולכן אם בהתקנת Debian שמוגדרת כברירת מחדל יש פגיעות אבטחה, צריך לעדכן את התמונה באופן ידני.
• אם יש לכם מכונות וירטואליות בכמה אזורים, אתם צריכים להגדיר שערי NAT בכל אזור.
• רוחב הפס לכל שער יכול להשתנות בהתאם לסוג החומרה. חשוב להביא בחשבון גורמים כמו רוחב הפס המקסימלי של תעבורת הנתונים היוצאת לכל מכונה וירטואלית. במקרה של תקלה בשער, התנועה מופצת לשערים שנותרו. מכיוון שזרימות פעילות לא מתוכנתות מחדש, התנועה לא מתאזנת מחדש באופן מיידי כשהשער חוזר למצב אונליין. לכן, חשוב להקצות מספיק מקום לתוספת הזו כשקובעים את הגודל.
• כדי לקבל התראה על תוצאות לא צפויות, אפשר להשתמש ב-Cloud Monitoring כדי לעקוב אחרי קבוצות מופעי מכונה מנוהלים ותנועה ברשת.

הסרת המשאבים

הדרך הקלה ביותר לבטל את החיוב היא למחוק את הפרויקט ב- Google Cloud שיצרתם בשביל המדריך הזה. אפשר גם למחוק את המשאבים בנפרד.

מחיקת הפרויקט

זהירות: כשמוחקים פרויקט:
• התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
• מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.
1. במסוף Google Cloud , נכנסים לדף Manage resources.

   כניסה לדף Manage resources

2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

מחיקת המשאבים הבודדים

אם אתם רוצים לשמור את הפרויקט Google Cloud , אתם יכולים למחוק את המשאבים שיצרתם בשביל המדריך הזה.

1. מוחקים את החיבורים של קישור בין רשתות VPC שכנות (peering):

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

2. מחיקת המופעים, המשאבים של מאזן העומסים, התבניות והמסלולים:

   gcloud compute instances delete spoke1-client \
     --zone=us-central1-c -q
   
   gcloud compute instances delete spoke2-client \
     --zone=us-central1-c -q
   
   gcloud compute routes delete hub-nat-gw-ilbnhop -q
   
   gcloud compute forwarding-rules delete hub-nat-gw-ilbnhop -q
   
   gcloud compute backend-services delete -q hub-nat-gw-ilbnhop-backend -q
   
   gcloud compute instance-groups managed delete hub-nat-gw-ilbnhop-mig \
     --region us-central1 -q
   
   gcloud compute health-checks delete nat-gw-ilbnhop-health-check -q
   
   gcloud compute instance-templates delete hub-nat-gw-ilbnhop-template -q
   
   gcloud compute routes delete hub-default-tagged -q
   

3. מוחקים את הכללים של חומת האש, את תת-הרשתות ואת רשתות ה-VPC:

   gcloud compute firewall-rules delete spoke2-vpc-iap -q
   
   gcloud compute firewall-rules delete spoke2-vpc-web-ping-dns -q
   
   gcloud compute firewall-rules delete spoke1-vpc-iap -q
   
   gcloud compute firewall-rules delete spoke1-vpc-web-ping-dns -q
   
   gcloud compute firewall-rules delete hub-vpc-iap -q
   
   gcloud compute firewall-rules delete hub-vpc-web-ping-dns -q
   
   gcloud compute firewall-rules delete hub-vpc-health-checks -q
   
   gcloud compute networks subnets delete spoke1-subnet1 \
       --region us-central1 -q
   
   gcloud compute networks subnets delete spoke2-subnet1 \
       --region us-central1 -q
   
   gcloud compute networks subnets delete hub-subnet1 \
       --region us-central1 -q
   
   gcloud compute networks delete spoke1-vpc -q
   
   gcloud compute networks delete spoke2-vpc -q
   
   gcloud compute networks delete hub-vpc -q
   

המאמרים הבאים

• שיטות מומלצות ודוגמאות לארכיטקטורות לתכנון VPC
• מומלץ לעיין במסמכים בנושא קישור בין רשתות VPC שכנות (peering) ומאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי כנקודות קפיצה הבאות.
• הגדרות מיוחדות למכונות וירטואליות