רשתות VPC

רשת ענן וירטואלי פרטי (VPC) היא גרסה וירטואלית של רשת פיזית, שמיושמת בתוך רשת הייצור של Google באמצעות Andromeda.

רשת VPC מבצעת את הפעולות הבאות:

  • מספק קישוריות למכונות וירטואליות (VM) ב-Compute Engine.
  • מציע מאזני עומסים פנימיים של רשת להעברת סיגנל ללא שינוי ומערכות proxy מקוריות עבור מאזני עומסים פנימיים של אפליקציות.
  • מתחבר לרשתות מקומיות באמצעות מנהרות Cloud VPN וקבצים מצורפים של VLAN ל-Cloud Interconnect.
  • מפיץ את תעבורת הנתונים ממאזני עומסים חיצוניים לשרתי קצה עורפיים. Google Cloud

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

רשתות ורשתות משנה

המונחים תת-רשת ורשת משנה הם מילים נרדפות. המונחים האלה משמשים לסירוגין במסוף Google Cloud , בפקודות gcloud ובמסמכי ה-API.

רשת משנה היא לא אותו דבר כמו רשת (VPC). רשתות ותת-רשתות הם סוגים שונים של משאבים ב- Google Cloud.

מידע נוסף זמין במאמר בנושא רשתות משנה.

מופעים של מכונות וירטואליות

מכונה וירטואלית (VM) של Compute Engine היא מכונה וירטואלית שמארחת בתשתית של Google. המונחים מכונה של Compute Engine ‏(Compute Engine instance), מכונת VM‏ (VM instance) ו-VM הם מילים נרדפות. המונחים האלה משמשים לסירוגין במסוףGoogle Cloud , בהפניה ל-Google Cloud CLI ובמאמרי העזרה של ה-API.

מכונות וירטואליות כוללות אשכולות של Google Kubernetes Engine‏ (GKE), מכונות של הסביבה הגמישה של App Engine ומוצרי Google Cloud ם אחרים שנבנו על מכונות וירטואליות של Compute Engine.

מידע נוסף זמין במאמר מכונות וירטואליות במאמרי העזרה של Compute Engine.

מפרטים

לרשתות VPC יש את המאפיינים הבאים:

דוגמה לרשת VPC

בדוגמה הבאה מוצגת רשת VPC במצב מותאם אישית עם שלוש רשתות משנה בשני אזורים:

דוגמה לרשת VPC.
דוגמה לרשת VPC (לחצו כדי להגדיל).
  • ‫Subnet1 מוגדר כ-10.240.0.0/24 באזור us-west1.
    • שתי מכונות וירטואליות באזור us-west1-a נמצאות בתת-הרשת הזו. כתובות ה-IP שלהם מגיעות מהטווח הזמין של כתובות בsubnet1.
  • ‫Subnet2 מוגדר כ-192.168.1.0/24 באזור us-east1.
    • שתי מכונות וירטואליות באזור us-east1-b נמצאות בתת-הרשת הזו. שתי כתובות ה-IP שלהם מגיעות מטווח הכתובות הזמין בsubnet2.
  • ‫Subnet3 מוגדר כ-10.2.0.0/16, גם באזור us-east1.
    • מכונה וירטואלית אחת באזור us-east1-b ומכונה וירטואלית שנייה באזור us-east1-c נמצאות בsubnet3, וכל אחת מהן מקבלת כתובת IP מהטווח הזמין שלה. תת-רשתות הן משאבים אזוריים, ולכן אפשר לשייך את ממשקי הרשת של המכונות הווירטואליות לכל תת-רשת באותו אזור שכולל את האזורים שלהן.

מגבלות שקשורות למדיניות הארגון

  • כל פרויקט חדש מתחיל עם רשת VPC שמוגדרת כברירת מחדל. כדי להשבית את היצירה של רשתות ברירת מחדל, צריך ליצור מדיניות ארגונית עם האילוץ compute.skipDefaultNetworkCreation. בפרויקטים שבהם המדיניות הזו מוגדרת בירושה, לא תהיה רשת ברירת מחדל.

  • אתם יכולים לשלוט בהגדרות הבאות של IPv6 באמצעות מדיניות הארגון:

    • השבתת השימוש ב-IPv6 חיצוני ב-VPC: אם הערך הוא true, האילוץ constraints/compute.disableVpcExternalIpv6 מונע ממכם להגדיר רשתות משנה עם טווחי IPv6 חיצוניים.

    • השבתת השימוש ב-IPv6 פנימי ב-VPC: אם המדיניות מוגדרת כ-True, האילוץ constraints/compute.disableVpcInternalIpv6 מונע מכם להגדיר רשתות משנה עם טווחי IPv6 פנימיים.

    • השבתה של כל השימוש ב-IPv6: אם הערך מוגדר כ-true, האילוץ constraints/compute.disableAllIpv6 משבית את היצירה של רשתות משנה או משאבי רשת אחרים שקשורים לשימוש ב-IPv6, או את העדכון שלהם.

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

מצב יצירת רשת משנה

‫Google Cloud מציעה שני סוגים של רשתות VPC, שנקבעים לפי מצב יצירת תת-הרשת:

  • כשיוצרים רשת VPC במצב אוטומטי, נוצרת בה אוטומטית רשת משנה אחת מכל אזור. רשתות המשנה שנוצרות באופן אוטומטי משתמשות בקבוצה של טווחים מוגדרים מראש של כתובות IPv4 שמתאימים לבלוק ה-CIDR‏ 10.128.0.0/9. כש Google Cloud אזורים חדשים הופכים לזמינים, תת-רשתות חדשות באזורים האלה מתווספות אוטומטית לרשתות VPC במצב אוטומטי באמצעות טווח כתובות IP מהבלוק הזה. בנוסף לתת-רשתות שנוצרות באופן אוטומטי, אפשר להוסיף עוד תת-רשתות באופן ידני לרשתות VPC במצב אוטומטי באזורים שתבחרו באמצעות טווחי כתובות IP מחוץ ל-10.128.0.0/9.

  • כשיוצרים רשת VPC במצב מותאם אישית, לא נוצרות רשתות משנה באופן אוטומטי. סוג הרשת הזה מאפשר לכם שליטה מלאה ברשתות המשנה ובטווח כתובות ה-IP שלה. אתם מחליטים אילו רשתות משנה ליצור באזורים שתבחרו, באמצעות טווחי IP שתציינו.

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

רשת ברירת מחדל

אלא אם משביתים את האפשרות הזו, כל פרויקט חדש מתחיל עם רשת ברירת מחדל. רשת ברירת המחדל היא רשת VPC במצב אוטומטי עם כללי חומת אש של IPv4 שמולאו מראש. ברשת שמוגדרת כברירת מחדל אין כללי חומת אש של IPv6 שמולאו מראש.

שיקולים לגבי רשתות VPC במצב אוטומטי

רשתות VPC במצב אוטומטי קלות להגדרה ולשימוש, והן מתאימות לתרחישי שימוש עם המאפיינים הבאים:

  • היתרון בשימוש ברשתות משנה שנוצרות אוטומטית בכל אזור הוא שזה חוסך זמן.

  • טווח כתובות ה-IP המוגדר מראש של רשתות המשנה לא חופף לטווח כתובות ה-IP שבו תשתמשו למטרות שונות (לדוגמה, חיבורי Cloud VPN למשאבים מקומיים).

עם זאת, רשתות VPC במצב מותאם אישית הן גמישות יותר ומתאימות יותר לסביבת ייצור. המאפיינים הבאים מדגישים תרחישי שימוש שבהם מומלץ או נדרש להשתמש ברשתות VPC במצב מותאם אישית:

  • לא חייבים ליצור אוטומטית רשת משנה אחת בכל אזור.

  • יכול להיות שרשתות משנה חדשות שנוצרות אוטומטית כשאזורים חדשים הופכים לזמינים יחפפו לכתובות IP שמשמשות רשתות משנה שנוצרו ידנית או מסלולים סטטיים, או יפריעו לתכנון הרשת הכולל שלכם.

  • אתם צריכים שליטה מלאה בתת-הרשתות שנוצרות ברשת ה-VPC, כולל האזורים וטווח כתובות ה-IP שבהם נעשה שימוש.

  • אתם מתכננים לחבר את רשת ה-VPC לרשת אחרת:

    • מכיוון שרשתות המשנה של כל רשת VPC במצב אוטומטי משתמשות באותו טווח מוגדר מראש של כתובות IP, אי אפשר לקשר בין רשתות VPC במצב אוטומטי באמצעות קישור בין רשתות VPC שכנות (peering) או Cloud VPN.

    • מכיוון שטווח ה-CIDR של מצב אוטומטי 10.128.0.0/9 הוא חלק ממרחב הכתובות RFC 1918 שנעשה בו שימוש נפוץ, יכול להיות שרשתות מחוץ ל- Google Cloud ישתמשו בטווח CIDR חופף.

  • אתם רוצים ליצור רשתות משנה עם טווחי IPv6. רשתות VPC במצב אוטומטי לא תומכות ברשתות משנה עם טווחי IPv6.

טווחי רשתות משנה של IPv4

לכל תת-רשת יש טווח כתובות IPv4 ראשי. הכתובות הפנימיות הראשיות של המשאבים הבאים מגיעות מהטווח הראשי של רשת המשנה: מכונות וירטואליות, מאזני עומסים פנימיים והעברת פרוטוקולים פנימית. אפשר גם להוסיף טווחי כתובות IP משניים לתת-רשת, שמשמשים רק לטווחי כתובות IP חלופיות. עם זאת, אפשר להגדיר טווחי IP של כינויים למופעים מהטווח הראשי או המשני של תת-רשת.

כל טווח כתובות IPv4 ראשי או משני לכל תת-הרשתות ברשת VPC חייב להיות בלוק CIDR חוקי וייחודי. אפשר לעיין במגבלות לכל רשת כדי לראות כמה טווחי כתובות IP משניים אפשר להגדיר.

לא צריך שכל תתי הרשתות של IPv4 יהיו חלק מבלוק CIDR רציף מוגדר מראש, אבל אפשר לעשות את זה אם רוצים. לדוגמה, רשתות VPC במצב אוטומטי יוצרות רשתות משנה שמתאימות לטווח IP מוגדר מראש במצב אוטומטי.

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

בכל טווח של רשת משנה ראשית של IPv4 יש ארבע כתובות IP שלא ניתן להשתמש בהן. מידע נוסף זמין במאמר בנושא כתובות שלא ניתן להשתמש בהן בטווחים של רשתות משנה ב-IPv4.

רשתות VPC במצב אוטומטי נוצרות עם רשת משנה אחת לכל אזור בזמן היצירה, ומקבלות אוטומטית רשתות משנה חדשות באזורים חדשים. לתת-הרשתות יש טווחי IPv4 בלבד, וכל טווחי תת-הרשתות מתאימים לבלוק ה-CIDR ‏10.128.0.0/9. חלקים שלא נוצלו מתוך 10.128.0.0/9 שמורים לשימוש עתידי ב-Google Cloud . מידע על טווח ה-IPv4 שמשמש באזור מסוים זמין במאמר טווחים של תת-רשתות IPv4 במצב אוטומטי.

טווחי רשתות משנה של IPv6

כשיוצרים רשת משנה עם טווח IPv6 ברשת VPC במצב מותאם אישית, בוחרים אם להגדיר את רשת המשנה עם טווח IPv6 פנימי או עם טווח IPv6 חיצוני.

  • נעשה שימוש בטווחים של תת-רשתות פנימיות של IPv6 לתקשורת בין מכונות וירטואליות ברשתות VPC. לא ניתן להגיע אליהם מהאינטרנט והם לא ניתנים לניתוב באופן ציבורי.
  • אפשר להשתמש בטווחים של תת-רשתות IPv6 חיצוניות לתקשורת בין מכונות וירטואליות, והן ניתנות לניתוב ציבורי.

מידע נוסף על טווחי רשתות משנה של IPv6 זמין במאמר בנושא רשתות משנה.

רשתות שתומכות בתת-רשתות עם טווחי כתובות IPv6

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

אין תמיכה ברשתות משנה עם טווחי כתובות IPv6 במוצרים הבאים:

  • רשתות VPC במצב אוטומטי, כולל רשת ברירת המחדל
  • רשתות מדור קודם

אם יש לכם רשת VPC במצב אוטומטי שאתם רוצים להוסיף לה רשתות משנה עם טווחי כתובות IPv6, אתם יכולים לעשות את הפעולות הבאות:

  1. המרת הרשת במצב אוטומטי למצב מותאם אישית.

  2. יוצרים רשתות משנה חדשות עם תמיכה בשני הפרוטוקולים או עם IPv6 בלבד. אפשר גם להמיר רשתות משנה קיימות של IPv4 בלבד ל-dual-stack.

מסלולים וכללים לחומת אש

מסלולים

מסלולים מגדירים נתיבים לחבילות שיוצאות ממופעים (תעבורת נתונים יוצאת). פרטים על Google Cloud סוגי מסלולים זמינים במאמר מסלולים.

מצב ניתוב דינמי

לכל רשת VPC משויך מצב ניתוב דינמי ששולט בהתנהגות של כל נתבי Cloud Router שלה. ‫Cloud Routers מנהל סשנים של BGP עבור מוצריGoogle Cloud שמשתמשים ב-Cloud Router.

תיאור של אפשרויות מצב הניתוב הדינמי זמין במאמר מצב ניתוב דינמי במאמרי העזרה של Cloud Router.

ניתוב של פרסומים וכתובות IP פנימיות

כתובות ה-IP הבאות מפורסמות ברשת VPC:

אם מחברים רשתות VPC באמצעות קישור בין רשתות VPC שכנות (peering), תמיד מתבצעת החלפה של טווחי רשתות משנה באמצעות כתובות IPv4 פרטיות. אתם יכולים לקבוע אם יתבצע שיתוף של טווחי תת-רשתות שמשתמשים בכתובות IPv4 ציבוריות לשימוש פרטי, וגם אם יתבצע שיתוף של טווחי תת-רשתות פנימיים וחיצוניים של IPv6. כתובות IPv4 פנימיות גלובליות אף פעם לא מוחלפות באמצעות שיתוף פעולה. פרטים נוספים זמינים במסמכי התיעוד בנושא VPC Network Peering.

כשמחברים רשת VPC לרשת אחרת, כמו רשת מקומית, באמצעות מוצר קישוריות כמו Cloud VPN,‏ Cloud Interconnect או נתב וירטואלי: Google Cloud

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

כללי חומת אש

גם מדיניות חומת אש היררכית וגם כללי חומת אש של VPC חלים על חבילות שנשלחות אל מכונות וירטואליות וממכונות וירטואליות (וממשאבים שתלויים במכונות וירטואליות, כמו צמתים של Google Kubernetes Engine). שני סוגי חומות האש שולטים בתעבורת הנתונים גם אם היא מתבצעת בין מכונות וירטואליות באותה רשת VPC.

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

תקשורת וגישה

תקשורת בתוך הרשת

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

חוץ מרשת ברירת המחדל, צריך ליצור במפורש כללי חומת אש לכניסה בעדיפות גבוהה יותר כדי לאפשר למופעים לתקשר אחד עם השני. רשת ברירת המחדל כוללת כמה כללים של חומת אש בנוסף לכללים המשתמעים, כולל הכלל default-allow-internal, שמאפשר תקשורת בין מופעים ברשת. רשת ברירת המחדל כוללת גם כללי תעבורה נכנסת שמאפשרים פרוטוקולים כמו RDP ו-SSH.

כללים שמגיעים עם רשת ברירת המחדל מוצגים גם כאפשרויות להחלה על רשתות VPC חדשות במצב אוטומטי שיוצרים באמצעות Google Cloud המסוף.

דרישות לגישה לאינטרנט

כדי שלמופע תהיה גישה לאינטרנט ליציאה, הוא צריך לעמוד בקריטריונים הבאים:

  • ברשת צריכה להיות רשת שער אינטרנט ברירת מחדל חוקית או מסלול מותאם אישית, שטווח כתובות ה-IP של היעד שלו הוא הכללי ביותר (0.0.0.0/0 ל-IPv4,‏ ::/0 ל-IPv6). המסלול הזה מגדיר את הנתיב לאינטרנט. מידע נוסף זמין במאמר סוגי מסלולים.

  • כללי חומת האש צריכים לאפשר תעבורת נתונים יוצאת מהמכונה. אלא אם בוטלה על ידי כלל בעדיפות גבוהה יותר, כלל ההיתר המשתמע לתעבורת נתונים יוצאת מאפשר תעבורת נתונים יוצאת מכל המכונות.

  • אחד מהתנאים הבאים חייב להתקיים:

    • למופע צריכה להיות כתובת IP חיצונית. אפשר להקצות כתובת IP חיצונית למופע כשיוצרים אותו או אחרי שיוצרים אותו.

    • המופע צריך להיות מסוגל להשתמש ב-Cloud NAT או בשרת proxy מבוסס-מופע שהוא היעד של נתיב סטטי 0.0.0.0/0או ::/0.

תקשורת וגישה ל-App Engine

כללי חומת האש של VPC חלים על משאבים שפועלים ברשת ה-VPC, כמו מכונות וירטואליות של Compute Engine. במקרים של מכונות App Engine, כללי חומת האש פועלים באופן הבא:

  • הסביבה הרגילה של App Engine: רק כללי חומת האש של App Engine חלים על תנועת גולשים נכנסת. מכיוון שמופעים של הסביבה הרגילה של App Engine לא פועלים בתוך רשת ה-VPC, כללי חומת האש של ה-VPC לא חלים עליהם.

  • הסביבה הגמישה של App Engine: כללי חומת האש של App Engine ושל VPC חלים על תעבורת נתונים נכנסת. תנועה נכנסת מותרת רק אם היא מאושרת על ידי שני סוגי כללי חומת האש. לגבי תעבורה יוצאת, חלים כללי חומת האש של ה-VPC.

מידע נוסף על שליטה בגישה למופעי App Engine זמין במאמר אבטחת אפליקציות.

Traceroute לכתובות IP חיצוניות

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

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

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

מגבלות על קצב העברת הנתונים היוצא

מידע על תפוקת הרשת זמין בדף רוחב פס ברשת במסמכי התיעוד של Compute Engine.

גודל המנות

מידע על גודל המנות זמין במאמר בנושא יחידת שידור מקסימלית.

יחידת שידור מקסימלית

מידע נוסף על הגדרת יחידת השידור המקסימלית (MTU) לרשת VPC ולמכונות וירטואליות שמחוברות אליה זמין במאמר יחידת שידור מקסימלית.

מידע על שינוי ה-MTU של רשת VPC או על העברת מכונות וירטואליות בין רשתות VPC עם הגדרות MTU שונות זמין במאמר שינוי הגדרת ה-MTU של רשת VPC.

פרוטוקולים נתמכים

הפונקציהGoogle Cloud תומכת רק בפרוטוקולים ובכותרות ההרחבה הבאים:

  • חבילות נתונים של IPv4 בין מכונות וירטואליות: כל פרוטוקולי IPv4.
  • חבילות נתונים של IPv4 בין מכונות וירטואליות לאינטרנט: הפרוטוקולים ICMP,‏ IPIP,‏ TCP,‏ UDP,‏ GRE,‏ ESP,‏ AH ו-SCTP.
  • חבילות נתונים של IPv6 בין מכונות וירטואליות ובין מכונות וירטואליות לאינטרנט: הפרוטוקולים AH,‏ ESP, ‏ GRE, ‏ ICMP, ‏ ICMPv6, ‏ IPIP, ‏ SCTP, ‏ TCP ו-UDP, וכותרות ההרחבה Destination Options ו-Fragments. עם זאת, אי אפשר למקם את הכותרת Destination Options אחרי הכותרת Fragment במנות נתונים של IPv6.
  • העברת פרוטוקולים: הפרוטוקולים AH,‏ ESP,‏ GRE,‏ ICMP,‏ ICMPv6,‏ SCTP,‏ TCP ו-UDP

כדי לאפשר חבילות נתונים של הפרוטוקולים הנתמכים, צריך להגדיר כללי חומת אש או כללים להעברת פרוטוקולים בהתאם לדרישות.

פרופילים של רשת לתרחישי שימוש ספציפיים

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

תרחיש השימוש שפרופילי הרשת תומכים בו הוא הפעלת עומסי עבודה של AI במכונות עם כרטיסי רשת (NIC) שתומכים בגישה ישירה לזיכרון מרחוק (RDMA).Google Cloud מספקת פרופילי רשת RDMA שמאפשרים ליצור רשתות ענן וירטואלי פרטי (VPC) שתומכות בקישוריות RDMA.

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

מידע נוסף על הפעלת עומסי עבודה של AI ב- Google Cloudזמין במאמרי העזרה בנושא AI Hypercomputer.

ביצועי הרשת

זמן אחזור

אפשר למצוא את זמן האחזור שנמדד בין אזורים ברשתות VPC בלוח הבקרה של ביצועי Network Intelligence Center, שזמין ללקוחות Google Cloud .

בנוסף, מרכז השליטה של הסטרימינג בשידור חי, שמתוחזק על ידי צד שלישי, מציג את המדדים של זמן האחזור החציוני בין אזורים ושל ביצועי התפוקה, כולל המתודולוגיה לשחזור התוצאות האלה באמצעות PerfKit Benchmarker. Google Cloud

בדרך כלל,Google Cloud מודד זמן אחזור של הלוך ושוב של פחות מ-55 מיקרו-שניות באחוזון ה-50, וזמן אחזור של פחות מ-80 מיקרו-שניות באחוזון ה-99 בין מכונות וירטואליות מסוג c2-standard-4 באותו אזור.

Google Cloud בדרך כלל נמדדים זמני אחזור של פחות מ-45 מיקרו-שניות באחוזון ה-50 וזמני אחזור של פחות מ-60 מיקרו-שניות באחוזון ה-99 בין מכונות וירטואליות מסוג c2-standard-4 באותה רשת עם זמן אחזור נמוך (מדיניות מיקום 'קומפקטית'). מדיניות מיקום קומפקטית מקטינה את זמן האחזור ברשת, כי היא מוודאת שהמכונות הווירטואליות ממוקמות פיזית באותה רשת עם זמן אחזור נמוך.

מתודולוגיה: זמן האחזור בתוך אזור נתון נמדד באמצעות כלי בדיקה מסוג blackbox שפועל באופן קבוע. הכלי מריץ את מדד הביצועים netperf TCP_RR בין זוג מכונות וירטואליות מסוג c2 בכל אזור שבו מופעלות מכונות וירטואליות מסוג c2. היא אוספת תוצאות של P50 ו-P99 להגדרה עם מדיניות למיקום קומפקטי ובלעדיה. המדד TCP_RR בודק את הביצועים של בקשות ותגובות על ידי מדידת קצב העסקאות. אם האפליקציות שלכם דורשות את זמן האחזור הטוב ביותר האפשרי, מומלץ להשתמש במופעי c2.

אובדן מנות

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

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

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

נסו בעצמכם

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

אני רוצה לנסות את VPC בחינם