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

במדריך הזה מוסבר איך ליצור נפח אחסון חדש ב-Kubernetes שמגובה על ידי מנהל התקן CSI של Managed Lustre ב-GKE עם הקצאת משאבים דינמית. מנהל התקן ה-CSI של Managed Lustre מאפשר ליצור נפחי אחסון על בסיס מכונות 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: יכול להיות שלצמתים שלכם מצורפים כרטיסי NIC של RDMA, אבל מנהל ההתקן של CSI של Managed Lustre משתמש רק בכרטיסי ה-NIC הרגילים לתעבורת אחסון 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, בלי קשר לגרסת האשכול. בלי הדגל הזה, לא תהיה אפשרות ל-GKE cluster לטעון את מופע Lustre הקיים.

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

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

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

  • מפעילים את Google Cloud Managed Lustre API ואת Google Kubernetes Engine API.
    • הפעלת ממשקי API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-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 IP_RANGE_NAME=LUSTRE_IP_RANGE
export FIREWALL_RULE_NAME=LUSTRE_FIREWALL_RULE
export LOCATION=ZONE
export CLUSTER_VERSION=CLUSTER_VERSION

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

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

הגדרת רשת VPC

כשיוצרים את מכונת Managed Lustre ואת אשכולות GKE, צריך לציין את אותה רשת VPC, או להתחבר דרך Network Connectivity Center אם משתמשים ברשת VPC שנוצרה באמצעות שירותי Peering.

  1. כדי להפעיל את רשת השירות, מריצים את הפקודה הבאה:

    gcloud services enable servicenetworking.googleapis.com \
    --project=${PROJECT_ID}

  2. יוצרים רשת VPC. הגדרת הדגל --mtu לערך 8896 מובילה לשיפור של 10% בביצועים.

    gcloud compute networks create ${NETWORK_NAME} \
    --subnet-mode=auto --project=${PROJECT_ID} \
    --mtu=8896

  3. יוצרים טווח כתובות IP.

    gcloud compute addresses create ${IP_RANGE_NAME} \
    --global \
    --purpose=VPC_PEERING \
    --prefix-length=20 \
    --description="Managed Lustre VPC Peering" \
    --network=${NETWORK_NAME} \
    --project=${PROJECT_ID}

  4. מקבלים את טווח ה-CIDR שמשויך לטווח שיצרתם בשלב הקודם.

    CIDR_RANGE=$(
  gcloud compute addresses describe ${IP_RANGE_NAME} \
      --global  \
      --format="value[separator=/](address, prefixLength)" \
      --project=${PROJECT_ID}
)

  5. יוצרים כלל חומת אש שמאפשר תעבורת TCP מטווח כתובות ה-IP שיצרתם.

    gcloud compute firewall-rules create ${FIREWALL_RULE_NAME} \
    --allow=tcp:988,tcp:6988 \
    --network=${NETWORK_NAME} \
    --source-ranges=${CIDR_RANGE} \
    --project=${PROJECT_ID}

  6. כדי להגדיר שיוך רשתות לפרויקט, צריך לוודא שיש לכם את הרשאות ה-IAM הנדרשות, במיוחד התפקיד compute.networkAdmin או servicenetworking.networksAdmin.

    1. נכנסים אל Google Cloud console > IAM & Admin ומחפשים את בעל הפרויקט.
    2. לוחצים על סמל העיפרון ואז על + ADD ANOTHER ROLE (הוספת תפקיד נוסף).
    3. בוחרים באפשרות Compute Network Admin או Service Networking Admin.
    4. לוחצים על Save.

  7. מקימים את הקישור בין הרשתות השכנות.

    gcloud services vpc-peerings connect \
    --network=${NETWORK_NAME} \
    --project=${PROJECT_ID} \
    --ranges=${IP_RANGE_NAME} \
    --service=servicenetworking.googleapis.com

הגדרת מנהל התקן 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

הפעלת הדרייבר המנוהל של Lustre CSI באשכולות 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

כדי להפעיל את מנהל התקן ה-CSI של Managed Lustre באשכול 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

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

הערה: אם משביתים את התמיכה בכמה כרטיסי 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

בקטעים הבאים מתואר התהליך האופייני ליצירת נפח Kubernetes שמגובה על ידי מופע Lustre מנוהל ב-GKE:

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

יצירת StorageClass

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

  • lustre-rwx-125mbps-per-tib
  • lustre-rwx-250mbps-per-tib
  • lustre-rwx-500mbps-per-tib
  • lustre-rwx-1000mbps-per-tib

‫GKE מספק StorageClass כברירת מחדל לכל רמת ביצועים נתמכת של Managed Lustre. השימוש ב-StorageClasses מובנה מפשט את ההקצאה הדינמית של מופעי Managed Lustre, כי אתם לא צריכים להגדיר StorageClasses משלכם.

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

בדוגמה הבאה אפשר לראות איך יוצרים StorageClass בהתאמה אישית עם דרישות טופולוגיה ספציפיות:

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

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: lustre-class
provisioner: lustre.csi.storage.gke.io
volumeBindingMode: Immediate
reclaimPolicy: Delete
parameters:
  perUnitStorageThroughput: "1000"
  network: LUSTRE_NETWORK
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - us-central1-a

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

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

    kubectl apply -f lustre-class.yaml

שימוש ב-PersistentVolumeClaim כדי לגשת ל-Volume

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

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

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: lustre-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 9000Gi
  storageClassName: lustre-class

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

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

    kubectl apply -f lustre-pvc.yaml

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

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

כמה פודים יכולים לחלוק את אותו משאב 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

  3. מוודאים שה-Pod פועל. ה-Pod פועל אחרי שהוקצה PersistentVolumeClaim. הפעולה הזו עשויה להימשך כמה דקות.

    kubectl get pods

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

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

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

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

פתרון בעיות

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

הסרת המשאבים

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

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

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

  2. בודקים את הסטטוס של PersistentVolume.

    kubectl get pv

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

    No resources found

    יכול להיות שיעברו כמה דקות עד שמופע Managed Lustre הבסיסי יימחק לגמרי.

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