רוחב הפס של הרשת

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

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

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

כל המידע שמופיע בדף הזה רלוונטי למכונות וירטואליות של Compute Engine, וגם למוצרים שתלויים במכונות של Compute Engine. לדוגמה, צומת של Google Kubernetes Engine הוא מופע של Compute Engine.

הגדרות שמשפיעות על רוחב הפס של הרשת

לא ממשקי רשת וירטואליים (vNIC) נוספים ולא כתובות IP נוספות לכל vNIC מגדילים את רוחב הפס של התעבורה הנכנסת או היוצאת של מכונת מחשוב. לדוגמה, מכונת VM מסוג C3 עם 22 ליבות וירטואליות מוגבלת לרוחב פס כולל של 23 Gbps ליציאה. אם מגדירים את מכונת ה-VM מסוג C3 עם שני vNIC, מכונת ה-VM עדיין מוגבלת לרוחב פס כולל של 23 Gbps ליציאה, ולא לרוחב פס של 23 Gbps לכל vNIC.

כדי לקבל את רוחב הפס הגבוה ביותר ברשת, יוצרים מופעים על סמך סדרות המכונות network-optimized או accelerator-optimized. למופעים האלה יש כמה כרטיסי רשת פיזיים (pNIC) שזמינים למופע.

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

שימוש בביצועי רשת Tier_1 לכל מכונה וירטואלית

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

ממשקי רשת דינמיים

ממשקי רשת דינמיים משתמשים ברוחב הפס של ה-vNIC הראשי שלהם. אין בידוד תנועה בתוך כרטיס רשת וירטואלי ראשי. תנועת רשת מ-NIC דינמי יכולה לגרום ל-NIC דינמי אחר שמשויך לאותו vNIC אב לא לקבל מספיק משאבים. כדי להימנע מהתנגשות כזו, אפשר להשתמש בבקרת תנועה (TC) של Linux כדי ליצור מדיניות לעיצוב תנועה ספציפית לאפליקציה. המדיניות הזו עוזרת להטמיע הוגנות או סוגים מסוימים של עדיפות. כדי לתעדף תנועה (למשל, עבור כרטיסי רשת דינמיים), ממפים את התנועה לסיווג תנועה, ואז ממפים את סיווג התנועה לאיכות השירות. דוגמה לגישה הזו מופיעה במאמר Traffic shaping with Red Hat.

לא ניתן להשתמש בממשקי רשת דינמיים (NIC) במופעי Compute Engine שמופעלת בהם מערכת הפעלה Windows.

שיתוף רוחב פס עם Cloud RDMA

אפליקציות שמשתמשות ב-Cloud RDMA בדרך כלל משתמשות בתעבורת TCP ו-RDMA. לדוגמה, במהלך עבודות של מחשוב עתיר ביצועים (HPC), אפליקציות בדרך כלל משתמשות ב-TCP לתקשורת במהלך שלבי הטעינה והאחסון, וב-RDMA לשלבי החישוב. מכונות H4D שמשתמשות ב-GVNIC לתעבורת TCP מספקות רוחב פס ברשת של עד 200 Gbps. אם מגדירים גם מופע H4D לשימוש ב-Cloud RDMA, רוחב הפס של הרשת משותף בין ממשקי הרשת המוגדרים.

הקצאת רוחב הפס ברשת בין תעבורת Cloud RDMA לתעבורת TCP מתבצעת באופן דינמי. במקום להגביל את התעבורה של Cloud RDMA ו-TCP לרוחב פס של 100 Gbps כל אחת, ממשק הרשת GVNIC יכול להשתמש בכל רוחב הפס הזמין כשממשק הרשת Cloud RDMA לא נמצא בשימוש. באופן דומה, ממשק הרשת של Cloud RDMA יכול להשתמש בכל רוחב הפס הזמין כשממשק הרשת של GVNIC לא נמצא בשימוש. כשמשתמשים בשני סוגי ממשקי הרשת, רוחב הפס משותף לתעבורת Cloud RDMA ולתעבורת TCP.

סיכום רוחב הפס

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

מגבלות רוחב פס לנתונים יוצאים

ניתוב בתוך רשת VPC
  • הגורם העיקרי שקובע את רוחב הפס הוא רוחב הפס המקסימלי לתעבורת נתונים יוצאת לכל מופע, שמבוסס על סוג המכונה של המופע השולח ועל ההגדרה של Tier_1 networking.

    • מכונות וירטואליות מסוג N2, ‏ N2D, ‏ C2, ‏ C2D, ‏ M3 ו-C4A עם תמיכה ברשת Tier_1, מגבלות רוחב פס של תעבורת נתונים יוצאת עד 100 Gbps.
    • מכונות וירטואליות מסוג H3 תומכות בהגבלות על רוחב הפס של תעבורת נתונים יוצאת ממכונה וירטואלית למכונה וירטואלית אחרת, עד 200 Gbps.
    • מכונות H4D תומכות ברוחב פס של תעבורת נתונים יוצאת ממכונה וירטואלית למכונה וירטואלית של עד ‎200 Gbps בשילוב של Cloud RDMA ו-gVNIC.
    • למכונות X4,‏ M4,‏ A2 ו-G2 יש תמיכה במגבלות רוחב פס של תעבורה יוצאת (egress) של עד ‎100 Gbps.
    • מכונות G4 תומכות במגבלות רוחב פס של תעבורת נתונים יוצאת (egress) של עד ‎400 Gbps.
    • במכונות וירטואליות מסוג A4X Max יש תמיכה במגבלות רוחב פס של תעבורת נתונים יוצאת עד 3,600 Gbps.
    • מכונות A4X תומכות במגבלות רוחב פס של תעבורה יוצאת עד ‎2,000 Gbps.
    • במכונות וירטואליות מסוג A4 ו-A3 יש תמיכה בהגבלות על רוחב פס של תעבורת נתונים יוצאת של עד 3,600 Gbps.
    • מכונות C4,‏ C4D,‏ C3,‏ C3D ו-Z3 תומכות במגבלות רוחב פס של עד 200 Gbps עם רשת Tier_1.
    • מכונות M4N תומכות ברוחב פס של עד ‎200 Gbps של תעבורת נתונים יוצאת ממכונה וירטואלית למכונה וירטואלית.
  • למידע על גורמים, הגדרות ותרחישים אחרים, אפשר לעיין במאמר בנושא תעבורת יציאה ליעדים שניתן לנתב בתוך רשת VPC.
ניתוב מחוץ לרשת
VPC
  • במכונות H3 ובמכונות H4D, העברת נתונים יוצאת ליעד מחוץ לרשת ה-VPC מוגבלת ל-1 Gbps.
  • במכונות שעברו אופטימיזציה לרשת, כמו M4N, המגבלה מבוססת על סוג המכונה של המופע השולח. רוחב הפס המקסימלי האפשרי של תעבורת נתונים יוצאת ליעד מחוץ לרשת ה-VPC לא יכול להיות יותר מ-100 Gbps.
  • בכל סדרות המכונות האחרות, המגבלה מוגדרת בעיקר על ידי רוחב פס מקסימלי לתעבורת נתונים יוצאת (egress) לכל מכונה, על סמך סוג המכונה של המכונה השולחת והאם מופעל רישות Tier_1. רוחב הפס המקסימלי האפשרי של מכונת מקור לשליחת תעבורת נתונים יוצאת (egress) ליעד מחוץ לרשת ה-VPC שלה לא יכול להיות גדול מהערכים הבאים:

    • ‫‎3 Gbps לכל זרימה
    • כשמופעלת רשת Tier_1: ‏ 25 Gbps בסך הכול
    • אם לא מפעילים את רשת Tier_1 או אם אין תמיכה בה, אפשר להשתמש ברוחב הפס הכולל הבא לכל סדרת מכונות:
      • למכונות G4: ‏ 7 Gbps סך הכול לסוגי מכונות עם פחות מ-48 vCPU, ו-28 Gbps סך הכול לסוגי מכונות עם 48 vCPU או יותר
      • בסדרות המכונות H4D ו-H3, ‏ 1 Gbps בסך הכול
      • לסדרות מכונות שתומכות בכמה כרטיסי NIC פיזיים, כמו מופעי A3,‏ A4,‏ A4X ו-A4X Max,‏ 7 Gbps לכל כרטיס NIC
      • לכל שאר סדרות המכונות, 7 Gbps בסך הכול
  • גורמים, הגדרות ואזהרות נוספים מפורטים במאמר בנושא תעבורת יציאה ליעדים מחוץ לרשת VPC.

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

ניתוב בתוך רשת VPC
  • בדרך כלל, שיעורי התעבורה הנכנסת דומים לשיעורי התעבורה היוצאת של סוג מכונה.
  • כדי לקבל את רוחב הפס הגבוה ביותר האפשרי של תעבורת נכנס, מפעילים את Tier_1 networking.
  • גודל מופע החישוב, הקיבולת של כרטיס הרשת של השרת, התנועה שנכנסת למכונות וירטואליות אחרות של אורחים שפועלות באותו חומרה של מארח, הגדרת הרשת של מערכת ההפעלה של האורח ומספר קריאות הדיסק שמבוצעות על ידי המופע – כל אלה יכולים להשפיע על קצב הכניסה.
  • Google Cloud לא מטילה מגבלות נוספות על שיעורי תעבורת נכנסת ברשת VPC.
  • גורמים, הגדרות ותרחישים נוספים מפורטים במאמר בנושא תעבורת Ingress ליעדים שניתן לנתב בתוך רשת VPC.
ניתוב מחוץ לרשת
VPC
  • Google Cloud מגן על כל מופע של Compute על ידי הגבלת תעבורת נתונים נכנסת שמנותבת מחוץ לרשת VPC. המגבלה היא השיעור הראשון מבין השיעורים הבאים שנתקלים בו:

    • ‫1,800,000 pps (חבילות לשנייה)
    • ‫30 Gbps
  • בסדרת מכונות שתומכת בכמה כרטיסי רשת פיזיים, כמו מופעי A3,‏ A4,‏ A4X ו-A4X Max או M4N, המגבלה היא השיעור הראשון שנתקלים בו מבין השיעורים הבאים:

    • ‫1,800,000 חבילות לשנייה לכל כרטיס רשת פיזי
    • ‫30 Gbps לכל כרטיס רשת פיזי
  • למידע על גורמים, הגדרות ותרחישים אחרים, אפשר לעיין במאמר בנושא תעבורת כניסה ליעדים מחוץ לרשת VPC.

רוחב פס יוצא

Google Cloud מגבילה את רוחב הפס היוצא (egress) באמצעות שיעורי יציאה מקסימליים לכל מופע. התעריפים האלה מבוססים על סוג המכונה של מופע Compute ששולח את החבילה, ועל האפשרות לגשת ליעד של החבילה באמצעות נתיבים בתוך רשת VPC או נתיבים מחוץ לרשת VPC. רוחב פס יוצא כולל מנות שמועברות מכל כרטיסי ה-NIC של המופע ונתונים שמועברים לכל נפחי ה-Hyperdisk והדיסק הקשיח שמחוברים למופע.

רוחב פס מקסימלי לתעבורת נתונים יוצאת לכל מכונה

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

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

מגבלת יציאה מקסימלית לכל מופע
סדרת מכונות רגילה Tier_1 networking
C4 ו-C4D ‫100 Gbps ‫200 Gbps
C4A ‫50 Gbps ‫100 Gbps
C3 ו-C3D ‫100 Gbps ‫200 Gbps
C2 ו-C2D ‫32 Gbps ‫100 Gbps
E2 ‫16 Gbps לא רלוונטי
ליבת מעבד משותפת E2 ‫2 Gbps לא רלוונטי
H4D ו-H3 ‫200 Gbps לא רלוונטי
M4N ‫200 Gbps לא זמין
M4 ‫100 Gbps לא רלוונטי
M3 ‫32 Gbps ‫100 Gbps
M2 ‫32 Gbps במעבד Intel Cascade Lake או במעבד מתקדם יותר
‫16 Gbps בפלטפורמות אחרות של מעבדים
לא רלוונטי
M1 ‫32 Gbps לא רלוונטי
N4, N4A, ו-N4D ‫50 Gbps לא רלוונטי
N2 ו-N2D ‫32 Gbps ‫100 Gbps
N1 (לא כולל מכונות וירטואליות עם ‎1 vCPU) ‫‎32 Gbps במעבד Intel Skylake ואילך
‫‎16 Gbps בפלטפורמות מעבד קודמות
לא רלוונטי
סוגי מכונות N1 עם vCPU אחד ‫2 Gbps לא רלוונטי
ליבת מעבד משותפת N1 ‏ (f1-micro ו-g1-small) ‫1 Gbps לא רלוונטי
T2A ו-T2D ‫32 Gbps לא רלוונטי
X4 ‫100 Gbps לא רלוונטי
Z3 ‫100 Gbps ‫200 Gbps

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

רוחב הפס המקסימלי לתעבורת נתונים יוצאת לכל מופע אינו מובטח. רוחב הפס בפועל של תעבורת הנתונים היוצאת (egress) יכול להיות נמוך יותר בהתאם לגורמים כמו אלה שמופיעים ברשימה החלקית הבאה:

  • שימוש ב-VirtIO במקום ב-gVNIC עם מכונות Compute שתומכות בשני מנהלי ההתקנים של ממשק הרשת
  • גודל המנות
  • תקורה של פרוטוקול
  • מספר התהליכים
  • הגדרות של מנהל התקן Ethernet של מערכת ההפעלה האורחת של מכונת החישוב, כמו checksum offload ו-TCP segmentation offload ‏ (TSO)
  • עומס ברשת
  • במצב שבו פעולות קלט/פלט של דיסק קבוע מתחרות עם תעבורת נתונים אחרת של יציאה מהרשת, 60% מרוחב הפס המקסימלי של הרשת מוקצים לכתיבות של דיסק קבוע, ו-40% מוקצים לתעבורת נתונים אחרת של יציאה מהרשת. פרטים נוספים זמינים במאמר בנושא גורמים שמשפיעים על ביצועי הדיסק.

כדי לקבל את רוחב הפס המקסימלי האפשרי לתעבורת נתונים יוצאת (egress) לכל מכונה:

  • כשיוצרים את מופע החישוב, משתמשים בסוג מכונה מסדרת המכונות שממוטבת לרשת.
  • משתמשים בסדרת מכונות מהדור השלישי ואילך שמשתמשות ב-Titanium כדי להעביר את עיבוד הרשת מה-CPU של המארח.
  • אם משתמשים בסדרת מכונות מהדור השני או השלישי, מומלץ להפעיל ביצועי רשת ברמה 1 לכל מכונה וירטואלית עם סוגי מכונות גדולים יותר.
  • משתמשים ביחידת השידור המקסימלית (MTU) הגדולה ביותר של רשת ה-VPC שנתמכת על ידי טופולוגיית הרשת. יחידות MTU גדולות יותר יכולות לצמצם את התקורה של כותרות המנות ולהגדיל את קצב העברת הנתונים של המטען הייעודי (payload).
  • משתמשים בגרסה העדכנית של מנהל ההתקן gVNIC, אם היא נתמכת על ידי המכונה ומערכת ההפעלה של האורח.

תעבורה יוצאת (egress) ליעדים שניתן לנתב בתוך רשת VPC

מנקודת המבט של מכונה ששולחת נתונים, ולכתובות IP של יעדים שאפשר לגשת אליהם באמצעות מסלולים ברשת VPC,‏Google Cloud מגבילה את התנועה היוצאת באמצעות הכללים הבאים:

  • רוחב פס מקסימלי ליציאה לכל מכונה וירטואלית: רוחב הפס המקסימלי ליציאה לכל מופע, כפי שמתואר בקטע רוחב פס מקסימלי ליציאה לכל מופע.
  • רוחב פס של תעבורת נתונים יוצאת בין אזורים לכל פרויקט: אם מופע השליחה ויעד פנימי או הנתב הבא שלו נמצאים באזורים שונים,Google Cloud אוכף מכסה על סמך האזור והפרויקט של מופע השליחה והאזור של היעד הפנימי או הנתב הבא. מידע נוסף על המכסה הזו זמין במאמר מכסות ומגבלות של VPC בקטע 'רוחב פס של תעבורת יציאה (Egress) מהרשת בין אזורים (Mbps) ממכונות Compute'.
  • מגבלות של Cloud VPN ו-Cloud Interconnect: כששולחים תעבורת נתונים ממופע לכתובת IP פנימית של יעד שאפשר לנתב אליו באמצעות מנהרת Cloud VPN של הצעד הבא או באמצעות צירוף ל-VLAN של Cloud Interconnect, רוחב הפס של תעבורת הנתונים היוצאת מוגבל על ידי:

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

  • כתובות IPv4 פנימיות אזוריות בטווחים של כתובות IPv4 ראשיות של רשת משנה וכתובות IPv4 משניות של רשת משנה, כולל טווחים של כתובות IPv4 פרטיות וטווחים של כתובות IPv4 ציבוריות שמשמשות לשימוש פרטי, שמשמשות את משאבי היעד הבאים:
    • כתובת ה-IPv4 הפנימית הראשית של ממשק הרשת (vNIC) של מכונת היעד. (כשמכונה ששולחת מתחברת לכתובת IPv4 חיצונית של כרטיס רשת וירטואלי של מכונה אחרת, החבילות מנותבות באמצעות שער אינטרנט שמוגדר כברירת מחדל לניתוב ליעד הבא, ולכן חלים במקום זאת כללי יציאה ליעדים מחוץ לרשת VPC).
    • כתובת IPv4 פנימית בטווח כתובות IP חלופיות של כרטיס רשת וירטואלי (vNIC) של מכונה מקבלת.
    • כתובת IPv4 פנימית של כלל העברה פנימי להעברת פרוטוקול או למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.
  • כתובות IPv4 פנימיות גלובליות למשאבי היעד האלה:
  • טווחים של כתובות IPv6 פנימיות של רשתות משנה שמשמשים את משאבי היעד האלה:
    • כתובת IPv6 מתוך /96 טווח כתובות IPv6 שהוקצה ל-vNIC של מכונת קבלה עם תמיכה כפולה או IPv6 בלבד.
    • כתובת IPv6 מטווח כתובות IPv6 של כלל העברה פנימי עבור העברת פרוטוקולים או עבור מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי./96
  • טווח כתובות של רשתות משנה חיצוניות של IPv6 שמשמשות את משאבי היעד האלה כשחבילות מנותבות באמצעות מסלולי רשת משנה או מסלולי רשת משנה של קישור (peering) בתוך רשת ה-VPC, או באמצעות מסלולים מותאמים אישית בתוך רשת ה-VPC שלא משתמשים בצעד הבא של שער האינטרנט שמוגדר כברירת מחדל:
    • כתובת IPv6 מתוך /96 טווח כתובות IPv6 שהוקצה ל-vNIC של מכונת קבלה עם תמיכה כפולה או IPv6 בלבד.
    • כתובת IPv6 מטווח כתובות IPv6 של כלל העברה חיצוני, להעברת פרוטוקול או למאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי./96
  • יעדים אחרים שאפשר לגשת אליהם באמצעות המסלולים הבאים ברשת ה-VPC:

הרשימה הבאה מדרגת את התנועה ממופעים ששולחים ליעדים פנימיים, מרוחב הפס הגבוה ביותר האפשרי לנמוך ביותר:

תעבורה יוצאת (egress) ליעדים מחוץ לרשת VPC

מנקודת המבט של מכונה ששולחת נתונים, ולכתובות IP של יעד מחוץ לרשת VPC, Google Cloud התעבורה היוצאת מוגבלת לשיעור הנמוך מבין השיעורים הבאים:

  • רוחב פס ליציאה לכל מופע: רוחב הפס המקסימלי לכל החיבורים ממופע של מחשוב ליעדים מחוץ לרשת VPC הוא הקטן מבין רוחב הפס המקסימלי ליציאה לכל מופע ואחד מהשיעורים הבאים:

    • אם רשת Tier_1 מופעלת: 25 Gbps
    • אם רשת Tier_1 לא מופעלת או לא נתמכת:
      • למופעים שעברו אופטימיזציה לרשת: 100 Gbps
      • למופעי G4: ‏ 7 Gbps בסך הכול לסוגי מכונות עם פחות מ-48 vCPU, ו-28 Gbps בסך הכול לסוגי מכונות עם 48 vCPU או יותר
      • ‫1 Gbps למכונות H4D ו-H3
      • ‫7 Gbps לכל כרטיס NIC פיזי בסדרות מכונות שתומכות בכמה כרטיסי NIC פיזיים, כמו מכונות A3,‏ A4,‏ A4X ו-A4X Max
      • ‫‎7 Gbps לכל שאר סדרות המכונות

    לדוגמה, למרות שלמכונת c3-standard-44 VM יש רוחב פס ליציאה (egress) של 32 Gbps לכל היותר לכל מופע, רוחב הפס ליציאה ממכונת c3-standard-44 VM ליעדים חיצוניים הוא 25 Gbps או 7 Gbps, בהתאם להגדרה של רשת Tier_1.

  • קצב היציאה המקסימלי לכל זרימה: רוחב הפס המקסימלי לכל חיבור ייחודי של 5 טאפלים, ממופע חישוב ליעד מחוץ לרשת VPC הוא 3 Gbps, למעט מופעי H4D ו-H3, שבהם הוא 1 Gbps.

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

יעדים מחוץ לרשת VPC כוללים את כל היעדים הבאים, שלכל אחד מהם אפשר לגשת באמצעות מסלול ברשת ה-VPC של המכונה השולחת, שהניתוב הבא שלו הוא שער האינטרנט שמוגדר כברירת מחדל:

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

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

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

‫Google Cloud מטפל ברוחב פס נכנס (ingress) בהתאם לאופן שבו המנות הנכנסות מנותבות למכונת Compute מקבלת.

תעבורה נכנסת ליעדים שניתן לנתב בתוך רשת VPC

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

  • נתיבי תת-רשת ברשת ה-VPC של המופע המקבל
  • נתיבי תת-רשת בקישור בין רשתות VPC שכנות (peering)
  • נתיבים ברשת אחרת שהניתוב הבא שלהם הוא מנהרות Cloud VPN, קבצים מצורפים של Cloud Interconnect ‏ (VLAN) או מופעים של נתב וירטואלי שנמצאים ברשת ה-VPC של המופע המקבל

היעדים של חבילות שמנותבות בתוך רשת VPC כוללים:

  • כתובת ה-IPv4 הפנימית הראשית של ממשק הרשת הווירטואלי (vNIC) של המכונה המקבלת. כתובות IPv4 פנימיות ראשיות הן כתובות IPv4 פנימיות אזוריות שמגיעות מטווח כתובות ה-IPv4 הראשי של רשת משנה.
  • כתובת IPv4 פנימית מטווח כתובות IP של כינוי של vNIC של המכונה המקבלת. טווחים של כתובות IP חלופיות יכולים להיות טווח כתובות IPv4 ראשי של תת-רשת או אחד מטווח כתובות IPv4 משני שלה.
  • כתובת IPv6 מתוך /96 טווח כתובות IPv6 שהוקצה ל-vNIC של מכונת קבלה עם תמיכה כפולה או IPv6 בלבד. טווחי IPv6 של מכונות Compute יכולים להגיע מטווחי IPv6 של רשתות המשנה הבאות:
  • כתובת IPv4 פנימית של כלל העברה שמשמש להעברת פרוטוקול פנימי למכונה המקבלת או למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, שבו המכונה המקבלת היא קצה עורפי של מאזן העומסים. כתובות IPv4 של כלל העברה פנימי מגיעות מטווח כתובות ה-IPv4 הראשי של רשת משנה.
  • כתובת IPv6 פנימית מטווח ה-IPv6 של /96 כלל העברה שמשמש להעברת פרוטוקול פנימית למכונה המקבלת או למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, כאשר המכונה המקבלת היא קצה עורפי של מאזן העומסים. כתובות IPv6 של כלל העברה פנימי מגיעות מטווח כתובות ה-IPv6 הפנימי של תת-רשת.
  • כתובת IPv6 חיצונית מטווח ה-IPv6 של /96 כלל העברה שמשמש להעברת פרוטוקול חיצוני למכונה המקבלת או למאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי. המכונה המקבלת היא קצה עורפי של מאזן העומסים כשהמנות הנכנסות מנותבות בתוך רשת ה-VPC באמצעות אחד מהנתיבים שצוינו קודם בקטע הזה. כתובות IPv6 של כללי העברה חיצוניים מגיעות מטווח כתובות ה-IPv6 החיצוניות של רשת משנה.
  • כתובת IP בטווח היעד של מסלול סטטי מותאם אישית שמשתמש במכונה המקבלת כמכונה של הצעד הבא (next-hop-instance או next-hop-address).
  • כתובת IP בטווח היעד של מסלול סטטי בהתאמה אישית באמצעות הצעד הבא של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי (next-hop-ilb), אם המכונה המקבלת היא קצה עורפי של מאזן העומסים הזה.

תעבורת Ingress ליעדים מחוץ לרשת VPC

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

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

  • ‫1,800,000 חבילות לשנייה
  • ‫30 Gbps

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

  • ‫1,800,000 חבילות נתונים לשנייה לכל כרטיס רשת פיזי
  • ‫30 Gbps לכל כרטיס רשת פיזי
תלוי בתנאי הרשת.

יעדים של מנות שמנותבות באמצעות מסלולים מחוץ לרשת VPC כוללים:

  • כתובת IPv4 חיצונית שהוקצתה בהגדרת גישה של NAT אחד-לאחד באחד מממשקי הרשת (NIC) של המכונה המקבלת.
  • כתובת IPv6 חיצונית מ/96 טווח כתובות ה-IPv6 שהוקצה ל-vNIC של מכונת יעד עם תמיכה כפולה או עם IPv6 בלבד כשהמנות הנכנסות מנותבות באמצעות נתיב מחוץ לרשת ה-VPC של מכונת היעד.
  • כתובת IPv4 חיצונית של כלל העברה שמשמש להעברת פרוטוקול חיצונית למכונה המקבלת או למאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי, כאשר המכונה המקבלת היא קצה עורפי של מאזן העומסים.
  • כתובת IPv6 חיצונית מטווח ה-IPv6 של /96 כלל העברה שמשמש להעברת פרוטוקול חיצוני למכונה המקבלת או למאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי. המכונה המקבלת צריכה להיות קצה עורפי של מאזן העומסים כשהמנות הנכנסות מנותבות באמצעות נתיב מחוץ לרשת VPC.
  • תשובות נכנסות שמעובדות על ידי Cloud NAT.

שימוש במסגרות ג'מבו כדי למקסם את רוחב הפס של הרשת

כדי לקבל ולשלוח מסגרות ג'מבו, צריך להגדיר את רשת ה-VPC שבה נעשה שימוש במופעי המחשוב. צריך להגדיר את יחידת השידור המקסימלית (MTU) לערך גדול יותר, עד 8896.

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

אפשר להשתמש ב-jumbo frames עם מנהל ההתקן gVNIC בגרסה 1.3 ואילך במכונות וירטואליות, או עם מנהל ההתקן IDPF במכונות Bare Metal. לא כל התמונות הציבוריות Google Cloud כוללות את הדרייברים האלה. מידע נוסף על תמיכה במערכות הפעלה ב-jumbo frames זמין בכרטיסייה תכונות רשת בדף פרטים על מערכת ההפעלה.

אם אתם משתמשים באימג' של מערכת הפעלה שלא תומך באופן מלא בפריימים גדולים, אתם יכולים להתקין באופן ידני את מנהל ההתקן gVNIC בגרסה v1.3.0 ואילך. ‫Google ממליצה להתקין את גרסת מנהל ההתקן gVNIC שמסומנת ב-Latest כדי ליהנות מתכונות נוספות ומתיקוני באגים. אפשר להוריד את מנהלי ההתקנים של gVNIC מ-GitHub.

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

פריימים גדולים ומכונות GPU

לגבי סוגי מכונות GPU, צריך להשתמש בהגדרות MTU המומלצות למסגרות ג'מבו. מידע נוסף זמין במאמר הגדרות מומלצות של MTU למסגרות ג'מבו.

תורים לקבלה ולשידור

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

  • תור לקבלה (RX): תור לקבלת חבילות. כשכרטיס ה-NIC מקבל חבילת נתונים מהרשת, הוא בוחר את המתאר של חבילת נתונים נכנסת מהתור, מעבד אותה ומעביר את חבילת הנתונים למערכת ההפעלה של האורח דרך תור חבילות שמצורף לליבת vCPU באמצעות הפרעה. אם התור של RX מלא ואין מאגר זמני זמין להצבת מנה, המנה מושמטת. זה יכול לקרות בדרך כלל אם אפליקציה משתמשת יתר על המידה בליבת vCPU שמצורפת גם לתור החבילות שנבחר.
  • תור שידור (TX): תור לשידור מנות. כשמערכת ההפעלה של האורח שולחת חבילה, מוקצה מתאר והוא ממוקם בתור ה-TX. לאחר מכן, כרטיס ה-NIC מעבד את המתאר ומשדר את המנה.

הקצאה של תור ברירת מחדל

אלא אם מקצים במפורש מספרים לתורים של כרטיסי NIC, אפשר ליצור מודל של האלגוריתם Google Cloud שמשמש להקצאת מספר קבוע של תורי RX ו-TX לכל vNIC באופן הבא:

מופעים שעברו אופטימיזציה לרשת
ב-M4N, כל vNIC יכול להכיל עד 64 תורים. המספר הכולל של התורים לכל מכונה הוא מספר המעבדים הווירטואליים.
מקרים של Bare Metal
במקרים של מכונות Bare Metal, יש רק כרטיס רשת וירטואלי אחד, ולכן מספר התורים המקסימלי הוא 16.
מכונות וירטואליות שמשתמשות בממשק הרשת gVNIC

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

  • במקרים של מכונות Linux עם 2 מעבדים וירטואליים, מספר התורים הוא 1.
  • במקרים של מכונות Linux עם 4 מעבדי vCPU, מספר התורים הוא 2.

בסדרות אחרות של מכונות, מספר התורים תלוי בשאלה אם סדרת המכונות משתמשת ב-Titanium או לא.

  • במקרים של מופעים מהדור השלישי (לא כולל M3) ואילך שמשתמשים ב-Titanium:

    מחלקים את מספר המעבדים הווירטואליים במספר כרטיסי ה-vNIC ‏ (num_vcpus/num_vnics) ומתעלמים מהשארית.

  • למכונות וירטואליות מדור M3 ולמכונות וירטואליות מהדור הראשון והשני שלא משתמשות ב-Titanium:

    מחלקים את מספר המעבדים הווירטואליים במספר כרטיסי הרשת הווירטואליים, ואז מחלקים את התוצאה ב-2 (num_vcpus/num_vnics/2). מתעלמים מהשארית.

כדי לסיים את החישוב של מספר התורים שמוגדר כברירת מחדל:

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

  2. בודקים אם המספר המחושב גדול ממספר התורים המקסימלי לכל vNIC, שהוא 16. אם המספר המחושב גדול מ-16, מתעלמים מהמספר המחושב ומקצים לכל vNIC‏ 16 תורים.

מכונות וירטואליות שמשתמשות בממשק הרשת VirtIO או במנהל התקן מותאם אישית

מחלקים את מספר המעבדים הווירטואליים במספר כרטיסי הרשת הווירטואליים, ומתעלמים מכל שארית –[number of vCPUs/number of vNICs].

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

  2. בודקים אם המספר המחושב גדול ממספר התורים המקסימלי לכל vNIC, שהוא 32. אם המספר המחושב גדול מ-32, מתעלמים מהמספר המחושב ומקצים לכל vNIC‏ 32 תורים במקום זאת.

מכונות H4D עם Cloud RDMA

במופעי H4D שמשתמשים ב-Cloud RDMA, כל מארח פיזי מריץ מופע חישוב יחיד. לכן, המופע מקבל את כל זוגות התורים הזמינים. למכונות H4D יש 16 תורים לממשק הרשת gVNIC ו-16 תורים לממשק הרשת IRDMA.

דוגמאות

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

  • אם מכונה וירטואלית משתמשת ב-VirtIO ויש לה 16 מעבדים וירטואליים ו-4 כרטיסי רשת וירטואליים, המספר המחושב הוא [16/4] = 4. Google Cloud מקצה לכל כרטיס רשת וירטואלי 4 תורים.

  • אם מופעלת במכונה וירטואלית gVNIC עם העברות של Titanium, ויש לה 128 vCPU ו-2 vNIC, המספר המחושב הוא [128/2] = 64. Google Cloud מקצה לכל vNIC את המספר המקסימלי של תורים לכל vNIC, שהוא 16.

במערכות Linux, אפשר להשתמש ב-ethtool כדי להגדיר vNIC עם פחות תורים ממספר התורים ש- Google Cloud מקצה לכל vNIC.

מספרים בתור כשמשתמשים בממשק רשת דינמי

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

הקצאת תור בהתאמה אישית למכונות וירטואליות

במקום הקצאת התורים שמוגדרת כברירת מחדל, אתם יכולים להקצות מספר תורים מותאם אישית (הסכום הכולל של RX ו-TX) לכל vNIC כשאתם יוצרים מכונת חישוב חדשה באמצעות Compute Engine API.

מספר התורים בהתאמה אישית שאתם מציינים צריך לעמוד בכללים הבאים:

  • המספר המינימלי של תורים שאפשר להקצות לכל vNIC הוא אחד.

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

    • אם משתמשים ב-virtIO או במנהל התקן בהתאמה אישית, מספר התורים המקסימלי הוא 32.
    • כשמשתמשים ב-gVNIC, מספר התורים המקסימלי הוא 16, למעט במקרים הבאים:
      • במכונות M4N, מספר התורים המקסימלי הוא 64 לכל כרטיס רשת.
      • במכונות מסוג A2 או G2, מספר התורים המקסימלי הוא 32 לכל כרטיס רשת.
      • למכונות TPU יש מספר מקסימלי של 32 תורים.
      • במופעי C2, ‏ C2D, ‏ N2 או N2D עם רשת Tier_1 מופעלת, מספר התורים המקסימלי הוא 32 לכל NIC.
    • ההגדרות הבאות של Confidential VM כוללות מספר מקסימלי של פריטים בתור של 8:

      • ‫AMD SEV בסוגי מכונות C2D ו-N2D
      • ‫AMD SEV-SNP בסוגי מכונות N2D
  • סכום מספרי התור בכל כרטיסי ה-NIC שהוגדרו עבור מופע המכונה הווירטואלית צריך לעמוד באחד מהכללים הבאים:

    • הערך המקסימלי הוא הנמוך מבין:
      • [number of vCPUS]
      • [number of NICs] * [max number of queues per NIC]
    • אם משתמשים בהקצאת יתר של תורים, הערך המקסימלי הוא:
      • [number of vNICs] * 16

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

  • משתמש ב-gVNIC כסוג ה-vNIC לכל ה-vNIC שהוגדרו למופע.
  • משתמשים בסוג מכונה בסדרת המכונות N2,‏ N2D,‏ C2 או C2D.
  • מופעל בו Tier_1 networking.
  • מציין מספר תורים מותאם אישית לכל כרטיסי ה-vNIC שהוגדרו למכונה הווירטואלית.

במקרה של הקצאת יתר של תור, מספר התורים המקסימלי במכונת ה-VM הוא פי 16 ממספר כרטיסי ה-vNIC. לכן, אם יש לכם 6 כרטיסי רשת וירטואליים שהוגדרו למופע עם 30 מעבדים וירטואליים, תוכלו להגדיר לכל היותר (16 * 6), או 96 תורים מותאמים אישית למכונה הווירטואלית.

דוגמאות

  • למכונה וירטואלית מסוג N2 עם 8 מעבדים וירטואליים ו-4 כרטיסי רשת וירטואליים:

    • אפשר להקצות עד 8 תורים ל-4 כרטיסי vNIC. לדוגמה, אפשר להקצות תור אחד ל-nic0,‏ 4 תורים ל-nic1 ו-3 תורים ל-nic2.
    • אי אפשר להגדיר הקצאת יתר בתור כי רשת Tier_1 עם N2 דורשת מכונה וירטואלית עם לפחות 32 מעבדים וירטואליים.
  • אם למכונה וירטואלית יש 48 מעבדים וירטואליים ו-4 כרטיסי רשת:

    • אם משתמשים במנהל ההתקן virtIO עבור כרטיסי ה-NIC, אפשר להקצות עד 48 תורים ל-4 כרטיסי ה-NIC, עם מספר תורים מקסימלי של 32 לכל vNIC. לדוגמה, יכול להיות שיהיו 12 תורים בכל vNIC, או שיהיו 32 תורים באחד מ-NIC,‏ 14 תורים ב-vNIC אחר ותור אחד בשני NIC הנותרים.
    • אם משתמשים במנהל ההתקן gVNIC עבור כרטיסי ה-NIC, אפשר להקצות עד 48 תורים ל-4 כרטיסי ה-NIC, עם מספר תורים מקסימלי של 16 לכל vNIC. לדוגמה, יכול להיות שיהיו לכם 15 תורים ב-3 כרטיסי NIC ו-3 תורים בכרטיס vNIC הנותר, או 12 תורים בכל כרטיס vNIC.
    • אם משתמשים ב-gVNIC וב-queue oversubscription, אפשר להקצות עד 16 תורים לכל vNIC, כלומר סך של 64 תורים.
  • למכונה וירטואלית מסוג N2D עם 224 ליבות וירטואליות ו-8 כרטיסי רשת:

    • אם משתמשים במנהל ההתקן virtIO עבור כרטיסי ה-NIC, אפשר להקצות עד 224 תורים ל-8 כרטיסי ה-NIC, עם מספר תורים מקסימלי של 32 לכל vNIC. לדוגמה, יכול להיות שיהיו 32 תורים ב-6 כרטיסי רשת, ו-16 תורים ב-2 כרטיסי הרשת הנותרים.
    • אם משתמשים במנהל ההתקן gVNIC עבור כרטיסי ה-NIC, אפשר להשתמש במספר התורים המקסימלי של 16 עבור כל 8 כרטיסי ה-NIC. הסכום המקסימלי של מספר הפריטים בתור הוא 128.

אפשר גם להקצות מספר תורים מותאם אישית לחלק מכרטיסי ה-vNIC בלבד, וכך לאפשר ל-Compute Engine להקצות תורים לכרטיסי ה-vNIC הנותרים. מספר התורים שאפשר להקצות לכל כרטיס רשת וירטואלי עדיין כפוף לכללים שצוינו קודם. כדי לבדוק את ההיתכנות של ההגדרה ואת מספר התורים ש-Compute Engine מקצה ל-vNICs שנותרו, אפשר לבצע את התהליך הבא:

  1. חישוב סכום התורים עבור כרטיסי ה-vNIC שהוקצו להם תורים בהתאמה אישית.

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

  3. מחלקים את ההפרש מהשלב הקודם במספר כרטיסי ה-vNIC ללא מספר תורים מותאם אישית, ומתעלמים מהשארית:

    [(number of vCPUs - sum of assigned queues)/(number of remaining vNICs)]
    

    החישוב הזה תמיד יניב מספר שלם (לא שבר) ששווה ל-1 או גדול ממנו, כי לכל vNIC צריכה להיות לפחות תור אחד.

  4. ‫Compute Engine מקצה לכל כרטיס רשת וירטואלי שנותר מספר תורים באופן הבא:

    • אם המספר המחושב נמוך מהמספר המקסימלי של תורים לכל vNIC, מספר התורים מוגדר כמספר המחושב.
    • אם המספר המחושב גדול ממספר התורים המקסימלי לכל vNIC, מספר התורים של ה-vNIC מוגדר כמספר התורים המקסימלי.

דוגמה

נניח שיש לכם מכונה וירטואלית עם 20 ליבות וירטואליות ו-6 כרטיסי רשת, והקציתם 5 תורים ל-nic0,‏ 6 תורים ל-nic1,‏ 4 תורים ל-nic2, ונתתם ל-Compute Engine להקצות את מספר התורים ל-nic3,‏ nic4 ו-nic5.

  1. סכום התורים שהוקצו בהתאמה אישית הוא 5 + 6 + 4 = 15.

  2. ל-Compute Engine נשארו 20 - 15 = 5 תורים להקצאה לשלושת ה-vNICs הנותרים (nic3, ‏ nic4, ‏ nic5). ההפרש (5) גדול ממספר ה-vNICs שלא הוגדר להם מספר תורים מותאם אישית (3).

  3. ההפרש 5 מחולק ב-3, והשארית מושלכת. התוצאה היא ערך של 1.

  4. מכיוון שהמספר המחושב (1) קטן מהמספר המקסימלי של תורים לכל vNIC, מספר התורים עבור שאר ה-vNIC מוגדר כ-1.

הגדרת מספרים מותאמים אישית בתור

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

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

gcloud

  1. אם עדיין אין לכם רשת VPC עם תת-רשת לכל ממשק vNIC שאתם מתכננים להגדיר, אתם צריכים ליצור אותם.
  2. משתמשים בפקודה gcloud compute instances create כדי ליצור את מכונת ה-Compute. חוזרים על הדגל --network-interface לכל vNIC שרוצים להגדיר עבור המכונה, וכוללים את האפשרות queue-count.
    gcloud compute instances create INSTANCE_NAME \
        --zone=ZONE \
        --machine-type=MACHINE_TYPE \
        --network-performance-configs=total-egress-bandwidth-tier=TIER_1  \
        --network-interface=network=NETWORK_NAME_1,subnet=SUBNET_1,nic-type=GVNIC,queue-count=QUEUE_SIZE_1 \
        --network-interface=network=NETWORK_NAME_2,subnet=SUBNET_2,nic-type=GVNIC,queue-count=QUEUE_SIZE_2

מחליפים את מה שכתוב בשדות הבאים:

  • INSTANCE_NAME: שם למכונת מחשוב חדשה
  • ZONE: האזור שבו רוצים ליצור את המכונה
  • MACHINE_TYPE: סוג המכונה של המופע. כדי להגדיל את מספר המנויים מעבר לקיבולת של התור, צריך להשתמש בסוג מכונה מסדרות המכונות N2, ‏ N2D, ‏ C2 או C2D שמשתמשות ב-gVNIC וברשת Tier_1.
  • NETWORK_NAME: השם של הרשת שנוצרה קודם
  • SUBNET_*: השם של אחת מתת-הרשתות שנוצרו קודם
  • QUEUE_SIZE: מספר התורים של ה-vNIC, בכפוף לכללים שמוסברים במאמר הקצאת תורים בהתאמה אישית.

Terraform

  1. אם עדיין אין לכם רשת VPC עם תת-רשת לכל ממשק vNIC שאתם מתכננים להגדיר, אתם צריכים ליצור אותם.
  2. כדי ליצור מכונת חישוב עם מספרים ספציפיים של תורים ל-vNIC, משתמשים במשאב google_compute_instance. חוזרים על הפרמטר --network-interface לכל vNIC שרוצים להגדיר עבור מכונת החישוב, וכוללים את הפרמטר queue-count.

    # Queue oversubscription instance
    resource "google_compute_instance" "INSTANCE_NAME" {
    project      = "PROJECT_ID"
    boot_disk {
      auto_delete = true
      device_name = "DEVICE_NAME"
      initialize_params {
         image="IMAGE_NAME"
         size = DISK_SIZE
         type = "DISK_TYPE"
      }
    }
    machine_type = "MACHINE_TYPE"
    name         = "INSTANCE_NAME"
    zone         = "ZONE"
    
    network_performance_config {
        total_egress_bandwidth_tier = "TIER_1"
    }
    
    network_interface {
        nic_type = "GVNIC"
        queue_count = QUEUE_COUNT_1
        subnetwork_project = "PROJECT_ID"
        subnetwork = "SUBNET_1"
     }
    
    network_interface {
        nic_type = "GVNIC"
        queue_count = QUEUE_COUNT_2
        subnetwork_project = "PROJECT_ID"
        subnetwork = "SUBNET_2"
    }
    
    network_interface {
        nic_type = "GVNIC"
        queue_count = QUEUE_COUNT_3
        subnetwork_project = "PROJECT_ID"
        subnetwork = "SUBNET_3""
    }
    
    network_interface {
        nic_type = "GVNIC"
        queue_count = QUEUE_COUNT_4
        subnetwork_project = "PROJECT_ID"
        subnetwork = "SUBNET_4""
    }
    
    }
    
    

מחליפים את מה שכתוב בשדות הבאים:

  • INSTANCE_NAME: שם למכונת מחשוב חדשה
  • PROJECT_ID: מזהה הפרויקט שבו רוצים ליצור את המופע. אלא אם אתם משתמשים ברשת VPC משותפת, הפרויקט שאתם מציינים חייב להיות אותו פרויקט שבו נוצרו כל רשתות המשנה והרשתות.
  • DEVICE_NAME: השם שמשויך לדיסק האתחול במערכת ההפעלה של האורח
  • IMAGE_NAME: שם התמונה, לדוגמה, "projects/debian-cloud/global/images/debian-12-bookworm-v20250311".
  • DISK_SIZE: גודל דיסק האתחול, ב-GiB
  • DISK_TYPE: סוג הדיסק שבו רוצים להשתמש לדיסק האתחול, לדוגמה, pd-standard
  • MACHINE_TYPE: סוג המכונה של המופע. כדי להגדיל את מספר המנויים מעבר לקיבולת של התור, צריך להשתמש בסוג מכונה מסדרות המכונות N2, ‏ N2D, ‏ C2 או C2D שמשתמשות ב-gVNIC וברשת Tier_1.
  • ZONE: האזור שבו רוצים ליצור את המכונה
  • QUEUE_COUNT: מספר התורים של ה-vNIC, בכפוף לכללים שמוסברים במאמר הקצאת תורים בהתאמה אישית.
  • SUBNET_*: השם של תת-הרשת שאליה מתחבר ממשק הרשת

REST

  1. אם עדיין אין לכם רשת VPC עם תת-רשת לכל ממשק vNIC שאתם מתכננים להגדיר, אתם צריכים ליצור אותם.
  2. כדי ליצור מכונת חישוב עם מספרים ספציפיים של תורים עבור vNICs, משתמשים בשיטה instances.insert. אפשר לחזור על המאפיין networkInterfaces כדי להגדיר כמה ממשקי רשת.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances
    {
    "name": "INSTANCE_NAME",
    "machineType": "machineTypes/MACHINE_TYPE",
    "networkPerformanceConfig": {
        "totalEgressBandwidthTier": TIER_1
    },
    "networkInterfaces": [
        {
          "nicType": gVNIC,
          "subnetwork":"regions/region/subnetworks/SUBNET_1",
          "queueCount": "QUEUE_COUNT_1"
        } ],
    "networkInterfaces": [
        {
          "nicType": gVNIC,
          "subnetwork":"regions/region/subnetworks/SUBNET_2",
          "queueCount": "QUEUE_COUNT_2"
        } ]
    }
    

    מחליפים את מה שכתוב בשדות הבאים:

    • PROJECT_ID: מזהה הפרויקט שבו רוצים ליצור את מופע ה-Compute
    • ZONE: האזור שבו רוצים ליצור את מכונת ה-Compute
    • INSTANCE_NAME: השם של מכונת המחשוב החדשה
    • MACHINE_TYPE: סוג המכונה, מוגדר מראש או בהתאמה אישית, למופע החדש של Compute. כדי להקצות יותר מדי מכונות למספר התורים, צריך להשתמש בסוג מכונה מסדרת המכונות N2, ‏ N2D, ‏ C2 או C2D שמשתמשת ב-gVNIC וברשת Tier_1.
    • SUBNET_*: השם של תת-הרשת שאליה מתחבר ממשק הרשת
    • QUEUE_COUNT: מספר התורים של ה-vNIC, בכפוף לכללים שמוסברים במאמר הקצאת תורים בהתאמה אישית.

הקצאות לתור ושינוי סוג המכונה

מכונות Compute נוצרות עם הקצאת תור ברירת מחדל, או שאתם יכולים להקצות מספר תורים בהתאמה אישית לכל כרטיס רשת וירטואלי (vNIC) כשאתם יוצרים מכונת Compute חדשה באמצעות Compute Engine API. ההקצאות של תורי vNIC שמוגדרות כברירת מחדל או בהתאמה אישית מוגדרות רק כשיוצרים מופע של מחשוב. אם למופע שלכם יש vNICs שמשתמשים במספרים של תורים שמוגדרים כברירת מחדל, אתם יכולים לשנות את סוג המכונה. אם סוג המכונה שאליו אתם משנים את המכונה כולל מספר שונה של vCPU, המערכת תחשב מחדש את מספר התורים שמוגדר כברירת מחדל למופע על סמך סוג המכונה החדש.

אם למכונה הווירטואלית יש vNICs שמשתמשים במספרים מותאמים אישית של תורים, שלא מוגדרים כברירת מחדל, אתם יכולים לשנות את סוג המכונה באמצעות Google Cloud CLI או Compute Engine API כדי לעדכן את מאפייני המכונה. ההמרה מצליחה אם המכונה הווירטואלית שמתקבלת תומכת באותו מספר תורים לכל vNIC כמו המופע המקורי. במכונות וירטואליות שמשתמשות בממשק VirtIO-Net ושיש להן מספר תורים מותאם אישית שגבוה מ-16 לכל vNIC, אי אפשר לשנות את סוג המכונה לסוג מכונה מהדור השלישי או מגרסה מאוחרת יותר, כי הן משתמשות רק ב-gVNIC. במקום זאת, אפשר להעביר את המכונה הווירטואלית לסוג מכונה מהדור השלישי או מדורות מאוחרים יותר. כדי לעשות זאת, צריך לפעול לפי ההוראות במאמר העברת עומס עבודה למופע מחשוב חדש.

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