רשתות VPC

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

רשת VPC:

  • מספק קישוריות למכונות וירטואליות (VM) ב-Compute Engine.
  • מציע מאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי ומערכות proxy מקוריות למאזני עומסים פנימיים של אפליקציות (ALB).
  • מתחבר לרשתות מקומיות באמצעות מנהרות 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 שלה. ‫Cloud Routers מנהלים סשנים של BGP עבור מוצריGoogle Cloud שמשתמשים ב-Cloud Router.

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

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

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

אם מחברים רשתות VPC באמצעות קישור בין רשתות VPC שכנות (peering), תמיד מתבצעת החלפה של טווחי רשתות משנה (subnet) באמצעות כתובות IPv4 פרטיות. אתם יכולים לקבוע אם יתבצע שיתוף של טווחי תת-רשתות שמשתמשים בכתובות IPv4 ציבוריות לשימוש פרטי, וגם אם יתבצע שיתוף של טווחי תת-רשתות פנימיים וחיצוניים של IPv6. כתובות IPv4 פנימיות גלובליות אף פעם לא מוחלפות באמצעות קישור בין רשתות שכנות (peering). פרטים נוספים זמינים במסמכי התיעוד בנושא 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 פנימיות. כדי שמופע אחד יוכל לתקשר עם מופע אחר, צריך גם להגדיר כללים מתאימים של חומת אש, כי לכל רשת יש כלל חומת אש משתמע של דחייה לתעבורת נתונים נכנסת.

חוץ מרשת ברירת המחדל, צריך ליצור במפורש כללי חומת אש לתעבורה נכנסת בעדיפות גבוהה יותר כדי לאפשר למופעים לתקשר אחד עם השני. רשת ברירת המחדל כוללת כמה כללים של חומת אש בנוסף לכללים המשתמעים, כולל הכלל default-allow-internal, שמאפשר תקשורת בין מופעים ברשת. רשת ברירת המחדל כוללת גם כללי תעבורת נתונים נכנסת (ingress) שמאפשרים פרוטוקולים כמו 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 חלים על תעבורת נתונים נכנסת (ingress). מכיוון שמופעים של הסביבה הרגילה של 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 חיצונית שמשויכת למכונה וירטואלית.

מגבלות על קצב העברת הנתונים (throughput) של תעבורת נתונים יוצאת

מידע על קצב העברת הנתונים ברשת זמין בדף רוחב פס ברשת במסמכי התיעוד של 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.

ביצועי הרשת

זמן אחזור

אפשר לראות את זמן הטעינה שנמדד בין אזורים ברשתות 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 בחינם