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

במאמר הזה מוסבר איך ליצור אשכול Google Kubernetes Engine ‏ (GKE) שעבר אופטימיזציה ל-AI, שמשתמש במכונות וירטואליות של Compute Engine מסוג A4X, ‏ A4, ‏ A3 Ultra, ‏ A3 Mega ו-A3 High (עם 8 יחידות GPU) כדי לתמוך בעומסי עבודה של 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
  • אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-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 Secret Version Manager (roles/secretmanager.secretVersionManager)

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

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

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

  2. קבלת קיבולת. תהליך קבלת הקיבולת שונה בכל אפשרות צריכה.

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

דרישות

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

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

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

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

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

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

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

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

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

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

    • ‫A4X Max: כדי להשתמש במכונות Bare Metal מסוג A4X Max עם כרטיסי GPU מסוג GB300, צריך לפחות את גרסת מנהל ההתקן של GPU‏ R580.95.05. אפשר לעיין בדרישות הגרסה שצוינו קודם.
    • ‫A4X: מעבדי ה-GPU מסוג GB200 במכונות וירטואליות (VM) מסוג A4X דורשים גרסה מינימלית של מנהל ההתקן של GPU מסוג R580. צריך לעיין בדרישות לגבי הגרסה שצוינו קודם.
    • ‫A4: מעבדי ה-GPU מסוג B200 במכונות וירטואליות מסוג A4 דורשים גרסה מינימלית של מנהל ההתקן של GPU מסוג R570. כברירת מחדל, 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, צריך להשתמש במודל הקצאת משאבים שמוגבל להזמנה. אין תמיכה במודלים אחרים של הקצאת הרשאות.

יצירת אשכול

כדי ליצור אשכול באמצעות Cluster Toolkit או XPK, פועלים לפי ההוראות הבאות.

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

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

A4X Max

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

  2. משכפלים את Cluster Toolkit ממאגר ה-Git:

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. מתקינים את Cluster Toolkit:

    cd cluster-toolkit && git checkout main && make

  4. יוצרים קטגוריה של 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: האזור של Compute שבו רוצים לאחסן את המצב של פריסת Terraform.

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

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

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

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

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

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

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

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

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

    gcloud auth application-default login

  7. פורסים את תוכנית ה-Blueprint כדי להקצות את התשתית של 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

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

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

A4X

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

  2. משכפלים את Cluster Toolkit ממאגר ה-Git:

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. מתקינים את Cluster Toolkit:

    cd cluster-toolkit && git checkout main && make

  4. יוצרים קטגוריה של 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: האזור של Compute שבו רוצים לאחסן את המצב של פריסת Terraform.

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

    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת. ערך ברירת המחדל הוא gke-a4x.
    • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION: אזור המחשוב של האשכול.
    • ‫COMPUTE_ZONE: אזור המחשוב של מאגר הצמתים של מכונות A4X. חשוב לזכור שאזור הזמן הזה צריך להיות זהה לאזור הזמן שבו המכונות זמינות בהזמנה.
    • ‫NODE_COUNT: מספר צמתי A4X במאגר הצמתים של האשכול, שחייב להיות 18 צמתים או פחות. מומלץ להשתמש ב-18 צמתים כדי לקבל את טופולוגיית ה-GPU של 1x72 בתת-בלוק אחד באמצעות דומיין NVLink.
    • ‫IP_ADDRESS/SUFFIX: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה צריך לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להתקשר אל Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.

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

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

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

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

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

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

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

    gcloud auth application-default login

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

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

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

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

A4

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

  2. משכפלים את Cluster Toolkit ממאגר ה-Git:

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. מתקינים את Cluster Toolkit:

    cd cluster-toolkit && git checkout main && make

  4. יוצרים קטגוריה של 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: האזור של Compute שבו רוצים לאחסן את המצב של פריסת Terraform.

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

    הזמנה בלבד

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

    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת. ערך ברירת המחדל הוא gke-a4.
    • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION: אזור המחשוב של האשכול.
    • ‫COMPUTE_ZONE: אזור המחשוב של מאגר הצמתים של מכונות A4. חשוב לזכור שאזור הזמן הזה צריך להיות זהה לאזור הזמן שבו המכונות זמינות בהזמנה.
    • ‫NODE_COUNT: מספר הצמתים מסוג A4 באשכול.
    • ‫IP_ADDRESS/SUFFIX: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה צריך לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.

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

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

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

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

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

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

    Flex-start

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

      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בתוך פרויקט, יצירת האשכול נכשלת. ערך ברירת המחדל הוא gke-a4.
      • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫COMPUTE_REGION: אזור המחשוב של האשכול.
      • ‫COMPUTE_ZONE: אזור המחשוב של מאגר הצמתים של מכונות A4.
      • הסרה של static_node_count.
      • ‫IP_ADDRESS/SUFFIX: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך פועלות רשתות מורשות.
      • מסירים את השדה reservation ומחליפים אותו בשדה enable_flex_start: true. מוסיפים בשורה הבאה enable_queued_provisioning: true אם רוצים להשתמש גם בהקצאת הרשאות בתור. מידע נוסף זמין במאמר בנושא שימוש במאגרי צמתים עם flex-start עם הקצאת משאבים בתור.

    2. בתוכנית הבסיסית examples/gke-a4/gke-a4.yaml ממאגר GitHub, מבצעים את השינויים הבאים:

      • בבלוק vars, מסירים את static_node_count.
      • בבלוק vars, מוודאים שהמספר version_prefix הוא "1.32." ומעלה. כדי להשתמש בהפעלה גמישה ב-GKE, האשכול צריך להיות מגרסה 1.32.2-gke.1652000 ואילך.
      • בבלוק vars, מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-enable_flex_start: true, ואם רוצים, ב-enable_queued_provisioning: true.
      • בבלוק vars, אם לא נדרשת הקצאת משאבים בתור, מסירים את השורה הבאה: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • בקטע id: a4-pool, מסירים את השורה הבאה: static_node_count: $(vars.static_node_count).

      • בקטע id: a4-pool, מסירים את החסימה של reservation_affinity. מחליפים את הבלוק הזה בשורות הבאות:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • אם רוצים להפעיל הקצאת הרשאות בתור, מוסיפים את השורות הנוספות הבאות:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • בקטע id: workload-manager-install, מסירים את הבלוק הבא:

         kueue:
    install: true
    config_path: $(vars.kueue_configuration_path)
    config_template_vars:
       num_gpus: $(a3-ultragpu-pool.static_gpu_count)
       accelerator_type: $(vars.accelerator_type)

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

          1. מוסיפים את gpu_nominal_quota: NOMINAL_QUOTA לבלוק vars. הערך gpu_nominal_quota משמש להגדרת nominalQuota של המעבדים הגרפיים במפרט ClusterQueue (בשלב הבא מוסבר איך מגדירים את ClusterQueue). בדוגמה הזו, ClusterQueue מאפשר עומסי עבודה רק אם סכום הבקשות למעבדים הגרפיים קטן מהערך NOMINAL_QUOTA או שווה לו. מידע נוסף על ClusterQueue זמין במסמך Kueue בנושא תור אשכול.

          2. מעדכנים את הבלוק kueue כך:

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. מחליפים את התוכן של הקובץ kueue-configuration.yaml.tftpl בתוכן הבא:

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

      • בקטע id: job-template, מחליפים את המשתנה node_count ב-2.

    כרטיס Spot

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

      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בתוך פרויקט, יצירת האשכול נכשלת. ערך ברירת המחדל הוא gke-a4.
      • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫COMPUTE_REGION: אזור המחשוב של האשכול.
      • ‫COMPUTE_ZONE: אזור המחשוב של מאגר הצמתים של מכונות A4.
      • ‫STATIC_NODE_COUNT: מספר הצמתים מסוג A4 באשכול.
      • ‫IP_ADDRESS/SUFFIX: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך פועלות רשתות מורשות.
      • מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-spot: true.

    2. בתוכנית הבסיסית examples/gke-a4/gke-a4.yaml ממאגר GitHub, מבצעים את השינויים הבאים:

      • בבלוק vars, מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-spot: true.

      • בקטע id: a4-pool, מסירים את החסימה של reservation_affinity. מחליפים את הבלוק הזה בשורה הבאה:

        • spot: $(vars.spot)

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

    gcloud auth application-default login

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

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

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

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

A3 Ultra

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

  2. משכפלים את Cluster Toolkit ממאגר ה-Git:

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. מתקינים את Cluster Toolkit:

    cd cluster-toolkit && git checkout main && make

  4. יוצרים קטגוריה של 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: האזור של Compute שבו רוצים לאחסן את המצב של פריסת Terraform.

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

    הזמנה בלבד

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

    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת.
    • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION: אזור המחשוב של האשכול.
    • ‫COMPUTE_ZONE: אזור החישוב של מאגר הצמתים של מכונות A3 Ultra. חשוב לזכור שאזור הזמן הזה צריך להיות זהה לאזור הזמן שבו המכונות זמינות בהזמנה.
    • ‫NODE_COUNT: מספר הצמתים של A3 Ultra באשכול.
    • ‫IP_ADDRESS/SUFFIX: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה צריך לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.

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

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

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

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

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

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

    Flex-start

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

      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בתוך פרויקט, יצירת האשכול נכשלת.
      • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫COMPUTE_REGION: אזור המחשוב של האשכול.
      • ‫COMPUTE_ZONE: אזור החישוב של מאגר הצמתים של מכונות A3 Ultra.
      • הסרה של static_node_count.
      • ‫IP_ADDRESS/SUFFIX: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.
      • מסירים את השדה reservation ומחליפים אותו בשדה enable_flex_start: true. מוסיפים בשורה הבאה enable_queued_provisioning: true אם רוצים להשתמש גם בהקצאת הרשאות בתור. מידע נוסף זמין במאמר בנושא שימוש במאגרי צמתים עם flex-start עם הקצאת משאבים בתור.

    2. ב-examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml תוכנית האב ממאגר GitHub, מבצעים את השינויים הבאים:

      • בבלוק vars, מסירים את static_node_count.
      • בבלוק vars, מעדכנים את המספר version_prefix ל-"1.32." ומעלה. כדי להשתמש בהפעלה גמישה ב-GKE, האשכול צריך להיות מגרסה 1.32.2-gke.1652000 ואילך.
      • בבלוק vars, מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-enable_flex_start: true, ואם רוצים, ב-enable_queued_provisioning: true.
      • בבלוק vars, מסירים את השורה הבאה: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • בקטע id: a3-ultragpu-pool, מסירים את השורה הבאה: static_node_count: $(vars.static_node_count).

      • בקטע id: a3-ultragpu-pool, מסירים את החסימה של reservation_affinity. מחליפים את הבלוק הזה בשורות הבאות:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • אם רוצים להפעיל הקצאת הרשאות בתור, מוסיפים את השורות הנוספות הבאות:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • בקטע id: workload-manager-install, מסירים את הבלוק הבא:

        config_path: $(vars.kueue_configuration_path)
config_template_vars:
  num_gpus: $(a4-pool.static_gpu_count)
  accelerator_type: $(vars.accelerator_type)

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

          1. מוסיפים את gpu_nominal_quota: NOMINAL_QUOTA לבלוק vars. הערך gpu_nominal_quota משמש להגדרת nominalQuota של מעבדים גרפיים במפרט ClusterQueue. בדוגמה הזו, ClusterQueue מאפשר רק לעומסי עבודה להיכנס אם סכום בקשות ה-GPU קטן מהערך NOMINAL_QUOTA או שווה לו. מידע נוסף על ClusterQueue זמין במסמך Kueue בנושא תור אשכול.

          2. מעדכנים את הבלוק kueue כך:

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. מחליפים את התוכן של הקובץ kueue-configuration.yaml.tftpl בתוכן הבא:

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

        • בשדה id: job-template, מחליפים את המשתנה node_count ב-2.

    כרטיס Spot

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

      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בתוך פרויקט, יצירת האשכול נכשלת.
      • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫COMPUTE_REGION: אזור המחשוב של האשכול.
      • ‫COMPUTE_ZONE: אזור החישוב של מאגר הצמתים של מכונות A3 Ultra.
      • ‫STATIC_NODE_COUNT: מספר הצמתים של A3 Ultra באשכול.
      • ‫IP_ADDRESS/SUFFIX: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך פועלות רשתות מורשות.
      • מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-spot: true.

    2. בתוכנית הבסיסית examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml ממאגר GitHub, מבצעים את השינויים הבאים:

      • בבלוק vars, מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-spot: true.

      • בקטע id: a3-ultragpu-pool, מסירים את החסימה של reservation_affinity. מחליפים את הבלוק הזה בשורה הבאה:

        • spot: $(vars.spot)

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

    gcloud auth application-default login

  7. פורסים את תוכנית ה-blueprint כדי להקצות את התשתית של 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 (החלה) כדי לפרוס את התוכנית.

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

A3 Mega

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

  2. משכפלים את Cluster Toolkit ממאגר Git:

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. מתקינים את Cluster Toolkit:

    cd cluster-toolkit && git checkout main && make

  4. יוצרים קטגוריה של 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: האזור של Compute שבו רוצים לאחסן את המצב של פריסת Terraform.

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

    הזמנה בלבד

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

    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת.
    • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION: אזור המחשוב של האשכול.
    • ‫COMPUTE_ZONE: אזור המחשוב של מאגר הצמתים של מכונות A3 Mega. שימו לב שאזור הזמינות הזה צריך להיות זהה לאזור הזמינות שבו המכונות זמינות בהזמנה שלכם.
    • ‫NODE_COUNT: מספר הצמתים מסוג A3 Mega באשכול.
    • ‫IP_ADDRESS/SUFFIX: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה צריך לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.

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

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

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

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

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

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

    Flex-start

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

      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בתוך פרויקט, יצירת האשכול נכשלת.
      • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫COMPUTE_REGION: אזור המחשוב של האשכול.
      • ‫COMPUTE_ZONE: אזור המחשוב של מאגר הצמתים של מכונות A3 Mega.
      • הסרה של static_node_count.
      • ‫IP_ADDRESS/SUFFIX: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.
      • מסירים את השדה reservation ומחליפים אותו בשדה enable_flex_start: true. אם רוצים להשתמש גם בהקצאת הרשאות בתור, מוסיפים את enable_queued_provisioning: true לשורה הבאה. מידע נוסף זמין במאמר בנושא שימוש במאגרי צמתים עם flex-start עם הקצאת משאבים בתור.

    2. בתוכנית הבסיסית examples/gke-a3-megagpu/gke-a3-megagpu.yaml ממאגר GitHub, מבצעים את השינויים הבאים:

      • בבלוק vars, מסירים את static_node_count.
      • בבלוק vars, מעדכנים את המספר version_prefix ל-"1.32." ומעלה. כדי להשתמש בהפעלה גמישה ב-GKE, האשכול צריך להיות מגרסה 1.32.2-gke.1652000 ואילך.
      • בבלוק vars, מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-enable_flex_start: true, ואם רוצים, ב-enable_queued_provisioning: true.
      • בבלוק vars, מסירים את השורה הבאה: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • בקטע id: a3_megagpu_pool, מסירים את השורה הבאה: static_node_count: $(vars.static_node_count).

      • בקטע id: a3_megagpu_pool, מסירים את החסימה של reservation_affinity. מחליפים את הבלוק הזה בשורות הבאות:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • אם רוצים להפעיל הקצאת הרשאות בתור, מוסיפים את השורות הנוספות הבאות:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • בקטע id: workload_manager_install, מסירים את הבלוק הבא:

        config_path: $(vars.kueue_configuration_path)
config_template_vars:
  num_gpus: $(a3_megagpu_pool.static_gpu_count)
  accelerator_type: $(vars.accelerator_type)

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

          1. מוסיפים את gpu_nominal_quota: NOMINAL_QUOTA לבלוק vars. הערך gpu_nominal_quota משמש להגדרת nominalQuota של מעבדים גרפיים במפרט ClusterQueue. בדוגמה הזו, ClusterQueue מאפשר רק לעומסי עבודה להיכנס אם סכום בקשות ה-GPU קטן מהערך NOMINAL_QUOTA או שווה לו. מידע נוסף על ClusterQueue זמין במסמך Kueue בנושא תור אשכול.

          2. מעדכנים את הבלוק kueue כך:

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. מחליפים את התוכן של הקובץ kueue-configuration.yaml.tftpl בתוכן הבא:

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

        • בשדה id: job-template, הערך של המשתנה node_count עם 2.

    כרטיס Spot

    1. בexamples/gke-a3-megagpu/gke-a3-megagpu-deployment.yamlתוכנית הבסיס ממאגר GitHub, ממלאים את ההגדרות הבאות בקטעים vars בהתאם לערכים הספציפיים של הפריסה:
      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בתוך פרויקט, יצירת האשכול נכשלת.
      • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫COMPUTE_REGION: אזור המחשוב של האשכול.
      • ‫COMPUTE_ZONE: אזור המחשוב של מאגר הצמתים של מכונות A3 Mega.
      • ‫STATIC_NODE_COUNT: מספר צמתי A3 Mega באשכול.
      • ‫IP_ADDRESS/SUFFIX: כתובת ה-IP
      • ‫IP_ADDRESS/SUFFIX: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך פועלות רשתות מורשות.
      • מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-provisioning_model: SPOT.

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

      • בבלוק vars, מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-spot: true.

      • בקטע id: a3_megagpu_pool, מסירים את החסימה של reservation_affinity. מחליפים את הבלוק הזה בשורה הבאה:

        • spot: $(vars.spot)

  6. אופציונלי: אפשר להפעיל את Cluster Health Scanner (CHS) באשכול. CHS בודק את תקינות אשכולות ה-GPU על ידי הרצת בדיקות כדי לוודא שהאשכולות מוכנים להרצת עומסי העבודה. כדי להפעיל את CHS, מבצעים את השינויים הבאים בקובץ examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml:

    • בבלוק vars, מגדירים את השדה enable_periodic_health_checks לערך true.

    • כברירת מחדל, בדיקות תקינות מופעלות בכל יום ראשון בשעה 00:00 (שעון החוף המערבי). כדי לשנות את ההגדרה הזו, בבלוק vars, מגדירים את השדה health_check_schedule לערך מתאים בפורמט cron.
      קביעת לוח זמנים בפורמט cron: none * * * * * # | | | | | # | | | | day of the week (0-6) (Sunday to Saturday) # | | | month (1-12) # | | day of the month (1-31) # | hour (0-23) # minute (0-59)

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

    gcloud auth application-default login

  8. פורסים את תוכנית ה-Blueprint כדי להקצות את התשתית של 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

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

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

יצירת אשכול והרצת עומסי עבודה באמצעות XPK

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

יצירת אשכול והרצת עומסי עבודה עם מכונות וירטואליות מסוג A3 Ultra באמצעות XPK:

  1. מתקינים את הכלים הנדרשים כדי לעמוד בדרישות המוקדמות של XPK.
  2. מעתיקים את מספר הגרסה של הגרסה האחרונה עם התג של XPK, למשל, v0.8.0. בפקודה הבאה, מחליפים את XPK_TAG במספר הגרסה העדכנית של XPK.

  3. פותחים חלון של Shell במחשב Linux ומזינים את הפקודות הבאות כדי לשכפל את XPK ממאגר Git ולהתקין את החבילות הנדרשות:

      ## Setup virtual environment.
  VENV_DIR=~/venvp3
  python3 -m venv $VENV_DIR
  source $VENV_DIR/bin/activate
  ## Clone the repository.
  git clone --branch XPK_TAG https://github.com/google/xpk.git
  cd xpk
  ## Install required packages
  make install && export PATH=$PATH:$PWD/bin

  4. יצירת אשכול רגיל באמצעות מכונות וירטואליות מסוג A3 Ultra,‏ A3 Mega או A3 High. אפשר להקצות את הצמתים של האשכול באמצעות קיבולת שמורה:

      python3 xpk.py cluster create \
     --cluster=CLUSTER_NAME \
     --device-type=DEVICE_TYPE \
     --zone=COMPUTE_ZONE  \
     --project=PROJECT_ID \
     --num-nodes=NUM_NODES \
     --reservation=RESERVATION_NAME

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

    • ‫CLUSTER_NAME: שם לאשכול.
    • ‫DEVICE_TYPE: סוג המכשיר שבו רוצים להשתמש.
      • ל-A3 Ultra, משתמשים ב- h200-141gb-8
      • ב-A3 Mega, משתמשים ב-h100-mega-80gb-8
      • ל-A3 High, משתמשים ב-h100-80gb-8
    • ‫COMPUTE_ZONE: אזור החישוב של מאגר הצמתים של מכונות A3 Ultra. כדי להשתמש בקיבולת השמורה, צריך לוודא שאתם משתמשים באזור שבו שריינתם את הקיבולת. בדרך כלל מומלץ לבחור אזור שקרוב למשתמש כדי לצמצם את זמן האחזור.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫NUM_NODES: מספר צמתי העובדים במאגר הצמתים.

    • ‫RESERVATION_NAME: השם של ההזמנה.

      ‫XPK מציע ארגומנטים נוספים ליצירת אשכולות, כולל ארגומנטים ליצירת אשכולות פרטיים, ליצירת Vertex AI Tensorboards ולשימוש בהקצאת משאבים אוטומטית של צמתים. מידע נוסף זמין במדריך יצירת אשכול ל-XPK.

  5. מוודאים שהאשכול נוצר בהצלחה:

      python3 xpk.py cluster list --zone=COMPUTE_ZONE --project=PROJECT_ID

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

      python3 xpk.py workload create \
     --workload WORKLOAD_NAME --command "echo goodbye" \
     --cluster CLUSTER_NAME \
     --device-type=DEVICE_TYPE \
     --num-nodes=WORKLOAD_NUM_NODES \
     --zone=COMPUTE_ZONE \
     --project=PROJECT_ID

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

    • ‫WORKLOAD_NAME: שם עומס העבודה.
    • ‫CLUSTER_NAME: שם האשכול.
    • ‫DEVICE_TYPE: סוג המכשיר שבו רוצים להשתמש.
      • ל-A3 Ultra, משתמשים ב- h200-141gb-8
      • ב-A3 Mega, משתמשים ב-h100-mega-80gb-8
      • ל-A3 High, משתמשים ב-h100-80gb-8
    • ‫WORKLOAD_NUM_NODES: מספר צמתי העובדים שמשמשים להרצת עומס העבודה.
    • ‫COMPUTE_ZONE: אזור החישוב של מאגר הצמתים של מכונות A3 Ultra.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

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

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

הפעלת נקודות השוואה שניתנות לשחזור

אפשר לשחזר מדדים של אימון מראש של מודלים גדולים של למידת מכונה בקוד פתוח במופעי מכונות וירטואליות מסוג A4,‏ A3 Ultra ו-A3 Mega ב-GKE.

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

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

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

מודלים Framework מתכון
Llama-3.1-70B MaxText עומס עבודה של 32 צמתים
Llama-3.1-70B NeMo עומס עבודה של 32 צמתים
Mixtral-8-7B NeMo עומס עבודה של 32 צמתים

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

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

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

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

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