‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

בחלק מסוגי המכונות (לדוגמה z4m-highmem-192) יש כמה כרטיסי רשת פיזיים. כשיוצרים מופעי מחשוב באמצעות סוגי המכונות האלה, מערכת Compute Engine מקצה לכל ממשק רשת וירטואלי (vNIC) שמגדירים ממשק רשת פיזי. בסוגי המכונות Z4D,‏ Z4M ו-C4N עם כמה כרטיסי רשת, המערכת של Compute Engine מקצה כרטיסי רשת וירטואליים לכרטיסי רשת פיזיים לפי שיטת Round-Robin.

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

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

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

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

שיתוף רוחב פס באמצעות Cloud RDMA

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

מכונות H4D מספקות רוחב פס של עד 200Gbps ברשת.
למכונות Z4M יש רוחב פס של עד 400Gbps ברשת, עם שני כרטיסי רשת פיזיים.

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

הקצאת רוחב הפס של הרשת בין תעבורת הנתונים של Cloud RDMA לבין תעבורת הנתונים של TCP מתבצעת באופן דינמי:

כשמשתמשים בשני סוגי ממשקי הרשת, רוחב הפס משותף בין תעבורת Cloud RDMA ותעבורת TCP.
ממשק הרשת gVNIC או IDPF יכול להשתמש בכל רוחב הפס הזמין כשלא נעשה שימוש בממשק הרשת Cloud RDMA.
ממשק הרשת Cloud RDMA יכול להשתמש בכל רוחב הפס הזמין כשלא נעשה שימוש בממשק הרשת gVNIC או IDPF.

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

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

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

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

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

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

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

ניתוב בתוך רשת VPC	באופן כללי, קצבי התעבורה הנכנסת דומים לקצבי התעבורה היוצאת של סוג המכונה. כדי לקבל את רוחב הפס הגבוה ביותר לתעבורת נתונים נכנסת, צריך להשתמש במכונה עם כמה כרטיסי רשת (multi-NIC) או להפעיל רשת Tier_1, אם היא נתמכת. גודל המכונה של המחשוב, הקיבולת של NIC השרת, תעבורת הנתונים שנכנסת למכונות אחרות של מחשוב שפועלות באותה חומרה של המארח, הגדרת הרשת של מערכת ההפעלה האורחת ומספר קריאות הדיסק שמתבצעות על ידי המכונה – כל אלה יכולים להשפיע על קצב תעבורת הנתונים הנכנסת (ingress). Google Cloud לא מטילה מגבלות נוספות על שיעורי תעבורת נכנסת ברשת VPC. למידע על גורמים, הגדרות ותרחישים אחרים, קראו את המאמר תעבורת נתונים נכנסת ליעדים שניתן לנתב בתוך רשת VPC.
ניתוב מחוץ לרשת VPC	Google Cloud מגן על כל מופע של Compute על ידי הגבלת תעבורת נתונים נכנסת שמנותבת מחוץ לרשת VPC. המגבלה היא הראשון מבין השיעורים הבאים שנמצאו: ‫1,800,000 pps (חבילות לשנייה) ‫30 Gbps במקרה של מופעי C4N, המגבלה היא הראשונה מבין השיעורים הבאים שנתקלים בהם: ‫24,000,000 חבילות לשנייה (PPS) לכל כרטיס רשת פיזי, או 48,000,000 חבילות לשנייה למכונות עם שני כרטיסי רשת ‫90 Gbps לכל כרטיס רשת פיזי או 180 Gbps למופעים עם שני כרטיסי רשת בסדרות מכונות שתומכות בכמה כרטיסי רשת פיזיים, כמו מכונות M4N,‏ Z4D,‏ Z4M,‏ A3,‏ A4,‏ A4X ו-A4X Max, המגבלה היא הראשונה מבין המהירויות הבאות: ‫1,800,000 pps (חבילות לשנייה) לכל NIC פיזי ‫‎30 Gbps לכל כרטיס רשת פיזי לגבי גורמים, הגדרות ותרחישים אחרים, אפשר לעיין במאמר בנושא תעבורת כניסה ליעדים מחוץ לרשת VPC.

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

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

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

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

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

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

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

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

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

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

	מגבלת תעבורת נתונים יוצאת מקסימלית לכל מכונה
סדרת מכונות	רגילה	רשתות Tier_1
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 shared-core	2 Gbps	לא זמין
‫H4D ו-H3	200 Gbps	לא זמין
M4N	400 Gbps	לא רלוונטי
M4	100 Gbps	לא זמין
M3	‫32 Gbps	100 Gbps
M2	‫32Gbps במעבד Intel Cascade Lake או במעבד חדש יותר ‫16Gbps בפלטפורמות אחרות של מעבדים	לא זמין
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	לא זמין
X5	200 Gbps	לא רלוונטי
X4	100 Gbps	לא רלוונטי
Z3	100 Gbps	‫200 Gbps
Z4D	‫400 Gbps	לא רלוונטי
Z4M	‫400 Gbps	לא רלוונטי

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

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

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

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

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

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

רוחב פס מקסימלי של תעבורת נתונים יוצאת לכל מכונה וירטואלית: רוחב הפס המקסימלי של תעבורת נתונים יוצאת לכל מופע, כפי שמתואר בקטע רוחב פס מקסימלי של תעבורת נתונים יוצאת לכל מופע.
רוחב פס של תעבורת נתונים יוצאת בין אזורים לכל פרויקט: אם מופע השליחה ויעד פנימי או הצעד הבא שלו נמצאים באזורים שונים,Google Cloud מכסה מופעלת על סמך האזור והפרויקט של מופע השליחה והאזור של היעד הפנימי או הצעד הבא. מידע נוסף על המכסה הזו זמין במאמר מכסות ומגבלות של VPC בקטע 'רוחב פס של תעבורת נתונים (Egress) ברשת בין אזורים (Mbps) ממכונות 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 הפנימית הראשית של ממשק הרשת (vNIC) של המכונה המקבלת. (כשמכונה ששולחת מתחברת לכתובת IPv4 חיצונית של כרטיס רשת וירטואלי של מכונה אחרת, החבילות מנותבות באמצעות שער אינטרנט שמוגדר כברירת מחדל לניתוב ליעד הבא, ולכן חלים במקום זאת כללי יציאה ליעדים מחוץ לרשת VPC).
- כתובת IPv4 פנימית בטווח כתובות IP של כינוי של כרטיס רשת וירטואלי (vNIC) של מכונה מקבלת.
- כתובת IPv4 פנימית של כלל העברה פנימי להעברת פרוטוקול או למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.
כתובות IPv4 פנימיות גלובליות למשאבי היעד האלה:
- נקודות קצה של Private Service Connect ל- Google Cloud APIs
- טווחים שהוקצו לגישה לשירותים פרטיים
טווחי כתובות של תת-רשתות פנימיות של IPv6 שמשמשים את משאבי היעד האלה:
- כתובת IPv6 מטווח כתובות ה-IPv6 של /96, שמוקצית ל-vNIC של מכונה מקבלת עם פריסת רשת ב-dual-stack או IPv6 בלבד.
- כתובת IPv6 מטווח כתובות ה-IPv6 של /96 של כלל העברה פנימי, להעברת פרוטוקול או למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.
טווחי כתובות של רשתות משנה חיצוניות של IPv6 שמשמשים את משאבי היעד האלה כשחבילות מנותבות באמצעות מסלולים של רשתות משנה או מסלולים של רשתות משנה מקושרות (peering) בתוך רשת ה-VPC, או באמצעות מסלולים בהתאמה אישית בתוך רשת ה-VPC שלא משתמשים בשער ברירת המחדל לאינטרנט בתור הצעד הבא:
- כתובת IPv6 מתוך /96 טווח כתובות IPv6 שהוקצה ל-vNIC של מכונת קבלה עם מחסנית כפולה או עם IPv6 בלבד.
- כתובת IPv6 מטווח כתובות ה-IPv6 של /96 של כלל העברה חיצוני, להעברת פרוטוקול או למאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי.
יעדים אחרים שאפשר לגשת אליהם באמצעות המסלולים הבאים ברשת ה-VPC:
- מסלולים דינמיים
- מסלולים סטטיים חוץ מאלה שמשתמשים בשער ברירת המחדל לאינטרנט בתור הצעד הבא
- התאמה אישית של מסלולי פירינג

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

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

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

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

רוחב פס יוצא לכל מכונה: רוחב הפס המקסימלי לכל החיבורים ממכונת חישוב ליעדים מחוץ לרשת VPC הוא הנמוך מבין רוחב הפס היוצא המקסימלי לכל מכונה ואחד מהערכים הבאים:
- אם רשת Tier_1 מופעלת: 25Gbps
- אם רשת Tier_1 לא מופעלת או לא נתמכת:
  - במכונות C4N: עד 100Gbps לכל NIC פיזי, או 200Gbps למכונות עם שני NIC
  - במכונות Z4D ו-Z4M: ‏ 7 Gbps סך הכול לסוגי מכונות עם פחות מ-48 vCPU, ועד 25 Gbps לכל NIC פיזי לסוגי מכונות עם 48 vCPU ומעלה
  - למופעי G4: ‏ 7 Gbps בסך הכול לסוגי מכונות עם פחות מ-48 מעבדים וירטואליים, ו-25 Gbps בסך הכול לסוגי מכונות עם 48 מעבדים וירטואליים או יותר
  - למכונות H4D ו-H3: ‏1 Gbps
  - בסדרות של מכונות שתומכות בכמה כרטיסי רשת פיזיים, כמו מכונות M4N,‏ A3,‏ A4,‏ A4X ו-A4X Max‏: 7Gbps לכל כרטיס רשת פיזי
  - לכל שאר סדרות המכונות: 7 Gbps
הערה: אפשר להשיג את רוחב הפס המקסימלי של תעבורת הנתונים היוצאת (egress) כשגודל המנה תואם לערך ברירת המחדל של MTU, שהוא 1,460 בייט. ככל שגודל החבילה קטן, רוחב הפס המקסימלי שניתן להשיג יורד גם הוא בגלל מגבלות על מספר החבילות לשנייה שהמכונה יכולה לטפל בהן.

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

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

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

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

רוחב הפס לנתונים נכנסים (ingress)

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

תעבורת נתונים נכנסת ליעדים שאפשר לנתב בתוך רשת VPC

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

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

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

כתובת ה-IPv4 הפנימית הראשית של ממשק הרשת הווירטואלית (vNIC) של המכונה המקבלת. כתובות IPv4 פנימיות ראשיות הן כתובות IPv4 פנימיות אזוריות שמגיעות מטווח כתובות ה-IPv4 הראשי של תת-הרשת.
כתובת IPv4 פנימית מטווח כתובות IP של כינוי של כרטיס ה-vNIC של המכונה המקבלת. טווחי כתובות ה-IP החלופיות יכולים להגיע מטווח כתובות ה-IPv4 הראשי של תת-הרשת או מאחד מטווחי כתובות ה-IPv4 המשניים שלה.
כתובת IPv6 מטווח כתובות ה-IPv6 של /96, שמוקצית ל-vNIC של מכונה מקבלת עם פריסת רשת ב-dual-stack או IPv6 בלבד. טווחי ה-IPv6 של המכונה יכולים להגיע מטווחי ה-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), אם המכונה המקבלת היא קצה עורפי של מאזן העומסים הזה.

תעבורת נתונים נכנסת ליעדים מחוץ לרשת 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 חיצונית מטווח כתובות ה-IPv6 של /96, שמוקצית ל-vNIC של מכונה מקבלת עם פריסת רשת בשני פרוטוקולים או עם IPv6 בלבד, כשהחבילה הנכנסת מנותבת באמצעות נתיב מחוץ לרשת ה-VPC של המכונה המקבלת.
כתובת IPv4 חיצונית של כלל העברה שמשמש להעברת פרוטוקול חיצוני למכונה המקבלת או למאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי, כאשר המכונה המקבלת היא קצה עורפי של מאזן העומסים.
כתובת IPv6 חיצונית מטווח ה-IPv6 של /96 של כלל העברה שמשמש להעברת פרוטוקול חיצוני למכונה המקבלת או למאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי. המכונה המקבלת חייבת להיות קצה עורפי של מאזן העומסים כשהחבילה הנכנסת מנותבת באמצעות נתיב מחוץ לרשת VPC.
תגובות נכנסות קיימות שעובדו על ידי Cloud NAT.

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

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

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

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

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

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

מסגרות גדולות ומכונות GPU

במכונות עם GPU, צריך להשתמש בהגדרות ה-MTU המומלצות למסגרות Jumbo. למידע נוסף, קראו את המאמר הגדרות MTU מומלצות למסגרות Jumbo.

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

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

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

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

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

הגדרת מכונה	מספר התורים המקסימלי לכל vNIC	מספר התורים המקסימלי לכל מכונה
מכונות Bare Metal	16	16
מכונות C4N שעברו אופטימיזציה לרשת	64	מספר המעבדים הווירטואליים (vCPU)
מכונות Z4D ו-Z4M עם אופטימיזציה לאחסון (כולל סוגי מכונות Bare Metal)	16	מספר המעבדים הווירטואליים (vCPU)
מכונות 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 הוא המספר המחושב	מספר יחידות ה-vCPU
מכונות וירטואליות מדור ראשון ושני שמשתמשות ב-gVNIC	מחלקים את מספר המעבדים הווירטואליים במספר כרטיסי הרשת הווירטואליים, ואז מחלקים את התוצאה ב-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 הוא המספר המחושב.	מספר יחידות ה-vCPU
מכונות H4D עם Cloud RDMA	16	‫16 או 32 אם משתמשים ב-Cloud RDMA
מכונות Confidential VM	16	16

דוגמאות

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

אם במכונה וירטואלית משתמשים ב-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 הוא אחד.
מספר התורים המקסימלי שאפשר להקצות לכל vNIC של מכונה הוא המספר הנמוך מבין מספר ה-vCPU או מספר התורים המקסימלי לכל vNIC, בהתאם לסוג ממשק הרשת:
- כשמשתמשים ב-virtIO או במנהל התקן בהתאמה אישית, מספר התורים המקסימלי הוא 32.
- כשמשתמשים ב-gVNIC, מספר התורים המקסימלי הוא 16, חוץ מהמקרים הבאים:
  - במכונות C4N, ‏ Z4D ו-Z4M, מספר התורים המקסימלי הוא 64 לכל NIC.
  - במכונות מסוג A2 או G2, מספר התורים המקסימלי הוא 32 לכל NIC.
  - למכונות TPU יש מספר תורים מקסימלי של 32.
  - במכונות C2, ‏ C2D, ‏ N2 או N2D שמופעלת בהן רשת Tier_1, מספר התורים המקסימלי הוא 32 לכל NIC.
- ב-IRDMA, מספר התורים המקסימלי הוא 8.
- בממשק רשת IDPF, מספר התורים המקסימלי הוא 16, חוץ ממכונות פיזיות מסוג Z4D ו-Z4M, שבהן מספר התורים המקסימלי הוא 64.
- ההגדרות הבאות של 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 של מכונה וירטואלית, גם אם מספר התורים הכולל של המכונה הווירטואלית חורג ממספר המעבדים הווירטואליים. כדי להגדיר מספר תורים בהתאמה אישית שגדול מהמספר המקסימלי, מכונת ה-VM צריכה לעמוד בתנאים הבאים:

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

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

דוגמאות

למכונה וירטואלית מסוג N2 עם שמונה vCPU וארבעה vNIC:
- אפשר להקצות עד שמונה תורים לארבעת ה-vNIC. לדוגמה, אפשר להקצות תור אחד ל-nic0, ארבעה תורים ל-nic1 ושלושה תורים ל-nic2.
- אי אפשר להירשם ליותר מדי תורים כי רשת Tier_1 עם N2 דורשת מכונה וירטואלית עם לפחות 32 מעבדי vCPU.
אם למכונה וירטואלית יש 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 ובמנוי יתר של תורים, אתם יכולים להקצות עד 16 תורים לכל vNIC, ובסך הכול 64 תורים.
למכונה וירטואלית מסוג N2D עם 224 מעבדי vCPU ו-8 כרטיסי רשת:
- אם משתמשים במנהל ההתקן virtIO לכרטיסי ה-NIC, אפשר להקצות עד 224 תורים ל-8 כרטיסי ה-NIC, עם מספר תורים מקסימלי של 32 לכל vNIC. לדוגמה, יכולים להיות 32 תורים ב-6 מכרטיסי ה-NIC, ו-16 תורים ב-2 כרטיסי ה-NIC הנותרים.
- אם אתם משתמשים במנהל ההתקן gVNIC לכרטיסי ה-NIC, אתם יכולים להשתמש במספר התורים המקסימלי של 16 לכל 8 כרטיסי ה-NIC. הסכום המקסימלי של מספר התורים הוא 128.

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

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

דוגמה

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

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

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

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

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

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

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

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

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

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

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

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

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

שיתוף רוחב פס באמצעות Cloud RDMA

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

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

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

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

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

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

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

רוחב הפס לנתונים נכנסים (ingress)

תעבורת נתונים נכנסת ליעדים שאפשר לנתב בתוך רשת VPC

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

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

מסגרות גדולות ומכונות GPU

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

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

דוגמאות

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

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

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

gcloud

Terraform

REST

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

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

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