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

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

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

תעבורת נתונים יוצאת (egress) או תעבורת נתונים נכנסת (ingress): כמו שמשתמשים במונחים האלה בדף הזה, תעבורת נתונים יוצאת (egress) ותעבורת נתונים נכנסת (ingress) תמיד מתייחסות ל Google Cloud מופע:
- מנות שנשלחות ממופע של Google Cloud מרכיבות את תעבורת הנתונים היוצאת (egress) שלו.
- מנות שנשלחות אל מופע 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.

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

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

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

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

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

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

מחשוב HPC עם Cloud 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, כי היא רגישה יותר לביצועים.

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

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

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

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

ניתוב בתוך רשת VPC

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

ניתוב מחוץ לרשת VPC

הוא מוגדר בעיקר לפי רוחב פס מקסימלי ליציאה לכל מופע, על סמך סוג המכונה של המופע השולח והאם מופעלת רשת Tier_1. למעט מכונות וירטואליות מסוג H3, נפח התעבורה המקסימלי האפשרי של נתונים יוצאים ממופע ששולח נתונים ליעד מחוץ לרשת ה-VPC שלו לא יכול לחרוג מהערכים הבאים:
- ‫7 Gbps בסך הכול כשלא מופעלת רשת Tier_1
- ‫25 Gbps בסך הכול כשמופעלת רשת Tier_1
- ‫‎3 Gbps לכל זרימה
גורמים, הגדרות ואזהרות נוספים מפורטים במאמר בנושא תעבורת נתונים יוצאת (egress) ליעדים מחוץ לרשת VPC.

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

ניתוב בתוך רשת VPC	בדרך כלל, תעריפי התעבורה הנכנסת דומים לתעריפי התעבורה היוצאת של סוג מכונה. כדי לקבל את רוחב הפס הכי גבוה שאפשר לתעבורת נתונים נכנסת (ingress), מפעילים את Tier_1 networking. גודל מופע החישוב, הקיבולת של NIC של השרת, התנועה שנכנסת למכונות וירטואליות אחרות של אורחים שפועלות באותו חומרה של המארח, הגדרת הרשת של מערכת ההפעלה של האורח ומספר קריאות הדיסק שמבוצעות על ידי המופע – כל אלה יכולים להשפיע על קצב הכניסה. Google Cloud לא מטילה מגבלות נוספות על שיעורי תעבורה נכנסת ברשת VPC. גורמים, הגדרות ותרחישים נוספים מפורטים במאמר בנושא תעבורת Ingress ליעדים שניתן לנתב בתוך רשת VPC.
ניתוב מחוץ לרשת VPC	Google Cloud מגן על כל מופע של Compute על ידי הגבלת תעבורת נתונים נכנסת שמנותבת מחוץ לרשת VPC. המגבלה היא השיעור הראשון מבין השיעורים הבאים שנתקלים בו: ‫1,800,000 pps (חבילות לשנייה) ‫30 Gbps בסדרת מכונות שתומכת בכמה כרטיסי רשת פיזיים, כמו A3, המגבלה היא הראשונה מבין השיעורים הבאים: ‫1,800,000 pps (packets per second) per physical NIC ‫30 Gbps לכל כרטיס רשת פיזי למידע על גורמים, הגדרות ותרחישים אחרים, אפשר לעיין במאמר בנושא תעבורת נתונים נכנסת (ingress) ליעדים מחוץ לרשת VPC.

ניתוב בתוך רשת VPC

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

ניתוב מחוץ לרשת VPC

Google Cloud מגן על כל מופע של Compute על ידי הגבלת תעבורת נתונים נכנסת שמנותבת מחוץ לרשת VPC. המגבלה היא השיעור הראשון מבין השיעורים הבאים שנתקלים בו:
- ‫1,800,000 pps (חבילות לשנייה)
- ‫30 Gbps
בסדרת מכונות שתומכת בכמה כרטיסי רשת פיזיים, כמו A3, המגבלה היא הראשונה מבין השיעורים הבאים:
- ‫1,800,000 pps (packets per second) per physical NIC
- ‫30 Gbps לכל כרטיס רשת פיזי
למידע על גורמים, הגדרות ותרחישים אחרים, אפשר לעיין במאמר בנושא תעבורת נתונים נכנסת (ingress) ליעדים מחוץ לרשת VPC.

רוחב פס של תעבורת נתונים יוצאת (egress)

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

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

רוחב הפס המקסימלי ליציאה לכל מופע הוא בדרך כלל 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	לא רלוונטי
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 עם ‎1 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)
עומס ברשת
במצב שבו פעולות קלט/פלט של Persistent Disk מתחרות עם תעבורת נתונים אחרת של יציאה מהרשת, 60% מרוחב הפס המקסימלי של הרשת מוקצים לכתיבה ב-Persistent Disk, ו-40% מוקצים לתעבורת נתונים אחרת של יציאה מהרשת. פרטים נוספים זמינים במאמר הגורמים שמשפיעים על ביצועי הדיסק.

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

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

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

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

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

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

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

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

בין מופעי מחשוב באותו אזור
בין מכונות וירטואליות באזורים שונים באותו אזור
בין מופעי מחשוב באזורים שונים
ממופע של Compute אל ממשקי API ושירותים באמצעות גישה פרטית ל-Google או גישה לממשקי Google API מכתובת IP חיצונית של מופע. Google Cloud כולל נקודות קצה של Private Service Connect ל-Google APIs.

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

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

רוחב פס של תעבורת נתונים יוצאת לכל מכונה: רוחב הפס המקסימלי לכל החיבורים ממכונת מחשוב ליעדים מחוץ לרשת VPC הוא הקטן מבין רוחב הפס המקסימלי של תעבורת נתונים יוצאת לכל מכונה ואחד מהערכים הבאים:
- ‫25 Gbps, אם מופעלת רשת Tier_1
- ‫7 Gbps, אם לא מופעלת רשת Tier_1
- ‫‎1 Gbps למכונות H4D ו-H3
- ‫7 Gbps לכל כרטיס רשת פיזי בסדרות מכונות שתומכות בכמה כרטיסי רשת פיזיים, כמו A3.
הערה: אפשר להשיג את רוחב הפס המקסימלי של תעבורת הנתונים היוצאת (egress) כשגודל המנה תואם לערך ברירת המחדל של MTU, שהוא 1,460 בייט. ככל שגודל המנה קטן, רוחב הפס המקסימלי שניתן להשיג יורד גם הוא בגלל מגבלות על מספר המנות לשנייה שמכונת החישוב יכולה לטפל בהן.

לדוגמה, למרות שלמכונת VM מסוג c3-standard-44 יש רוחב פס מקסימלי של 32 Gbps ליציאה (egress) לכל מופע, רוחב הפס ליציאה (egress) לכל מופע ממכונת VM מסוג c3-standard-44 ליעדים חיצוניים הוא 25 Gbps או 7 Gbps, בהתאם להגדרה של רשת Tier_1.
קצב היציאה המקסימלי לכל זרימה: רוחב הפס המקסימלי לכל חיבור ייחודי של 5 טאפלים, ממכונה ליעד מחוץ לרשת VPC, הוא 3 Gbps, למעט ב-H4D וב-H3, שבהם הוא 1 Gbps.
רוחב פס של תעבורת נתונים יוצאת לאינטרנט לכל פרויקט: רוחב הפס המקסימלי לכל החיבורים ממופעי מחשוב בכל אזור בפרויקט ליעדים מחוץ לרשת VPC מוגדר על ידי מכסות רוחב הפס של תעבורת נתונים יוצאת לאינטרנט של הפרויקט.

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

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

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

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

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

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

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

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

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

מקרים של Bare Metal

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

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

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

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

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

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

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

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

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

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

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

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

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

מכונות H4D עם Cloud RDMA

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

דוגמאות

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

אם מכונה וירטואלית משתמשת ב-VirtIO ויש לה 16 vCPU ו-4 vNIC, המספר המחושב הוא [16/4] = 4. Google Cloud מקצה לכל vNIC ארבעה תורים.
אם מופעלת במכונה וירטואלית 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 הוא אחד.
מספר התורים המקסימלי שאפשר להקצות לכל vNIC של מופע מכונה וירטואלית הוא הנמוך מבין מספר ה-vCPU או מספר התורים המקסימלי לכל vNIC, בהתאם לסוג מנהל ההתקן:
- אם משתמשים ב-virtIO או במנהל התקן בהתאמה אישית, מספר התורים המקסימלי הוא 32.
- כשמשתמשים ב-gVNIC, מספר התורים המקסימלי הוא 16, למעט במקרים הבאים, שבהם מספר התורים המקסימלי הוא 32:
  - מכונות A2 או G2
  - מכונות TPU
  - מופעלת רשת Tier_1 במופעי C2,‏ C2D,‏ N2 או N2D
- בהגדרות הבאות של Confidential VM, מספר התורים המקסימלי הוא 8:
  - ‫AMD SEV בסוגי מכונות C2D ו-N2D
  - ‫AMD SEV-SNP בסוגי מכונות N2D
סכום מספרי התור בכל כרטיסי ה-NIC שהוגדרו עבור מכונת ה-VM צריך לעמוד באחד מהכללים הבאים:
- הערך המקסימלי הוא הנמוך מבין:
  - [number of vCPUS]
  - [number of vNICs] * [max number of queues per vNIC]
- אם משתמשים בהקצאת יתר של תורים, הערך המקסימלי הוא:
  - [number of vNICs] * 16

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

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

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

דוגמאות

למכונה וירטואלית מסוג N2 עם 8 מעבדים וירטואליים ו-4 כרטיסי רשת וירטואליים:
- אפשר להקצות עד 8 תורים ל-4 vNICs. לדוגמה, אפשר להקצות תור אחד ל-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 הנותרים, באמצעות התהליך הבא:

חישוב סכום התורים עבור כרטיסי ה-vNIC שהוקצו להם תורים מותאמים אישית.
מפחיתים את סכום התורים שהוקצו בהתאמה אישית ממספר ה-vCPU. אם ההפרש קטן ממספר ה-vNICs שנותרו ושעבורם Compute Engine צריך להקצות תורים, ‏ Compute Engine מחזיר שגיאה כי לכל vNIC צריך להיות לפחות תור אחד.
מחלקים את ההפרש מהשלב הקודם במספר כרטיסי ה-vNIC ללא מספר תורים מותאם אישית, ומתעלמים מהשארית:
```
[(number of vCPUs - sum of assigned queues)/(number of remaining vNICs)]
```
החישוב הזה תמיד יניב מספר שלם (לא שבר) שהוא לפחות אחד, כי לכל vNIC צריכה להיות לפחות תור אחד.
‫Compute Engine מקצה לכל vNIC שנותר מספר תורים באופן הבא:
- אם המספר המחושב נמוך ממספר התורים המקסימלי לכל vNIC, מספר התורים מוגדר כמספר המחושב.
- אם המספר המחושב גדול ממספר התורים המקסימלי לכל vNIC, מספר התורים של ה-vNIC מוגדר כמספר התורים המקסימלי.

דוגמה

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

סכום התורים שהוקצו בהתאמה אישית הוא 5 + 6 + 4 = 15.
ל-Compute Engine נותרו 20 - 15 = 5 תורים להקצאה לשלושת כרטיסי ה-vNIC הנותרים (nic3, ‏ nic4, ‏ nic5). ההפרש (5) גדול ממספר כרטיסי ה-vNIC שלא הוגדר להם מספר תורים מותאם אישית (3).
ההפרש 5 מחולק ב-3, והשארית מושמטת. הערך שנותר הוא 1.
מכיוון שהמספר המחושב (1) קטן מהמספר המקסימלי של תורים לכל vNIC, מספר התורים עבור שאר ה-vNIC מוגדר כ-1.

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

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

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

gcloud

אם עדיין אין לכם רשת VPC עם תת-רשת לכל ממשק vNIC שאתם מתכננים להגדיר, אתם צריכים ליצור אותם.
משתמשים בפקודה 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

אם עדיין אין לכם רשת VPC עם תת-רשת לכל ממשק vNIC שאתם מתכננים להגדיר, אתם צריכים ליצור אותם.

כדי ליצור מכונת חישוב עם מספרים ספציפיים של תורים עבור vNICs, משתמשים במשאב 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

אם עדיין אין לכם רשת VPC עם תת-רשת לכל ממשק vNIC שאתם מתכננים להגדיר, אתם צריכים ליצור אותם.
כדי ליצור מכונת חישוב עם מספרים ספציפיים של תורים עבור vNICs, משתמשים ב-method‏ 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. במקום זאת, אפשר להעביר את המכונה הווירטואלית לסוג מכונה מהדור השלישי או מדורות מאוחרים יותר. כדי לעשות זאת, צריך לפעול לפי ההוראות במאמר העברת עומס עבודה למופע מחשוב חדש.

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

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

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

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

מחשוב HPC עם Cloud RDMA

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

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

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

רוחב פס של תעבורת נתונים יוצאת (egress)

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

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

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

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

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

תעבורת נתונים נכנסת (ingress) ליעדים מחוץ לרשת VPC

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

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

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

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

דוגמאות

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

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

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

gcloud

Terraform

REST

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

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

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