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

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

‫1.29: זמינה לכולם
‫1.28: גרסת Preview
‫1.16: לא זמינה

אפשר להעביר את סוגי האחסון הבאים:

• אחסון לרכיבי מערכת שמנוהלים על ידי Google Distributed Cloud, כולל:

  • דיסקים של נתונים (קבצי VMDK) שמשמשים את הצמתים של מישור הבקרה של אשכולות אדמין ואת אשכולות המשתמשים של Controlplane V2

  • דיסקים לאתחול (קבצי VMDK) שמשמשים את כל הצמתים באשכול הניהול ובאשכול המשתמשים

  • נפחי vSphere שמיוצגים על ידי PV/PVC באשכול האדמין ומשמשים את רכיבי מישור הבקרה של אשכולות משתמשים של kubeception

• אחסון לעומסי עבודה שפורסים בצמתי עובדים של אשכול משתמש עם PV/PVCs שהוקצו על ידי הפלאגין של נפח vSphere בתוך העץ או על ידי מנהל התקן ה-CSI של vSphere

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

1. ל-admin cluster צריך להיות מישור בקרה עם זמינות גבוהה. אם באשכול האדמין יש מישור בקרה שאינו HA, צריך להעביר ל-HA לפני שממשיכים.

2. מוודאים שלקלאסטר האדמין יש מישור בקרה של HA:

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes
   

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

   בפלט, מוודאים שמוצגים שלושה צמתים של מישור הבקרה. לדוגמה:

   admin-cp-1   Ready    control-plane,master ...
   admin-cp-2   Ready    control-plane,master ...
   admin-cp-3   Ready    control-plane,master ...
   

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

1. צריך להשבית את התיקון האוטומטי של הצמתים באשכול. אם האפשרות לתיקון אוטומטי של הצומת מופעלת, משביתים אותה.

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

3. מוודאים שהאשכול משתמש ב-SPBM:

   kubectl --kubeconfig CLUSTER_KUBECONFIG get onpremadmincluster --namespace kube-system \
     -ojson | jq '{datastore: .items[0].spec.vCenter.datastore, storagePolicyName: .items[0].spec.vCenter.storagePolicyName}'
   

   (אשכול משתמשים בלבד) מוודאים שמאגרי הצמתים משתמשים ב-SPBM:

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremnodepools --namespace USER_CLUSTER_NAME-gke-onprem-mgmt \
     -ojson | jq '.items[] | {name: .metadata.name, datastore: .spec.vsphere.datastore, storagePolicyName: .spec.vsphere.storagePolicyName}'
   

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

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

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

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

   בפלט, אם השדה datastore ריק והשדה storagePolicyName לא ריק, המשמעות היא שהאשכול משתמש ב-SPBM.

4. אסור להשתמש באשכול בתוסף נפח האחסון vSphere in-tree.

   אם האשכול שלכם שודרג מגרסה קודמת של Google Distributed Cloud, יכול להיות שיש לו PV/PVCs שהוקצו על ידי התוסף vSphere in-tree volume. יכול להיות שסוג כזה של נפח אחסון נמצא בשימוש על ידי צומת של מישור בקרה של אשכול משתמש kubeception או על ידי עומס עבודה שיצרתם בצומת עובד.

   רשימה של כל ה-PVC וה-StorageClass שלהם:

   kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc --all-namespaces  \
      -ojson | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, storageClassName: .spec.storageClassName}'
   

   כדי להציג רשימה של כל ה-StorageClasses ולראות באילו provisioners הם משתמשים:

   kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass
   

   בפלט, אם העמודה PROVISIONER היא kubernetes.io/vsphere-volume, אז ה-PVC שנוצרו עם StorageClass הזה משתמשים בתוסף של נפח vSphere בתוך העץ. עבור StatefulSets שמשתמשים ב-PV/PVCs האלה, צריך להעביר אותם ל-vSphere CSI driver.

ביצוע העברת האחסון

‫Google Distributed Cloud תומך בשתי קטגוריות של העברת נתונים:

• ‫Storage vMotion למכונות וירטואליות, שמעביר את האחסון של המכונות הווירטואליות, כולל נפחי vSphere CNS המצורפים שמשמשים את ה-Pods שפועלים בצומת, וקובצי VMDK שמשמשים את נפחי ה-VM CNS האלה שמצורפים לצמתים

• העברה של נפח אחסון ב-CNS, שמעבירה נפחי אחסון ספציפיים ב-vSphere CNS למאגר נתונים תואם בלי לבצע אחסון vMotion למכונות וירטואליות

ביצוע אחסון vMotion למכונות וירטואליות

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

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

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

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

   מקבלים את אובייקטי המכונות באשכול:

   kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml

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

   status:
   addresses:
   – address: 172.16.20.2
     type: ExternalIP
   disks:
   – bootdisk: true
     datastore: pf-ds06
     filepath: me-xvz2ccv28bf9wdbx-2/me-xvz2ccv28bf9wdbx-2.vmdk
     uuid: 6000C29d-8edb-e742-babc-9c124013ba54
   – datastore: pf-ds06
     filepath: anthos/gke-admin-nc4rk/me/ci-bluecwang-head-2-data.vmdk
     uuid: 6000C29e-cb12-8ffd-1aed-27f0438bb9d9
   

   מוודאים שכל הדיסקים של כל המכונות באשכול הועברו למאגר הנתונים של היעד.

4. בתחנת העבודה של האדמין, מריצים את הפקודה gkectl diagnose כדי לוודא שהאשכול תקין.

שליחת קריאה לממשקי ה-API של העברת CNS כדי להעביר נפחי CNS

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

עדכון מדיניות האחסון, אם צריך

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