יצירת אשכול GKE שעבר אופטימיזציה ל-AI באמצעות Cluster Toolkit

במאמר הזה מוסבר איך ליצור אשכול Google Kubernetes Engine (GKE) שמותאם ל-AI ומשתמש במכונות Compute Engine מסוג A4X,‏ A4,‏ A3 Ultra,‏ A3 Mega ו-A3 High (8 GPUs) כדי לתמוך בעומסי העבודה של AI ו-ML.

סדרות המכונות A4X,‏ A4,‏ A3 Ultra,‏ A3 Mega ו-A3 High (עם 8 מעבדי GPU) מיועדות להרצת אשכולות AI/ML בקנה מידה גדול, עם תכונות כמו מיקום ממוקד של עומסי עבודה, אמצעי בקרה מתקדמים לתחזוקת אשכולות ותזמון מבוסס-טופולוגיה. מידע נוסף זמין במאמר סקירה כללית על ניהול אשכולות.

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

איך בוחרים את הדרך ליצור אשכול GKE שמותאם ל-AI

האפשרויות הבאות ליצירת אשכולות מספקות רמות שונות של קלות וגמישות בהגדרת האשכולות ובתזמון עומסי העבודה:

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

  • מפעילים את Google Kubernetes Engine API.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם כבר התקנתם את ה-CLI של gcloud, הריצו את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שבגרסאות קודמות של ה-CLI של gcloud אי אפשר להריץ את הפקודות שבמסמך הזה.
  • מוודאים שיש לכם את ההרשאות הנדרשות כדי ליצור ולנהל את אשכול ה-GKE ואת חשבונות השירות המשויכים:
    • אדמין ב-Kubernetes Engine‏ (roles/container.admin)
    • אדמין ב-Compute‏ (roles/compute.admin)
    • אדמין באחסון (roles/storage.admin)
    • אדמין IAM בפרויקט (roles/resourcemanager.projectIamAdmin)
    • אדמין בחשבון שירות (roles/iam.serviceAccountAdmin)
    • משתמש בחשבון שירות (roles/iam.serviceAccountUser)
    • Service Usage Consumer (roles/serviceusage.serviceUsageConsumer)
    • אדמין של תפקידים (roles/iam.roleAdmin)
    • ניהול גרסאות של סודות ב-Secret Manager ‏ (roles/secretmanager.secretVersionManager)
    • כדי להשתמש במקום שמור לפרויקט יחיד: Compute Instance Admin ‏ (v1) (roles/compute.instanceAdmin.v1) בפרויקט
    • כדי להשתמש במכונות שהוקצו במשותף: התפקיד "אדמין מכונות של Compute ‏ (v1)" (roles/compute.instanceAdmin.v1) בפרויקט הבעלים ובכל פרויקט צרכן שבו רוצים להשתמש במכונות שהוקצו.

בחירת אפשרות צריכה וקבלת קיבולת

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

  1. בוחרים אפשרות צריכה: בוחרים את האפשרות בהתאם לאופן שבו רוצים לקבל משאבי GPU ולהשתמש בהם. מידע נוסף זמין במאמר בחירת אפשרות צריכה.

    כשבוחרים אפשרות צריכה ב-GKE, כדאי להביא בחשבון את המידע הנוסף הבא:

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

דרישות

אלה הדרישות לאשכול GKE שעבר אופטימיזציה ל-AI:

  • ב-A4X Max, צריך להשתמש באחת מהגרסאות הבאות:

    • בגרסה 1.35 ואילך, צריך להשתמש בגרסת GKE‏ 1.35.0-gke.2745000 ואילך.
    • בגרסה 1.34, צריך להשתמש בגרסה ‎1.34.3-gke.1318000 או בגרסה חדשה יותר של GKE.

    הגרסאות האלה עוזרות לוודא ש-A4X Max משתמש ב:

    • ‫R580.95.05, הגרסה המינימלית של מנהל ההתקן של ה-GPU ל-A4X Max, שמופעלת כברירת מחדל.
    • ניהול זיכרון מבוסס-דרייבר קוהרנטי (CDMM), שמופעל כברירת מחדל. ‫NVIDIA ממליצה להפעיל את המצב הזה באשכולות Kubernetes כדי לפתור את הבעיה של דיווח יתר על הזיכרון. ‫CDMM מאפשר לנהל את הזיכרון של ה-GPU באמצעות מנהל ההתקן במקום מערכת ההפעלה (OS). הגישה הזו עוזרת להימנע מהעברת זיכרון ה-GPU למצב אונליין במערכת ההפעלה, וחושפת את זיכרון ה-GPU לצומת של גישה לא אחידה לזיכרון (NUMA) במערכת ההפעלה. אין תמיכה במעבדים גרפיים עם כמה מופעים במקביל כש-CDMM מופעל. מידע נוסף על CDMM זמין במאמר תמיכה בחומרה ובתוכנה.
    • ‫GPUDirect RDMA ו-MNNVL, שמומלץ להפעיל במאגרי צמתים של A4X Max כדי להשתמש ביכולות הרשת של A4X Max.

  • ב-A4X, צריך להשתמש באחת מהגרסאות הבאות:

    • בגרסה 1.33 ואילך, צריך להשתמש בגרסה ‎1.33.4-gke.1036000 ואילך של GKE.
    • בגרסה 1.32, צריך להשתמש בגרסה ‎1.32.8-gke.1108000 או בגרסה חדשה יותר של GKE.

    הגרסאות האלה עוזרות לוודא שב-A4X נעשה שימוש ב:

    • ‫R580, הגרסה המינימלית של מנהל ההתקן של ה-GPU ל-A4X, שמופעלת כברירת מחדל.
    • ניהול זיכרון מבוסס-דרייבר קוהרנטי (CDMM), שמופעל כברירת מחדל. ‫NVIDIA ממליצה להפעיל את המצב הזה באשכולות Kubernetes כדי לפתור את הבעיה של דיווח יתר על הזיכרון. ‫CDMM מאפשר לנהל את זיכרון ה-GPU באמצעות מנהל ההתקן במקום מערכת ההפעלה (OS). הגישה הזו עוזרת להימנע מהעברת זיכרון ה-GPU למצב אונליין במערכת ההפעלה, וחושפת את זיכרון ה-GPU לצומת של גישה לא אחידה לזיכרון (NUMA) במערכת ההפעלה. אין תמיכה במעבדים גרפיים עם כמה מופעים במקביל כש-CDMM מופעל. מידע נוסף על CDMM זמין במאמר תמיכה בחומרה ובתוכנה.
    • ‫GPUDirect RDMA ו-MNNVL, שמומלץ להפעיל במאגרי צמתים של A4X כדי להשתמש ביכולות הרשת של A4X.

  • חשוב לוודא שאתם משתמשים בגרסה המינימלית של מנהל ההתקן של ה-GPU, בהתאם לסוג המכונה:

    • ‫A4X Max: למעבדי ה-GPU מסוג GB300 במכונות Bare Metal מסוג A4X Max נדרשת גרסה R580.95.05 ומעלה של מנהל ההתקן של ה-GPU. כדאי לעיין בדרישות הגרסה שצוינו למעלה.
    • ‫A4X: למעבדי ה-GPU מסוג GB200 במכונות A4X נדרשת גרסה R580 ומעלה של מנהל ההתקן של ה-GPU. עיינו בדרישות הגרסה שצוינו קודם.
    • ‫A4: במכונות A4, למעבדי ה-GPU מדגם B200 נדרשת גרסה R570 ומעלה של מנהל ההתקן של ה-GPU. כברירת מחדל, GKE מתקין באופן אוטומטי את גרסת הדרייבר הזו בכל צומתי A4 שמריצים את גרסת המינימום הנדרשת ל-A4,‏ 1.32.1-gke.1729000 ואילך.
    • ‫A3 Ultra: למעבדי ה-GPU מדגם H200 במכונות A3 Ultra נדרשת גרסת מנהל התקן של GPU מ-R550 ומעלה, שזמינה ב-GKE בגרסה 1.31 כגרסת מנהל ההתקן latest. ב-A3 Ultra, צריך להגדיר את gpu-driver-version=latest עם GKE 1.31. ב-GKE מגרסה 1.31.5-gke.1169000 ואילך, GKE מתקין באופן אוטומטי כברירת מחדל את מנהלי ההתקנים של ה-GPU מגרסה R550 בצומתי A3 Ultra.
    • ‫A3 Mega ו-A3 High: מעבדי ה-GPU מסוג H100 במכונות A3 High ו-A3 Mega נתמכים על ידי גרסת ברירת המחדל של מנהל ההתקן של ה-GPU בכל הגרסאות הנתמכות של GKE. אפשר גם להגדיר את gpu-driver-version=latest כדי לגשת לדרייברים חדשים יותר של סביבת הייצור שזמינים בגרסאות נתמכות של GKE.

  • במאגרי צמתים של A3 Ultra, צריך להגדיר את סוג הדיסק בתור hyperdisk-balanced.

  • כדי להשתמש ב-GPUDirect RDMA, צריך להשתמש בגרסאות המינימליות הבאות, בהתאם לסוג המכונה:

    • ‫A4X Max: עיינו בדרישות הגרסה שצוינו למעלה.
    • ‫A4X: ראו את דרישות הגרסה שצוינו למעלה.
    • ‫A4: צריך להשתמש בגרסה 1.32.2-gke.1475000 ואילך.
    • ‫A3 Ultra: צריך להשתמש בגרסה ‎1.31.4-gke.1183000 ואילך.

  • כדי להשתמש ב-GPUDirect-TCPXO (ל-A3 Mega) וב-GPUDirect-TCPX (ל-A3 High), צריך להשתמש בגרסאות הבאות של GKE:

    • ‫A3 High: אפשר להשתמש בכל גרסה זמינה של GKE לפני 1.34.
    • ‫A3 Mega: אפשר להשתמש בכל גרסה זמינה של GKE.

  • כדי להשתמש ב-GPUDirect RDMA, הצמתים של GKE צריכים להשתמש בתמונת צומת של מערכת הפעלה שמותאמת לקונטיינרים. אין תמיכה בתמונות של צומתי Ubuntu ו-Windows.

  • כדי ליצור אשכולות עם A4X Max ו-A4X, צריך להשתמש במודל הקצאת המשאבים reservation-bound. אין תמיכה במודלים אחרים של הקצאת הרשאות.

יצירת אשכול באמצעות Cluster Toolkit

כדי ליצור אשכול באמצעות Cluster Toolkit, פועלים לפי ההוראות הבאות. בקטע הזה נסביר איך ליצור אשכול, כדי לוודא שהפרויקט פועל לפי השיטות המומלצות ועומד בדרישות של אשכול GKE שמותאם ל-AI. בקטע הזה מוסבר גם איך משתמשים ב-Terraform כדי להקצות ולנהל את התשתית לפריסה.

A4X Max

  1. מפעילים את Cloud Shell. אפשר להשתמש בסביבה אחרת, אבל מומלץ להשתמש ב-Cloud Shell כי יחסי התלות כבר מותקנים מראש ב-Cluster Toolkit. אם אתם לא רוצים להשתמש ב-Cloud Shell, אתם יכולים להכין סביבה אחרת לפי ההוראות להתקנת יחסי תלות.

  2. מתקינים את Cluster Toolkit.

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

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    מחליפים את המשתנים הבאים:

    • ‫BUCKET_NAME: השם של הקטגוריה החדשה ב-Cloud Storage, שצריך לעמוד בדרישות למתן שמות לקטגוריות.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION_TERRAFORM_STATE: אזור המחשוב שבו רוצים לאחסן את המצב של פריסת Terraform.

  4. ב-examples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml blueprint ממאגר GitHub, ממלאים את ההגדרות הבאות בקטעים terraform_backend_defaults ו-vars כך שיתאימו לערכים הספציפיים של הפריסה:

    • ‫BUCKET: השם של הקטגוריה ב-Cloud Storage שיצרתם בשלב הקודם.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי לפרויקט, יצירת האשכול תיכשל. ערך ברירת המחדל הוא gke-a4x-max-bm.
    • ‫REGION: אזור המחשוב של האשכול.
    • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A4X Max. האזור הזה חייב להתאים לאזור שבו המכונות זמינות בהזמנה שלכם.
    • ‫STATIC_NODE_COUNT: מספר הצמתים של A4X Max במאגר הצמתים של האשכול, שחייב להיות 18 צמתים או פחות. מומלץ להשתמש ב-18 צמתים כדי לקבל את טופולוגיית ה-GPU של 1x72 בבלוק משנה אחד באמצעות דומיין NVLink.
    • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שאתם רוצים לאפשר להן להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שמפעילה את Terraform. איך פועלות רשתות מורשות

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

    • כדי למקם את מאגר הצמתים בכל מקום בהזמנה, צריך לציין את שם ההזמנה (RESERVATION_NAME).

    • כדי לטרגט בלוק ספציפי בתוך ההזמנה, משתמשים בשמות של ההזמנה והבלוק בפורמט הבא:

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

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

    • ‫RESERVATION_PROJECT_ID: מזהה הפרויקט Google Cloudשבו נמצאת ההזמנה. יכול להיות שההזמנה נמצאת בפרויקט אחר, ולא בפרויקט PROJECT_ID.

    • ‫NUM_NODE_POOLS: מספר מאגרי הצמתים שרוצים להפעיל באשכול. אם אתם רוצים אשכול עם יותר מ-18 צמתים, אתם יכולים לציין כמה מאגרי צמתים. ערך ברירת המחדל הוא 1.

    כדי לשנות את ההגדרות המתקדמות, עורכים את קובץ ה-blueprint של examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml.

  5. יוצרים Application Default Credentials ‏ (ADC) כדי לספק גישה ל-Terraform. אם אתם משתמשים ב-Cloud Shell, השתמשו בפקודה gcloud auth application-default login:

    gcloud auth application-default login

  6. מריצים את הפקודה gcluster deploy כדי לפרוס את התוכנית ולהקצות את התשתית של GKE באמצעות סוגי המכונות A4X Max:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml \
    examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml

  7. כשמופיעה בקשה, בוחרים באפשרות (A)pply כדי לפרוס את התוכנית.

    • ה-blueprint יוצר רשתות VPC, רשת VPC של GPU RDMA, חשבונות שירות, אשכול ומאגר צמתים.
    • כדי לתמוך בתבנית של משימת fio-bench-job-template בתוכנית, נוצרים קטגוריות שלGoogle Cloud , אחסון ברשת ומשאבי נפח קבועים.

A4X

  1. מפעילים את Cloud Shell. אפשר להשתמש בסביבה אחרת, אבל מומלץ להשתמש ב-Cloud Shell כי יחסי התלות כבר מותקנים מראש ב-Cluster Toolkit. אם אתם לא רוצים להשתמש ב-Cloud Shell, אתם יכולים להכין סביבה אחרת לפי ההוראות להתקנת יחסי תלות.

  2. מתקינים את Cluster Toolkit.

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

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    מחליפים את המשתנים הבאים:

    • ‫BUCKET_NAME: השם של הקטגוריה החדשה ב-Cloud Storage, שצריך לעמוד בדרישות למתן שמות לקטגוריות.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION_TERRAFORM_STATE: אזור המחשוב שבו רוצים לאחסן את המצב של פריסת Terraform.

  4. ב-examples/gke-a4x/gke-a4x-deployment.yaml blueprint ממאגר GitHub, ממלאים את ההגדרות הבאות בקטעים terraform_backend_defaults ו-vars כך שיתאימו לערכים הספציפיים של הפריסה:

    • ‫BUCKET: השם של הקטגוריה ב-Cloud Storage שיצרתם בשלב הקודם.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי לפרויקט, יצירת האשכול תיכשל. ערך ברירת המחדל הוא gke-a4x.
    • ‫REGION: אזור המחשוב של האשכול.
    • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A4X. האזור הזה חייב להיות זהה לאזור שבו המכונות זמינות בהזמנה שלכם.
    • ‫STATIC_NODE_COUNT: מספר הצמתים של A4X במאגר הצמתים של האשכול, שחייב להיות 18 צמתים או פחות. מומלץ להשתמש ב-18 צמתים כדי לקבל את הטופולוגיה של ה-GPU של 1x72 בבלוק משנה אחד באמצעות דומיין NVLink.
    • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שאתם רוצים לאפשר להן להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שמפעילה את Terraform. איך פועלות רשתות מורשות

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

    • כדי למקם את מאגר הצמתים בכל מקום בהזמנה, צריך לציין את שם ההזמנה (RESERVATION_NAME).

    • כדי לטרגט בלוק ספציפי בתוך ההזמנה, משתמשים בשמות של ההזמנה והבלוק בפורמט הבא:

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

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

    • ‫RESERVATION_PROJECT_ID: מזהה הפרויקט Google Cloudשבו נמצאת ההזמנה. יכול להיות שההזמנה נמצאת בפרויקט אחר, ולא בפרויקט PROJECT_ID.

    • ‫NUM_NODE_POOLS: מספר מאגרי הצמתים שרוצים להפעיל באשכול. אם אתם רוצים אשכול עם יותר מ-18 צמתים, אתם יכולים לציין כמה מאגרי צמתים. ערך ברירת המחדל הוא 1.

    כדי לשנות את ההגדרות המתקדמות, עורכים את קובץ ה-blueprint של examples/gke-a4x/gke-a4x.yaml.

  5. יוצרים Application Default Credentials ‏ (ADC) כדי לספק גישה ל-Terraform. אם אתם משתמשים ב-Cloud Shell, השתמשו בפקודה gcloud auth application-default login:

    gcloud auth application-default login

  6. מריצים את הפקודה gcluster deploy כדי לפרוס את התוכנית ולהקצות את התשתית של GKE באמצעות סוגי המכונות של A4X:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4x/gke-a4x-deployment.yaml \
    examples/gke-a4x/gke-a4x.yaml

  7. כשמופיעה בקשה, בוחרים באפשרות (A)pply כדי לפרוס את התוכנית.

    • ה-blueprint יוצר רשתות VPC, רשת VPC של GPU RDMA, חשבונות שירות, אשכול ומאגר צמתים.
    • כדי לתמוך בתבנית של משימת fio-bench-job-template בתוכנית, נוצרים קטגוריות שלGoogle Cloud , אחסון ברשת ומשאבי נפח קבועים.

A4

  1. מפעילים את Cloud Shell. אפשר להשתמש בסביבה אחרת, אבל מומלץ להשתמש ב-Cloud Shell כי יחסי התלות כבר מותקנים מראש ב-Cluster Toolkit. אם אתם לא רוצים להשתמש ב-Cloud Shell, אתם יכולים להכין סביבה אחרת לפי ההוראות להתקנת יחסי תלות.

  2. מתקינים את Cluster Toolkit.

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

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    מחליפים את המשתנים הבאים:

    • ‫BUCKET_NAME: השם של הקטגוריה החדשה ב-Cloud Storage, שצריך לעמוד בדרישות למתן שמות לקטגוריות.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION_TERRAFORM_STATE: אזור המחשוב שבו רוצים לאחסן את המצב של פריסת Terraform.

  4. בוחרים אפשרות צריכה לפריסת GKE:

    כברירת מחדל, קובץ הפריסה מוגדר לצרוך הזמנות ספציפיות. כדי להשתמש במודל צריכה חלופי (כמו מכונות וירטואליות במודל Spot או מצב הקצאה flex-start), צריך לעדכן את קובץ ה-YAML של הפריסה. מידע נוסף זמין במאמר אפשרויות הצריכה של GKE.

  5. ב-examples/gke-a4/gke-a4-deployment.yaml blueprint ממאגר GitHub, ממלאים את ההגדרות הבאות בקטעים terraform_backend_defaults ו-vars כך שיתאימו לערכים הספציפיים של הפריסה:

    • ‫BUCKET: השם של הקטגוריה ב-Cloud Storage שיצרתם בשלב הקודם.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי לפרויקט, יצירת האשכול תיכשל. ערך ברירת המחדל הוא gke-a4.
    • ‫REGION: אזור המחשוב של האשכול.
    • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A4. האזור הזה חייב להיות זהה לאזור שבו המכונות זמינות בהזמנה שלכם.
    • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להן להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שמפעילה את Terraform. איך פועלות רשתות מורשות
    • בקטע של ההזמנה הספציפית, קובעים את ההגדרות הבאות:

    • בבלוק reservation_affinity, ברשימה specific_reservations, מציינים את השדה name של שמירת המקום:

      • כדי למקם את מאגר הצמתים בכל מקום בהזמנה, צריך לציין את שם ההזמנה (RESERVATION_NAME).
      • כדי לטרגט בלוק ספציפי בתוך ההזמנה, משתמשים בשמות של ההזמנה והבלוק בפורמט הבא:
      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

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

    • ‫STATIC_NODE_COUNT: מספר צומתי A4 באשכול.

    כדי לשנות את ההגדרות המתקדמות, עורכים את קובץ ה-blueprint של examples/gke-a4/gke-a4.yaml.

  6. יוצרים Application Default Credentials ‏ (ADC) כדי לספק גישה ל-Terraform. אם אתם משתמשים ב-Cloud Shell, השתמשו בפקודה gcloud auth application-default login:

    gcloud auth application-default login

  7. מריצים את הפקודה gcluster deploy כדי לפרוס את התוכנית ולהקצות את התשתית של GKE באמצעות מכונות מסוג A4:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4/gke-a4-deployment.yaml \
    examples/gke-a4/gke-a4.yaml

  8. כשמופיעה בקשה, בוחרים באפשרות (A)pply כדי לפרוס את התוכנית.

    • ה-blueprint יוצר רשתות VPC, רשת VPC של GPU RDMA, חשבונות שירות, אשכול ומאגר צמתים.
    • כדי לתמוך בתבנית של משימת fio-bench-job-template בתוכנית, נוצרים קטגוריות שלGoogle Cloud , אחסון ברשת ומשאבי נפח קבועים.

A3 Ultra

  1. מפעילים את Cloud Shell. אפשר להשתמש בסביבה אחרת, אבל מומלץ להשתמש ב-Cloud Shell כי יחסי התלות כבר מותקנים מראש ב-Cluster Toolkit. אם אתם לא רוצים להשתמש ב-Cloud Shell, אתם יכולים להכין סביבה אחרת לפי ההוראות להתקנת יחסי תלות.

  2. מתקינים את Cluster Toolkit.

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

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    מחליפים את המשתנים הבאים:

    • ‫BUCKET_NAME: השם של הקטגוריה החדשה ב-Cloud Storage, שצריך לעמוד בדרישות למתן שמות לקטגוריות.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION_TERRAFORM_STATE: אזור המחשוב שבו רוצים לאחסן את המצב של פריסת Terraform.

  4. בוחרים אפשרות צריכה לפריסת GKE:

    כברירת מחדל, קובץ הפריסה מוגדר לצרוך הזמנות ספציפיות. כדי להשתמש במודל צריכה חלופי (כמו מכונות וירטואליות במודל Spot או מצב הקצאה flex-start), צריך לעדכן את קובץ ה-YAML של הפריסה. מידע נוסף זמין במאמר אפשרויות הצריכה של GKE.

  5. בתוכנית examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml מהמאגר ב-GitHub, ממלאים את ההגדרות הבאות בקטעים terraform_backend_defaults ו-vars כך שיתאימו לערכים הספציפיים של הפריסה:

    • ‫BUCKET: השם של הקטגוריה ב-Cloud Storage שיצרתם בשלב הקודם.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי לפרויקט, יצירת האשכול תיכשל. ערך ברירת המחדל הוא gke-a3-ultragpu.
    • ‫REGION: אזור המחשוב של האשכול.
    • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A3 Ultra. האזור הזה חייב להיות זהה לאזור שבו המכונות זמינות בהזמנה שלכם.
    • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להן להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שמפעילה את Terraform. איך פועלות רשתות מורשות
    • בקטע של ההזמנה הספציפית, קובעים את ההגדרות הבאות:

    • בבלוק reservation_affinity, ברשימה specific_reservations, מציינים את השדה name של שמירת המקום:

      • כדי למקם את מאגר הצמתים בכל מקום בהזמנה, צריך לציין את שם ההזמנה (RESERVATION_NAME).
      • כדי לטרגט בלוק ספציפי בתוך ההזמנה, משתמשים בשמות של ההזמנה והבלוק בפורמט הבא:
      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

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

    • ‫STATIC_NODE_COUNT: מספר הצמתים של A3 Ultra באשכול.

    כדי לשנות את ההגדרות המתקדמות, עורכים את קובץ ה-blueprint של examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml.

  6. יוצרים Application Default Credentials ‏(ADC) כדי לספק גישה ל-Terraform. אם אתם משתמשים ב-Cloud Shell, השתמשו בפקודה gcloud auth application-default login:

    gcloud auth application-default login

  7. מריצים את הפקודה gcluster deploy כדי לפרוס את התוכנית ולהקצות את התשתית של GKE באמצעות סוגי מכונות A3 Ultra:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml \
    examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml

  8. כשמופיעה בקשה, בוחרים באפשרות (A)pply כדי לפרוס את התוכנית.

    • ה-blueprint יוצר רשתות VPC, רשת VPC של GPU RDMA, חשבונות שירות, אשכול ומאגר צמתים.
    • כדי לתמוך בתבנית של משימת fio-bench-job-template בתוכנית, נוצרים קטגוריות שלGoogle Cloud , אחסון ברשת ומשאבי נפח קבועים.

A3 Mega

  1. מפעילים את Cloud Shell. אפשר להשתמש בסביבה אחרת, אבל מומלץ להשתמש ב-Cloud Shell כי יחסי התלות כבר מותקנים מראש ב-Cluster Toolkit. אם אתם לא רוצים להשתמש ב-Cloud Shell, אתם יכולים להכין סביבה אחרת לפי ההוראות להתקנת יחסי תלות.

  2. מתקינים את Cluster Toolkit.

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

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    מחליפים את המשתנים הבאים:

    • ‫BUCKET_NAME: השם של הקטגוריה החדשה ב-Cloud Storage, שצריך לעמוד בדרישות למתן שמות לקטגוריות.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION_TERRAFORM_STATE: אזור המחשוב שבו רוצים לאחסן את המצב של פריסת Terraform.

  4. בתוכנית examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml מהמאגר ב-GitHub, מחליפים את המשתנים הבאים בקטעים terraform_backend_defaults ו-vars בערכים הספציפיים של הפריסה:

    • ‫BUCKET: השם של הקטגוריה ב-Cloud Storage שיצרתם בשלב הקודם.
    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי לפרויקט, יצירת האשכול תיכשל.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫REGION: אזור המחשוב של האשכול.
    • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A3 Mega. האזור הזה חייב להיות זהה לאזור שבו המכונות זמינות בהזמנה שלכם.
    • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להן להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שמפעילה את Terraform. איך פועלות רשתות מורשות כדי לקבל את כתובת ה-IP של המכונה המארחת, מריצים את הפקודה curl -s https://ifconfig.me.

  5. בוחרים אפשרות צריכה לפריסת GKE:

    כברירת מחדל, קובץ הפריסה מוגדר לצרוך מקומות שמורים רגילים או עתידיים. כדי להשתמש במודל צריכה חלופי (כמו קיבולת על פי דרישה, VM במודל Spot או מצב הקצאה בהתחלה גמישה), צריך לעדכן את קובץ ה-YAML של הפריסה. מידע נוסף זמין במאמר אפשרויות צריכה ב-GKE.

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

    • בבלוק reservation_affinity, ברשימה specific_reservations, מציינים את השדה name של ההזמנה:
    • כדי למקם את מאגר הצמתים בכל מקום בהזמנה, צריך לציין את שם ההזמנה (RESERVATION_NAME).

    • כדי לטרגט בלוק ספציפי בתוך ההזמנה, משתמשים בשמות של ההזמנה והבלוק בפורמט הבא:

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

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

    • ‫STATIC_NODE_COUNT: מספר הצמתים של A3 Mega באשכול.

    כדי לשנות הגדרות מתקדמות, עורכים את התוכנית examples/gke-a3-megagpu/gke-a3-megagpu.yaml מהמאגר ב-GitHub.

  6. יוצרים Application Default Credentials ‏(ADC) כדי לספק גישה ל-Terraform. אם אתם משתמשים ב-Cloud Shell, השתמשו בפקודה gcloud auth application-default login:

    gcloud auth application-default login

  7. משתמשים בפקודה gcluster deploy כדי לפרוס את התוכנית ולהקצות את התשתית של GKE באמצעות סוגי מכונות A3 Mega:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml \
    examples/gke-a3-megagpu/gke-a3-megagpu.yaml

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

A3 High

  1. מפעילים את Cloud Shell. אפשר להשתמש בסביבה אחרת, אבל מומלץ להשתמש ב-Cloud Shell כי יחסי התלות כבר מותקנים מראש ב-Cluster Toolkit. אם אתם לא רוצים להשתמש ב-Cloud Shell, אתם יכולים להכין סביבה אחרת לפי ההוראות להתקנת יחסי תלות.

  2. מתקינים את Cluster Toolkit.

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

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    מחליפים את המשתנים הבאים:

    • ‫BUCKET_NAME: השם של הקטגוריה החדשה ב-Cloud Storage, שצריך לעמוד בדרישות למתן שמות לקטגוריות.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION_TERRAFORM_STATE: אזור המחשוב שבו רוצים לאחסן את המצב של פריסת Terraform.

  4. בתוכנית examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml מהמאגר ב-GitHub, מחליפים את המשתנים הבאים בקטעים terraform_backend_defaults ו-vars בערכים הספציפיים של הפריסה:

    • ‫BUCKET: השם של הקטגוריה ב-Cloud Storage שיצרתם בשלב הקודם.
    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי לפרויקט, יצירת האשכול תיכשל.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫REGION: אזור המחשוב של האשכול.
    • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A3 High. האזור הזה חייב להיות זהה לאזור שבו המכונות זמינות בהזמנה שלכם.
    • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להן להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שמפעילה את Terraform. איך פועלות רשתות מורשות כדי לקבל את כתובת ה-IP של המכונה המארחת, מריצים את הפקודה curl -s https://ifconfig.me.

  5. בוחרים אפשרות צריכה לפריסת GKE:

    כברירת מחדל, קובץ הפריסה מוגדר לצרוך מקומות שמורים רגילים או עתידיים. כדי להשתמש במודל צריכה חלופי (כמו קיבולת על פי דרישה, VM במודל Spot או מצב הקצאה בהתחלה גמישה), צריך לעדכן את קובץ ה-YAML של הפריסה. מידע נוסף זמין במאמר אפשרויות הצריכה של GKE.

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

    • בבלוק reservation_affinity, ברשימה specific_reservations, מציינים את השדה name של ההזמנה:
    • כדי למקם את מאגר הצמתים בכל מקום בהזמנה, צריך לציין את שם ההזמנה (RESERVATION_NAME).

    • כדי לטרגט בלוק ספציפי בתוך ההזמנה, משתמשים בשמות של ההזמנה והבלוק בפורמט הבא:

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

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

    • ‫STATIC_NODE_COUNT: מספר הצמתים מסוג A3 High באשכול.

    כדי לשנות הגדרות מתקדמות, עורכים את תוכנית examples/gke-a3-highgpu/gke-a3-highgpu.yaml מהמאגר ב-GitHub.

  6. יוצרים Application Default Credentials ‏(ADC) כדי לספק גישה ל-Terraform. אם אתם משתמשים ב-Cloud Shell, השתמשו בפקודה gcloud auth application-default login:

    gcloud auth application-default login

  7. משתמשים בפקודה gcluster deploy כדי לפרוס את התוכנית ולהקצות את התשתית של GKE באמצעות סוגי המכונות A3 High:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml \
    examples/gke-a3-highgpu/gke-a3-highgpu.yaml

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

הרצת משימות לדוגמה של מתזמן משימות לפריסת workload דינמית (DWS)

אם הקציתם את האשכול באמצעות מתזמן משימות לפריסת workload דינמית (DWS) (התחלה גמישה או הקצאת משאבים בהמתנה), אתם יכולים לאמת את תזמון עומסי העבודה על ידי שליחת משימות לדוגמה ב-Kubernetes.

מידע נוסף על מצבי הקצאת המשאבים של מתזמן המשימות לפריסת workload דינמית זמין במאמר התחלה גמישה (Flex-start) של מתזמן המשימות לפריסת workload דינמית עם הקצאת משאבים בהמתנה.

שליחת משרה לדוגמה

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

התחלה גמישה (Flex-start)

המשימה הזו אופציונלית ורלוונטית רק אם הקציתם את האשכול עם התחלה גמישה (Flex-start). בעומסי עבודה שמוגדרים להתחלה גמישה, צריך להוסיף את בורר הצמתים cloud.google.com/gke-flex-start: "true" למפרט ה-Pod.

  1. שולחים את המשימה לדוגמה של התחלה גמישה:

    kubectl apply -f examples/dws-sample-workloads/sample-job-flex.yaml

  2. עוקבים אחרי הסטטוס של המשימה וה-Pods:

    kubectl get jobs
kubectl describe job JOB_NAME
kubectl get pods
kubectl describe pod POD_NAME

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

    • ‫JOB_NAME: שם המשימה.
    • ‫POD_NAME: שם ה-Pod.

  3. כשהמשימה מסתיימת, מוחקים את המשאבים שלה:

    kubectl delete -f examples/dws-sample-workloads/sample-job-flex.yaml

הקצאת משאבים בהמתנה

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

  • תווית: kueue.x-k8s.io/queue-name: dws-local-queue
  • הערה: provreq.kueue.x-k8s.io/maxRunDurationSeconds: "MAX_RUN_DURATION"

מידע נוסף זמין במאמר דרישות המניפסט של עומס העבודה להקצאת משאבים בהמתנה.

  1. שולחים את משימת הקצאת המשאבים בהמתנה לדוגמה:

    kubectl apply -f examples/dws-sample-workloads/sample-job-flex-queue.yaml

  2. עוקבים אחרי הסטטוס של המשימה וה-Pods:

    kubectl get jobs
kubectl describe job JOB_NAME
kubectl get pods
kubectl describe pod POD_NAME

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

    • ‫JOB_NAME: שם המשימה.
    • ‫POD_NAME: שם ה-Pod.

  3. כשהמשימה מסתיימת, מוחקים את המשאבים שלה:

    kubectl delete -f examples/dws-sample-workloads/sample-job-flex-queue.yaml

בדיקת ביצועי הרשת

מומלץ לאמת את הפונקציונליות של האשכולות שהוקצו. כדי לעשות את זה, משתמשים בבדיקות NCCL, שהן בדיקות של NVIDIA Collective Communications Library (NCCL)‎ שעברו אופטימיזציה לסביבה של Google.

הרצת בדיקות השוואה שניתן לשחזר

אחרי שיוצרים אשכול באמצעות Cluster Toolkit, אפשר לשחזר את נקודות ההשוואה (benchmark) שלפני האימון למודלים פתוחים גדולים של למידת מכונה בסדרת המכונות שבחרתם, לפי המתכונים שמופיעים ב-GitHub.

כל מתכון כולל הוראות לביצוע המשימות הבאות:

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

כדי לראות את כל המתכונים הזמינים לאימון ולסוגים אחרים של עומסי עבודה, עיינו במאגר מתכוני GPU ב-GitHub.

ניקוי המשאבים שנוצרו על ידי Cluster Toolkit

כדי להימנע מחיובים חוזרים על המשאבים שבהם השתמשתם בדף הזה, השתמשו בפקודה gcluster destroy כדי למחוק את המשאבים שהוקצו על ידי Cluster Toolkit, כולל רשתות ה-VPC ואשכול GKE:

   cd ~/cluster-toolkit
   ./gcluster destroy CLUSTER_NAME/

מחליפים את CLUSTER_NAME בשם של האשכול. באשכולות שנוצרו באמצעות Cluster Toolkit, שם האשכול מבוסס על השם של DEPLOYMENT_NAME.

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