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

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

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

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

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

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

אם רוצים להשבית את התמיכה ב-multi-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 לא יצליח לטעון את מכונת Lustre הקיימת.

אתם יכולים להגדיר את האשכולות החדשים והקיימים כך שישתמשו ביציאת ברירת המחדל 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 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 Network Peering עם Managed Lustre.
  • ‫LUSTRE_FIREWALL_RULE: השם של הכלל של חומת האש שמאפשר תעבורת TCP מטווח כתובות ה-IP.
  • ‫ZONE: האזור הגיאוגרפי של אשכול GKE, לדוגמה us-central1-a.
  • ‫CLUSTER_VERSION: הגרסה של אשכול GKE.

הגדרת רשת VPC

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

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

    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 > IAM & Admin, ואז מחפשים את חשבון המשתמש של בעלי הפרויקט.
    2. לוחצים על סמל העיפרון ואז על ‎+ ADD ANOTHER ROLE.
    3. בוחרים באפשרות אדמין של רשת Compute או אדמין של רשת שירותים.
    4. לוחצים על Save.

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

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

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

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

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

הפעלת מנהל ההתקן של Managed 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

כדי להפעיל את מנהל ההתקן של 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 באשכולות קיימים יכולה להפעיל יצירה מחדש של צמתים כדי לעדכן את מודולי הליבה (kernel) הנדרשים ללקוח Managed Lustre. כדי שהגרסה תהיה זמינה באופן מיידי, מומלץ לשדרג ידנית את מאגרי הצמתים.

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

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

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

(אופציונלי) יצירת מאגר צמתים multi-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

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

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

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

יצירת אמצעי אחסון חדש באמצעות מנהל ההתקן של Managed Lustre CSI

בקטעים הבאים מתואר התהליך הרגיל ליצירת ווליום של Kubernetes שמגובה על ידי מכונה של Managed 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. כך קל יותר להקצות באופן דינמי מכונות של Managed Lustre, כי אפשר להשתמש ב-StorageClasses המובנים בלי להגדיר אותם בעצמכם.

באשכולות אזוריים, מנהל ההתקן של CSI מקצה מכונות של Managed 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 מופיעה במאמרי העזרה של מנהל ההתקן של Managed Lustre CSI.

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

    kubectl apply -f lustre-class.yaml

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

בקטע הזה מוסבר איך ליצור משאב 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, קראו את מאמרי העזרה של מנהל ההתקן של Managed Lustre CSI.

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

    kubectl apply -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

  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 תימחק לגמרי.

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