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

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

תמיכה בכמה כרטיסי NIC לרשתות עתירות ביצועים

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

כדי להשתמש בתמיכה בכרטיסי רשת מרובים, הצמתים צריכים לעמוד בדרישות הבאות:

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

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

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

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

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

  7. מחברים את ה-peering.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי להשתמש ברשתות בעלות ביצועים גבוהים, צריך ליצור מאגר צמתים עם סוג מכונה שתומך בממשקי רשת מרובים. התמיכה בכמה כרטיסי 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, שמשמש לעיתים קרובות עם כרטיסי רשת מרובים לביצועים גבוהים. יש תמיכה בכרטיסי NIC מרובים בכל סוגי המכונות.
  • ‫NETWORK_NAME: השם של רשת ה-VPC.
  • ‫SECONDARY_SUBNET: השם של תת-הרשת המשנית.

השבתה של כרטיסי רשת מרובים ב-Lustre

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

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

באשכול

כדי להשבית את הרשתות עם הביצועים הגבוהים בכל האשכול, משתמשים בדגל --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: האזור של האשכול.

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

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

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

אחרי שמשביתים את מנהל ההתקן של CSI, ‏ GKE יוצר מחדש באופן אוטומטי את הצמתים ומסיר את מודולי הליבה המנוהלים של 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 של Lustre מנוהל.

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

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