Google Distributed Cloud פועל במקום שלכם בסביבת vSphere. במסמך הזה מפורטות הדרישות לסביבת vSphere.
הדף הזה מיועד לאדמינים ולארכיטקטים שמגדירים פתרונות IT וארכיטקטורת מערכת בהתאם לאסטרטגיה של החברה, ויוצרים ומנהלים מדיניות שקשורה להרשאות משתמשים. מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם בתוכן של Google Cloud זמין במאמר תפקידים נפוצים של משתמשים ומשימות ב-GKE.
תאימות גרסאות
הדרישות של vSphere משתנות בהתאם לגרסה של Google Distributed Cloud שבה אתם משתמשים. מידע נוסף זמין במטריצת התאימות של הגרסאות הנתמכות באופן מלא.
גרסאות נתמכות
vSphere היא תוכנה לווירטואליזציה של שרתים מבית VMware. vSphere כוללת את ESXi ואת vCenter Server.
Google Distributed Cloud תומך בגרסאות הבאות של ESXi ושל vCenter Server
- 9.0 ו-9.1
- עדכונים מגרסה 8.0 ואילך
מומלץ להשתמש בגרסה 9.1.
אם רוצים ליצור תמונות מצב של נפח CSI, צריך להשתמש באחת מהגרסאות הבאות:
- 9.0 ו-9.1
- גרסה 8.0 או עדכון מאוחר יותר של גרסה 8.0
דרישות לגבי רישיונות
צריך אחד מהרישיונות הבאים:
רישיון vSphere Enterprise Plus. בנוסף לרישיון הזה, צריך להיות לכם מינוי תמיכה תקף.
רישיון vSphere Standard בנוסף לרישיון הזה, צריך להיות לכם מינוי תמיכה תקף. עם הרישיון הזה, אי אפשר להפעיל קבוצות למניעת קרבה. בנוסף, אי אפשר לציין מאגר משאבים משלכם. חובה להשתמש במאגר ברירת המחדל של המשאבים.
דרישות חומרה
Google Distributed Cloud פועל על קבוצה של מארחים פיזיים שמריצים את hypervisor של VMware ESXi. מידע על דרישות החומרה של ESXi זמין במאמר ESXi Hardware Requirements.
בסביבות ייצור, מומלץ מאוד:
מפעילים את VMware Distributed Resource Scheduler (DRS).
צריכים להיות לפחות ארבעה מארחי ESXi שזמינים למכונות הווירטואליות של האשכול.
אם אתם מתכננים לפרוס אשכולות Anthos ב-VMware באשכולות vSphere שונים או במאגרי משאבים שונים באותו מרכז נתונים של vSphere, אתם צריכים להפעיל תעבורת Network File Copy (NFC) בין מארחי ESXi כדי לאפשר שיתוף של תבניות מערכת הפעלה.
מגדירים את
antiAffinityGroups.enabledלערךtrueבקובצי התצורה של האשכול.
אם מגדירים את antiAffinityGroups.enabled ל-true, Google Distributed Cloud יוצר כללי DRS למניעת קרבה בין צמתי האשכול, וכתוצאה מכך הם מפוזרים בין לפחות שלושה מארחי ESXi פיזיים. למרות שכללי ה-DRS מחייבים שצמתי האשכול יתפרסו על פני שלושה מארחי ESXi, אנחנו ממליצים מאוד שיהיו לכם לפחות ארבעה מארחי ESXi זמינים. כך מונעים מצב שבו מאבדים את מישור הבקרה של האשכול. לדוגמה, נניח שיש לכם רק שלושה מארחי ESXi, וצומת מישור הבקרה של אשכול האדמין נמצא במארח ESXi שנכשל. כלל ה-DRS ימנע את ההצבה של צומת מישור הבקרה באחד משני מארחי ה-ESXi שנותרו.
לצורך הערכה והוכחת היתכנות, אפשר להגדיר את antiAffinityGroups.enabled ל-false ולהשתמש רק במארח ESXi אחד. מידע נוסף מופיע במאמר בנושא הגדרת תשתית מינימלית.
הרשאות בחשבון משתמש ב-vCenter
כדי להגדיר סביבת vSphere, אדמין ארגוני יכול לבחור להשתמש בחשבון משתמש ב-vCenter עם תפקיד האדמין ב-vCenter Server. לתפקיד הזה מוקצית גישה מלאה לכל האובייקטים של vSphere.
אחרי שמגדירים את סביבת vSphere, אדמין של אשכול יכול ליצור אשכולות אדמין ואשכולות משתמשים. לאדמין של האשכול לא צריך להיות את כל ההרשאות שמוענקות בתפקיד האדמין של vCenter Server.
כשמנהל אשכול או מפתח יוצרים אשכול, הם מספקים חשבון משתמש ב-vCenter בקובץ הגדרות של פרטי הכניסה. מומלץ להקצות לחשבון המשתמש ב-vCenter שמופיע בקובץ ההגדרות של פרטי הכניסה תפקידים בהתאמה אישית עם הרשאות מינימליות שנדרשות ליצירה ולניהול של אשכולות.
אדמין בארגון יכול לבחור באחת משתי גישות שונות:
ליצור כמה תפקידים עם רמות שונות של הרשאות. לאחר מכן יוצרים הרשאות שמקצות את התפקידים המוגבלים האלה למשתמש או לקבוצה באובייקטים ספציפיים של vSphere. אנחנו ממליצים על הגישה הזו כי היא מגבילה את הגישה ומגבירה את האבטחה של סביבת vCenter Server. מידע נוסף זמין במאמר בנושא אבטחת vSphere.
יוצרים תפקיד אחד עם כל ההרשאות הנדרשות. אחר כך יוצרים הרשאה גלובלית שמקצה את התפקיד הזה למשתמש או לקבוצה מסוימים בכל האובייקטים בהיררכיות של vSphere. מידע על השימוש בגישה הזו זמין במאמר בנושא יצירת הרשאה גלובלית אחת.
בטבלה הבאה מוצגים ארבעה תפקידים בהתאמה אישית שאדמין בארגון יכול ליצור. לאחר מכן האדמין יכול להשתמש בתפקידים המותאמים אישית כדי להקצות הרשאות לאובייקטים ספציפיים ב-vSphere:
| תפקיד בהתאמה אישית | הרשאות | Objects | האם להחיל על אובייקטים צאצאים? |
|---|---|---|---|
| ClusterEditor |
System.Read System.View System.Anonymous Host.Inventory.Modify cluster |
cluster | כן |
| SessionValidator |
System.Read System.View System.Anonymous Sessions.Validate session Cns.Searchable Profile-driven storage.Profile-driven storage view |
שרת vCenter הבסיסי | לא |
| ReadOnly |
System.Read System.View System.Anonymous |
data center network |
כן |
| Anthos | הרשאות בתפקיד ב-Anthos |
datastore resource pool VM folder network |
כן |
הרשאות בתפקיד מותאם אישית ב-Anthos
יצירה של תפקידים והרשאות בהתאמה אישית
אדמין בארגון יכול להשתמש בכלי govc של שורת הפקודה כדי ליצור תפקידים והרשאות בהתאמה אישית.
לאדמין של הארגון צריך להיות חשבון ב-vCenter Server עם הרשאות מספיקות ליצירת תפקידים והרשאות. לדוגמה, חשבון עם תפקיד אדמין.
לפני שמריצים את הפקודה govc, צריך להגדיר כמה משתני סביבה:
מגדירים את GOVC_URL לכתובת ה-URL של המופע של vCenter Server.
מגדירים את GOVC_USERNAME לשם המשתמש של חשבון האדמין הארגוני ב-vCenter Server.
מגדירים את GOVC_PASSWORD לסיסמה של חשבון vCenter Server של האדמין בארגון.
לדוגמה:
export GOVC_URL=vc-01.example export GOVC_USERNAME=alice@vsphere.local export GOVC_PASSWORD=8ODQYHo2Yl@
יצירת תפקידים מותאמים אישית
יוצרים את התפקידים בהתאמה אישית ClusterEditor, SessionValidator ו-ReadOnly:
govc role.create ClusterEditor System.Read System.View System.Anonymous Host.Inventory.EditCluster govc role.create SessionValidator System.Read System.View System.Anonymous Sessions.ValidateSession Cns.Searchable StorageProfile.View govc role.create ReadOnly System.Read System.View System.Anonymous
יצירת הרשאה שמעניקה את התפקיד ClusterEditor
הרשאה מקבלת צמד (משתמש, תפקיד) ומשייכת אותו לאובייקט. כשמקצים הרשאה לאובייקט, אפשר לציין אם ההרשאה תועבר לאובייקטים צאצאים. ב-govc, מגדירים את הדגל --propagate לערך true או false. ערך ברירת המחדל הוא false.
יוצרים הרשאה שמעניקה למשתמש את התפקיד ClusterEditor באובייקט של אשכול. ההרשאה הזו מועברת לכל אובייקטי הצאצא של אובייקט האשכול:
govc permissions.set -principal ACCOUNT \ -role ClusterEditor -propagate=true CLUSTER_PATH`
מחליפים את מה שכתוב בשדות הבאים:
ACCOUNT: חשבון המשתמש ב-vCenter Server שמקבל את התפקיד
CLUSTER_PATH: הנתיב של האשכול בהיררכיית האובייקטים של vSphere
לדוגמה, הפקודה הבאה יוצרת הרשאה שמשייכת את הצמד (bob@vsphere.local, ClusterEditor עם my-dc/host/my-cluster. ההרשאה מועברת לכל אובייקטי הצאצא של my-dc/host/my-cluster:
govc permissions.set -principal bob@vsphere.local \
-role ClusterEditor -propagate=true my-dc/host/my-cluster
יצירת הרשאות נוספות
בחלק הזה תמצאו דוגמאות ליצירת הרשאות נוספות. מחליפים את נתיבי האובייקטים לדוגמה לפי הצורך בסביבה שלכם.
יוצרים הרשאה שמעניקה את התפקיד SessionValidator לחשבון באובייקט הבסיסי של vCenter Server. ההרשאה הזו לא מועברת לאובייקטים משניים:
govc permissions.set -principal ACCOUNT \
-role SessionValidator -propagate=false
יוצרים הרשאות שמעניקות לחשבון את התפקיד ReadOnly באובייקט של מרכז נתונים ובאובייקט של רשת. ההרשאות האלה מועברות לאובייקטים צאצאים:
govc permissions.set -principal ACCOUNT \
-role ReadOnly -propagate=true \
/my-dc \
/my-dc/network/my-net
יצירת הרשאות שמעניקות את תפקיד Anthos לחשבון בארבעה אובייקטים: מאגר נתונים, תיקיית מכונה וירטואלית, מאגר משאבים ורשת. ההרשאות האלה מועברות לאובייקטים צאצאים:
govc permissions.set -principal ACCOUNT -role Anthos -propagate=true \
/my-dc/datastore/my-ds \
/my-dc/vm/my-folder \
/my-dc/host/my-cluster/Resources/my-rp \
/my-dc/network/my-net
יצירת הרשאה גלובלית אחת
בקטע הזה מוצגת חלופה ליצירה של כמה תפקידים וכמה הרשאות. אנחנו לא ממליצים על הגישה הזו כי היא מעניקה קבוצה גדולה של הרשאות לכל האובייקטים בהיררכיות של vSphere.
אם עדיין לא יצרתם תפקיד בהתאמה אישית ב-Anthos, צריך ליצור אותו עכשיו.
יוצרים הרשאה גלובלית אחת:
govc permissions.set -principal ACCOUNT \ -role Anthos -propagate=true
מחליפים את מה שכתוב בשדות הבאים:
מחליפים את ACCOUNT בחשבון המשתמש ב-vCenter Server שמקבל את התפקיד.
לדוגמה, הפקודה הבאה יוצרת הרשאה גלובלית שמעניקה את התפקיד Anthos ל-bob@vsphere.local. ההרשאה מועברת לכל האובייקטים בהיררכיות של vSphere:
govc permissions.set -principal bob@vsphere.local -role Anthos -propagate=true
בעיות מוכרות
מידע נוסף זמין במאמר התקנת הכלי נכשלת כשיוצרים דיסק נתונים של vSphere.
המאמרים הבאים
דרישות לגבי יחידת עיבוד מרכזית (CPU), זיכרון RAM ואחסון