אנו עוסקים כיום לא מעט בתחום ה-ML וה-AI, כמו בהרבה טכנולוגיות מתקדמות, טכנולוגיות אילו מבוססות על טכנולוגיה שמלווה אותנו הרבה שנים ומהווה תפקיד משמעותי בביצועי הטכנולוגיה/האפליקציה וחווית המשתמש. במאמר זה נדון על תפקיד הרשת בפתרונות AI וכיצד הן תורמות לתפקוד מיטבי של ה-AI.
חשוב להדגיש כי לא נרחיב על רשתות המשתמשות ב-AI על מנת לסייע בניטור הרשת ואיתור תקלות, אלא איך אנחנו כארכיטקטים ניגשים לפרויקט מסוג זה.

AI אינה טכנולוגיה חדשה ולמעשה כבר בשנות ה-50 השתמשו בטכנולוגיה זו בסביבה אקדמית לפתרון בעיות מאתגרות רבות, מה שהעצים את השימוש ב-AI היה למעשה היכולת לבצע Deep Learning (DL) ובכך הפכה הטכנולוגיה ליעילה יותר.
לפני השימוש ב-Machine Learning (ML) או DL, רוב אפליקציות ה-AI  היו מבוססות על אוסף חוקים סטטיים המגדירים שלבי ביצוע (if-then-else).
שיטה זו היתה פחות יעילה מאחר ונכתב ע״י האדם ואכן בשלב מאוחר יותר נמצאה בעיה בקוד.
ML וה-DP למעשה ייעלו את תהליך המשוב וכעת מחשבים בונים את החוקיות הנדרשת להגדלת היעילות.

ML מאפשר למחשב לייצר בצורה אוטומטית חוקים אשר יסייעו למחשב לפתור בעיות, החוקים נוצרים כאשר המחשב למד בצורה מספקת ומוכן לעבודה. תהליך הלמידה מתבצע באמצעות אלגוריתמים אשר יודעים “לקבל” הרבה מידע הקשור לפתרון הבעיה וכעבור זמן מה למערכת יש מספיק יידע בנושא.

דרישות מערכת ה-Machine Learning

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

Remote Direct Memory Access (RDMA) מאפשר למערכות AI/ML להחליף מידע על גבי הרשת ישירות מרכיב ה-RAM, ובכך אנחנו עוקפים את המעבד ומשיגים שיהוי נמוך יותר. טכנולוגיה זאת הוטמעה בעבר בעיקר ברשתות infiniband שמאוחר יותר שולבו ברשתות Ethernet באמצעות פרוטוקול RoCE (RDMA over converged Ethernet). ולכן עד לאחרונה הטכנולוגיה השלטת בתחום הייתה infiniband שספקה רוחב פס גבוה ושיהוי נמוך באמצעות Fabric מנוהל, אך עם השנים והתקדמות טכנולוגית Ethernet הפכה להיות חלופה יעילה יותר וזולה יותר לעומת Infiniband.

רשת אחודה לכלל ה-Workloads

עם עליית רוחב הפס לקצב 400/800G, אנו יכולים לשנות את הארכיטקטורה – עבור כל workload ניתן לבנות סביבה ייעודית בהתאם לדרישות workload, לדוגמא AI/ML נשתמש ב- infiniband של 200/400G ו-HPC או סביבת DC על בסיס 100G.

עם המעבר לרשתות המבוססות 400/800G נוכל לאחד את כל ה-workloads לרשת אחודה שתתן מענה לכל הדרישות.

• התקשורת בין השרתים/מערגות השונות תהיה non-blocking, Lossless ועם ה-Buffer המתאים.
• השיהוי יהיה נמוך ככל הניתן.
• הרשת תשתמש ב- equal cost multipath protocol (ECMP)לתקשורת בין המתגים.
• נראות היא שם המשחק – צוות התפעול צריך לדעת בהקדם על כל בעיה ברשת.

איך נתמודד עם עומסים (גודש) ברשתות ?ML/AI

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

• רוחב פס גבוה
• שיהוי נמוך
• ניהול יעיל של ה-buffer
• גמישות ב-QOS
• טלמטריה להבנת סטטוס הרשת

לאחר בחירת המתג המתאים נתכנן את הרשת בארכיטקטורת CLOS, אשר יעילה מאוד לאפליקציות AI/ML ו-microservices. יתרונות ארכיטקטורת CLOS בכך שמספקת שיהוי נמוך וידוע, יכולת גדילה פשוטה (Scale out) ויתירות מובנית. 

ובכל זאת , יש לנו גודש ברשת – האם RoCEv2 יודע להתמודד עם זה? ואם כן כיצד?

RoCEv2 עוטף את המידע ב- IP/UDP packet, ל-UDP  אין מנגנון מובנה להתמודדות עם גודש ולכן RoCEv2 משתמש ב- Data canter Quantized Congestion Notification (DCQCN)אשר מושתת על 2 טכניקות, ENC ו-PFC.

• Explicit Congestion Notification- משתמש במנגנון ה-QoS על מנת להתריע כאשר ה-buffer עובר סף מסוים.
• Priority Flow Control -מאפשר לנו להגדיר תור שלא “זורק” packet כאשר תור מסוים מתמלא.

באמצעות שתי הטכנולוגיות הללו אנחנו משיגים רשת Ethernet שמאפשרת רשת RDMA lossless.

אתגר נוסף שנתקל בו הינו, תעבורה שאינה אופטימלית לדוגמא, מנגנון ה-QoS אינו מודע לרוחב הפס הנדרש  ע”י כל Flow וכך יכול להיווצר מצב שבו Flow מסוים יצרוך רוחב פס גדול מידי וייפגע בביצועים של שאר ה- flows. לכן אנו משתמשים בתכונה של Approximate Fair Drop (AFD)  אשר מסווג את התעבורה ל:

• Elephant flows זרם ארוך וכבד אשר יתויג באמצעות ה-AFD והסיכוי שתעבורה זו “תזרק” יגדל.
• Mice Flows זרם קצר וקל אשר יתויג באמצעות ה-AFD והסיכוי תעבורה זו “תזרק” יקטן.

למידע כיצד ניתן להגדיר RoCEv2 במתגי Nexus NX-OS VXLAN RoCE Implementation

ניטור

על אף שמנגנון ה-DCQCN, מאפשר התמודדות טובה במקרה של גודש ברשת, עדיין נדרש לנטר את הסביבה על מנת

• האם יש קישורים בהם הגודש\עומס קורה לעיתים תכופות
• האם ניתן לבצע התאמות ב-QoS שעלו ממערכות הניטור

ה-ASICs במתגי הנקסוס מאפשר הזרמה של המידע הנ”ל מערכת ה-Nexus Dashboard Insights, והוא ידע לאסוף ולהציג את המידע לאנשי התפעול.

לסיכום

רשתות AI/ML צוברות תאוצה רבה ולכן תכנון מתאים ימנע בעיות בהמשך. רשתות Ethernet אחודות נותנות מענה מעולה כאשר תואמות את דרישות האפליקציה:

• Lossless
• שיהוי נמוך
• Non blocking
• תמיכה ב- DCQCN (WRED w/ECN +PFC)

נעטוף את הדרישות במערכת ניהול מרכזית או רשת SDN אשר תסייע לנו בתהליך ההקמה (Day-0) ועד הניטור (Day-2), נקבל סביבת ML/AI יעילה, מודרנית, מתקדמת וזולה ביחס לפתרונות הקיימים היום בשוק.

מתגי סיסקו מסדרת ה-Nexus 9000 מכילים את כל התכנות הללו ועוד, וכאשר מחברים אותם ביחד עם פתרון הניהול Nexus Dashboard Fabric Controller (NDFC) ו- Nexus Dashboard Insight(NDI) מקבלים פתרון אשר מספר ללקוח מענה משלב ההקמה דרך התפעול ועד שלב הניטור.

למידע נוסף: Cisco Data Center Networking Blueprint for AI/ML