תכנון העברת אשכול לתכונות מומלצות

סקירה כללית

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

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

אלה האפשרויות לכל אזור של תכונות:

אזור התכונה	האפשרויות המומלצות	האפשרויות המקוריות
ממשק רשת קונטיינרים (CNI)	Dataplane V2 (enableDataplaneV2: true)	‫Dataplane V1‏ (Calico) (enableDataplaneV2: false)
מאזן עומסים	‫ManualLB (פועל עם סוכני F5 Big IP) (loadBalancer.kind: "ManualLB") ‫MetalLB (loadBalancer.kind: "MetalLB")	integrated F5 Big IP^1 (loadBalancer.kind: "F5BigIP") Seesaw (loadBalancer.kind: "Seesaw")
מישור הבקרה של אשכול האדמין	אשכול אדמין בזמינות גבוהה (HA) (adminMaster.replicas: 3)	אשכול אדמין ללא זמינות גבוהה (adminMaster.replicas: 1)
מישור הבקרה של אשכול המשתמשים	‫Controlplane V2 (enableControlplaneV2: true)	אשכול משתמשים של Kubeception (enableControlplaneV2: false)

‫^{1 F5 BIG-IP משולב מתייחס ל-loadBalancer.kind: "F5BigIP" ולהגדרות קשורות בקטע loadBalancer.f5BigIP בקובץ התצורה של האשכול.}

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

סוג האשכול	תכונה מיושנת	הוספה לאשכול חדש	אישור לשדרוג האשכול	מעבר לתכונה חדשה
גרסה 1.32 ואילך
אדמין	לא HA	לא	לא	לא רלוונטי
	Seesaw	לא	לא	לא רלוונטי
	‫F5 Big IP משולב	לא	לא	לא רלוונטי
משתמש	Kubeception	לא	לא	לא רלוונטי
	Seesaw	לא	לא	לא רלוונטי
	‫F5 Big IP משולב	לא	לא	לא רלוונטי
	Dataplane V1	לא	לא	לא רלוונטי
גרסאות 1.30 ו-1.31
אדמין	לא HA	לא	כן	כן
	Seesaw	לא	כן	כן
	‫F5 Big IP משולב	לא	כן	כן
משתמש	Kubeception	לא	כן	כן
	Seesaw	לא	כן	כן
	‫F5 Big IP משולב	לא	כן	כן
	Dataplane V1	לא	כן	כן
גרסה 1.29
אדמין	לא HA	לא	כן	כן (גרסת טרום-השקה (Preview))
	Seesaw	לא	כן	כן
	‫F5 Big IP משולב	כן	כן	כן (גרסת טרום-השקה (Preview))
משתמש	Kubeception	כן	כן	כן (גרסת טרום-השקה (Preview))
	Seesaw	כן	כן	כן
	‫F5 Big IP משולב	כן	כן	כן (גרסת טרום-השקה (Preview))
	Dataplane V1	כן	כן	לא
גרסה 1.28
אדמין	לא HA	לא	כן	לא
	Seesaw	לא	כן	כן
	‫F5 Big IP משולב	כן	כן	לא
משתמש	Kubeception	כן	כן	לא
	Seesaw	כן	כן	כן
	‫F5 Big IP משולב	כן	כן	לא
	Dataplane V1	כן	כן	לא

נקודות עיקריות:

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

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

  • אשכולות אדמין:

    • מישור בקרה ללא זמינות גבוהה: 1.28 ואילך
    • איזון עומסים של Seesaw: ‏1.28 ואילך
    • ‫F5 Big IP משולב: 1.30 ומעלה

  • אשכולות משתמשים:

    • ‫Kubeception: ‏1.30 ואילך
    • ‫Seesaw: ‏1.30 ומעלה
    • ‫F5 Big IP משולב: 1.30 ומעלה
    • Dataplane V1: ‏1.30 ואילך

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

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

אתם יכולים לבחור ממשק רשת של קונטיינר (CNI) שמציע תכונות של רשתות קונטיינרים, כמו Calico או Dataplane V2. ‫Dataplane V2, הטמעת ה-CNI של Google, מבוסס על Cilium ומשמש גם ב-Google Kubernetes Engine (GKE) וגם ב-Google Distributed Cloud.

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

החל מגרסה 1.30, ‏Dataplane V2 היא האפשרות היחידה של CNI ליצירת אשכולות חדשים.

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

• ביצועים משופרים ויכולת התאמה לעומס: העיצוב המשופר של Dataplane V2 והשימוש היעיל במשאבים יכולים לשפר את ביצועי הרשת ואת יכולת ההתאמה לעומס, במיוחד באשכולות גדולים או בסביבות עם דרישות גבוהות לתנועה ברשת. הסיבה לכך היא השימוש ב-EBPF במקום ב-IPTables, שמאפשר לשנות את קנה המידה של האשכול באמצעות מפות BPF.

• ניהול ותמיכה פשוטים יותר: סטנדרטיזציה של Dataplane V2 ב-Google Distributed Cloud וב-GKE יכולה לפשט את הניהול של האשכולות ואת פתרון הבעיות, כי אפשר להסתמך על קבוצה עקבית של כלים ומסמכי תיעוד.

• תכונות מתקדמות של רשתות: EgressNAT ותכונות מתקדמות אחרות של רשתות נתמכות רק ב-Dataplane V2. כל בקשות הרשת העתידיות יוטמעו בשכבת Dataplane V2.

	לפני ההעברה	אחרי ההעברה
kube-proxy	חובה ופריסה אוטומטית	לא נדרש ולא נפרס
ניתוב	kube-proxy + iptables	eBPF

אחרי שמוודאים שההעברה מ-Calico ל-Dataplane V2 הושלמה ואין צורך לחזור ל-Calico, מסירים את ההערה features.onprem.cluster.gke.io/dpv2-migration מהמשאב המותאם אישית OnPremUserCluster ומהמשאב המותאם אישית OnPremAdminCluster (אם אשכול האדמין הועבר מ-Calico במהלך השדרוג מגרסה 1.29 ל-1.30). אם תסירו את ההערה הזו לפני שתשדרגו את האשכול או תשנו את קנה המידה שלו, בקר האשכול יוכל למחוק באופן סופי את ה-DaemonSets הרדומים של calico-node ו-calico-route-daemon. לא צריך לבצע את השלב הזה באשכולות שנוצרו כש-Dataplane V2 מופעל. מידע נוסף זמין במאמר הסרת DaemonSets רדומים של Calico.

העברת סוג מאזן העומסים

סוגי מאזני העומסים המומלצים (loadBalancer.kind) הם "ManualLB" ו-"MetalLB". אם יש לכם מאזן עומסים של צד שלישי, כמו F5 BIG-IP או Citrix, השתמשו ב-"ManualLB". משתמשים ב-"MetalLB" כדי להשתמש בפתרון המובנה לאיזון עומסים באמצעות מאזן העומסים MetalLB.

החל מגרסה 1.30, אלה האפשרויות היחידות ליצירת אשכולות חדשים. לאשכולות קיימים שמשתמשים ב-F5 Big IP המשולב או במאזן העומסים Seesaw בחבילה, אנחנו מספקים מדריכים להעברת נתונים (מיגרציה) להעברת הגדרות התצורה של "F5BigIP" ל-"ManualLB", ולהעברת מאזן העומסים בחבילה מ-Seesaw ל-MetalLB.

העברת הגדרות אישיות של מאזן העומסים F5 BIG-IP

כדאי לתכנן את ההעברה של כל האשכולות שמשתמשים ב-F5 Big IP המשולב אל ManualLB. השילוב של F5 Big IP משתמש ב-F5 BIG-IP עם סוכני איזון עומסים, שמורכבים משני הבקרים הבאים:

• ‫F5 Controller ‏ (pod prefix: load-balancer-f5): מתאים בין שירותי Kubernetes מסוג LoadBalancer לפורמט F5 Common Controller Core Library (CCCL) ConfigMap.
• ‫F5 BIG-IP CIS Controller v1.14 (pod prefix: k8s-bigip-ctlr-deployment): מתרגם את ConfigMaps להגדרות של מאזן העומסים F5.

ל-F5 Big IP המשולב המקורי יש את המגבלות הבאות:

• יכולת ביטוי מוגבלת: השילוב של F5 BIG-IP מגביל את הפוטנציאל המלא של F5 BIG-IP על ידי הגבלת יכולת הביטוי של Service API. זה יכול למנוע מכם להגדיר את בקר BIG-IP בהתאם לצרכים הספציפיים שלכם, או להשתמש בתכונות מתקדמות של F5 שעשויות להיות חיוניות לאפליקציה.
• רכיב מדור קודם: ההטמעה הנוכחית מסתמכת על טכנולוגיות ישנות יותר, כמו CCCL ConfigMap API ו-CIS מגרסה 1.x. יכול להיות שהרכיבים הקודמים האלה לא תואמים לפיתוחים האחרונים במוצרים של F5, וכתוצאה מכך אתם עלולים לפספס הזדמנויות לשיפור הביצועים והאבטחה.

השינויים אחרי המעבר מ-F5 BIG-IP המשולב אל ManualLB כוללים:

	לפני ההעברה	אחרי ההעברה
רכיבי סוכני F5	בקר F5 בקר OSS CIS	F5 Controller (ללא שינוי) ‫OSS CIS Controller (ללא שינוי)
שדרוג גרסת הרכיב של F5	כדי לשדרג את רכיבי F5, צריך לשדרג את האשכולות. גרסאות הרכיבים הזמינות מוגבלות, כפי שהוסבר קודם.	אפשר לשדרג את הגרסאות של רכיבי F5 לפי הצורך.
יצירת שירות	בטיפול של סוכני F5	טופלו על ידי סוכני F5 (ללא שינוי)

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

מעבר מ-Seesaw ל-MetalLB

ל-MetalLB יש את היתרונות הבאים בהשוואה ל-Seesaw:

• ניהול פשוט יותר ופחות משאבים: בניגוד ל-Seesaw, ‏MetalLB פועל ישירות על צומתי האשכול, ומאפשר שימוש דינמי במשאבי האשכול לאיזון עומסים.
• הקצאת כתובות IP אוטומטית: הבקר של MetalLB מנהל את כתובות ה-IP של השירותים, כך שלא צריך לבחור ידנית כתובת IP לכל שירות.
• חלוקת העומס בין צומתי LB: מכונות פעילות של MetalLB לשירותים שונים יכולות לפעול בצמתים שונים.
• תכונות משופרות ופתרון לטווח ארוך: הפיתוח הפעיל של MetalLB והשילוב שלו עם סביבת Kubernetes הרחבה יותר הופכים אותו לפתרון לטווח ארוך יותר בהשוואה ל-Seesaw. שימוש ב-MetalLB מאפשר לכם ליהנות מההתקדמות האחרונה בטכנולוגיית איזון העומסים.

	לפני ההעברה	אחרי ההעברה
צומתי LB	מכונות וירטואליות נוספות של Seesaw (מחוץ לאשכול)	צומתי LB באשכול עם אפשרויות בחירה מותאמת אישית ללקוחות
שמירה על כתובת ה-IP של הלקוח	אפשר להשיג את זה באמצעות externalTrafficPolicy: Local	אפשר להשיג את זה באמצעות מצב DataplaneV2 DSR
יצירת שירות	כתובת ה-IP של השירות שצוינה באופן ידני	כתובת IP של שירות שהוקצתה אוטומטית ממאגר כתובות

העברת אשכולות של משתמשים ל-Controlplane V2 ואשכולות של אדמינים ל-HA

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

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

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

בעבר, אשכולות של משתמשים השתמשו ב-kubeception. בגרסה 1.13, מישור הבקרה בגרסה 2 הוצג כתכונה בגרסת טרום-השקה (Preview), ובגרסה 1.14 הוא עבר לזמינות כללית (GA). החל מגרסה 1.15, מישור הבקרה בגרסה 2 הוא אפשרות ברירת המחדל ליצירת אשכולות משתמשים, והוא האפשרות היחידה בגרסה 1.30.

בהשוואה ל-kubeception, היתרונות של Controlplane V2 כוללים:

• עקביות בארכיטקטורה: אשכולות אדמין ואשכולות משתמשים משתמשים באותה ארכיטקטורה.
• בידוד תקלות: תקלה באשכול אדמין לא משפיעה על אשכולות משתמשים.
• הפרדה תפעולית: שדרוג של אשכול אדמין לא גורם להשבתה של אשכולות משתמשים.
• הפרדת פריסה: אתם יכולים להציב את אשכולות האדמין ואשכולות המשתמשים בדומיינים שונים של טופולוגיה או בכמה מיקומים. לדוגמה, במודל פריסה של מחשוב קצה (edge computing), יכול להיות שאשכול המשתמשים יהיה במיקום שונה מאשכול הניהול.

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

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

	לפני ההעברה	אחרי ההעברה
אובייקטים של צומת Kubernetes במישור הבקרה	צומת באשכול אדמין	צומת של אשכול משתמשים
פודים של מישור הבקרה של Kubernetes	אשכול אדמין Statefulsets/Deployments (מרחב שמות של אשכול משתמש)	פודים סטטיים של אשכול משתמש (מרחב השמות kube-system)
פודים אחרים של מישור הבקרה	אשכול אדמין Statefulsets/Deployments (מרחב שמות של אשכול משתמש)	‫Statefulsets/Deployments של אשכול משתמשים (מרחב שמות של kube-system)
כתובת ה-VIP של מישור הבקרה	שירות מאזן העומסים של אשכול האדמין	‫keepalived + haproxy (פודים סטטיים של אשכול משתמש)
נתוני Etcd	נפח קבוע של אשכול אדמין	דיסק נתונים
ניהול כתובות ה-IP של מכונות במישור הבקרה	IPAM או DHCP	IPAM
רשת מישור הבקרה	VLAN של אשכול אדמין	VLAN של אשכול משתמשים

מעבר לאשכול אדמין עם זמינות גבוהה (HA)

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

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

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

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

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

	לפני ההעברה	אחרי ההעברה
רפליקות של צומת מישור הבקרה	1	3
צמתים של חבילות תוכן	2	0
גודל דיסק הנתונים	‫100GB‏ * 1	‫25GB * 3
נתיב דיסקי הנתונים	מוגדר על ידי vCenter.dataDisk בקובץ התצורה של אשכול האדמין	נוצר אוטומטית בספרייה: /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk
כתובת ה-VIP של מישור הבקרה	מוגדר על ידי loadBalancer.kind בקובץ התצורה של אשכול האדמין	keepalived + haproxy
הקצאת כתובות IP לצומתי מישור הבקרה של אשכול האדמין	‫DHCP או סטטית, בהתאם ל-network.ipMode.type	3 כתובות IP סטטיות

העברת קבוצות של מאזני עומסים ומישורי בקרה

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

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

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

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

1. מעבירים כל אשכול משתמשים לשימוש ב-CNI המומלץ, Dataplane V2.

   1. מבצעים את השינויים בהגדרות ומעדכנים את אשכול המשתמשים כדי להפעיל את ההעברה של אשכול המשתמשים מה-CNI הישן, Calico, ל-Dataplane V2.

      הערה: לא צריך לבצע את השלב הזה באשכול האדמין. כשמשדרגים את אשכול האדמין לגרסה 1.30, האשכול מועבר באופן אוטומטי ל-Dataplane V2.

   2. אחרי שמוודאים שההעברה ל-Dataplane V2 הושלמה ואין צורך לחזור ל-Calico, מסירים את ההערה features.onprem.cluster.gke.io/dpv2-migration מהמשאב המותאם אישית OnPremUserCluster (וגם מ-OnPremAdminCluster אם אשכול האדמין הועבר מ-Calico במהלך השדרוג מגרסה 1.29 ל-1.30). אם תסירו את ההערה הזו לפני שתשדרגו את האשכול או תשנו את קנה המידה שלו, בקר האשכול יוכל למחוק באופן סופי את ה-DaemonSets הרדומים של calico-node ו-calico-route-daemon. להוראות, ראו הסרת DaemonSets רדומים של Calico.

2. מעבירים כל אשכול משתמש ממאזן העומסים (LB) הישן וממישור הבקרה (CP) הישן, כדי להשתמש במאזן העומסים המומלץ וב-Controlplane V2.

   1. משנים את ההגדרות כדי להשתמש במאזן העומסים המומלץ (MetalLB או ManualLB).
   2. משנים את ההגדרות כדי להפעיל את Controlplane V2.
   3. מעדכנים את אשכול המשתמש כדי להעביר את מאזן העומסים ואת מישור הבקרה.

3. מעבירים את אשכול האדמין כדי להשתמש במאזן העומסים המומלץ ולהפוך את מישור הבקרה לזמין מאוד.

   1. משנים את ההגדרות כדי להשתמש במאזן העומסים המומלץ (MetalLB או ManualLB).
   2. משנים את ההגדרות כדי להעביר את מישור הבקרה של אשכול האדמין מ-Non-HA ל-HA.
   3. מעדכנים את אשכול האדמין כדי להעביר את מאזן העומסים ואת מישור הבקרה.

4. מבצעים את שלבי הניקוי האופציונליים, כמו ניקוי ה-VM של מישור הבקרה ללא זמינות גבוהה.

התרשים הבא ממחיש את שלבי ההעברה:

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

• העברת אשכולות משתמשים לתכונות מומלצות
• העברת אשכול אדמין לתכונות מומלצות