גישה למכונות Managed Lustre קיימות ב-GKE באמצעות מנהל התקן ה-CSI של Managed Lustre

במדריך הזה מוסבר איך להתחבר למופע קיים של Managed Lustre באמצעות מנהל התקנים (driver) של Managed Lustre CSI. כך תוכלו לגשת למכונות Managed Lustre קיימות כאל אמצעי אחסון לעומסי עבודה עם שמירת מצב, בצורה מבוקרת וצפויה.

תמיכה ב-multi-NIC לביצועים גבוהים ברשת

באשכולות GKE שמופעלת בהם גרסה 1.35.2-gke.1842000 ומעלה, דרייבר ה-CSI המנוהל של Managed Lustre מופעל כברירת מחדל כדי להשתמש בכל כרטיסי ממשק הרשת (NIC) הזמינים, וכך להגדיל את קצב העברת הנתונים. התמיכה הזו מאגדת את רוחב הפס על ידי פיזור תעבורת האחסון של TCP על פני ממשקי הרשת.

כדי להשתמש בתמיכה ב-multi-NIC, הצמתים צריכים לעמוד בדרישות הבאות:

  • כרטיסי רשת רגילים ל-TCP: הצמתים צריכים להשתמש בכרטיסי רשת רגילים, כמו Google Virtual NIC‏ (gVNIC) או VirtIO-Net, כדי לטפל בתעבורת אחסון של TCP.
  • אותו VPC: כל כרטיסי ה-NIC הרגילים חייבים להיות באותה רשת VPC.
  • שיקולים לגבי RDMA: יכול להיות שיהיו צמתי RDMA NICs שמחוברים לצמתים שלכם, אבל מנהל ההתקן של Managed Lustre CSI משתמש רק ב-NICs רגילים לתנועת אחסון TCP.

אם רוצים להשבית את התמיכה ב-NIC מרובים, אפשר לעיין במאמר השבתת multi-NIC עבור Lustre.

יציאות תקשורת של Lustre

מנהל התקן ה-CSI של GKE Managed Lustre משתמש ביציאות שונות לתקשורת עם מופעי Managed Lustre, בהתאם לגרסת אשכול GKE ולהגדרות Managed Lustre הקיימות.

  • יציאת ברירת מחדל (מומלץ): באשכולות GKE חדשים שמריצים גרסה 1.33.2-gke.4780000 ואילך, מנהל ההתקן משתמש ביציאה 988 לתקשורת Lustre כברירת מחדל.

  • יציאה מדור קודם (הוצאה משימוש): משתמשים ביציאה 6988 על ידי הוספת הדגל --enable-legacy-lustre-port לפקודות gcloud בתרחישים הבאים:

    • גרסאות קודמות של GKE: אם אשכול GKE שלכם מריץ גרסה מוקדמת מ-1.33.2-gke.4780000, הדגל --enable-legacy-lustre-port פותר בעיה של התנגשות יציאות עם gke-metadata-server בצמתים של GKE.
    • מכונות Lustre קיימות: אם אתם מתחברים למכונת Managed Lustre קיימת שנוצרה עם הדגל gke-support-enabled, אתם עדיין חייבים לכלול את --enable-legacy-lustre-port בפקודות gcloud, בלי קשר לגרסת האשכול. בלי הדגל הזה, לא תהיה אפשרות לטעון את מופע Lustre הקיים באשכול GKE.

אתם יכולים להגדיר את האשכולות החדשים והקיימים כך שישתמשו ביציאת ברירת המחדל 988 או ביציאה מדור קודם 6988.

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

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

  • מפעילים את Google Cloud Managed Lustre API ואת Google Kubernetes Engine API.
    • הפעלת ממשקי API
  • כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שבגרסאות קודמות של ה-CLI של gcloud אי אפשר להריץ את הפקודות שבמסמך הזה.

הגדרה של משתני סביבה

מגדירים את משתני הסביבה הבאים:

export CLUSTER_NAME=CLUSTER_NAME
export PROJECT_ID=PROJECT_ID
export NETWORK_NAME=LUSTRE_NETWORK
export LOCATION=ZONE

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

  • ‫CLUSTER_NAME: שם האשכול.
  • ‫PROJECT_ID: Google Cloud מזהה הפרויקט.
  • ‫LUSTRE_NETWORK: הרשת המשותפת של הענן הווירטואלי הפרטי (VPC) שבה נמצאים אשכול GKE ומופע Managed Lustre.
  • ‫ZONE: האזור הגיאוגרפי של אשכול GKE, לדוגמה us-central1-a.

הגדרת מנהל התקן CSI של Managed Lustre

בקטע הזה מוסבר איך להפעיל ולהשבית את מנהל ההתקן של Managed Lustre CSI.

הפעלת דרייבר CSI מנוהל של Lustre באשכול GKE חדש

בקטעים הבאים מוסבר איך להפעיל את מנהל התקן Managed Lustre CSI באשכול GKE חדש.

שימוש ביציאה 988 שמוגדרת כברירת מחדל

כדי להפעיל את מנהל ההתקן של Managed Lustre CSI כשיוצרים אשכול GKE חדש שפועלת בו גרסה 1.33.2-gke.4780000 ואילך, מריצים את הפקודה הבאה:

טייס אוטומטי

gcloud container clusters create-auto "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --enable-lustre-csi-driver

רגילה

gcloud container clusters create "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --addons=LustreCsiDriver

שימוש ביציאה מדור קודם 6988

כדי להפעיל את מנהל ההתקן של Managed Lustre CSI כשיוצרים אשכול GKE חדש שפועלת בו גרסה מוקדמת יותר מ-1.33.2-gke.4780000, מריצים את הפקודה הבאה:

טייס אוטומטי

gcloud container clusters create-auto "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --enable-lustre-csi-driver \
    --enable-legacy-lustre-port

רגילה

gcloud container clusters create "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --addons=LustreCsiDriver \
    --enable-legacy-lustre-port

הפעלת מנהל התקן ה-CSI של Managed Lustre באשכולות GKE קיימים

בקטעים הבאים מוסבר איך להפעיל את מנהל ההתקן של Managed Lustre CSI באשכולות GKE קיימים.

שימוש ביציאה שמוגדרת כברירת מחדל 988

כדי להפעיל את מנהל ההתקן של Managed Lustre CSI באשכול GKE קיים שפועלת בו גרסה 1.33.2-gke.4780000 ואילך, מריצים את הפקודה הבאה:

  gcloud container clusters update ${CLUSTER_NAME} \
      --location=${LOCATION} \
      --update-addons=LustreCsiDriver=ENABLED

שימוש ביציאה מדור קודם 6988

כדי להפעיל את מנהל ההתקן של Managed Lustre CSI באשכול GKE קיים, יכול להיות שתצטרכו להשתמש ביציאה הקודמת 6988 על ידי הוספת הדגל --enable-legacy-lustre-port. חובה להשתמש בדגל הזה בתרחישים הבאים:

  • אם אשכול GKE פועל בגרסה קודמת ל-1.33.2-gke.4780000.

  • אם אתם מתכוונים לחבר את האשכול הזה למכונה קיימת של Managed Lustre שנוצרה עם הדגל gke-support-enabled.

    gcloud container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --enable-legacy-lustre-port

צריך לשדרג צמתים באשכולות קיימים

הפעלת מנהל ההתקן של Managed Lustre CSI באשכולות קיימים יכולה להפעיל מחדש את יצירת הצומת כדי לעדכן את מודולי הליבה הנדרשים עבור לקוח Managed Lustre. כדי שהזמינות תהיה מיידית, מומלץ לשדרג את מאגרי הצמתים באופן ידני.

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

עד שהשדרוג של הצומת יושלם באופן מלא, יכול להיות ש-Pod של מנהל התקן CSI יבצע לולאת קריסה בצמתים שממתינים לעדכון. אם מופיעה שגיאת Operation not permitted ביומני ה-Pod של מנהל ההתקן של CSI, צריך לשדרג או ליצור מחדש את הצומת.

אחרי השדרוג של מאגר הצמתים, יכול להיות שצמתי CPU יופיעו כצמתים שמשתמשים בתמונת GPU במסוף Google Cloud או בפלט של CLI. זו התנהגות רגילה. קובץ האימג' של ה-GPU עובר שימוש חוזר בצמתי CPU כדי להתקין באופן מאובטח את מודולי הליבה של Managed Lustre. לא נחייב אתכם על השימוש ב-GPU.

(אופציונלי) יצירת מאגר צמתים עם כמה כרטיסי NIC

כדי להשתמש ברשתות עם ביצועים גבוהים, צריך ליצור מאגר צמתים עם סוג מכונה שתומך בכמה ממשקי רשת. התמיכה ב-multi-NIC מופעלת כברירת מחדל באשכולות GKE שפועלים בגרסה 1.35.2-gke.1842000 ואילך. חשוב לוודא שממשקי הרשת המשניים נמצאים באותה רשת VPC כמו הממשק הראשי.

מריצים את הפקודה הבאה:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=MACHINE_TYPE \
    --enable-gvnic \
    --additional-node-network network=NETWORK_NAME,subnetwork=SECONDARY_SUBNET

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

  • ‫NODE_POOL_NAME: השם של מאגר הצמתים.
  • ‫CLUSTER_NAME: השם של האשכול.
  • ‫LOCATION: האזור או התחום של האשכול.
  • ‫MACHINE_TYPE: סוג המכונה של מאגר הצמתים, למשל a3-megagpu-8g, שמשמשת לעיתים קרובות עם multi-NIC לביצועים גבוהים. יש תמיכה ב-multi-NIC בכל סוגי המכונות.
  • ‫NETWORK_NAME: השם של רשת ה-VPC.
  • ‫SECONDARY_SUBNET: השם של רשת המשנה המשנית.

השבתת multi-NIC ב-Lustre

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

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

באשכול

כדי להשבית את הרשתות בעלות הביצועים הגבוהים בכל האשכול, משתמשים בדגל --disable-multi-nic-lustre כשיוצרים או מעדכנים את האשכול. לדוגמה:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --disable-multi-nic-lustre

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

  • ‫CLUSTER_NAME: השם של האשכול.
  • ‫LOCATION: האזור או התחום של האשכול.

למאגר צמתים

כדי להשבית את הרשתות בעלות הביצועים הגבוהים במאגר צמתים ספציפי, מעדכנים את מאגר הצמתים כדי להגדיר את התווית lustre.csi.storage.gke.io/multi-nic לערך false:

gcloud container node-pools update NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--zone=LOCATION \
--node-labels=lustre.csi.storage.gke.io/multi-nic=false

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

  • ‫NODE_POOL_NAME: השם של מאגר הצמתים.
  • ‫CLUSTER_NAME: שם האשכול.
  • ‫LOCATION: האזור של האשכול.

השבתת מנהל ההתקן של Managed Lustre CSI

אפשר להשבית את מנהל ההתקן של Managed Lustre CSI באשכול GKE קיים באמצעות Google Cloud CLI.

gcloud container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --update-addons=LustreCsiDriver=DISABLED

אחרי שמשביתים את מנהל התקן ה-CSI, ‏ GKE יוצר מחדש באופן אוטומטי את הצמתים ומסיר את ההתקנה של מודולי הליבה של Managed Lustre.

גישה למכונה קיימת ב-Managed Lustre באמצעות מנהל התקן ה-CSI של Managed Lustre

אם כבר הקציתם מכונה של Managed Lustre באותה רשת כמו אשכול GKE, תוכלו לפעול לפי ההוראות האלה כדי להקצות באופן סטטי PersistentVolume שמפנה למכונה.

בקטעים הבאים מתואר התהליך הרגיל לגישה למכונה קיימת של Managed Lustre באמצעות מנהל ההתקן של Managed Lustre CSI:

  1. יוצרים PersistentVolume שמפנה למכונת Managed Lustre.
  2. שימוש ב-PersistentVolumeClaim כדי לגשת לנפח האחסון.
  3. יוצרים עומס עבודה שצורכת את הנפח.

יצירת PersistentVolume

  1. כדי לאתר את המכונה של Managed Lustre, מריצים את הפקודה הבאה.

    gcloud lustre instances list \
    --project=${PROJECT_ID} \
    --location=${LOCATION}

    הפלט אמור להיראות כך: לפני שעוברים לשלב הבא, חשוב לרשום את שם המכונה ב-Managed Lustre, את מערכת הקבצים ואת השדות mountPoint.

    capacityGib: '9000'
createTime: '2025-04-28T22:42:11.140825450Z'
filesystem: testlfs
gkeSupportEnabled: true
mountPoint: 10.90.1.4@tcp:/testlfs
name: projects/my-project/locations/us-central1-a/instances/my-lustre
network: projects/my-project/global/networks/default
perUnitStorageThroughput: '1000'
state: ACTIVE
updateTime: '2025-04-28T22:51:41.559098631Z'

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

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: lustre-pv
spec:
  storageClassName: "STORAGE_CLASS_NAME"
  capacity:
    storage: 9000Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem
  claimRef:
    namespace: default
    name: lustre-pvc
  csi:
    driver: lustre.csi.storage.gke.io
    volumeHandle: "PROJECT_ID/LOCATION/INSTANCE_NAME"
    volumeAttributes:
      ip: IP_ADDRESS
      filesystem: FILESYSTEM

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

    • ‫storageClassName: השם של StorageClass. הערך יכול להיות מחרוזת ריקה, אבל הוא חייב לעמוד במפרט של PersistentVolumeClaim.
    • ‫volumeHandle: המזהה של הכרך הזה.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫LOCATION: המיקום של מכונת Lustre באזור. צריך לציין אזור נתמך עבור מנהל ההתקן של Managed Lustre CSI.
      • ‫INSTANCE_NAME: השם של מופע Lustre.
    • ‫ip: כתובת ה-IP של מופע Lustre. מקבלים את זה מהשדה mountPoint בפלט של הפקודה הקודמת.
    • ‫filesystem: השם של מערכת הקבצים של מכונת Managed Lustre.

    רשימה מלאה של השדות שנתמכים באובייקט PersistentVolume מופיעה במסמכי העזר של מנהל התקן CSI של Managed Lustre.

  3. מריצים את הפקודה הבאה כדי ליצור את PersistentVolume:

    kubectl apply -f lustre-pv.yaml

שימוש ב-PersistentVolumeClaim כדי לגשת לאמצעי האחסון

אפשר ליצור משאב PersistentVolumeClaim שמפנה ל-StorageClass של מנהל ההתקן Managed Lustre CSI.

קובץ המניפסט הבא מראה דוגמה ליצירת PersistentVolumeClaim ב-ReadWriteMany access mode , שמפנה ל-StorageClass שיצרתם קודם.

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

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: lustre-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: "STORAGE_CLASS_NAME"
  volumeName: lustre-pv
  resources:
    requests:
      storage: STORAGE_SIZE

    מחליפים את STORAGE_SIZE בגודל האחסון, לדוגמה, 9000Gi. היא צריכה להיות זהה למפרט ב-PersistentVolume.

  2. כדי ליצור את PersistentVolumeClaim, מריצים את הפקודה הבאה:

    kubectl create -f lustre-pvc.yaml

יצירת עומס עבודה שמשתמש בנפח האחסון

בקטע הזה מוסבר איך ליצור Pod שמשתמש במשאב PersistentVolumeClaim שיצרתם קודם.

כמה Pods יכולים לשתף את אותו משאב PersistentVolumeClaim.

  1. שומרים את המניפסט הבא בקובץ בשם my-pod.yaml.

    apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
      - name: lustre-volume
        mountPath: /data
  volumes:
  - name: lustre-volume
    persistentVolumeClaim:
      claimName: lustre-pvc

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

    kubectl apply -f my-pod.yaml

    ה-Pod ממתין עד ש-GKE יקצה את PersistentVolumeClaim לפני שהוא מתחיל לפעול. הפעולה הזו עשויה להימשך כמה דקות.

  3. מוודאים שה-Pod פועל:

    kubectl get pods

    יכול להיות שיחלפו כמה דקות עד שה-Pod יגיע למצב Running.

    הפלט אמור להיראות כך:

    NAME           READY   STATUS    RESTARTS   AGE
my-pod         1/1     Running   0          11s

שימוש ב-fsGroup עם אמצעי אחסון של Managed Lustre

אפשר לשנות את הבעלות על הקבוצה של ספריית הרמה הבסיסית של מערכת הקבצים המצורפת כך שתתאים ל-fsGroup שצוין על ידי המשתמש ב-SecurityContext של ה-Pod.

פתרון בעיות

להנחיות לפתרון בעיות, קראו את הדף בנושא פתרון בעיות במסמכי התיעוד של Managed Lustre.

הסרת המשאבים

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

  1. מוחקים את ה-Pod ואת ה-PersistentVolumeClaim.

    kubectl delete pod my-pod
kubectl delete pvc lustre-pvc

  2. בודקים את הסטטוס של PersistentVolume. אחרי שמוחקים את ה-Pod ואת ה-PersistentVolumeClaim, הסטטוס של ה-PersistentVolume צריך להיות Released:

    kubectl get pv

    הפלט אמור להיראות כך:

    NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                 STORAGECLASS   REASON   AGE
lustre-pv   9000Gi      RWX            Retain        Released   default/preprov-pvc                           2m28s

  3. שימוש חוזר בנפח אחסון מתמיד. כדי לעשות שימוש חוזר בנפח אחסון מתמיד, מסירים את ההפניה לתביעה (claimRef):

    kubectl patch pv lustre-pv --type json -p '[{"op": "remove", "path": "/spec/claimRef"}]'

    הסטטוס של PersistentVolume צריך להיות עכשיו Available (זמין), כלומר הוא מוכן להיות מקושר ל-PersistentVolumeClaim חדש. בודקים את הסטטוס של PersistentVolume:

    kubectl get pv

    הפלט אמור להיראות כך:

    NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
lustre-pv   9000Gi      RWX           Retain         Available                                   19m

  4. מוחקים את PersistentVolume אם הוא כבר לא נחוץ. אם אין יותר צורך ב-PersistentVolume, מוחקים אותו:

    kubectl delete pv lustre-pv

    מחיקה של PersistentVolume לא מסירה את המכונה הבסיסית ב-Managed Lustre.

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