אם אתם אדמינים ב-IT או יוצרי תשתיות בענן, כשאתם מתכננים להפעיל אפליקציה ב-Compute Engine, אתם צריכים לתכנן טופולוגיה של מכונות וירטואליות שתוכלו להקצות ולהפעיל ביעילות.
ב-Compute Engine יש מגוון אפשרויות פריסה: לדוגמה, אפשר לפרוס קבוצה של מכונות וירטואליות שמנוהלות כישות אחת, או להקצות ולנהל את המכונות הווירטואליות כמשאבים נפרדים. לכל גישה יש יתרונות ומגבלות שונים. איך בוחרים אסטרטגיית פריסה אופטימלית?
- מתחילים בהערכת הדרישות העיקריות של האפליקציה.
- בודקים את אפשרויות הפריסה הזמינות ואת היתרונות היחסיים שלהן.
- בוחרים אסטרטגיה שעונה על הדרישות שלכם ומנצלת בצורה אופטימלית את היכולות של Compute Engine.
הערכת עומס העבודה
השתמשו בשאלות הבאות כדי לנתח את הדרישות העיקריות של עומס העבודה שאתם רוצים לפרוס. התשובות שלכם יעזרו לכם למפות את היכולות של כל אפשרות פריסה (שמפורטות בקטע הבא) לדרישות של עומס העבודה. כדי לקבל חלופה אינטראקטיבית מבוססת-AI לתרשים זרימת ההחלטות הזה, אתם יכולים להזין הנחיה ל-Gemini במסוף Cloud de Confiance עם היעדים של הפרויקט ולקבל המלצות מותאמות לפריסה. מידע נוסף זמין במאמר תכנון של תשתית מחשוב באמצעות Compute Advisor.
מצב האפליקציה
האם האפליקציה היא stateful?
- אפליקציה עם מצב שומרת נתונים מסוימים, כמו מזהה הלקוח או מזהה הסשן, עד שהנתונים האלה כבר לא נחוצים. לדוגמה, באפליקציית קניות אונליין, שירות עגלת הקניות עשוי לאחסן פרטים של פריטים שנוספו או הוסרו בזמן שהמשתמש ממשיך בקניות, ולשמור את המצב הסופי של העגלה כשהמשתמש מתחיל את תהליך התשלום.
- אפליקציה בלי שמירת מצב לא צריכה לאחסן נתונים של לקוחות, טרנזקציות או סשנים. לדוגמה, שרת אינטרנט עשוי לסגור סשן אחרי שהוא מציג את התוכן שהלקוח ביקש.
למידע נוסף על אפליקציות עם שמירת מצב ואפליקציות בלי שמירת מצב, אפשר לקרוא את המאמר ההבדלים בין עומסי עבודה עם שמירת מצב לבין עומסי עבודה בלי שמירת מצב.
האם צריך לשמור מטא-נתונים ספציפיים למכונה כשהמכונות הווירטואליות מופעלות מחדש או כש-Compute Engine יוצר מחדש את המכונות הווירטואליות (תיקון אוטומטי)?
הקצאת הרשאות
- האם המכונות הווירטואליות צריכות להשתמש בשילוב של סוגי מכונות או תמונות? לדוגמה, האם חלק מהמכונות הווירטואליות צריכות סוגי מכונות שעברו אופטימיזציה לזיכרון, ואילו האחרות משתמשות בסוגי מכונות לשימוש כללי?
- האם התשתית צריכה להתרחב באופן אוטומטי בהתאם לשינויים בעומס, כדי לשמור על איזון אופטימלי בין עלות לזמן תגובה?
- האם כל המכונות הווירטואליות יכולות לפעול באזור אחד, ברשת VPC אחת וברשת משנה אחת?
- האם האפליקציה צריכה לפעול באותו אזור כמו משאבים אחרים? לדוגמה, האם האפליקציה דורשת חיבור עם זמן אחזור נמוך למסד נתונים?
פעולות
- רוצים לנהל את המכונות הווירטואליות כקבוצה אחת? לדוגמה, האם תרצו להפוך את הפריסה של עדכוני אפליקציות לאוטומטית בכל המכונות הווירטואליות?
- האם אתם צריכים להשתמש בכלי בהתאמה אישית או בכלי של צד שלישי כדי לנהל את המכונות הווירטואליות?
- האם אתם צריכים שליטה בטיפול במכונות וירטואליות שנכשלו? לדוגמה, אם מכונה וירטואלית נכשלת, האם אתם רוצים שהיא תישאר מושבתת בזמן שאתם מנסים להבין מה גרם לכשל?
- האם אתם צריכים שליטה ברצף של הפעלה, עצירה, השהיה והמשך של מכונות וירטואליות, או בתזמון שלהן? לדוגמה, כדי לחסוך בעלויות, האם אתם מתכננים להפסיק את השימוש במכונות הווירטואליות בסופי שבוע או בשעות מסוימות ביום?
חוסן
- האם האפליקציה צריכה הגנה מפני כשלים אזוריים? במילים אחרות, אם אזור מסוים מושבת, האם תרצו שהאפליקציה תמשיך לטפל בבקשות ממכונות וירטואליות באזורים אחרים באזור?
- אם מכונה וירטואלית מפסיקה לפעול או קורסת מסיבה כלשהי, או אם האפליקציה לא מגיבה לבקשות, האם Compute Engine צריך ליצור מחדש את המכונה הווירטואלית באופן אוטומטי?
- האם האפליקציה צריכה כתובות IP פנימיות או חיצוניות קבועות למכונות הווירטואליות של המארח?
אחרי שבדקתם את הדרישות שלכם, כדאי לעיין באפשרויות הפריסה ש-Compute Engine מציע.
בדיקת אפשרויות הפריסה הזמינות
כדאי לעיין באפשרויות לפריסת עומסי עבודה ב-Compute Engine ולהבין את התכונות והיתרונות היחסיים שלהן.
- מכונות וירטואליות עצמאיות
- באפשרות הזו, בוחרים את סוג המכונה, התמונה, הדיסקים ומאפיינים אחרים בנפרד לכל מכונת VM שמקצים. את המכונות הווירטואליות מנהלים כמשאבים נפרדים.
- קבוצת מופעים לא מנוהלת
- אפשר להקצות מכונות וירטואליות עצמאיות ולהוסיף אותן לקבוצת מכונות. אחר כך תוכלו להשתמש בקבוצת המופעים הלא מנוהלת כבק-אנד למאזן עומסים.
- קבוצת מופעי מכונה מנוהלים (MIG)
קבוצת מופעי מכונה מנוהלים (MIG) היא קבוצה של מופעים זהים או מופעים עם הגדרות דומות שאתם מקצים באמצעות תבנית של הגדרות מכונה.
אפשר להפוך קבוצת מופעים מנוהלת (MIG) לבעלת מצב, כך שדיסקים או מטא-נתונים ספציפיים יישמרו.
בקבוצת MIG חסרת מצב, אפשר להפעיל התאמה אוטומטית לעומס ולהגדיר מדיניות של התאמה לעומס.
כשיוצרים קבוצת MIG, אפשר לבחור אם לפרוס את מכונות ה-VM באזור אחד או לפזר אותן בין כמה אזורים באזור כדי להשיג זמינות גבוהה.
בטבלה הבאה מפורטות התכונות העיקריות של כל אפשרות פריסה.
| יכולת | מכונות וירטואליות עצמאיות | קבוצת מופעים לא מנוהלת | קבוצת MIG עם שמירת מצב | קבוצת MIG בלי שמירת מצב |
|---|---|---|---|---|
| הקצאת משאבים של קבוצת מכונות וירטואליות על סמך תבנית | ||||
| שילוב של סוגי מכונות ושל תמונות | ||||
| קבועות פנימיות או חיצוניות כתובות IP | ||||
| תיקון אוטומטי של מכונות וירטואליות שנכשלו | ||||
| שליטה בפעולות הפעלה והפסקה והשהיה והמשך של מכונות וירטואליות | ||||
| הגדרת קבוצה של מכונות וירטואליות כקצה עורפי של מאזן עומסים | ||||
| שמירה של דיסקים ומטא-נתונים, לעומסי עבודה עם מצב (stateful) | ||||
| עדכון מבוקר של מכונות וירטואליות ספציפיות | ||||
| עדכון מתגלגל אוטומטי של כל המכונות הווירטואליות | ||||
| גידול אוטומטי (וחוזה מראש) של קיבולת האחסון |
בתרשימים הבאים מוצגות דוגמאות לפריסות זו לצד זו, כדי לעזור לכם להבין את ההבדלים העיקריים.
| מכונות וירטואליות עצמאיות | קבוצת MIG עם שמירת מצב | קבוצת MIG בלי שמירת מצב |
|---|---|---|
| בדוגמה הזו מוצגים שלושה מכונות וירטואליות שנוצרו בנפרד. | בדוגמה הזו מוצגת קבוצת MIG שמכילה שלוש מכונות וירטואליות עם הגדרות דומות, שהוקצו באמצעות תבנית של הגדרות מכונה. |
בדוגמה הזו מוצגת קבוצת MIG שמכילה שלוש מכונות וירטואליות זהות, שהוקצו באמצעות תבנית של הגדרות מכונה. |
|
|
|
|
|
|
סיימתם להעריך את עומס העבודה, בדקתם את אפשרויות הפריסה ש-Compute Engine מציע ואתם מוכנים לבחור גישת פריסה.
בחירת אסטרטגיית פריסה
ההמלצות שמופיעות כאן מבוססות על מיפוי של מאפיינים ספציפיים של עומס עבודה (workload) ליכולות של כל אפשרות פריסה של Compute Engine.
כדאי להשתמש בתרשים הבא כדי לקבל החלטה. אם אתם מעדיפים מדריך ויזואלי, תוכלו לעיין בעץ ההחלטות שבהמשך המאמר.
בוחרים בין מכונות וירטואליות עצמאיות לבין קבוצות של מכונות וירטואליות.
דרישות שיטת פריסה מומלצת לפחות אחת מהדרישות הבאות חיונית לעומס העבודה שלכם. - האפליקציה צריכה לפעול במכונות וירטואליות שמשתמשות בשילוב של סוגי מכונות או תמונות.
- האפליקציה צריכה כתובות IP פנימיות או כתובות IP חיצוניות קבועות למכונות הווירטואליות של המארח.
- אתם צריכים שליטה בטיפול במכונות VM שנכשלו.
- אתם צריכים שליטה בפעולות ההתחלה וההפסקה או ההשהיה וההמשך של מכונות וירטואליות.
- צריך להשתמש בסקריפט מותאם אישית או בכלי של צד שלישי כדי להקצות מכונות וירטואליות ולהסיר אותן.
בוחרים מכונות וירטואליות עצמאיות.
אם כל המכונות הווירטואליות העצמאיות יכולות לפעול באזור יחיד, ברשת VPC ובתת-רשת, כדאי להוסיף את המכונות הווירטואליות לקבוצת מופעים לא מנוהלת. אחר כך תוכלו להשתמש בקבוצת המופעים הלא מנוהלת כבק-אנד למאזן עומסים.
מדלגים על שאר התהליך לקבלת החלטות.
אף אחת מהדרישות שלמעלה לא חיונית לתרחיש השימוש שלכם. אתם יכולים להשתמש ב-MIG כדי להגדיר טופולוגיה של Compute Engine שקל לנהל, בעלת זמינות גבוהה וניתנת להתאמה לעומס.
עוברים לשלב הבא.
בוחרים בין קבוצת MIG עם שמירת מצב לבין קבוצת MIG ללא שמירת מצב.
דרישות סוג ה-MIG המומלץ האפליקציה דורשת שימור של נתונים ומטא-נתונים בכונן, כלומר האפליקציה היא בעלת מצב. בוחרים קבוצת MIG עם שמירת מצב, ומגדירים את הדיסקים ש-Compute Engine צריך לשמור במהלך אירועים משבשים כמו יצירה מחדש של מכונה וירטואלית, תיקון אוטומטי ועדכונים.
עוברים לשלב הבא.
האפליקציה לא שומרת את המצב שלה. בוחרים קבוצת MIG ללא שמירת מצב, ונהנים מהיכולת של שינוי גודל אוטומטי. במהלך פעולות שגורמות לשיבושים, מערכת Compute Engine יוצרת מחדש את הדיסקים בהתאם לתבנית של הגדרות מכונה.
עוברים לשלב הבא.
בוחרים בין MIG אזורי לבין MIG אזורי.
דרישות סוג ה-MIG המומלץ האפליקציה צריכה לפעול בתחום אחד, או שההגנה מפני כשלים בתחום לא חיונית. בוחרים קבוצת מופעים מנוהלת (MIG) אזורית. האפליקציה צריכה להמשיך לפעול גם אם מתרחשת תקלה אזורית. בוחרים קבוצת MIG אזורית.
עץ החלטה
התרשים הבא מציג את הגורמים שצריך לקחת בחשבון כשמחליטים על אסטרטגיית הפריסה של Compute Engine:
