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

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

סקירה כללית

בחלק מסדרות המכונות שמותאמות למאיצים, כולל A5X,‏ A4X Max,‏ A4X,‏ A4 ו-A3 Ultra, יש שני ממשקי רשת LAN מארחים לאחסון ולניהול, שמחוברים לרשתות רגילות של ענן וירטואלי פרטי (VPC). למכונות האלה יש גם ממשקי רשת (MRDMA) שצריך לחבר לרשת VPC של גישה ישירה מרוחקת לזיכרון (RDMA) דרך Converged Ethernet ‏(RoCE).

במאמר הזה נתמקד בהגדרה של ממשקי ה-LAN המארחים (gVNIC או IDPF) ברשתות VPC רגילות, ולא בממשקי רשת RDMA. ממשקי ה-LAN של המארח הם יחידות עיבוד תשתית (IPU) מסוג Titanium, שמחוברות לשקעי מעבד (CPU) נפרדים ולצמתים של גישה לא אחידה לזיכרון (NUMA). בתוך המכונה, יחידות ה-IPU האלה מופיעות בתור ממשקי רשת של Google Virtual NIC ‏(gVNIC) או של Infrastructure Data Path Function ‏(IDPF). הממשקים האלה מספקים רוחב פס ברשת לפעילויות אחסון וניהול, כמו נקודות בקרה, טעינת נתוני אימון וטעינת מודלים. טופולוגיית ה-NUMA של המכונה, כולל הטופולוגיה של ממשקי הרשת, גלויה למערכת ההפעלה (OS) של האורח.

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

• הגדרות הרשת: מגדירים כל ממשק gVNIC או IDPF כך שישתמש ברשת VPC נפרדת. כדי להגדיר את ה-VPC, מבצעים את ההגדרות הבאות:
  • מגדירים יחידת העברה מקסימלית (MTU) גדולה לכל רשת VPC, למשל 8896 (ה-MTU המקסימלי שנתמך).
  • אם חבילות נתונים נכנסות שהושמטו בצד המקבל מאטות את ביצועי הכניסה של עומס העבודה, צריך לבדוק אם יש חבילות שהושמטו באמצעות הכלי ethtool. כדי לבצע אופטימיזציה של הקצאת הנתונים מהמטמון של הדף, כך שכל מסגרת שכבה 2 נכנסת תתאים לשני מאגרי נתונים זמניים של 4KB, צריך לשנות את גודל הפלח המקסימלי (MSS) של ה-TCP, את ה-MTU של הממשק או את ה-MTU של ה-VPC.
• הגדרות האפליקציה:
  • כדי להתאים את האפליקציה ל-NUMA, משתמשים בליבות מעבד, בהקצאות זיכרון ובממשק רשת מאותו צומת NUMA. אם אתם מריצים מכונה ייעודית של האפליקציה לצומת NUMA או לממשק רשת ספציפיים, צריך לקשר את משאבי המעבד (CPU) והזיכרון של האפליקציה לאותו צומת NUMA באמצעות כלי כמו numactl.
• הגדרות של מערכת ההפעלה:
  • הפעילו את TCP segmentation offload‏ (TSO) ואת large receive offload‏ (LRO).
  • לכל ממשק gVNIC או IDPF, מגדירים זיקה של עיבוד סימטרי (SMP) כדי לנתב בקשות פסיקה (IRQ) לאותו צומת NUMA כמו הממשק, ולפזר את הפסיקות בין ליבות המעבד (CPU). אם אתם משתמשים באימג' של Linux ש-Google מספקת, הסוכן האורח של Compute Engine מריץ את הסקריפט google_set_multiqueue בזמן ההפעלה כדי להחיל את ההגדרה הזו באופן אוטומטי. אם אתם משתמשים באימג' בהתאמה אישית, אתם צריכים להתקין את סביבת האורח. אם הסקריפט לא פועל באופן אוטומטי, מריצים את הפקודה sudo /usr/bin/google_set_multiqueue.
  • כדאי לבדוק את ההגדרות של Receive Flow Steering‏ (RFS),‏ Receive Packet Steering‏ (RPS) ו-Transmit Packet Steering‏ (XPS) כדי לקבוע אם הן מועילות לעומס העבודה.
  • במכונות A4X Max ו-A4X, ‏ NVIDIA ממליצה להשבית את התזמון האוטומטי של NUMA.
  • אל תשתמשו ב-Linux kernel bonding עם ממשקי gVNIC או IDPF במכונות האלה, כי אין תמיכה ב-kernel bonding.

תבניות לשימוש בכמה כרטיסי רשת (NIC) של מארחים

בטבלה הבאה מפורטות תבניות כלליות לשימוש בכמה כרטיסי רשת (NIC) של מארחים ב-Google Cloud:

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

דוגמת קוד	פריסת התהליך הנתמכת	נתיב פריסה: Compute Engine	נתיב הפריסה: Google Kubernetes Engine	נתיב פריסה: Slurm	הערות
שינוי אפליקציה לשימוש בממשק ספציפי	תהליך של פיצול לכל ממשק	כן	כן	כן	צריך לשנות את הקוד של האפליקציה.
שינוי אפליקציה כדי להשתמש בשני הממשקים	תהליך עם ממשק כפול	כן	כן	כן	צריך לשנות את הקוד של האפליקציה.
שימוש במרחב שמות ייעודי ברשת לאפליקציות ספציפיות	תהליך של פיצול נתונים לכל ממשק	כן	כן (קונטיינרים עם הרשאות בלבד)	לא	ללא
מיפוי של כל התנועה של מאגר נתונים לממשק אחד	כל תנועת הגולשים בקונטיינר ממופה לממשק אחד	כן	כן	לא	ללא
שימוש בקישור בין רשתות VPC שכנות (peering) ואיזון עומסים של סשנים בממשקים על ידי המערכת	תהליך עם ממשק כפול	כן	כן	כן	קשה או בלתי אפשרי לבצע התאמה ל-NUMA. נדרשת ליבת Linux בגרסה 6.16 ואילך.
פיצול תנועה בין רשתות	תהליך עם ממשק כפול תהליך של פיצול נתונים לכל ממשק	כן	כן	כן	יכול להיות שיהיה צורך לשנות את הקוד כדי להתאים ל-NUMA אם מריצים תהליך עם ממשק כפול.
שימוש בתרגום כתובת רשת של מקור (SNAT) כדי לבחור את ממשק המקור	תהליך עם ממשק כפול תהליך של פיצול נתונים לכל ממשק	כן	כן (ההגדרה דורשת הרשאות אדמין)	כן (ההגדרה דורשת הרשאות אדמין)	יכול להיות קשה להגדיר אותם.

הערות

• בתבניות Use VPC peering and let the system load-balance sessions across interfaces ו-Shard traffic across networks: האפשרויות האלה לא מומלצות בדרך כלל, אבל הן יכולות להיות שימושיות לעומסי עבודה מוגבלים בפלטפורמות x86 (A4 ו-A3 Ultra).

שינוי אפליקציה כדי להשתמש בממשק ספציפי

דרישות:

• צריך לשנות את הקוד באפליקציה.
• נדרשות הרשאות לאחת או יותר מהשיטות הבאות:
  • ‫bind(): נדרשות הרשאות מיוחדות רק אם משתמשים ביציאת מקור עם הרשאות.
  • ‫SO_BINDTODEVICE: נדרשת ההרשאה CAP_NET_RAW.
• יכול להיות שתצטרכו לשנות את טבלת הניתוב של הליבה כדי ליצור נתיבים ולמנוע ניתוב אסימטרי.

סקירה כללית ברמה גבוהה

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

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

1. מוסיפים קישור לממשק רשת בקוד המקור של האפליקציה באחת מהדרכים הבאות:
   • משתמשים בקריאת המערכת bind() כדי לקשר שקע לכתובת IP ספציפית של מקור.
   • משתמשים באפשרות השקע SO_BINDTODEVICE כדי לקשר שקע לממשק רשת ספציפי.
2. משנים את טבלת הניתוב של הליבה לפי הצורך כדי לוודא שקיים נתיב מממשק הרשת של המקור לכתובת היעד. כדי למנוע ניתוב אסימטרי, צריך להגדיר מדיניות ניתוב כמו שמתואר בקטע הגדרת ניתוב לממשק רשת נוסף.
3. אופציונלי: מריצים את האפליקציה בזיכרון ובמעבדים שחולקים את אותו צומת NUMA כמו ממשק הרשת שבחרתם, באמצעות הפקודה numactl.

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

שינוי אפליקציה כדי להשתמש בשני הממשקים

דרישות:

• צריך לשנות את הקוד באפליקציה.
• נדרשות הרשאות לאחת או יותר מהשיטות הבאות:
  • ‫bind(): נדרשות הרשאות מיוחדות רק אם משתמשים ביציאת מקור עם הרשאות.
  • ‫SO_BINDTODEVICE: נדרשת ההרשאה CAP_NET_RAW.
• יכול להיות שתצטרכו לשנות את טבלת הניתוב של הליבה כדי ליצור נתיבים ולמנוע ניתוב אסימטרי.

סקירה כללית ברמה גבוהה

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

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

1. מוסיפים קישור לכל ממשק רשת בקוד המקור של האפליקציה, באחת מהדרכים הבאות:
   • משתמשים בקריאת המערכת bind() כדי לקשר כל שקע לכתובת ה-IP של המקור של ממשק הרשת המתאים.
   • משתמשים באפשרות השקע SO_BINDTODEVICE כדי לקשר כל שקע לממשק רשת ספציפי.
2. אם האפליקציה פועלת כלקוח, צריך ליצור שקע לקוח (client socket) נפרד לכל ממשק רשת מקור.
3. משנים את טבלת הניתוב של הליבה לפי הצורך כדי לוודא שקיים נתיב מכל ממשק רשת של מקור לכתובת היעד. כדי למנוע ניתוב אסימטרי, צריך להגדיר מדיניות ניתוב כמו שמתואר בקטע הגדרת ניתוב לממשק רשת נוסף.
4. חלוקת הפעילות ברשת לשרשורים שפועלים באותו צומת NUMA כמו ממשק gVNIC או IDPF המתאים – לדוגמה, על ידי קריאה ל-pthread_setaffinity_np. מכיוון שהאפליקציה משתמשת במשאבים בכמה צומתי NUMA, אל תשתמשו ב-numactl, או ודאו שהפקודה numactl כוללת את צומתי ה-NUMA של כל ממשקי הרשת שבהם האפליקציה משתמשת.

שימוש במרחב שמות ייעודי ברשת לאפליקציות ספציפיות

דרישות:

• נדרשת היכולת CAP_SYS_ADMIN.
• לא תואם ל-GKE Autopilot.
• אם אתם משתמשים ב-GKE, אתם צריכים להשתמש בקונטיינר עם הרשאות.

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

העברת הממשק המשני למרחב שמות ייעודי ברשת

בתבנית הזו, יוצרים מרחב שמות של רשת, מעבירים את ממשק ה-gVNIC או ה-IDPF המשני למרחב השמות החדש, ואז מריצים את האפליקציה ממרחב השמות הזה. התבנית הזו פשוטה יותר להגדרה ולכוונון בהשוואה למתג וירטואלי, אבל אפליקציות מחוץ למרחב השמות החדש של הרשת לא יכולות לגשת לממשק הרשת המשני.

כדי להעביר את הממשק eth1 למרחב שמות של רשת בשם app-net ולהריץ פקודה במרחב השמות הזה, מריצים את הפקודות הבאות:

ip netns add app-net
ip link set eth1 netns app-net
ip netns exec app-net ip addr add ETH1_IP/PREFIX dev eth1
ip netns exec app-net ip link set dev eth1 up
ip netns exec app-net ip route add default via GATEWAY_IP dev eth1
ip netns exec app-net COMMAND

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

• ‫ETH1_IP: כתובת ה-IP הפנימית של הממשק eth1.
• ‫PREFIX: אורך הקידומת של רשת המשנה לממשק eth1.
• ‫GATEWAY_IP: כתובת ה-IP של שער ברירת המחדל של רשת המשנה eth1.
• ‫COMMAND: הפקודה להרצה בתוך מרחב השמות של הרשת app-net.

כשמריצים את הפקודות האלה, COMMAND פועל בתוך מרחב השמות של הרשת app-net ומשתמש בממשק eth1.

אפליקציות שפועלות בתוך מרחב השמות החדש של הרשת משתמשות בממשק המשני של gVNIC או IDPF. אפשר גם להשתמש בפקודה numactl כדי להריץ את האפליקציה באמצעות הזיכרון והמעבדים באותו צומת NUMA כמו ממשק הרשת שבחרתם.

שימוש במתג וירטואלי ובמרחב שמות של רשת לממשק משני

בדפוס הזה, מגדירים מתג וירטואלי כדי לגשת לממשק gVNIC או IDPF המשני ממרחב שמות של רשת:

1. פותחים חיבור SSH למכונה. מידע נוסף זמין במאמר התחברות למכונות וירטואליות של Linux.
2. יוצרים זוג מכשירים Virtual Ethernet (veth) באמצעות הפקודה ip link add, לדוגמה ip link add veth0 type veth peer name veth1.

3. משנים את ה-MTU בכל מכשיר כך שיתאים ל-MTU של הממשק המשני באמצעות הפקודה ip link set:

   ip link set dev veth0 mtu MTU
   ip link set dev veth1 mtu MTU
   

   מחליפים את MTU ב-MTU של הממשק המשני, לדוגמה 8896.

4. מפעילים העברת חבילות IPv4:

   sysctl -w net.ipv4.ip_forward=1
   

5. מעבירים קצה אחד של צמד ה-veth למרחב שמות חדש ברשת, ומשאירים את הקצה השני במרחב השמות הבסיסי.

6. ממפים את התנועה מהמכשיר veth לממשק המשני. כדי להגדיר את המיפוי הזה, יוצרים טווח כתובות IP חלופיות לממשק המשני של המכונה ומקצים כתובת IP מהטווח הזה לממשק הצאצא במרחב השמות.

7. מריצים את האפליקציה ממרחב השמות החדש של הרשת. אתם יכולים להשתמש בפקודה numactl כדי להריץ את האפליקציה באמצעות הזיכרון והמעבדים באותו צומת NUMA כמו ממשק הרשת שנבחר.

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

מיפוי התנועה של מאגר תגים שלם לממשק אחד

דרישות:

• האפליקציה צריכה לפעול בתוך קונטיינר שמשתמש במרחב שמות של רשת לצורך רישות קונטיינרים, כמו GKE,‏ Docker או Podman. אי אפשר להשתמש ברשת המארחת.

סביבות זמן ריצה של קונטיינרים כמו GKE,‏ Docker ו-Podman משתמשות במרחב שמות ייעודי ברשת לכל קונטיינר כדי לבודד את התנועה שלו. אפשר לשנות את מרחב השמות הזה של הרשת – ישירות או באמצעות הכלים של סביבת זמן הריצה של הקונטיינר – כדי למפות את התנועה לממשק רשת אחר.

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

metadata:
  # ...
  annotations:
    networking.gke.io/default-interface: 'eth1'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth1","network":"secondary-network"}
      ]

בגישה הזו אין הבטחה להתאמת NUMA בין ממשק הרשת שמוגדר כברירת מחדל לבין המעבדים או הזיכרון שהוקצו.

שימוש בקישור בין רשתות VPC שכנות (peering) ומתן אפשרות למערכת לאזן את העומסים של הסשנים בין הממשקים

דרישות:

• צריך ליצור קישור בין רשתות VPC שכנות (peering) בין רשתות ה-VPC של כרטיסי ה-NIC הראשיים והמשניים של המארח.
• כדי לאזן את העומסים של סשנים של TCP בממשקי המקור כששולחים תעבורת נתונים לכתובת IP וליציאה אחת של יעד, צריך להשתמש בגרסת ליבה 6.16 או גרסה חדשה יותר של Linux.
• עומס העבודה צריך להיות מסוגל לעמוד בהעברות זיכרון בין שקעים בלי לפספס את יעדי הביצועים.

סקירה כללית ברמה גבוהה

אם אתם לא יכולים לפצל בקלות את החיבורים לרשת בתוך אפליקציה או בין מכונות של אפליקציות, ועומס העבודה שלכם פועל במכונות A4 או A3 Ultra שלא רגישות להעברות בין NUMA או בין שקעים, אתם יכולים להתייחס לשני הממשקים כניתנים להחלפה.

כדי להגדיר את ההתנהגות הזו, מפעילים את הפרמטר fib_multipath_hash_policy sysctl ומוסיפים נתיב מרובה-נתיבים:

PRIMARY_GW=192.168.1.1  # Gateway of nic0
SECONDARY_GW=192.168.2.1  # Gateway of nic1
PRIMARY_IP=192.168.1.15  # Internal IP address for nic0
SECONDARY_IP=192.168.2.27  # Internal IP address for nic1

# Enable L4 5-tuple equal-cost multipath (ECMP) hashing
sysctl -w net.ipv4.fib_multipath_hash_policy=1
ip route add DESTINATION_NETWORK/SUBNET_MASK \
    nexthop via ${PRIMARY_GW} \
    nexthop via ${SECONDARY_GW}

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

• ‫DESTINATION_NETWORK: טווח כתובות ה-IP הפנימיות של היעד.
• ‫SUBNET_MASK: אורך הקידומת של תת-הרשת של רשת היעד.

פיצול התנועה בין רשתות שונות

דרישות:

• ‫nic0 ו-nic1 במכונה צריכים להתחבר לרשתות VPC ולרשתות משנה נפרדות, וכתובות ה-IP של היעד צריכות להיות מפוצלות בין שתי רשתות ה-VPC.

סקירה כללית ברמה גבוהה

כברירת מחדל, ליבת Linux יוצרת נתיבים לרשת המשנה nic0 ולרשת המשנה nic1, שמנתבים את התנועה לפי כתובת ה-IP של היעד דרך ממשק הרשת המתאים.

לדוגמה, נניח ש-nic0 משתמש ברשת ה-VPC‏ net1 עם רשת המשנה subnet-a, ו-nic1 משתמש ברשת ה-VPC‏ net2 עם רשת המשנה subnet-b. כברירת מחדל, תעבורת הנתונים לכתובות IP שכנות ב-subnet-a משתמשת ב-nic0, ותעבורת הנתונים לכתובות IP שכנות ב-subnet-b משתמשת ב-nic1. ההגדרה הזו רלוונטית בדרך כלל כשקבוצה של מכונות עם כרטיס רשת אחד מתחברת ל-net1 וקבוצה שנייה מתחברת ל-net2.

טיפ: אם מריצים שני מופעים של האפליקציה (אחד לכל רשת VPC), אפשר להשתמש בכלי numactl כדי להתאים את משאבי הזיכרון והמחשוב של כל אפליקציה ל-NUMA עם ממשק הרשת שלה, כדי לצמצם את ההעברות בין השקעים.

שימוש ב-SNAT כדי לבחור את ממשק המקור

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

דרישות:

• כדי להגדיר את הכללים הראשוניים של iptables, נדרשת היכולת CAP_NET_ADMIN, אבל לא כדי להפעיל את האפליקציה.
• נדרשת הערכה קפדנית כשמשלבים את הכלל הזה עם כללים אחרים או עם הגדרות ניתוב אחרות של iptables שאינם טריוויאליים.

הערה: כריכת NIC חלה רק כשנוצר חיבור. אם שרשור עובר למעבד (CPU) בצומת NUMA אחר, החיבור גורר קנסות חוצי-NUMA. כשמשתמשים בתבנית הזו, צריך לקשור את ה-threads לקבוצות ספציפיות של מעבדים. רק חיבורים יוצאים שמקורם במכונה מקושרים ל-NIC ספציפי. חיבורים נכנסים משתמשים ב-NIC שתואם לכתובת ה-IP של היעד שלהם.

סקירה כללית ברמה גבוהה

אם אתם לא יכולים להשתמש במרחבי שמות של רשתות או לשנות את האפליקציה, אתם יכולים להשתמש ב-SNAT כדי לבחור ממשק מקור. באמצעות כלי כמו iptables, אפשר לשכתב את כתובת ה-IP של המקור של תהליך, כך שתתאים לכתובת ה-IP של ממשק ספציפי על סמך מאפיין של האפליקציה השולחת, כמו cgroup, המשתמש או המעבד (CPU).

בדוגמה הבאה נעשה שימוש בכללים שמבוססים על מעבד (CPU), כך שכל זרימה שמקורה בשרשור במעבד נתון יוצאת דרך ממשק gVNIC או IDPF שמחובר לצומת NUMA של אותו מעבד:

# --- Begin Configuration ---
OUTPUT_INTERFACE_0="enp0s19"        # CHANGEME: NIC0
OUTPUT_INTERFACE_1="enp192s20"      # CHANGEME: NIC1

CPUS_0=($(seq 0 55; seq 112 167))   # CHANGEME: CPU IDs for NIC0
GATEWAY_0="10.0.0.1"                # CHANGEME: Gateway for NIC0
SNAT_IP_0="10.0.0.2"                # CHANGEME: SNAT IP for NIC0
CONNMARK_0="0x1"
RT_TABLE_0="100"

CPUS_1=($(seq 56 111; seq 168 223)) # CHANGEME: CPU IDs for NIC1
GATEWAY_1="10.0.1.1"                # CHANGEME: Gateway for NIC1
SNAT_IP_1="10.0.1.2"                # CHANGEME: SNAT IP for NIC1
CONNMARK_1="0x2"
RT_TABLE_1="101"
# --- End Configuration ---

# Specify which interface to use for packets in each routing table.
ip route add default via "$GATEWAY_0" dev "$OUTPUT_INTERFACE_0" table "$RT_TABLE_0"
ip route add default via "$GATEWAY_1" dev "$OUTPUT_INTERFACE_1" table "$RT_TABLE_1"

# Route replies to connections from peers through the matching egress interface.
# Add these rules before the fwmark rules so that fwmark takes precedence.
ip rule add from "$SNAT_IP_0" table "$RT_TABLE_0"
ip rule add from "$SNAT_IP_1" table "$RT_TABLE_1"

# Select the routing table based on the packet mark set in OUTPUT.
ip rule add fwmark "$CONNMARK_0" table "$RT_TABLE_0"
ip rule add fwmark "$CONNMARK_1" table "$RT_TABLE_1"

# Relax reverse path filtering so that the kernel doesn't drop legitimate
# replies to the SNAT IP addresses.
sysctl -w net.ipv4.conf."$OUTPUT_INTERFACE_0".rp_filter=2
sysctl -w net.ipv4.conf."$OUTPUT_INTERFACE_1".rp_filter=2

# Mark packets and connections with a per-NIC mark based on the source CPU.
# The fwmark rules then select the corresponding routing table for this traffic.
for cpu_id in "${CPUS_0[@]}"; do
    iptables -t mangle -A OUTPUT -m state --state NEW -m cpu --cpu "$cpu_id" -j CONNMARK --set-mark "$CONNMARK_0"
    iptables -t mangle -A OUTPUT -m state --state NEW -m cpu --cpu "$cpu_id" -j MARK --set-mark "$CONNMARK_0"
done
for cpu_id in "${CPUS_1[@]}"; do
    iptables -t mangle -A OUTPUT -m state --state NEW -m cpu --cpu "$cpu_id" -j CONNMARK --set-mark "$CONNMARK_1"
    iptables -t mangle -A OUTPUT -m state --state NEW -m cpu --cpu "$cpu_id" -j MARK --set-mark "$CONNMARK_1"
done

# Restore the connection mark for established connections so that packets use
# the same NIC regardless of other routing rules.
iptables -t mangle -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j CONNMARK --restore-mark

# Rewrite the source address after the packet is routed to the target interface
# so that replies return to the same NIC and pass VPC network validation.
iptables -t nat -A POSTROUTING -m mark --mark "$CONNMARK_0" -j SNAT --to-source "$SNAT_IP_0"
iptables -t nat -A POSTROUTING -m mark --mark "$CONNMARK_1" -j SNAT --to-source "$SNAT_IP_1"

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

• מידע ולמידה על סוגי מכונות של רישות ו-GPU
• שימוש ברוחב פס גדול יותר של הרשת במכונות GPU
• הגדרת כמה ממשקי רשת