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

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

חלק מסוגי המכונות (לדוגמה, z4d-highmem-384-standardlssd) מספקים שני כרטיסי רשת פיזיים. כשיוצרים מכונות וירטואליות באמצעות סוגי המכונות האלה, כל ממשק רשת וירטואלי (vNIC) שמגדירים מוקצה לממשק רשת פיזי בשיטת round-robin.

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

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

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

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

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

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

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

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

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

ממשקי רשת דינמיים משתמשים ברוחב הפס של ה-vNIC של האב. אין בידוד תנועה בתוך 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
  • הגורם העיקרי שקובע את המהירות הוא רוחב הפס המקסימלי לתעבורת נתונים יוצאת (egress) לכל מופע, שמבוסס על סוג המכונה של המופע השולח ועל ההגדרה של רשת Tier_1.

    • מכונות וירטואליות מסוג 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 עם שני כרטיסי NIC פיזיים תומכות ברוחב פס של עד ‎400 Gbps ביציאה ממכונה וירטואלית למכונה וירטואלית.
    • מכונות C4N עם שני כרטיסי רשת פיזיים תומכות ברוחב פס של עד ‎400 Gbps ליציאת נתונים מ-VM ל-VM, עד ‎95,000,000 מנות לשנייה (PPS) ועד ‎50 Gbps של רוחב פס של זרימה יחידה בין מכונות C4N שמנותבות באותה רשת VPC.
  • למידע על גורמים, הגדרות ותרחישים אחרים, אפשר לעיין במאמר בנושא תעבורת יציאה ליעדים שניתן לנתב בתוך רשת VPC.
ניתוב מחוץ לרשת
VPC
  • במכונות H3 ובמכונות H4D, העברת נתונים יוצאת ליעד מחוץ לרשת ה-VPC מוגבלת ל-1 Gbps.
  • במקרים של מופעי C4N, המגבלה היא:

    • ‫‎100 Gbps לכל כרטיס רשת פיזי, או ‎200 Gbps למופעים עם שני כרטיסי רשת
    • ‫24,000,000 PPS לכל כרטיס NIC פיזי, או 48,000,000 PPS למופעים עם שני כרטיסי NIC
  • בכל שאר סדרות המכונות, המגבלה מוגדרת בעיקר על ידי רוחב פס מקסימלי של תעבורת נתונים יוצאת לכל מכונה, על סמך סוג המכונה של המכונה השולחת והאם מופעלת רשת Tier_1. רוחב הפס המקסימלי האפשרי של מכונת מקור לשליחת תעבורת נתונים יוצאת (egress) ליעד מחוץ לרשת ה-VPC שלה לא יכול להיות גדול מהערכים הבאים:

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

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

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

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

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

רוחב פס יוצא

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

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

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

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

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

מגבלת יציאה מקסימלית לכל מופע
סדרת מכונות רגילה Tier_1 networking
C4N ‫400 Gbps לא רלוונטי
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 ‫400 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 shared-core (f1-micro and g1-small) ‫1 Gbps לא זמין
T2A ו-T2D ‫32 Gbps לא זמין
X4 ‫100 Gbps לא רלוונטי
Z3 ‫100 Gbps ‫200 Gbps
Z4D עם 192 או פחות מעבדים וירטואליים ‫200 Gbps לא רלוונטי
Z4D עם 384 מעבדי vCPU ‫400 Gbps לא רלוונטי

אין ערובה לרוחב הפס המקסימלי של התעבורה היוצאת לכל מופע. רוחב הפס בפועל של תעבורת הנתונים היוצאת (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 לא מופעלת או לא נתמכת:
      • למופעי C4N: עד ‎100 Gbps לכל כרטיס רשת פיזי או ‎200 Gbps למופעים עם שני כרטיסי רשת
      • למופעי G4: ‏ 7 Gbps סך הכול לסוגי מכונות עם פחות מ-48 vCPU, ו-25 Gbps סך הכול לסוגי מכונות עם 48 vCPU או יותר
      • למופעים מסוג H4D ו-H3: ‏1 Gbps
      • לסדרות מכונות שתומכות בכמה כרטיסי NIC פיזיים, כמו מכונות M4N,‏ A3,‏ A4,‏ A4X ו-A4X Max: ‏ 7 Gbps לכל כרטיס NIC פיזי
      • לכל שאר סדרות המכונות: 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

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

  • למופעי C4N:
    • ‫24,000,000 PPS לכל כרטיס NIC פיזי (או 48,000,000 PPS למופעים עם שני כרטיסי NIC)
    • ‫90 Gbps לכל כרטיס רשת פיזי (או 180 Gbps למופעים עם שני כרטיסי רשת)
  • לסוגי מופעים אחרים:
    • ‫1,800,000 PPS לכל כרטיס רשת פיזי
    • ‫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 (פיזי או וירטואלי) של מופע Compute מוקצה מספר תורים לקבלה ולשידור של חבילות מידע מהרשת.

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

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

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

מופעים שעברו אופטימיזציה לרשת
C4N: כל vNIC יכול להכיל עד 64 תורים. המספר המקסימלי של תורים לכל מופע הוא מספר ה-vCPU.
הגדרת מכונה מספר התורים המקסימלי לכל vNIC המספר המקסימלי של תורים לכל מופע
Bare metal instances 16 16
מכונות C4 עם 2 ליבות vCPU 1 2
מופעי C4 עם 4 vCPU 2 8
מכונות וירטואליות מהדור השלישי (לא כולל M3) ואילך שמשתמשות ב-gVNIC עם Titanium, כולל Z4D

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

  • אם המספר המחושב קטן מ-1, המספר המקסימלי של תורים לכל vNIC הוא 1.
  • אם המספר המחושב גדול מ-16, אז מספר התורים המקסימלי הוא 16 לכל vNIC.
  • אחרת, מספר התורים המקסימלי לכל vNIC הוא המספר המחושב
מספר המעבדים הווירטואליים
‫M3 או מכונות וירטואליות מדור ראשון ושני שמשתמשות ב-gVNIC

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

  • אם המספר המחושב קטן מ-1, המספר המקסימלי של תורים לכל vNIC הוא 1.
  • אם המספר המחושב גדול מ-16, מספר התורים המקסימלי לכל vNIC הוא 16.
  • אחרת, מספר התורים המקסימלי לכל vNIC הוא המספר המחושב.
מספר המעבדים הווירטואליים חלקי 2
מכונות וירטואליות מהדור הראשון והשני שמשתמשות בממשק רשת VirtIO או במנהל התקן בהתאמה אישית

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

  • אם המספר המחושב קטן מ-1, המספר המקסימלי של תורים לכל vNIC הוא 1.
  • אם המספר המחושב גדול מ-32, מספר התורים המקסימלי לכל vNIC הוא 32.
  • אחרת, מספר התורים המקסימלי לכל vNIC הוא המספר המחושב.
מספר המעבדים הווירטואליים
מכונות H4D עם Cloud RDMA 16 ‫16 או 32 אם משתמשים ב-Cloud RDMA

דוגמאות

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

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

  • אם מכונה וירטואלית משתמשת ב-gVNIC עם Titanium offloads, ויש לה 128 vCPU ושני 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, למעט במקרים הבאים:
      • במכונות C4N, מספר התורים המקסימלי הוא 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. לכן, אם הגדרתם שש כרטיסי רשת וירטואליים למכונה עם 30 מעבדים וירטואליים, תוכלו להגדיר עד (16 * 6), או 96 תורים מותאמים אישית למכונה הווירטואלית.

דוגמאות

  • לדוגמה, למכונת VM מסוג N2 עם שמונה יחידות vCPU וארבעה ממשקי vNIC:

    • אפשר להקצות עד שמונה תורים לארבעת ה-vNIC. לדוגמה, אפשר להקצות תור אחד ל-nic0, ארבעה תורים ל-nic1 ושלושה תורים ל-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 כרטיסי רשת, ו-3 תורים בכרטיס הרשת הווירטואלי שנותר, או 12 תורים בכל כרטיס רשת וירטואלי.
    • אם משתמשים ב-gVNIC וב-queue oversubscription, אפשר להקצות עד 16 תורים לכל vNIC, כלומר סך של 64 תורים.
  • למכונה וירטואלית מסוג N2D עם 224 ליבות וירטואליות ו-8 כרטיסי רשת:

    • אם משתמשים במנהל ההתקן virtIO עבור כרטיסי ה-NIC, אפשר להקצות לכל היותר 224 תורים ל-8 כרטיסי ה-NIC, עם מספר תורים מקסימלי של 32 לכל vNIC. לדוגמה, יכול להיות שיהיו 32 תורים ב-6 מתוך כרטיסי ה-NIC, ואז 16 תורים ב-2 כרטיסי ה-NIC הנותרים.
    • אם משתמשים בדרייבר 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 ועם ביצועי הרשת Tier_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. כדי ליצור מכונת חישוב עם מספרים ספציפיים של תורים עבור vNICs, משתמשים במשאב google_compute_instance. חוזרים על הפרמטר --network-interface לכל vNIC שרוצים להגדיר עבור מופע Compute, וכוללים את הפרמטר 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, משתמשים ב-method‏ instances.insert. אפשר לחזור על המאפיין networkInterfaces כדי להגדיר כמה ממשקי רשת.

    POST https://compute./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, בכפוף לכללים שמוסברים במאמר הקצאת תורים בהתאמה אישית.

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

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

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

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