העברת מאגר נתונים ל-SPBM

במאמר הזה מוסבר איך להעביר מאגר נתונים של vSphere אל ניהול מבוסס מדיניות אחסון (SPBM).

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

‫1.30: GA
‫1.29: תצוגה מקדימה
‫1.16 וגרסאות קודמות: לא זמין

הקשר

יש ארבעה מקומות שבהם אפשר לציין מאגר נתונים בקובצי התצורה של האשכול:

• קלאסטר אדמין: vCenter.datastore

• אשכול משתמשים ברמת האשכול, שכולל צמתים של מישור הבקרה וכל מאגרי צמתים של עובדים: vCenter.datastore

• צמתים של מישור הבקרה באשכול משתמשים: masterNode.vsphere.datastore

• מאגרי צמתים עובדים של אשכול משתמש: ‫nodePools[i].vsphere.datastore

ההורשה של השדות האלה היא כדלקמן:

adminCluster.vCenter.datastore ->
  userCluster.vCenter.datastore ->
    (userCluster.masterNode.vsphere.datastore and userCluster.nodePools[i].vsphere.datastore)

דוגמאות:

• אם userCluster.vCenter.datastore ריק, הוא מקבל את הערך מ-adminCluster.vCenter.datastore.

• אם userCluster.nodePools[i].vsphere.datastore ריק, הוא מקבל בירושה את הערך מ-userCluster.vCenter.datastore.

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

• אשכול אדמין vCenter.storagePolicyName

• אשכול משתמשים ברמת האשכול, שכולל צמתים של מישור הבקרה וכל מאגרי הצמתים של העובדים: vCenter.storagePolicyName

• צמתים של מישור הבקרה באשכול משתמש: masterNode.vsphere.storagePolicyName

• מאגרי צמתים של Worker באשכול משתמש: nodePools[i].vsphere.storagePolicyName

ההורשה של השדות storagePolicyName זהה להורשה של השדות datastore.

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

• התהליך הזה הוא העברה חד-כיוונית. אנחנו לא תומכים בהעברה חזרה למצב הקודם.
• מאגר הנתונים צריך להיות תואם למדיניות האחסון החדשה שאתם עומדים להגדיר.
• יש תמיכה רק באשכולות אדמין עם זמינות גבוהה (HA). אם אשכול האדמין שלכם הוא אדמין ללא זמינות גבוהה, אתם צריכים קודם להעביר את אשכול האדמין לזמינות גבוהה.

העברת אשכול משתמשים

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

כדי לעזור לכם לתכנן חלון זמן לתחזוקה, כדאי לשים לב לנקודות הבאות:

• כדי להעביר את כל האשכול, צריך לעדכן רק אשכול אחד.

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

כל האשכול

אפשר להשתמש בשלבים האלה אם רוצים להעביר את כל האשכול, כולל כל הצמתים של מישור הבקרה ומאגרי הצמתים של העובדים. גרסת אשכול המשתמשים צריכה להיות 1.30 ומעלה.

1. משנים את קובץ התצורה של אשכול המשתמשים באופן הבא:

   1. מגדירים את השדה vCenter.storagePolicyName עם השם של מדיניות האחסון.

   2. אם מצוינים הערכים הבאים, צריך להסיר אותם או להוסיף להם הערה:

      • vCenter.datastore שדה
      • קטע של masterNode.vsphere
      • nodepools[i].vsphere.datastore
      • nodepools[i].vsphere.storagePolicyName

   בדוגמאות הבאות של הגדרות אפשר לראות את השינויים האלה.

   לפני השינויים:

   vCenter:
     datastore: ds-1
   

   אחרי השינויים:

   vCenter:
     storagePolicyName: sp-1
     # datastore: ds-1
   

2. מעדכנים את אשכול המשתמשים:

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config USER_CLUSTER_CONFIG
   

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

   • ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

   • ‫USER_CLUSTER_CONFIG: הנתיב של קובץ התצורה של אשכול המשתמשים.

עדכון של StorageClass בחבילה

אחרי שמעדכנים את הגדרות התצורה באשכול, צריך לעדכן את StorageClass שכלול בחבילה.

1. מקבלים את ברירת המחדל הנוכחית StorageClass של החבילה vsphere-csi-driver, שנקראת standard-rwo, ושומרים אותה בקובץ מקומי בשם storage-class.yaml.

   kubectl get storageclass standard-rwo -oyaml \
       --kubeconfig USER_CLUSTER_KUBECONFIG > storage-class.yaml
   

   מחליפים את USER_CLUSTER_KUBECONFIG בנתיב של קובץ ה-kubeconfig של אשכול המשתמשים.

2. כדאי ליצור עותק של storage-class.yaml למקרה שתצטרכו לבצע שינויים בקובץ:

   cp storage-class.yaml storage-class.yaml-backup.yaml
   

3. מחיקת ברירת המחדל StorageClass מהאשכול:

   kubectl delete storageclass standard-rwo \
       --kubeconfig USER_CLUSTER_KUBECONFIG
   

4. מעדכנים את ההגדרה ב-storage-class.yaml באופן הבא:

   1. מוחקים את השדות הבאים או מוסיפים להם הערות:

      • parameters.datastoreURL
      • resourceVersion

   2. מוסיפים את השדה parameters.storagePolicyName ומגדירים אותו לשם של מדיניות האחסון.

   בדוגמאות הבאות של הגדרות אפשר לראות את השינויים האלה.

   לפני השינויים:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     datastoreURL: ds//ds-1
   

   אחרי השינויים:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     storagePolicyName: sp-1
   

5. מחילים את StorageClass ששיניתם על אשכול המשתמשים:

   kubectl apply -f storage-class.yaml \
       --kubeconfig USER_CLUSTER_KUBECONFIG
   

רק אשכולות משתמשים של Kubeception

באשכולות משתמשים של Kubeception, צריך לעדכן את StorageClass עבור צמתי מישור הבקרה של אשכול המשתמש באשכול הניהול. ב-Kubeception clusters, שדה ההגדרה enableControlplaneV2 מוגדר ל-false. כשהאפשרות Controlplane V2 מופעלת, מישור הבקרה של אשכול המשתמשים פועל באשכול המשתמשים עצמו. אם Controlplane V2 לא מופעל, מישור הבקרה של אשכול המשתמשים פועל באשכול האדמין, שנקרא kubeception.

מריצים את הפקודה הבאה כדי לבדוק אם Controlplane V2 מופעל באשכול:

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

אם הפלט הוא false, צריך לבצע את השלבים הבאים כדי לעדכן את ברירת המחדל StorageClass עבור הצמתים של מישור הבקרה של אשכול המשתמשים באשכול הניהול:

1. מקבלים את ברירת המחדל הנוכחית StorageClass עבור החבילה vsphere-csi-driver, שנקראת USER_CLUSTER_NAME-csi, ושומרים אותה בקובץ מקומי בשם storage-class-kubeception.yaml.

   kubectl get storageclass USER_CLUSTER_NAME-csi -oyaml \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG > storage-class-kubeception.yaml
   

   מחליפים את ADMIN_CLUSTER_KUBECONFIG בנתיב של קובץ ה-kubeconfig של אשכול האדמין.

2. כדאי ליצור עותק של storage-class-kubeception.yaml למקרה שתצטרכו לבצע שינויים בקובץ:

   cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml
   

3. מחיקת ברירת המחדל StorageClass מהאשכול:

   kubectl delete storageclass USER_CLUSTER_NAME-csi \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

4. מעדכנים את ההגדרה ב-storage-class-kubeception.yaml באופן הבא:

   1. מוחקים את השדות הבאים או מוסיפים להם הערות:

      • parameters.datastoreURL
      • resourceVersion

   2. מוסיפים את השדה parameters.storagePolicyName ומגדירים אותו לשם של מדיניות האחסון.

   בדוגמאות הבאות של הגדרות אפשר לראות את השינויים האלה.

   לפני השינויים:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     datastoreURL: ds//ds-1
   

   אחרי השינויים:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     storagePolicyName: sp-1
   

5. מחילים את השינוי ב-StorageClass על אשכול האדמין:

   kubectl apply -f storage-class-kubeception.yaml \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

אחרי המיגרציה

אם יוצרים מאגר צמתים חדש אחרי העברה, המאגר החדש פועל לפי כללי הירושה בהתאם לאשכול המעודכן.

לדוגמה, נניח שהעברתם את vCenter.datastore למדיניות אחסון.

עכשיו, אם יוצרים מאגר חדש של צמתים ומשאירים את nodePools[i].vsphere.datastore ואת nodePools[i].vsphere.storagePolicyName ריקים, מאגר הצמתים החדש יקבל בירושה את מדיניות האחסון שצוינה ב-vCenter.storagePolicyName.

צמתים בנפרד

אם רוצים להעביר את הצמתים של מישור הבקרה ואת מאגרי הצמתים של העובדים בנפרד, צריך לבצע את השלבים הבאים.

1. גרסה 1.29 בלבד: אחזור של הגדרת האשכול הנוכחית. השלב הזה לא נדרש אם אשכול המשתמשים הוא בגרסה 1.30 ומעלה.

   gkectl get-config cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --cluster-name USER_CLUSTER_NAME \
     --output-dir ./gen-files
   

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

   • ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב של קובץ ה-kubeconfig של אשכול האדמין.

   • ‫USER_CLUSTER_NAME: השם של אשכול המשתמשים.

   ב./gen-files, מאתרים את user-cluster.yaml.

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

   שם קובץ התצורה שנוצר הוא datastore בכל רמה: אשכול, masterNode (לצמתי מישור הבקרה) ו-nodepools (לצמתי העובד), כמו בדוגמה הבאה:

   apiVersion: v1
   kind: UserCluster
   ...
   # VCenter config in cluster level:
   vCenter:
     datastore: ds-1
   ...
   # VCenter config in master node level:
   masterNode:
     vsphere:
       datastore: ds-1
   ...
   # VCenter config in nodepool level:
   nodepools:
   - name: pool-1
     vsphere:
       datastore: ds-1
   - name: pool-2
     vsphere:
       datastore: ds-1
   

העברת צמתים של מישור הבקרה

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

1. מבצעים את השינויים הבאים בקובץ התצורה של אשכול המשתמשים:

   • מגדירים את השדה masterNode.vsphere.storagePolicyName עם השם של מדיניות האחסון.
   • מוחקים את השדה masterNode.vsphere.datastore או הופכים אותו לתגובה.

   בדוגמאות הבאות של הגדרות אפשר לראות את השינויים האלה.

   לפני השינויים:

   masterNode:
     vsphere:
       datastore: ds-1
   

   אחרי השינויים:

   masterNode:
     vsphere:
       # datastore: ds-1
       storagePolicyName: sp-1
   

2. מעדכנים את אשכול המשתמשים:

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config USER_CLUSTER_CONFIG
   

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

   • ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

   • ‫USER_CLUSTER_CONFIG: הנתיב של קובץ התצורה של אשכול המשתמשים.

   צריך לחכות שפקודת העדכון תושלם לפני שמעדכנים את מאגרי הצמתים.

העברת מאגרי צמתים

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

1. מבצעים את השינויים הבאים בקובץ התצורה של אשכול המשתמשים:

   • מגדירים כל שדה nodePools[i].vsphere.storagePolicyName עם השם של מדיניות האחסון.
   • מוחקים כל שדה nodePools[i].vsphere.datastore או מוסיפים לו הערה.

   בדוגמאות הבאות של הגדרות אפשר לראות את השינויים האלה.

   לפני השינויים:

   nodepools:
   - name: pool-1
     vsphere:
       datastore: ds-1
   - name: pool-2
     vsphere:
       datastore: ds-1
   

   אחרי השינויים:

   nodepools:
   - name: pool-1
     vsphere:
       # datastore: ds-1
       storagePolicyName: sp-1
   - name: pool-2
     vsphere:
       # datastore: ds-1
       storagePolicyName: sp-1
   

2. מעדכנים את אשכול המשתמשים:

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config USER_CLUSTER_CONFIG
   

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

בקטע vCenter ברמת האשכול, השדות datastore ו-storagePolicyName הם ערכי ברירת מחדל שמשמשים בקטעים masterNode ו-nodepools. אחרי שמבצעים את השלבים הקודמים, רכיבי האשכול לא משתמשים בהגדרות vCenter datastore ו-storagePolicyName ברמת האשכול. אפשר להשאיר את הקטע vCenter ברמת האשכול כמו שהוא או לעדכן אותו כך שיהיה זהה לערכים של masterNode ושל nodepools.

אם משאירים את ההגדרה כמו שהיא, מומלץ להוסיף הערה מעל הקטע vCenter ברמת האשכול, ולציין שהמערכת מתעלמת מההגדרה כי היא מוחלפת בהגדרות שבקטעים masterNode ו-nodepools.

אם רוצים, אפשר לשנות את הקטע vCenter ברמת האשכול כך שיתאים לקטעים masterNode ו-nodepools, ולעדכן את האשכול באמצעות השלבים הבאים:

1. משנים את קובץ התצורה של אשכול המשתמשים באופן הבא:

   • מגדירים את השדה vCenter.storagePolicyName עם השם של מדיניות האחסון.
   • מסירים את השדה vCenter.datastore או הופכים אותו לתגובה.

2. מעדכנים את אשכול המשתמשים:

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config USER_CLUSTER_CONFIG
   

   פקודת העדכון הזו לא תבצע שינויים באשכול, אבל היא תעדכן את השדות בצד השרת (OnPremUserCluster) vCenter.datastore ו-vCenter.storagePolicyName.

עדכון של StorageClass בחבילה

אחרי שמעדכנים את הגדרות התצורה, צריך לעדכן את החבילה StorageClass.

1. מקבלים את ברירת המחדל הנוכחית StorageClass של החבילה vsphere-csi-driver, שנקראת standard-rwo, ושומרים אותה בקובץ מקומי בשם storage-class.yaml.

   kubectl get storageclass standard-rwo -oyaml \
       --kubeconfig USER_CLUSTER_KUBECONFIG > storage-class.yaml
   

   מחליפים את USER_CLUSTER_KUBECONFIG בנתיב של קובץ ה-kubeconfig של אשכול המשתמשים.

2. כדאי ליצור עותק של storage-class.yaml למקרה שתצטרכו לבצע שינויים בקובץ:

   cp storage-class.yaml storage-class.yaml-backup.yaml
   

3. מחיקת ברירת המחדל StorageClass מהאשכול:

   kubectl delete storageclass standard-rwo \
       --kubeconfig USER_CLUSTER_KUBECONFIG
   

4. מעדכנים את ההגדרה ב-storage-class.yaml באופן הבא:

   1. מוחקים את השדות הבאים או מוסיפים להם הערות:

      • parameters.datastoreURL
      • resourceVersion

   2. מוסיפים את השדה parameters.storagePolicyName ומגדירים אותו לשם של מדיניות האחסון.

   בדוגמאות הבאות של הגדרות אפשר לראות את השינויים האלה.

   לפני השינויים:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     datastoreURL: ds//ds-1
   

   אחרי השינויים:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     storagePolicyName: sp-1
   

5. מחילים את StorageClass ששיניתם על אשכול המשתמשים:

   kubectl apply -f storage-class.yaml \
       --kubeconfig USER_CLUSTER_KUBECONFIG
   

רק אשכולות משתמשים של Kubeception

באשכולות משתמשים של Kubeception, צריך לעדכן את StorageClass עבור צמתי מישור הבקרה של אשכול המשתמש באשכול הניהול. ב-Kubeception clusters, שדה ההגדרה enableControlplaneV2 מוגדר ל-false. כשהאפשרות Controlplane V2 מופעלת, מישור הבקרה של אשכול המשתמשים פועל באשכול המשתמשים עצמו. אם Controlplane V2 לא מופעל, מישור הבקרה של אשכול המשתמשים פועל באשכול האדמין, שנקרא kubeception.

מריצים את הפקודה הבאה כדי לבדוק אם Controlplane V2 מופעל באשכול:

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

אם הפלט הוא false, צריך לבצע את השלבים הבאים כדי לעדכן את ברירת המחדל StorageClass עבור הצמתים של מישור הבקרה של אשכול המשתמשים באשכול הניהול:

1. מקבלים את ברירת המחדל הנוכחית StorageClass עבור החבילה vsphere-csi-driver, שנקראת USER_CLUSTER_NAME-csi, ושומרים אותה בקובץ מקומי בשם storage-class-kubeception.yaml.

   kubectl get storageclass USER_CLUSTER_NAME-csi -oyaml \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG > storage-class-kubeception.yaml
   

   מחליפים את ADMIN_CLUSTER_KUBECONFIG בנתיב של קובץ ה-kubeconfig של אשכול האדמין.

2. כדאי ליצור עותק של storage-class-kubeception.yaml למקרה שתצטרכו לבצע שינויים בקובץ:

   cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml
   

3. מחיקת ברירת המחדל StorageClass מהאשכול:

   kubectl delete storageclass USER_CLUSTER_NAME-csi \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

4. מעדכנים את ההגדרה ב-storage-class-kubeception.yaml באופן הבא:

   1. מוחקים את השדות הבאים או מוסיפים להם הערות:

      • parameters.datastoreURL
      • resourceVersion

   2. מוסיפים את השדה parameters.storagePolicyName ומגדירים אותו לשם של מדיניות האחסון.

   בדוגמאות הבאות של הגדרות אפשר לראות את השינויים האלה.

   לפני השינויים:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     datastoreURL: ds//ds-1
   

   אחרי השינויים:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     storagePolicyName: sp-1
   

5. מחילים את השינוי ב-StorageClass על אשכול האדמין:

   kubectl apply -f storage-class-kubeception.yaml \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

העברת אשכול אדמין

מוודאים שגם אשכול האדמין מעודכן עם שם מדיניות האחסון.

1. מבצעים את השינויים הבאים בקובץ התצורה של אשכול האדמין:

   • מסירים את השדה vCenter.datastore או הופכים אותו לתגובה.
   • מגדירים את השדה vCenter.storagePolicyName עם השם של מדיניות האחסון.

2. מעדכנים את אשכול האדמין:

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config ADMIN_CLUSTER_CONFIG
   

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

   • ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
   • ‫ADMIN_CLUSTER_CONFIG: הנתיב לקובץ התצורה של אשכול האדמין.

העברת אחסון באמצעות SPBM

אחרי העברת מאגר הנתונים ל-SPBM, האשכולות שלכם משתמשים עכשיו ב-SPBM. אבל ההעברה לא מעבירה עומסי עבודה של אחסון (כמו דיסקים של נתוני מכונה או נפחים של קונטיינרים) ממאגר הנתונים הישן.

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