‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

אוטומציה של העברת נתונים מ-Cloud Storage לנפח Hyperdisk ML באמצעות GKE Volume Populator

טייס אוטומטי רגילה

במאמר הזה מוסבר איך לטעון מראש מערכי נתונים מדלי של Cloud Storage לנפחי אחסון של Google Cloud Hyperdisk ML באמצעות Volume Populator של Google Kubernetes Engine ‏ (GKE) במהלך הקצאה דינמית. מידע נוסף זמין במאמר מידע על GKE Volume Populator.

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

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

ניהול מאגר הצמתים ב-GKE Volume Populator עם Hyperdisk ML

כדי להריץ בהצלחה את משימות העברת הנתונים שנוצרות על ידי GKE Volume Populator כדי לאכלס נפחי Hyperdisk ML, חשוב להקצות, לספק ולשנות את הגודל של מאגרי הצמתים בצורה יעילה. אתם משתמשים במחלקת מחשוב כדי להגדיר את הדרישות של הצומת, כמו סוג המכונה והגודל שלה, עבור משימות ספציפיות של העברת נתונים. סוג מחשוב מאפשר לכם לשלוט בעלות וברמת הביצועים של תהליך העברת הנתונים. מידע נוסף זמין במאמר היתרונות של מחלקות מחשוב בהתאמה אישית.

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

מטרות

במדריך הזה תבצעו את המשימות הבאות:

מגדירים את סביבת אשכול GKE כדי לתמוך בהעברות נתונים באמצעות GKE Volume Populator, כולל יצירת אשכול, הגדרת מחלקת מחשוב והגדרת הרשאות.
יוצרים GCPDataSource משאב בהתאמה אישית כדי לציין את קטגוריית Cloud Storage של המקור.
הגדרה של StorageClass ל-Hyperdisk ML.
יוצרים PersistentVolumeClaim שמפנה אל GCPDataSource כדי להפעיל את אכלוס הנתונים בכרך Hyperdisk ML.
אימות העברת הנתונים.
צריכת הנפח שאוכלס ב-Pod.
לפנות את המשאבים

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

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

מפעילים את ממשקי ה-API של GKE ו-Cloud Storage.

הפעלת ממשקי ה-API
מוודאים שהחיוב מופעל בGoogle Cloud פרויקט.
מורידים ומתקינים את כלי שורת הפקודה של Google Cloud CLI, או משתמשים ב-Cloud Shell כדי להריץ את הפקודות gcloud CLI ו-kubectl. ‫Cloud Shell היא סביבת מעטפת לניהול משאבים שמתארחים ב- Google Cloud. הוא מגיע עם כלי שורת הפקודה gcloud ו-kubectl שמותקנים מראש.
הגדרת אזור ותחום כברירת מחדל
יוצרים קטגוריה של Cloud Storage או משתמשים בקטגוריה קיימת. במדריך הזה אנחנו יוצאים מנקודת הנחה שכבר יש לכם קטגוריה של Cloud Storage עם נתוני אימון המודל.
מפעילים את מנהל ההתקן של Compute Engine Persistent Disk CSI באשכולות רגילים קיימים, שבהם יכול להיות שמנהל ההתקן מושבת באופן מפורש. באשכולות חדשים של Autopilot ו-Standard, ‏ GKE מפעיל את הדרייבר כברירת מחדל. אחסון ה-Hyperdisk ML ביעד שאתם יוצרים צריך להיות מנוהל על ידי מנהל ההתקן של Compute Engine Persistent Disk CSI.
מפעילים איחוד זהויות של עומסי עבודה ל-GKE באשכול. כך חשבון השירות של Kubernetes שמשמש את GKE Volume Populator יכול לגשת לקטגוריה של Cloud Storage המקורית. מידע נוסף זמין במאמר בנושא הגדרת ההרשאות הנדרשות.

דרישות

כדי להעביר נתונים באמצעות GKE Volume Populator, צריך לעמוד בדרישות הבאות:

באשכול GKE צריך להפעיל גרסה 1.33.2-gke.4780000 ואילך.
GCPDataSource המשאב המותאם אישית צריך להיות באותו מרחב שמות כמו עומס העבודה של GKE. אין תמיכה במקורות נתונים שמשתרעים על מרחבי שמות שונים.
כשיוצרים את סוג המחשוב, בוחרים מכונה וירטואלית נתמכת. מוודאים שלפרויקט יש מכסת שימוש מספקת לסוג המכונה שבחרתם.
gcs-to-hdml-compute-class שם מחלקת המחשוב מוגדר מראש עבור עבודת ההעברה, וצריך לציין אותו בדיוק כשיוצרים את מחלקת המחשוב.

עלויות

למרות שאין עלות ישירה לשימוש ב-GKE Volume Populator, יש חיובים על אחסון והעברת נתונים. העלויות העקיפות שקשורות לשימוש ב-Google Cloud כוללות את העלויות הבאות:

‫Compute Engine instances used by GKE: העלות של הצמתים שמשמשים להרצת משימות העברת הנתונים. ההשלכות על ניהול הצמתים והעלויות משתנות בהתאם לסוגי האשכולות. מידע נוסף מופיע במאמר יצירת אשכול GKE בקטע על סוגי האשכולות.
גודל הצומת של העברת נתונים: כדי להשיג ביצועים אופטימליים של העברת נתונים, כברירת מחדל, העברת נתונים מגדילה את הצומת עם 24 vCPU. ההגדרה הזו חלה על כל סוגי האשכולות. אם רוצים לשנות את הגודל והסוג של הצומת כדי לבצע אופטימיזציות ספציפיות של עלויות או ביצועים, אפשר לעשות זאת כשיוצרים את סוג המחשוב.
נפח האחסון שנעשה בו שימוש בקטגוריה של Cloud Storage: מידע נוסף זמין במאמר תמחור של Cloud Storage.
עלויות של נפח אחסון מסוג Hyperdisk ML: כולל קיבולת האחסון והביצועים (IOPS/throughput) של נפחי האחסון מסוג Hyperdisk ML שאתם יוצרים. מידע נוסף מופיע במאמר בנושא תמחור Hyperdisk.

הכנת הסביבה

בקטע הזה, יוצרים את תשתית אשכול GKE עם חומרה מתאימה, ומגדירים את ההרשאות הנדרשות לגישה לנתונים ב-Cloud Storage.

לפני שיוצרים את האשכול כדי להשתמש ב-GKE Volume Populator עם Hyperdisk ML, חשוב להבין איך מחלקת מחשוב מוחלת על סוגים שונים של אשכולות, ומי אחראי לניהול הצמתים – GKE או אתם.

איך פועלות מחלקות מחשוב עם סוגים שונים של אשכולות ב-Hyperdisk ML

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

התעניינות ברכישה	‫GKE Autopilot ו-GKE Standard עם הקצאה אוטומטית של צמתים	GKE Standard ללא הקצאה אוטומטית של צמתים
הגדרת סוג המחשוב	`nodePoolAutoCreation` מופעל	`nodePoolAutoCreation` מושבת
ניהול צמתים	‫GKE יוצר ומנהל צמתים באופן אוטומטי.	אתם יוצרים ומנהלים את הצמתים באופן ידני.
שינוי גודל הצומת	אוטומטי	גלילה ידנית
Node labeling	לא רלוונטי	חובה לתייג את הצמתים באמצעות `cloud.google.com/compute-class=gcs-to-hdml-compute-class`
מידע נוסף	הקצאת משאבים אוטומטית של צמתים וסוגי מחשוב	הגדרה של מאגרי צמתים שנוצרו באופן ידני

מערכת GKE מתחילה את משימת העברת הנתונים אחרי הקצאת PersistentVolume עבור PersistentVolumeClaim. כדי לאכלס את נפח ה-Hyperdisk ML, PersistentVolumeClaim צריך להפנות אל GCPDataSource, שמגדיר את נתוני המקור ב-Cloud Storage.

יצירת אשכול GKE

אתם יכולים לבחור לפרוס את צינור העברת הנתונים באמצעות אשכול רגיל או אשכול במצב Autopilot עם GKE בגרסה 1.33.2-gke.4780000 ואילך. לכל סוג אשכול יש יתרונות משלו ומודלים שונים של תמחור.

כדאי לבחור באוטופילוט כדי לנהל את האשכולות בקלות רבה יותר, לחסוך בעלויות ולהשתמש בהתאמת קנה מידה אוטומטית.
בוחרים באפשרות Standard עם Node Auto Provisioning מופעל אם אתם צריכים התאמה אוטומטית לעומס (automatic scaling) עם יותר שליטה בהקצאת צמתים.
אם אתם רוצים שליטה מקסימלית ונוח לכם לנהל את כל ההיבטים של הקצאת צמתים, שינוי גודל ותחזוקה, אתם יכולים לבחור באפשרות Standard without node auto-provisioning enabled (רגיל ללא הקצאה אוטומטית של צמתים).

טייס אוטומטי

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

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

  gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=CLUSTER_VERSION

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

‫CLUSTER_NAME: השם של האשכול שאתם יוצרים.
‫LOCATION: האזור של שירותי המחשוב באשכול. לדוגמה, us-central1.
‫CLUSTER_VERSION: גרסת GKE של האשכול. במדריך הזה נעשה שימוש ב-1.33.2-gke.4780000.

רגיל (עם הקצאת צמתים אוטומטית)

ב-GKE, באשכולות Standard עם הקצאת צמתים אוטומטית (NAP), המערכת מטפלת באופן אוטומטי ביצירה ובמחיקה של הצמתים שנדרשים למשימות העברת הנתונים. כשמשימת ההעברה מסתיימת, המשאבים של הצומת מצטמצמים אוטומטית. אין צורך למחוק ידנית את ה-Pods של ההעברה או את הצמתים שה-Pods פעלו בהם.

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

  gcloud container clusters create CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --location=LOCATION \
    --project=PROJECT_ID \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --enable-autoprovisioning \
    --min-cpu MINIMUM_CPU \
    --min-memory MINIMUM_MEMORY \
    --max-cpu MAXIMUM_CPU \
    --max-memory MAXIMUM_MEMORY \
  --autoprovisioning-scopes=https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring,https://www.googleapis.com/auth/devstorage.read_only

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

‫CLUSTER_NAME: השם של האשכול שאתם יוצרים עם הקצאת צמתים אוטומטית (NAP) מופעלת.
‫CLUSTER_VERSION: גרסת GKE של האשכול. במדריך הזה נעשה שימוש ב-1.33.2-gke.4780000.
‫LOCATION: אזור או אזור מחשוב של האשכול. לדוגמה, us-central1-a או us-central1.
‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
‫MINIMUM_CPU: מספר ה-vCPU המינימלי להקצאה אוטומטית. לדוגמה, 10.
‫MINIMUM_MEMORY: כמות הזיכרון המינימלית ב-GiB להקצאה אוטומטית. לדוגמה, 200.
‫MAXIMUM_CPU: המספר המקסימלי של מעבדי vCPU להקצאה אוטומטית. לדוגמה, 100. המגבלה הזו היא סך כל משאבי ה-CPU בכל מאגרי הצמתים הקיימים שנוצרו באופן ידני ובכל מאגרי הצמתים ש-GKE עשוי ליצור באופן אוטומטי.
‫MAXIMUM_MEMORY: כמות הזיכרון המקסימלית להקצאה אוטומטית. לדוגמה, 1000. המגבלה הזו היא סך משאבי הזיכרון בכל מאגרי הצמתים הקיימים שנוצרו באופן ידני, ובכל מאגרי הצמתים ש-GKE עשוי ליצור באופן אוטומטי.

רגיל (ללא הקצאת צמתים אוטומטית)

כדי להשתמש ב-GKE Volume Populator באשכול Standard שבו לא מופעלת הקצאה אוטומטית של צמתים, אתם יכולים להשתמש במאגר צמתים קיים או ליצור מאגר צמתים ייעודי להעברה. לצמתים צריכה להיות קיבולת להרצת משימות ההעברה והתוויות שמתאימות ל-compute-class.

מציינים את מחלקת המחשוב gcs-to-hdml-compute-class כתווית צומת כשיוצרים את האשכול ואת מאגר הצמתים. שימו לב ששם מחלקת המחשוב, gcs-to-hdml-compute-class, מוגדר מראש למשימת ההעברה, וחובה לציין אותו בדיוק.

כדי ליצור אשכול Standard חדש ללא הקצאת צמתים אוטומטית (NAP), ומאגר צמתים חדש באשכול הזה, מריצים את הפקודות הבאות:

  gcloud container clusters create CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --location=LOCATION \
    --num-nodes=1 \
    --project=PROJECT_ID \
    --workload-pool=PROJECT_ID.svc.id.goog

  gcloud container node-pools create NODE_POOL_NAME\
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --num-nodes=1 \
    --machine-type=c3-standard-44 \
    --node-labels="cloud.google.com/compute-class=gcs-to-hdml-compute-class" \
    --node-taints="cloud.google.com/compute-class=gcs-to-hdml-compute-class:NoSchedule"

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

‫CLUSTER_NAME: השם של האשכול שאתם יוצרים בלי שהקצאת צמתים אוטומטית (NAP) מופעלת.
‫CLUSTER_VERSION: גרסת GKE של האשכול. במדריך הזה נעשה שימוש ב-1.33.2-gke.4780000.
‫LOCATION: האזור של שירותי המחשוב באשכול. לדוגמה, us-central1-a או us-central1.
‫PROJECT_ID מזהה הפרויקט. Google Cloud
‫NODE_POOL_NAME: השם של מאגר הצמתים שאתם יוצרים באשכול החדש. מאגר הצמתים הזה משמש את GKE Volume Populator לפריסת משימות העברת הנתונים הזמניות.

כדי להימנע מעלויות מיותרות, מריצים את הפקודה gcloud container node-pools delete כדי למחוק את מאגרי צמתי ההעברה שנוצרו באופן ידני אחרי סיום העברת הנתונים.

יצירת מחלקת מחשוב

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

שומרים את קובץ המניפסט הבא בשם computeclass.yaml:
עם הקצאת משאבים אוטומטית של צמתים

באשכולות Autopilot ובאשכולות Standard שבהם מופעלת הקצאת משאבים אוטומטית של צמתים, מגדירים את מחלקת המחשוב עם הקטע nodePoolAutoCreation באופן הבא. כשהקצאת צמתים אוטומטית (NAP) מופעלת, GKE יוצרת באופן אוטומטי מאגרי צמתים חדשים עם התווית gcs-to-hdml-compute-class של סוג המכונה.
apiVersion: cloud.google.com/v1 kind: ComputeClass metadata: name: gcs-to-hdml-compute-class spec: priorities: - machineFamily: c3 - machineFamily: c3d nodePoolAutoCreation: enabled: true whenUnsatisfiable: DoNotScaleUp
ללא הקצאת משאבים אוטומטית של צמתים

באשכולות Standard שלא מופעלת בהם הקצאת צמתים אוטומטית (NAP), מגדירים את מחלקת המחשוב ללא הקטע nodePoolAutoCreation באופן הבא. מוודאים שכבר יצרתם מאגר צמתים עם התווית של מחלקת המחשוב gcs-to-hdml-compute-class.
apiVersion: cloud.google.com/v1 kind: ComputeClass metadata: name: gcs-to-hdml-compute-class spec: priorities: - machineFamily: c3 - machineFamily: c3d whenUnsatisfiable: DoNotScaleUp
אתם יכולים לציין כל machineFamily תואם בהתאם לצרכים שלכם להעברת נתונים. מידע נוסף על בחירת סוג מכונה מתאים זמין במאמר תמיכה בסדרות מכונות ב-Hyperdisk ML.
כדי ליצור את מחלקת המחשוב, מפעילים את המניפסט:
```
kubectl apply -f computeclass.yaml
```

הגדרת ההרשאות הנדרשות

כדי להעביר נתונים מקטגוריה של Cloud Storage, צריך להגדיר את ההרשאות הנדרשות לאיחוד זהויות של עומסי עבודה ל-GKE. אם יש לכם את ההרשאות המתאימות, עבודת ההעברה שנוצרה על ידי GKE Volume Populator יכולה לגשת לקטגוריה שלכם ב-Cloud Storage. במדריך הזה אנחנו יוצאים מנקודת הנחה שכבר יש לכם קטגוריה של Cloud Storage עם נתוני אימון של מודל שאתם רוצים להעביר.

יוצרים מרחב שמות של Kubernetes:
```
kubectl create namespace NAMESPACE
```
מחליפים את NAMESPACE במרחב השמות שבו רוצים שהעומסים יפעלו.

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

הערה: חשוב להשתמש באותו מרחב שמות כדי ליצור את כל המשאבים במדריך הזה.
יוצרים חשבון שירות ב-Kubernetes:
```
kubectl create serviceaccount KSA_NAME \
  --namespace=NAMESPACE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫KSA_NAME: השם של חשבון השירות של Kubernetes שתציינו במשאב GCPDataSource. משימת ההעברה שנוצרה על ידי GKE Volume Populator משתמשת בחשבון השירות הזה כדי לבצע אימות ל- Google Cloud APIs.
- ‫NAMESPACE: מרחב השמות של Kubernetes שיצרתם בשלב הקודם.
זהירות: שימוש חוזר בחשבון השירות הזה של Kubernetes בעומסי עבודה אחרים באותו מרחב שמות מאפשר ל-Pod לגשת לקטגוריה של Cloud Storage שבה אתם משתמשים במדריך הזה. לא מומלץ להשתמש מחדש בחשבון השירות הזה לעומסי עבודה אחרים במרחב השמות.
נותנים לחשבון השירות ב-IAM את התפקיד המתאים כדי לגשת לקטגוריה של Cloud Storage:
```
gcloud storage buckets \
  add-iam-policy-binding gs://GCS_BUCKET \
  --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \
  --role "ROLE"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫GCS_BUCKET: השם של הקטגוריה שלכם ב-Cloud Storage.
- ‫PROJECT_NUMBER: המזהה המספרי של Google Cloud הפרויקט שבו יצרתם את האשכול. כדי למצוא את מספר הפרויקט, אפשר להיעזר במאמר זיהוי פרויקטים.
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
- ‫NAMESPACE: מרחב השמות שיצרתם קודם, שבו יפעלו עומסי העבודה.
- ‫KSA_NAME: השם של חשבון השירות של Kubernetes שציינתם במשאב GCPDataSource. משימת ההעברה שנוצרה על ידי GKE Volume Populator משתמשת בחשבון השירות הזה כדי לבצע אימות ל- Google Cloud APIs.
- ‫ROLE: תפקיד ה-IAM שרוצים להקצות לחשבון השירות. למטרות המדריך הזה, נותנים את התפקיד roles/storage.objectViewer כדי לאפשר קריאה מהקטגוריה.
הערכים PROJECT_NUMBER,‏ PROJECT_ID,‏ NAMESPACE ו-KSA_NAME משמשים ליצירת מזהה ראשי של איחוד זהויות של עומסי עבודה ל-GKE עבור הפרויקט שלכם.

יצירת נפח Hyperdisk ML עם נתונים שנטענו מראש

כדי להגדיר את התשתית וההגדרה של GKE שנדרשות ליצירת נפח אחסון של Hyperdisk ML, ולהפעיל ולנהל את תהליך העברת הנתונים האוטומטי באמצעות GKE Volume Populator, צריך לבצע את השלבים הבאים:

יוצרים GCPDataSource משאב בהתאמה אישית כדי להגדיר את מקור הנתונים.
יוצרים StorageClass כדי להגדיר את סוג האחסון המתמיד (נפח Hyperdisk ML) שבו ייעשה שימוש.
יוצרים PersistentVolumeClaim כדי להפעיל הקצאה דינמית של האחסון ולאפשר גישה לנפח Hyperdisk ML שהוקצה לאחרונה.
(אופציונלי) הצגת ההתקדמות של העברת הנתונים.
יוצרים ומפריסים Pod שצורכת את נפח ה-ML של Hyperdisk.

יצירת `GCPDataSource` משאב בהתאמה אישית

יוצרים GCPDataSource משאב בהתאמה אישית ב-GKE כדי לציין את המיקום של קטגוריית המקור ב-Cloud Storage ואת חשבון השירות עם ההרשאות הנדרשות לגישה לקטגוריה הזו. ההגדרה הזו של משאב בהתאמה אישית (CRD) ספציפית ל-GKE Volume Populator.

שומרים את קובץ המניפסט הבא בשם gcpdatasource.yaml.
```
apiVersion: datalayer.gke.io/v1
kind: GCPDataSource
metadata:
 name: GCP_DATA_SOURCE
 namespace: NAMESPACE
spec:
 cloudStorage:
  serviceAccountName: KSA_NAME
  uri: gs://GCS_BUCKET/
```
מחליפים את הערכים הבאים:
- ‫GCP_DATA_SOURCE: השם של ה-CRD‏ GCPDataSource שמכיל הפניה לקטגוריה שלכם ב-Cloud Storage. מידע נוסף זמין במאמר בנושא הפניה ל-CRD‏ GCPDataSource.
- ‫NAMESPACE: אותו מרחב שמות שבו פועלים עומסי העבודה. משאב מותאם אישית GCPDataSource נוצר במרחב השמות הזה.
- ‫KSA_NAME: השם של חשבון השירות של Kubernetes שציינתם במשאב GCPDataSource. משימת ההעברה שנוצרה על ידי GKE Volume Populator משתמשת בחשבון השירות הזה כדי לבצע אימות ל- Google Cloud APIs. הערך של cloudStorage.serviceAccountName הוא חשבון השירות של Kubernetes שהגדרתם עבור איחוד הזהויות של עומסי העבודה ב-GKE בקטע הגדרת ההרשאות הנדרשות.
- ‫GCS_BUCKET: השם של הקטגוריה שלכם ב-Cloud Storage. השדה uri מציין את נתוני המקור.
- כדי להעתיק את כל הקטגוריה, משתמשים בפקודה gs://GCS_BUCKET/.
- כדי להעתיק נתונים מתיקייה ספציפית בתוך הדלי, משתמשים בפורמט gs://GCS_BUCKET/PATH_INSIDE_BUCKET/. לדוגמה, כדי להעתיק נתונים מהתיקייה gemma/v1.0/weights/ בתוך קטגוריית my-project-llm-models, ה-URI יהיה gs://my-project-llm-models/gemma/v1.0/weights/. חשוב לוודא שהנתיב מסתיים בלוכסן כדי לציין תיקייה.
כדי ליצור את משאב GCPDataSource, מחילים את קובץ המניפסט:
```
kubectl apply -f gcpdatasource.yaml
```

יצירת Hyperdisk ML StorageClass

יוצרים StorageClass שמשתמש ב-provisioner‏ pd.csi.storage.gke.io כדי להקצות נפח אחסון של Hyperdisk ML באזור שבחרתם. אם רוצים שהעותקים של הנתונים יהיו נגישים ביותר מאזור אחד, אפשר ליצור StorageClass של כמה אזורים. דוגמה ל-StorageClass של מספר אזורים.

שומרים את קובץ המניפסט הבא בשם hdml-class.yaml.
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: hyperdisk-ml-single-zone
parameters:
 type: hyperdisk-ml
 provisioned-throughput-on-create: "2400Mi"
provisioner: pd.csi.storage.gke.io
allowVolumeExpansion: false
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowedTopologies:
- matchLabelExpressions:
 - key: topology.gke.io/zone
  values:
  - ZONE
```
מחליפים את ZONE בתחום היעד שבו רוצים ליצור את נפח האחסון של Hyperdisk ML:
- באשכול GKE Standard ללא הקצאת משאבים אוטומטית של צמתים, הערך של ZONE צריך להיות המיקום שבו יצרתם את הצמתים.
- באשכולות GKE Autopilot או באשכולות רגילים עם הקצאת משאבים אוטומטית של צמתים, הערך של ZONE צריך להיות המיקום שבו האשכול יכול להגדיל את הקיבולת וליצור צמתים חדשים אם נדרש.
(אופציונלי) כדי להציג את מיקומי הצמתים של האשכול, מריצים את הפקודה הבאה:
```
gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(locations)"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול.
- ‫LOCATION: אזור או אזור מחשוב של האשכול. לדוגמה, us-central1-a או us-central1.
כדי ליצור את StorageClass, מפעילים את המניפסט :
```
kubectl apply -f hdml-class.yaml
```

יצירת PersistentVolumeClaim כדי לגשת לנפח האחסון

במניפסט הבא מוצגת דוגמה לאופן שבו יוצרים PersistentVolumeClaim במצב גישה ReadOnlyMany שמפנה אל StorageClass שיצרתם קודם.

שומרים את קובץ המניפסט הבא בשם volume-populator-pvc.yaml:
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: PVC_NAME
 namespace: NAMESPACE
spec:
 accessModes:
 - ReadOnlyMany
 storageClassName: hyperdisk-ml-single-zone
 resources:
  requests:
   storage: DISK_SIZE
 dataSourceRef:
  apiGroup: datalayer.gke.io
  kind: GCPDataSource
  name: GCP_DATA_SOURCE
```
מחליפים את הערכים הבאים:
- ‫PVC_NAME: השם של PersistentVolumeClaim שאליו רוצים להעביר את הנתונים.
- ‫NAMESPACE: מרחב השמות שבו יפעלו עומסי העבודה.
- ‫DISK_SIZE: גודל הדיסק, בגיגה-בייט, שייווצר כדי לאכלס נתונים. כדי לאכלס את הנתונים בהצלחה, צריך לוודא שגודל הדיסק שנדרש גדול יותר מגודל הנתונים של המודל שנמצאים בקטגוריה של Cloud Storage. כדי שהערך של DISK_SIZE יהיה בטווח הנתמך של נפחי Hyperdisk ML, הוא צריך להיות גדול מ-4 Gi. מידע נוסף זמין במאמר בנושא מגבלות הגודל של נפחי Hyperdisk.
- ‫GCP_DATA_SOURCE: השם של GCPDataSource CRD שמכיל הפניה לקטגוריה של Cloud Storage.
אתם יכולים להתאים אישית את העברת הנתונים על ידי הוספת הערות אופציונליות ל-PVC. ההערות האלה משפיעות על ההתנהגות של משימת ההעברה הבסיסית שמעתיקה נתונים לנפח ה-ML של Hyperdisk.
- ‫volume-populator.datalayer.gke.io/cpu-request: משתמשים בהערה הזו כדי לציין בקשה אחרת למשאב CPU להעברה Job. אם לא מציינים בקשה אחרת למשאבי CPU, בקשת ה-PVC מבקשת כברירת מחדל 24 ליבות וירטואליות כדי לייעל את ביצועי ההעברה.
- ‫volume-populator.datalayer.gke.io/transfer-path: משתמשים בהערה הזו כדי לציין את נתיב היעד בתוך הנפח החדש שבו יישמרו הנתונים שהועתקו מהמשאב GCPDataSource. אם לא מציינים נתיב אחר, הנתונים מועתקים לנתיב הבסיס בנפח ה-ML של Hyperdisk.
כדי ליצור את ה-PVC, מפעילים את המניפסט:
```
kubectl apply -f volume-populator-pvc.yaml
```

חשוב לשים לב לנקודות הבאות:

אם מגדירים את השדה volumeBindingMode ב-StorageClass ל-immediate, העברת הנתונים מופעלת מיד אחרי הפריסה של ה-PVC.
אם מגדירים את השדה volumeBindingMode ב-StorageClass ל-WaitForFirstConsumer, העברת הנתונים מופעלת רק אחרי פריסת Pod שמבקש את ה-PVC, ואחרי שה-Pod הזה מתוזמן בהצלחה לצומת. אפשר לתזמן את ה-Pod, אבל הקונטיינרים ימתינו עד להשלמת העברת הנתונים ועד שהנפח יהיה מוכן לשימוש.

כדי לבדוק את התקדמות העברת הנתונים, אפשר לעיין במאמר בנושא הצגת התקדמות העברת הנתונים. אם נתקלתם בשגיאות במהלך הקצאת המשאבים או העברת הנתונים, תוכלו להיעזר בפתרון בעיות בהעברת נתונים ב-GKE Volume Populator.

(אופציונלי) צפייה בהתקדמות העברת הנתונים

בקטע הזה מוסבר איך לעקוב אחרי ההתקדמות וההצלחה של העברת הנתונים מקטגוריה ב-Cloud Storage לנפח אחסון של Hyperdisk ML.

כדי לבדוק את הסטטוס של PersistentVolumeClaim, מריצים את הפקודה הבאה. אפשר להריץ את הפקודה הזו גם אם הפעולה של קישור PersistentVolumeClaim נמשכת יותר מדי זמן.
```
kubectl describe pvc PVC_NAME -n NAMESPACE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PVC_NAME: השם של ה-PVC שיצרתם בקטע יצירת PersistentVolumeClaim לגישה לנפח.
- ‫NAMESPACE: מרחב השמות שבו נעשה שימוש לאורך המדריך הזה, שיצרתם בקטע הגדרת ההרשאות הנדרשות.

בפלט, בודקים את האירועים של PersistentVolumeClaim כדי לעקוב אחר התקדמות העברת הנתונים. יומני GKE מתעדים את האירועים בערך פעם בדקה. הפלט אמור להיראות כך:

Name:     vp-pvc
Namespace:   default
StorageClass: hyperdisk-ml-single-zone
Status:    Bound
Volume:    pvc-f7ae2ee2-106d-4b87-b458-481a3ff82b62
Labels:    <none>
Annotations:  pv.kubernetes.io/bind-completed: yes
       pv.kubernetes.io/bound-by-controller: yes
       volume.beta.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io
       volume.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io
Finalizers:  [kubernetes.io/pvc-protection]
Capacity:   200Gi
Access Modes: ROX
VolumeMode:  Filesystem
DataSource:
 APIGroup: datalayer.gke.io
 Kind:   GCPDataSource
 Name:   vp-gds
Used By:   verify-data-665cfd4dbf-mwc7t
      verify-data-665cfd4dbf-n7xw9
Events:
 Type   Reason             Age           From                                               Message
 ----   ------             ----          ----                                               -------
 Warning ProvisioningFailed       9m8s          persistentvolume-controller                                    Error saving claim: Operation cannot be fulfilled on persistentvolumeclaims "vp-pvc": the object has been modified; please apply your changes to the latest version and try again
 Normal  Provisioning          9m5s          pd.csi.storage.gke.io_gke-f110123a1cbd44cdaa7a-921b-b1f4-vm_1a100bd9-5231-4f20-8e65-1f8e995a03c0 External provisioner is provisioning volume for claim "default/vp-pvc"
 Normal  Provisioning          9m5s          external-provisioner                                       Assuming an external populator will provision the volume
 Normal  PopulateOperationStartSuccess 8m58s          gkevolumepopulator-populator                                   populateFn: Populate operation started for zone us-central1-c
 Normal  TransferInProgress       8m58s (x2 over 8m58s)  gkevolumepopulator-populator                                   populateCompleteFn: For PVC vp-pvc in namespace default, transfer job with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f in zone us-central1-c waiting for pod to get created
 Normal  TransferInProgress       6m10s (x14 over 8m57s) gkevolumepopulator-populator                                   populateCompleteFn: For PVC vp-pvc in namespace default, transfer job in zone us-central1-c with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f is still active with pod status as - Phase: Pending
 Normal  ExternalProvisioning      3m35s (x24 over 9m5s)  persistentvolume-controller                                    Waiting for a volume to be created either by the external provisioner 'pd.csi.storage.gke.io' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.
 Normal  TransferJobCompleted      3m24s (x2 over 3m26s)  gkevolumepopulator-populator                                   populateCompleteFn: For PVC vp-pvc in namespace default, job with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f for zone us-central1-c completed successfully
 Normal  TransferJobCompleted      3m24s (x2 over 3m26s)  gkevolumepopulator-populator                                   populateCompleteFn: For PVC vp-pvc in namespace default, transfer job for all zones have completed successfully
 Normal  PopulateOperationFinished   3m24s (x2 over 3m26s)  gkevolumepopulator-populator                                   Populate operation finished
 Normal  PopulatorFinished       3m19s (x3 over 3m20s)  gkevolumepopulator-populator                                   Populator finished

יכול להיות שיעברו כמה דקות עד שתהליך האכלוס יתחיל, בהתאם לגודל הנתונים. אם לא רואים התקדמות בהעברת הנתונים אחרי כמה דקות, אפשר לעיין במאמר פתרון בעיות בהעברת נתונים ב-GKE Volume Populator לקבלת עזרה.

בהעברות נתונים של נפח Hyperdisk ML מרובה אזורים, העבודה מסומנת כהושלמה רק אם הנתונים הועברו בהצלחה לכל האזורים שצוינו ב-StorageClass. אם העברת העבודה נכשלת באזור אחד או יותר, התוסף GKE Volume Populator מנסה שוב להעביר את הנתונים ללא הגבלה, כל עוד ה-PVC קיים.

יצירה ופריסה של Pod שמשתמש בנפח האחסון

כדי ליצור Pod ולאמת את התוכן של PVC שאוכלס בנתונים:

שומרים את קובץ המניפסט הבא בשם verify-data.yaml:

apiVersion: v1
kind: Pod
metadata:
 name: verify-data
 namespace: NAMESPACE
spec:
 nodeSelector:
  cloud.google.com/compute-class: gcs-to-hdml-compute-class
 containers:
 - name: verify-data
  image: busybox
  command:
  - sleep
  - infinity
  volumeMounts:
   - mountPath: /models
    name: mypvc
 volumes:
 - name: mypvc
  persistentVolumeClaim:
   claimName: PVC_NAME

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

‫NAMESPACE: מרחב השמות שבו נמצא ה-PVC ושבו רוצים ליצור את ה-Pod‏ verify-data.
‫PVC_NAME: השם של ה-PVC שיצרתם לאכלוס הנתונים בקטע יצירת PersistentVolumeClaim לגישה לנפח האחסון.

יוצרים את ה-Pod באמצעות הפקודה הבאה:
```
kubectl create -f verify-data.yaml
```
כדי להציג את רשימת הקבצים, מריצים את הפקודה הבאה:
```
kubectl exec -it verify-data -- /bin/sh
# cd /models && ls
```

אם הפקודה תצליח, תוכלו למצוא את הנתונים המאוכלסים בספרייה /models בקטגוריה של Cloud Storage.

הסרת המשאבים

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

מחיקה של PersistentVolumeClaim במהלך הקצאה דינמית

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

במהלך תהליך המחיקה, מחליפים את המשתנים הרלוונטיים הבאים:

‫POD_NAME: השם של ה-Pod שיצרתם בקטע יצירה ופריסה של Pod שמשתמש בנפח האחסון.
‫NAMESPACE: מרחב השמות שבו נמצא ה-PVC.
‫PVC_NAME: השם של ה-PVC שיצרתם בקטע יצירת PersistentVolumeClaim לגישה לנפח.
‫GCP_DATA_SOURCE: השם של GCPDataSource המשאב המותאם אישית שיצרתם בקטע יצירת GCPDataSource משאב מותאם אישית.

מוחקים את ה-Pod של עומס העבודה:
```
kubectl delete pod POD_NAME -n NAMESPACE
```

מאתרים את השם של ה-PersistentVolumeClaim הזמני:

# Store the relevant environment variables
export PVC_NAME=PVC_NAME
export NAMESPACE=NAMESPACE

# Check the status
export PVC_UID=$(kubectl get pvc ${PVC_NAME} -n ${NAMESPACE} -o jsonpath='{.metadata.uid}')
export TEMP_PVC=prime-${PVC_UID}
echo ${TEMP_PVC}

מוחקים את ה-PVC שנוצר במרחב השמות:
```
kubectl delete pvc PVC_NAME -n NAMESPACE
```

יכול להיות שה-PVC תקוע במצב Terminating:

NAME      STATUS    VOLUME  CAPACITY  ACCESS MODES  STORAGECLASS        VOLUMEATTRIBUTESCLASS  AGE
vp-pvc  Terminating                   hyperdisk-ml  <unset>         7m23s

אם כן, צריך לנקות את ה-PVC באופן ידני על ידי הסרת ה-finalizers שלו:

kubectl patch pvc PVC_NAME -n NAMESPACE -p '{"metadata":{"finalizers":null}}'

מוחקים את המשאב GCPDataSource רק אחרי שמוחקים את ה-PVC. אם תמחקו קודם את המשאב GCPDataSource, מחיקת ה-PVC תיתקע.
```
kubectl delete gcpdatasource GCP_DATA_SOURCE -n NAMESPACE
```
בודקים שהמשאבים הזמניים נמחקו.

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

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

אוטומציה של העברת נתונים מ-Cloud Storage לנפח Hyperdisk ML באמצעות GKE Volume Populator קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

ניהול מאגר הצמתים ב-GKE Volume Populator עם Hyperdisk ML

מטרות

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

דרישות

עלויות

הכנת הסביבה

איך פועלות מחלקות מחשוב עם סוגים שונים של אשכולות ב-Hyperdisk ML

יצירת אשכול GKE

טייס אוטומטי

רגיל (עם הקצאת צמתים אוטומטית)

רגיל (ללא הקצאת צמתים אוטומטית)

יצירת מחלקת מחשוב

עם הקצאת משאבים אוטומטית של צמתים

ללא הקצאת משאבים אוטומטית של צמתים

הגדרת ההרשאות הנדרשות

יצירת נפח Hyperdisk ML עם נתונים שנטענו מראש

יצירת GCPDataSource משאב בהתאמה אישית

יצירת Hyperdisk ML StorageClass

יצירת PersistentVolumeClaim כדי לגשת לנפח האחסון

(אופציונלי) צפייה בהתקדמות העברת הנתונים

יצירה ופריסה של Pod שמשתמש בנפח האחסון

הסרת המשאבים

מחיקה של PersistentVolumeClaim במהלך הקצאה דינמית

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

אוטומציה של העברת נתונים מ-Cloud Storage לנפח Hyperdisk ML באמצעות GKE Volume Populator

יצירת `GCPDataSource` משאב בהתאמה אישית