בדף הזה מוסבר איך להעביר ארגון Apigee Hybrid מאשכול Kubernetes אחד לאשכול אחר. הנה כמה מקרים שבהם יכול להיות שתצטרכו להעביר ארגון לאשכול אחר:
- למרכז הנתונים שמארח את האשכול הקיים אין יותר קיבולת, או שהוא יוצא משימוש.
- האשכול מריץ תשתית ישנה או גרסה ישנה של Kubernetes, ואתם רוצים להעביר אותו לאשכול עם תשתית חדשה יותר.
- אתם רוצים להעביר ארגונים מאשכולות של כמה ארגונים לאשכולות נפרדים.
חשוב לזכור שיש סיכונים ומגבלות כשמעבירים ארגון לאשכול היברידי אחר. לפני שמבצעים העברה, חשוב לקרוא את הפרטים בקטע מגבלות.
מגבלות
המגבלות הבאות חלות כשמעבירים ארגון היברידי לאשכול Kubernetes אחר:
- קיים סיכון לאובדן נתונים כשמעבירים נתונים של הארגון לאשכול Kubernetes חדש. לפני שמבצעים העברה של ארגון, צריך לגבות את הנתונים של כל הארגונים באשכול Kubernetes באמצעות ההוראות לגיבוי היברידי.
- גודל הנתונים המקסימלי שנתמך בהעברת ארגון הוא 5GB בכל מרחבי המפתחות של הארגון, לא כולל מטמון ומכסה.
- נתוני מטמון לא יועברו. הגרסה ההיברידית בונה מחדש את נתוני המטמון.
- נתוני המכסה לא יועברו. הנתונים של מכסת השימוש מתאפסים ב-Hybrid.
- אפשר להעביר ארגונים רק לאשכול Kubernetes שלא מכיל פריסה היברידית קיימת. אין תמיכה בהעברה לאשכול עם פריסה היברידית קיימת.
- אפשר להעביר את הארגון שמועבר רק לאשכול חדש עם פריסה באזור יחיד. אחרי שהפריסה באזור יחיד תפעל, תוכלו להרחיב את הפריסה לאזורים אחרים באמצעות התהליך שמתואר במאמר פריסה במספר אזורים.
- אוסף Cassandra צריך לפעול בצורה תקינה בכל האזורים.
העברת ארגון
כדי להעביר ארגון היברידי מאשכול Kubernetes אחד לאשכול אחר, פועלים לפי ההוראות הבאות:
- אם הגיבויים עדיין לא מופעלים, מפעילים אותם באשכול Kubernetes שמכיל את הארגון ההיברידי שרוצים להעביר. מידע על גיבויים היברידיים זמין במאמר בנושא סקירה כללית על גיבוי של Cassandra.
- מפעילים עבודת גיבוי היברידית באמצעות הפקודה הבאה:
kubectl create job -n APIGEE_NAMESPACE --from=cronjob/apigee-cassandra-backup <backup job name>
<backup job name>יכול להיות כל שם קונטיינר תקין. - אחרי שמשימת הגיבוי מסתיימת, צריך לפעול לפי ההוראות בקטעים הבאים של מעקב אחרי גיבויים כדי לוודא שהגיבוי הסתיים בהצלחה:
- 'בדיקת הסטטוס של משימת הגיבוי'
- 'בדיקת יומני הגיבוי'
- אחרי שמוודאים שהגיבוי בוצע בהצלחה, רושמים את מספר המזהה בסוף יומן הגיבוי.
לדוגמה, יומן גיבוי מוצלח צריך להכיל שורה כמו הבאה:
רושמים את המספר הרב-ספרתי בסוף השורה. תצטרכו את המספר הזה בהמשך.INFO: completed upload for 20230207004250
- מעבירים את ההקשר של Kubernetes לאשכול היעד של Kubernetes:
kubectl config use-context <destination cluster name> # <destination cluster name>
כאשר
<destination cluster name>הוא השם של אשכול היעד של Kubernetes. - משחזרים את נתוני הגיבוי לאשכול היעד של Kubernetes באמצעות ההוראות שבמאמר בנושא
שחזור באזור יחיד.
- משתמשים בקובץ overrides.yaml עבור הארגון שמועבר לפריסה ההיברידית של היעד.
- חשוב לזכור להגדיר את הערך
restore:snapshotTimestampלמספר הרב-ספרתי שמוצג ביומן הגיבוי בשלב 4. מידע נוסף זמין במאמר בנושא שחזור באזור יחיד.
- אחרי שהשחזור יסתיים, צריך למחוק את כל נתוני הארגון, מלבד הנתונים של הארגון שמועבר, מאשכול היעד של Kubernetes. קבצים של גיבוי היברידי מכילים את הנתונים של כל הארגונים, כולל כאלה שאולי לא תרצו להעביר. אחרי שמשחזרים את הפריסה ההיברידית של היעד, צריך להסיר את כל נתוני הארגון הנוספים שהועתקו לפריסה, באמצעות השלבים הבאים:
- מוודאים שההקשר הנוכחי הוא ההקשר הנכון עבור אשכול היעד של Kubernetes:
kubectl config current-context
- מריצים את הפקודה exec אל הפוד
apigee-cassandra-default-0:kubectl exec -it -n APIGEE_NAMESPACE apigee-cassandra-default-0 -- /bin/bash
- מריצים את הפקודה הבאה:
find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*<migrated org name>*' -type d -maxdepth 2 -printf "%f\n"
הוראות למציאת
<migrated org name>זמינות במאמר איך מקבלים את השם של הארגון שהועבר.מעתיקים את רשימת כל השמות שמופיעים בפלט. תצטרכו את הרשימה הזו בשלב 7. ו.
- יוצאים מהתרמיל
apigee-cassandra-default-0. - יוצרים פוד של לקוח לניפוי באגים ב-Cassandra לפי ההוראות במאמר בנושא
יצירת קונטיינר של לקוח לניפוי באגים. אחרי שמקבלים הנחיה
cqlsh, עוברים לשלב הבא. - מריצים את הפקודות הבאות בהנחיה
cqlsh:-
desc keyspaces;
מוודאים שהפקודה הזו לא מחזירה שגיאות.
- לכל שם ברשימה שנוצרה בשלב 7. ג., מריצים את הפקודה הבאה:
drop keyspace <name>
-
- יוצאים מ-pod של לקוח לניפוי באגים ב-Cassandra.
- אחרי שמריצים את הפקודות
cqlsh, מריצים את הפקודות הבאות בכל ה-pods של Cassandra באשכול היעד של Kubernetes:kubectl exec -it -n APIGEE_NAMESPACE
-- /bin/bash find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*<migrated org name>*' -type d -maxdepth 2
הוראות למציאת
<migrated org name>מפורטות במאמר איך מקבלים את השם של הארגון שהועבר.find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*
*' -type d -maxdepth 2 -exec rm -rf {} +
- יוצאים מ-Cassandra pod.
- מוודאים שההקשר הנוכחי הוא ההקשר הנכון עבור אשכול היעד של Kubernetes:
- מעבירים את ההקשר של Kubernetes לאשכול Kubernetes של המקור:
kubectl config use-context <source cluster name>
כאשר
<source cluster name>הוא השם של אשכול Kubernetes של המקור. - מוחקים את הארגון שהועבר מאשכול Kubernetes של המקור. חשוב להשתמש בקובץ
overrides.yamlשל הארגון בפקודת המחיקה:- מוודאים שההקשר הנוכחי הוא ההקשר הנכון עבור אשכול Kubernetes של המקור:
kubectl config current-context
אם צריך, מגדירים את ההקשרים של Kubernetes לאשכול ולארגון שצריך להוציא משימוש.
כדי לראות את שם ההקשר של כל אשכול, מריצים את הפקודה הבאה:
kubectl config get-contexts
מגדירים את ההקשר לאשכול ולתחום שרוצים להוציא משימוש:
kubectl config use-context CONTEXT_NAME
כאשר CONTEXT_NAME הוא שם ההקשר של האשכול והאזור.
לדוגמה:
kubectl config get-contextsCURRENT NAME CLUSTER AUTHINFO NAMESPACE gke_example-org-1_us-central1_example-cluster-1 gke_example-org-1_us-central1_example-cluster-1 gke_example-org-1_us-central1_example-cluster-1 apigee * gke_example-org-1_us-central1_example-cluster-2 gke_example-org-1_us-central1_example-cluster-2 gke_example-org-1_us-central1_example-cluster-2 apigee gke_example-org-1_us-west1_example-cluster-2 gke_example-org-1_us-west1_example-cluster-2 gke_example-org-1_us-west1_example-cluster-2 apigeekubectl config use-context gke_example-org-1_us-west1_example-cluster-2 - מוחקים את ה-virtualhost. חוזרים על הפעולה לכל קבוצת סביבות:
helm -n APIGEE_NAMESPACE delete ENV_GROUP_NAME
- מוחקים את הסביבות. חוזרים על הפעולה לכל סביבה:
helm -n APIGEE_NAMESPACE delete ENV_NAME
- מוחקים את הארגון ב-Apigee.
helm -n APIGEE_NAMESPACE delete ORG_NAME
- מריצים את הפקודה exec ב-pod apigee-cassandra-default-0:
kubectl exec -it -n APIGEE_NAMESPACE apigee-cassandra-default-0 -- /bin/bash
- מריצים את הפקודה הבאה:
find /opt/apigee/data/apigee-cassandra/ -iname '*<migrated org name>_hybrid' -type d -maxdepth 2 -printf "%f\n"
הוראות למציאת
<migrated org name>מפורטות במאמר איך מקבלים את השם של הארגון שהועבר.מעתיקים את רשימת כל השמות שמופיעים בפלט. תצטרכו את הרשימה הזו בשלב 9. j.
- יוצאים מהתרמיל
apigee-cassandra-default-0. - יוצרים פוד של לקוח לניפוי באגים ב-Cassandra לפי ההוראות במאמר
יצירת קונטיינר של לקוח לניפוי באגים. עוברים לשלב הבא אחרי שמקבלים הנחיה
cqlsh. - מריצים את הפקודות הבאות בהנחיה
cqlsh:desc keyspaces;
מוודאים שהפקודה הזו לא מחזירה שגיאות.
- לכל שם ברשימה שנוצרה בשלב 10. ו',
מריצים את הפקודה הבאה:
drop keyspace <name>;
- יוצאים מ-pod של לקוח לניפוי באגים ב-Cassandra. אחרי שמריצים את הפקודות
-
kubectl exec -it -n APIGEE_NAMESPACE CASSANDRA_POD_NAME -- /bin/bash
-
find /opt/apigee/data/apigee-cassandra/ -iname '*<migrated org name>_hybrid' -type d -maxdepth 2
הוראות למציאת
<migrated org name>מפורטות במאמר איך מקבלים את השם של הארגון שהועבר. -
find /opt/apigee/data/apigee-cassandra/ -iname '*<migrated org name>_hybrid' -type d -maxdepth 2 -exec rm -rf {} + - יוצאים מ-Cassandra pod.
cqlsh, מריצים את הפקודות הבאות בכל ה-pods של Cassandra באשכול Kubernetes של המקור: - מוודאים שההקשר הנוכחי הוא ההקשר הנכון עבור אשכול Kubernetes של המקור:
איך מקבלים את השם של הארגון שהועבר
כמה מהשלבים בתהליך שמתואר בקטע הקודם דורשים את השם של הארגון שהועבר. כדי לקבל את שם הארגון שהועבר:
- אפשר למצוא את שם הארגון בקובץ overrides.yaml של הארגון. חשוב לבדוק את הקובץ overrides.yaml של הארגון שמועבר.
- אם שם הארגון מכיל מקפים "-", צריך להחליף את כל המקפים "-" בקו תחתון "_".