הגדרת אחסון ב-Distributed Cloud במודל מחובר

בדף הזה מוסבר איך להגדיר אחסון לאשכולות מחוברים של Distributed Cloud, כולל:

הגדרת Distributed Cloud במודל מחובר ל-Symcloud Storage

צמתים מחוברים של Distributed Cloud לא חושפים את האחסון המקומי שלהם ישירות לעומסי העבודה. במקום זאת, ב-Distributed Cloud connected נעשה שימוש ב-Rakuten Symcloud Storage, שהוא פתרון של צד שלישי שפועל כשכבת הפשטה של אחסון מקומי. הפתרון הזה פועל בכל צומת של Distributed Cloud connected, ומאפשר לעומסי עבודה שפועלים בכל הצמתים של Distributed Cloud connected באשכול לגשת לאחסון המקומי.

‫Container Storage Interface‏ (CSI) הוא API בתקן פתוח שנתמך על ידי הרבה ספקי אחסון גדולים. הוא מאפשר ל-Kubernetes לחשוף מערכות אחסון שרירותיות לעומסי עבודה מבוססי-קונטיינרים. ב-Distributed Cloud connected, ‏ Symcloud Storage הוא פתרון האחסון הנתמך והמנוהל של CSI. כשמפעילים את Symcloud Storage, המערכת מגדירה בשבילכם את StorageClasses הנדרשים של Kubernetes. לאחר מכן תוכלו להגדיר את עומסי העבודה כך שישתמשו בסוג האחסון המתאים.

שירות Symcloud Storage נפרס מ-Google Cloud Marketplace והוא כפוף לתנאים שמפורטים שם. ‫Google מספקת תמיכה מוגבלת בשימוש ב-Symcloud Storage עם Distributed Cloud במודל מחובר, ועשויה לפנות לספק הצד השלישי לקבלת עזרה. עדכוני התוכנה של Symcloud Storage כלולים בעדכוני התוכנה המקושרים של Distributed Cloud.

הגרסה הזו של Distributed Cloud connected מגיעה עם Symcloud Storage 6.0.0-226 ותומכת בה. אין תמיכה בגרסאות אחרות של Symcloud Storage במהדורה הזו של Distributed Cloud connected.

קבלת רישיון ל-Symcloud Storage

צריך לקבל רישיון ל-Symcloud Storage בפורמט YAML מ-Google Cloud Marketplace:

מעבר אל Marketplace

דרישות מוקדמות

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

  1. הגדרת רישום ביומן ומעקב עבור פרויקט היעד המקושר ב-Distributed Cloud.
  2. יוצרים את אשכול היעד של Distributed Cloud במודל מחובר.
  3. מגדירים את הרשת של Distributed Cloud כך ש-Pods באשכול המחובר של Distributed Cloud יוכלו להגיע למרכז הנתונים Google Cloud .
  4. צריך לקשר כל local-block נפח אחסון קבוע בכל צומת של Distributed Cloud שלא רוצים ש-Symcloud Storage יבצע לו הפשטה. אם מבטלים את הקישור של local-blockנפח אחסון מתמיד מקושר, התקנת Symcloud Storage מוחקת את התוכן של נפח האחסון המתמיד הזה. הוראות מפורטות זמינות במאמר בנושא Binding במאמרי העזרה של Kubernetes.

התקנת Symcloud Storage בצומת מחובר של Distributed Cloud

כדי להתקין את Symcloud Storage בצומת שמחובר ל-Distributed Cloud:

  1. כדי להחיל את רישיון Symcloud Storage על האשכול, משתמשים בפקודה הבאה. מחליפים את LICENSE_FILE בנתיב המלא ובשם של קובץ הרישיון של Symcloud Storage.

    kubectl apply -f LICENSE_FILE -n robin-admin

  2. כדי לבדוק את הסטטוס של שירות RobinCluster ושל כל הצמתים של Symcloud Storage, משתמשים בפקודה הבאה:

    kubectl describe robinclusters -n robinio

    הפקודה מחזירה פלט שדומה לזה:

    [...]
Status:
[...]
Phase:              Ready
robin_node_status:
[...]
 Status:           Ready
[...]
 Status:           Ready
[...]
 Status:           Ready
[...]

    הסטטוס הצפוי של השירות והצמתים הוא Ready.

הגדרת Symcloud Storage כסוג האחסון (storage class) שמוגדר כברירת מחדל

כדי להגדיר את Symcloud Storage כסוג האחסון שמוגדר כברירת מחדל באשכול שמחובר ל-Distributed Cloud, מריצים את הפקודה הבאה: מחליפים את STORAGE_CLASS באחד מסוגי האחסון של Symcloud.

kubectl patch storageclass STORAGE_CLASS -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

מידע נוסף על הגדרת סוג האחסון שמוגדר כברירת מחדל מופיע במאמר שינוי סוג האחסון שמוגדר כברירת מחדל במסמכי Kubernetes.

סוגי אחסון (storage classes) ב-Symcloud

בקטע הזה מתוארים סוגי האחסון ש-Symcloud Storage יכול להפעיל באשכול שמחובר ל-Distributed Cloud. ‫Symcloud Storage ב-Distributed Cloud connected לא תומך בrobin-rwxstorage class או בכרכים של מערכת קבצים במצב RWX עם הגדרה בהתאמה אישית. מידע נוסף על סוגי אחסון של Symcloud מופיע במאמר שימוש ב-Robin CNS ב-Kubernetes.

סוג אחסון (storage class)robin

סוג האחסון robin הוא סוג אחסון בסיסי מסוג Read Write-Once (RWO). בדוגמה הבאה מוצגת יצירה של מופע של המחלקה:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

סוג אחסון (storage class)robin-immediate

מחלקת האחסון robin-immediate זהה למחלקה robin, אלא שנפח האחסון המתמיד נוצר מיד אחרי שנוצרת דרישת נפח האחסון המתמיד התואמת. בדוגמה הבאה מוצגת יצירה של מופע של המחלקה:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-immediate
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate

סוג אחסון (storage class)robin-repl-3

‫robin-repl-3 הוא סוג אחסון RWO עם שלוש רפליקות שמתפרסות על פני כמה צמתים של Distributed Cloud. בדוגמה הבאה מוצגת יצירה של מופע של המחלקה:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-repl-3
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
parameters:
    replication: "3"
    faultdomain: host

הגדרת נפחי אחסון מופשטים של Symcloud לעומסי עבודה

בקטע הזה מובאות דוגמאות לאופן השימוש בסוגי האחסון של Symcloud כדי להגדיר אחסון מופשט לעומסי העבודה המחוברים ל-Distributed Cloud. פרטים נוספים על הגדרת נפחי אחסון של Symcloud זמינים במאמר בנושא שימוש ב-Robin CNS ב-Kubernetes.

הגדרת נפח אחסון מסוג ext4 RWO במצב מערכת קבצים

בדוגמה הבאה מוסבר איך להגדיר בקשה לנפח אחסון קבוע לנפח אחסון מסוג RWO במצב מערכת קבצים עם מערכת הקבצים ext4. מחליפים את STORAGE_CLASS באחד מסוגי האחסון של Symcloud.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-fs-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

הגדרת נפח RWO במצב בלוק

בדוגמה הבאה מוסבר איך להגדיר בקשה לנפח אחסון קבוע לנפח RWO במצב חסימה. מחליפים את STORAGE_CLASS באחד מסוגי האחסון של Symcloud.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS
  volumeMode: Block

שינוי ההגדרה של אמצעי אחסון קיים

בדוגמה הבאה אפשר לראות איך משנים את ההגדרה של נפח RWO דחוס ב-LZ4 ב-Symcloud Storage באמצעות הערות. מחליפים אתSTORAGE_CLASS באחד מסוגי האחסון של Symcloud.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: compressed-rwo-fs-pvc
  annotations:
    robin.io/compression: LZ4
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

הדוגמה הבאה ממחישה איך לשנות את התצורה של נפח RWO קיים ב-Symcloud Storage עם מערכת הקבצים xfs באמצעות הערות. מחליפים אתSTORAGE_CLASS באחד מסוגי האחסון של Symcloud.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-xfs-pvc
  annotations:
    robin.io/fstype: xfs
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

הגדרת לקוח ה-CLI של Symcloud Storage

‫Symcloud Storage מספק לקוח של ממשק שורת פקודה (CLI) שבו אפשר להשתמש כדי לנהל את ההגדרות של Symcloud Storage. כדי להגדיר את הלקוח באשכול המחובר של Distributed Cloud, צריך לבצע את השלבים הבאים:

  1. מקבלים את נתיב התמונה של Symcloud Storage שמשמש את מופע השירות RobinCluster שנפרס באשכול המחובר של Distributed Cloud, ומגדירים את משתני הסביבה באופן הבא:

    image_robin=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_robin}')
image_registry_path=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_registry_path}')
ROBIN_CNS_IMAGE="$image_registry_path/$image_robin"

  2. יוצרים משאב robincli עם התוכן הבא:

    kind: Deployment
apiVersion: apps/v1
metadata:
 name: robincli
 namespace: default
 labels:
   name: robincli
spec:
 replicas: 1
 selector:
   matchLabels:
     name: robincli
 template:
   metadata:
     annotations:
       product: robin
     labels:
       name: robincli
   spec:
     containers:
     - name: robincli
       image: ROBIN_CNS_IMAGE
       workingDir: /root
       command: ["/bin/bash","-c","mkdir -p /root/.robin; ln -s -t /usr/lib/python3.7/site-packages/ /opt/robin/current/python3/site-packages/robincli /opt/robin/current/python3/site-packages/stormgr_def.py /opt/robin/current/python3/site-packages/stormgr_lib.py; /opt/robin/current/bin/robin client add-context robin-master.robinio --set-current; while true; do sleep 10000; done"]
       resources:
         requests:
           memory: "10Mi"
           cpu: "100m"

    מחליפים את ROBIN_CNS_IMAGE בנתיב המלא של המאגר ובשם של האימג' שקיבלתם בשלב 1.

  3. מחילים את המשאב robincli על האשכול המחובר שלכם ב-Distributed Cloud.

  4. במהלך ההתקנה הראשונית, Symcloud Storage יוצר סוד במרחב השמות robinio עם סיסמה אקראית.default-admin-user כדי לקבל את פרטי הכניסה האלה, משתמשים בפקודות הבאות:

    1. משיגים את שם המשתמש:

      kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.username}' | base64 -d

    2. משיגים את הסיסמה:

       
kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.password}' | base64 -d

  5. מתחברים ל-Pod שנוצר ומריצים את הלקוח:

    kubectl exec -it robincli -- bash

הפניה לסוג האחסון (storage class) ב-StatefulSet

בדוגמה הבאה אפשר לראות איך מפנים לסוג אחסון (storage class) Symcloud Storage בעומס עבודה של StatefulSet.

בדוגמה הזו אנחנו מניחים שאתם משתמשים בסוג אחסון robin-repl-3 שהוגדר מראש, שמספקת נפחי אחסון שמשוכפלים בשלושה צמתי עובדים נפרדים כדי להבטיח זמינות גבוהה.

כשמגדירים StatefulSet לזמינות גבוהה, כדאי לכלול בהגדרה את השיטות המומלצות הבאות:

  • שירות ללא ראש: ל-StatefulSet נדרש שירות ללא ראש תואם לשדה serviceName. שירות ללא GUI הוא שירות עם clusterIP: None. השירות הזה מקצה שמות מארחים יציבים של DNS לכל Pod בסט.
  • Pod anti-affinity: אם משתמשים בסוג אחסון משוכפל כמו robin-repl-3, הנתונים משוכפלים בצורה בטוחה בכמה צמתי עובד. עם זאת, אם Kubernetes מתזמן את כל ה-Pods של האפליקציה שלכם באותו צומת עובד, הפסקת פעולה של צומת יחיד עלולה להשבית את האפליקציה. הגדרת אנטי-אפיניות של Pod מבטיחה שה-Pods יפוזרו על פני צמתי עובדים נפרדים, כך שזמינות המחשוב תתאים ליתירות האחסון.

בדוגמה הבאה מוצגת הגדרה מלאה שכוללת את Headless Service ‏(nginx) ו-StatefulSet שהוגדר עם Pod anti-affinity שמפנה לסוג האחסון (storage class) robin-repl-3. אם דרישות האחסון של עומס העבודה גדלות עם הזמן, אפשר לשנות את הגודל של אמצעי האחסון באופן דינמי על ידי עריכת בקשת האחסון ב-PersistentVolumeClaim.

statefulset.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates: # Reference the storage class in this specification
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi # Symcloud Storage classes support dynamic volume expansion if more storage is needed
      storageClassName: robin-repl-3 # References the Symcloud storage class

המגבלות של Symcloud Storage

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

הסרת צמתים שמשתמשים ב-Symcloud Storage מאשכול

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

  • אם אתם מפרקים את כל האשכול, צריך להסיר את עומסי העבודה ואת הכרכים המתאימים של Symcloud Storage Persistent Volumes לפני שמפרקים את האשכול עצמו.
  • אם מסירים צמתים ספציפיים מהאשכול, צריך להעביר את נתוני עומס העבודה שמאוחסנים בצמתים האלה לפני שמסירים אותם מהאשכול. הוראות מפורטות מופיעות במאמר העברת נפחים מדיסק.

הגדרת סכימות של אחסון מקומי

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

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

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

הגדרת מחיצות בסכימת אחסון מקומי

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

למחיצה יש את המאפיינים הבאים:

  • גודל. אפשר לציין את גודל המחיצה בבייטים בינאריים, או להגדיר שהמחיצה תשתמש בכל השטח שנותר בדיסק המקומי.
  • סוג. אתם יכולים להגדיר מחיצה כנפח אחסון מתמיד (PV) של Kubernetes או כנפח אחסון מקומי של Linux בדיסק המקומי.
  • מצב. אתם יכולים להגדיר את עוצמת הקול שמאוחסנת במחיצה כעוצמת קול של בלוק או כעוצמת קול של מערכת קבצים. במחיצות של נפח אחסון קבוע, סוג האחסון (storage class) של המחיצה הוא local-block או local-disks, בהתאמה. במחיצות של נפח מקומי, אפשר לציין את נקודות הקישור והטעינה של מערכות הקבצים הכלולות.

בקשה לסכימת אחסון מקומית

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

כשנקבל את הבקשה שלכם, נריץ סדרה של בדיקות כדי לוודא שהסכימה חזקה, ואז ניצור אותה באשכול המחובר שלכם ב-Distributed Cloud.

סכימות ברירת מחדל של אחסון מקומי

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

  • ‫default_control_plane_node. הסכימה הזו מגדירה את המחיצות הבאות:

    • מחיצה של נפח מקומי בגודל 100GB במצב מערכת קבצים.
    • מחיצה של נפח אחסון מתמיד במצב בלוק שתופסת את שטח האחסון הפנוי שנותר.

  • ‫default_worker_node. הסכימה הזו מגדירה מחיצה של נפח אחסון מתמיד בנפח 410GB במצב בלוק.

החלת סכימת אחסון מקומית על אשכול

כדי להחיל סכימת אחסון מקומית על אשכול מחובר של Distributed Cloud, מבצעים אחת מהפעולות הבאות:

  • כדי להחיל סכימת אחסון מקומית על צמתי מישור הבקרה של האשכול, משתמשים בדגל --control-plane-node-storage-schema כשיוצרים את האשכול. מידע נוסף מופיע במאמר בנושא יצירת אשכול.

  • כדי להחיל סכימת אחסון מקומית על צמתי העובדים של האשכול, משתמשים ב---node-storage-schema כשיוצרים מאגר צמתים לאשכול. מידע נוסף זמין במאמר בנושא יצירת מאגר צמתים.

‫Distributed Cloud connected יוצר את המחיצות שמוגדרות בסכימת האחסון המקומית אחרי שהאשכול או מאגר הצמתים נוצרים בהצלחה.

פתרון בעיות

אם PersistentVolumeClaims נשארים בהמתנה באופן לא צפוי או שעומסי עבודה לא מצליחים לצרף נפחים, מריצים את השלבים לפתרון בעיות שמפורטים בקטע הזה.

הסטטוס של PersistentVolumeClaims נשאר pending

אם ה-PersistentVolumeClaims נשארים במצב Pending, צריך לבדוק את volumeBindingMode של סוג אחסון. בסוגי אחסון שהוגדרו מראש ב-Symcloud נעשה שימוש ב-volumeBindingMode: WaitForFirstConsumer, שגורם לעיכוב בהקצאת נפח האחסון עד שה-Pod שמפנה לתביעה מתוזמן. מוודאים ש-Pod של עומס העבודה מתוזמן בהצלחה.

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

אימות התקינות של מישור הבקרה

כדי לוודא שמטוס הבקרה של Symcloud Storage תקין ומוכן להקצאת נפחי אחסון, מריצים את הפקודה kubectl describe כדי לבדוק את הסטטוס של המשאב המותאם אישית RobinCluster:

kubectl describe robinclusters -n robinio

בפלט פקודה, מוודאים ש-Phase הוא Ready.

אימות תקינות של שד האחסון

כדי לוודא שכל ה-Pods של דמון האחסון ברמת הצומת פועלים, מריצים את הפקודה kubectl get:

kubectl get pods -n robinio

בפלט פקודה, מוודאים שכל ה-Pods נמצאים במצב Running. אם עומס עבודה מתוזמן בצומת עם Pod של דמון אחסון שנכשל, צירוף אמצעי האחסון נתקע בלי קשר לסטטוס המרכזי של RobinCluster.

יצירת קשר עם התמיכה

אם סטטוס מישור הבקרה של Symcloud Storage הוא לא Ready או שאף אחד מהפודים של דמון האחסון לא במצב Running, פנו לתמיכה של Google. כשפותחים כרטיס תמיכה, צריך לספק את התוצאות של פקודות פתרון הבעיות שהפעלתם.