שיטות מומלצות לשימוש ברשת

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

הגדרת תפקידים ברורים ומוגבלים ב-IAM

הגדרה נכונה של IAM עוזרת לשפר את האבטחה ואת ההצלחה של פריסות AI Hypercomputer. בסביבות ייצור, הרשאות לא מספיקות או הרשאות שהוגדרו בצורה שגויה עלולות להוביל לכשלים בפריסה. פריסות של AI Hypercomputer, במיוחד כאלה שמשתמשות ב- Cluster Toolkit, נכשלות לעיתים קרובות בסביבות עם אמצעי אבטחה מחמירים, שבהן לחשבון השירות שמשמש כברירת המחדל של Compute Engine אין את התפקיד Editor עם ההרשאות הרחבות.

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

שימוש בחשבונות שירות ייעודיים

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

אתם יכולים להשתמש ב-Workload Identity מנוהל כדי לאמת ולאשר עומסי עבודה במקום להשתמש באסימונים של חשבון שירות. מידע נוסף זמין במאמר אימות עומסי עבודה באמצעות mTLS ל-Compute Engine או במאמר Workload Identity ל-GKE.

הענקת תפקידי IAM נדרשים

מקצים לחשבון השירות הייעודי שיצרתם את תפקידי ה-IAM הבאים:

  • אדמין של Compute (roles/compute.admin): מאפשר שליטה מלאה במשאבי Compute Engine.
  • משתמש בחשבון השירות (roles/iam.serviceAccountUser): מאפשר לצרף את חשבון השירות למשאבים אחרים, וזה חשוב לכלים כמו Packer כשיוצרים תמונות בהתאמה אישית.
  • אדמין לניהול נפח האחסון (roles/storage.admin): נדרשת גישה לקטגוריות של Cloud Storage וניהול שלהן, למשל כדי לאחסן תמונות Packer או פריטים אחרים.
  • אדמין של Logging (roles/logging.admin): מאפשר לחשבון השירות להגדיר את הרישום ביומן ולצפות ביומנים, וזה חיוני לניפוי באגים.

אימות ההרשאות לפני הפריסה

לפני שמתחילים פריסה, צריך לוודא שלחשבון השירות יש את ההרשאות הנדרשות. מריצים את הפקודה gcloud projects get-iam-policy:

gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \ format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:SERVICE_ACCOUNT_EMAIL"

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

  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫SERVICE_ACCOUNT_EMAIL: כתובת האימייל של חשבון השירות שרוצים לאמת.

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

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

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

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

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

סטנדרטיזציה של ברירות המחדל של הרשת הפנימית

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

  • שימוש ב-DNS אזורי: בפרויקטים חדשים, מגדירים את מערכת שמות הדומיינים (DNS) הפנימית ל-DNS אזורי בלבד. הגישה הזו עוזרת לצמצם את ההשפעה של הפסקת שירות DNS גלובלית פוטנציאלית. מידע נוסף על השימוש ב-Zonal DNS זמין במאמר סקירה כללית על השימוש ב-Zonal DNS.
  • השבתה של כתובות IP חיצוניות: כשזה אפשרי, משביתים כתובות IP חיצוניות. לפני שמשביתים את כתובות ה-IP, צריך לתכנן ולבדוק בקפידה בסביבת פיתוח, כי שירותים מסוימים כמו קבוצות מנוהלות של מופעים (MIG) או אשכולות GKE עם צמתים ציבוריים מסתמכים עליהן. מידע נוסף על הגבלת כתובות IP ציבוריות זמין במאמר הגבלת כתובות IP ציבוריות ב-Google Cloud.

אופטימיזציה של הרשת לפי התשתית

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

שיטות מומלצות כלליות לשימוש ב-GPU

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

  • שימוש במדיניות מיקום קומפקטית: אם מופעים של GPU כללי לא מדווחים על מזהה physicalHost, אפשר להשתמש במדיניות מיקום קומפקטית כדי לזהות קבוצות של מופעים ולבצע אופטימיזציה של הביצועים של המשאבים האלה. מידע נוסף זמין במאמר בנושא הגדרת מיקום של מופע.
  • שימוש ב-Google Virtual NIC‏ (gVNIC) לתקשורת בין מארחים: כדי לקבל ביצועים עקביים, צריך להשתמש ב-TCP/IP רגיל דרך gVNIC לכל התקשורת בין המארחים. מידע נוסף על gVNIC זמין במאמר שימוש ב-Google Virtual NIC.
  • פשטו את התהליך באמצעות ארכיטקטורה של VPC יחיד: אלא אם דרישות הבידוד מחייבות אחרת, השתמשו ברשת VPC רגילה ויחידה לכל התקשורת. ההמלצה הזו לגבי VPC יחיד רלוונטית לסדרות G2, ‏ G4, ‏ A2 ו-N1. סדרת A3 Edge היא יוצאת דופן, ונדרשים בה ארבעה רשתות VPC של נתונים ו-GPUDirect-TCPX. מידע נוסף מופיע במאמר בנושא הגדלת רוחב הפס של רשת ה-GPU באשכולות במצב רגיל.

שיטות מומלצות לשימוש ב-GPU באשכול

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

  • הטמעה של סביבת multi-VPC: כדי לוודא שתעבורת הנתונים מ-GPU ל-GPU מבודדת ברשתות VPC ייעודיות עם רוחב פס גבוה, וכך למנוע תחרות על רוחב הפס בין תעבורת הנתונים של המארח או האחסון. מידע נוסף זמין במאמר בנושא סביבת Multi-VPC.
  • החלת פרופילי רשת שעברו אופטימיזציה ל-RDMA: שימוש בפרופילי רשת בניהול Google כדי להגדיר באופן אוטומטי את ה-VPC לזמן האחזור הנמוך שנדרש ל-RDMA over Converged Ethernet ‏ (RoCE). למידע נוסף, ראו פרופילים של רשתות לתרחישי שימוש ספציפיים.
  • הפחתת עומס של משימות תשתית: אפשר להשתמש בכרטיסי NIC מותאמים אישית של Titanium כדי להפחית עומס של משימות, כמו עיבוד של חבילות נתונים ברשת ו-וירטואליזציה לאחסון, וכך לשמור מחזורי מעבד (CPU) לאפליקציית ה-AI שלכם.

סיכום השיטות המומלצות

בטבלה הבאה מפורטות השיטות המומלצות שמופיעות במסמך הזה:

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

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