כ-Cloud Architect או אדמין ממחלקת IT, כשאתם מתכננים להריץ אפליקציה ב-Compute Engine, אתם צריכים לתכנן טופולוגיה של מכונות שתוכלו להקצות ולהפעיל ביעילות תפעולית.
ב-Compute Engine יש מגוון אפשרויות פריסה: לדוגמה, אתם יכולים לפרוס קבוצה של מכונות ולנהל אותן כישות אחת, או לנהל את המכונות כמשאבים נפרדים. לכל גישה יש יתרונות ומגבלות משלה. איך בוחרים את אסטרטגיית הפריסה האופטימלית?
- קודם כל, בודקים את הדרישות העיקריות של האפליקציה.
- לבדוק את אפשרויות הפריסה הזמינות ואת היתרונות היחסיים שלהן.
- בחרו אסטרטגיה שמתאימה לדרישות שלכם ומנצלת בצורה אופטימלית את היכולות של Compute Engine.
הערכת עומס העבודה
השאלות הבאות יעזרו לכם לנתח את הדרישות העיקריות של עומס העבודה שאתם רוצים לפרוס. התשובות שלכם יעזרו לכם למפות את היכולות של כל אפשרות פריסה (המפורטות בקטע הבא) לדרישות של עומס העבודה שלכם. כחלופה אינטראקטיבית מבוססת-AI לתהליך קבלת ההחלטות הזה, אתם יכולים להנחות את Gemini במסוף Google Cloud עם יעדי הפרויקט שלכם כדי לקבל המלצות פריסה מותאמות אישית. מידע נוסף זמין במאמר תכנון תשתית מחשוב באמצעות Compute Advisor.
מצב האפליקציה
האם האפליקציה היא stateful?
- אפליקציה עם שמירת מצב מאחסנת נתונים מסוימים, כמו מזהה הלקוח או מזהה הסשן, עד שהנתונים האלה כבר לא נחוצים. לדוגמה, באפליקציית קניות אונליין, שירות עגלת הקניות יכול לאחסן פרטים של פריטים שנוספו או הוסרו בזמן שהמשתמש ממשיך בקניות, ולשמור את המצב הסופי של עגלת הקניות כשהמשתמש מתחיל את תהליך התשלום.
- באפליקציה בלי שמירת מצב אין צורך לאחסן נתונים של לקוחות, טרנזקציות או סשנים. לדוגמה, שרת אינטרנט יכול לסגור סשן אחרי שהוא מספק את התוכן שהלקוח ביקש.
למידע נוסף על אפליקציות עם שמירת מצב וללא שמירת מצב, קראו את המאמר מה ההבדל בין עומסי עבודה עם שמירת מצב לעומסי עבודה ללא שמירת מצב.
האם צריך לשמור מטא-נתונים ספציפיים למכונה כשמפעילים מחדש את המכונות או כש-Compute Engine יוצר מחדש (מתקן אוטומטית) את המכונות?
הקצאה ידנית
- האם המכונות צריכות להשתמש בשילוב של סוגי מכונות או קובצי אימג'? לדוגמה, האם במכונות מסוימות צריך להשתמש במכונות עם זיכרון אופטימלי (memory-optimized) ובאחרות במכונות וירטואליות לשימוש כללי?
- האם התשתית צריכה להתאים את עצמה באופן אוטומטי לשינויים בעומס, כדי לשמור על איזון אופטימלי בין העלות לזמן התגובה?
- האם כל המכונות יכולות לפעול באזור אחד, ברשת VPC אחת וברשת משנה אחת?
- האם האפליקציה צריכה לפעול באותו אזור כמו משאבים אחרים? לדוגמה, האם האפליקציה דורשת חיבור עם זמן אחזור קצר למסד נתונים?
תפעול
- רוצים לנהל את המכונות כקבוצה אחת? לדוגמה, האם אתם רוצים להפוך את פריסת העדכונים של האפליקציה לאוטומטית בכל המכונות?
- האם אתם צריכים להשתמש בכלי בהתאמה אישית או בכלי של צד שלישי כדי לנהל את המכונות?
- האם אתם צריכים שליטה על הטיפול במכונות שנכשלו? לדוגמה, אם מכונה וירטואלית נכשלת, האם אתם רוצים שהיא תישאר במצב עצירה בזמן שאתם מנסים להבין מהו שורש הבעיה לכשל?
- האם אתם צריכים לשלוט ברצף או בלוח הזמנים של ההפעלה, העצירה, ההשהיה וההמשך של המכונות שלכם? לדוגמה, כדי לחסוך בעלויות, האם אתם מתכננים לעצור את המכונות בסופי שבוע או בשעות מסוימות ביום?
חוסן
- האם האפליקציה צריכה הגנה מפני כשלים באזורים? במילים אחרות, אם אזור מסוים מושבת, האם אתם רוצים שהאפליקציה תמשיך לשרת בקשות ממכונות באזורים אחרים?
- אם מכונה מפסיקה לפעול או קורסת מסיבה כלשהי, או אם האפליקציה לא מגיבה לבקשות, האם Compute Engine צריך ליצור מחדש את המכונה באופן אוטומטי?
- האם האפליקציה צריכה כתובות IP פנימיות או כתובות IP חיצוניות קבועות למכונות המחשוב המארחות?
אחרי שהערכתם את הדרישות שלכם, אתם יכולים לקרוא על אפשרויות הפריסה ש-Compute Engine מציע.
בדיקת אפשרויות הפריסה הזמינות
כדאי לבדוק ולהבין את התכונות והיתרונות היחסיים של האפשרויות לפריסת עומסי העבודה ב-Compute Engine.
- מכונות Compute עצמאיות
- באפשרות הזו, אתם בוחרים את סוג המכונה, קובץ האימג', הדיסקים ומאפיינים אחרים בנפרד לכל מכונה שאתם מקצים. אתם מנהלים את המכונות כמשאבים נפרדים.
- אשכולות של מכונות
- באפשרות הזו, אתם יוצרים קבוצה של מכונות שנמצאות קרוב אחת לשנייה, כדי לספק קישוריות לרשת עם זמן אחזור קצר ורוחב פס גבוה לעומסי עבודה של מחשוב עתיר ביצועים (HPC) ובינה מלאכותית (AI).
- לעומסי עבודה שמבוססים על מעבד (CPU), אתם יכולים ליצור אשכולות באמצעות סוגי המכונות C2, C2D, H3 ו-H4D. מידע נוסף זמין במאמר יצירת אשכולות HPC ב-Compute Engine.
- לעומסי עבודה שמבוססים על GPU, קראו את המאמר AI Hypercomputer.
- קבוצת מכונות לא מנוהלת
- אפשר להקצות מכונות עצמאיות ולהוסיף אותן לקבוצת מכונות. לאחר מכן תוכלו להשתמש בקבוצת המכונות הלא מנוהלות כ-backend למאזן עומסים.
- קבוצת מופעי מכונה מנוהלים (MIG)
קבוצת MIG היא קבוצה של מכונות זהות או עם הגדרות דומות, שאתם מקצים באמצעות תבנית של הגדרות מכונה.
אפשר להגדיר קבוצת MIG כשומרת מצב, כדי לשמור דיסקים או מטא-נתונים ספציפיים.
בקבוצת MIG בלי שמירת מצב, אפשר להפעיל התאמה אוטומטית לעומס ולהגדיר מדיניות התאמה לעומס.
כשיוצרים קבוצת MIG, אפשר לפרוס את המכונות באזור אחד או לפזר אותן בכמה אזורים כדי לשפר את הזמינות.
בטבלה הבאה מפורטות התכונות העיקריות של כל אפשרות פריסה.
| יכולת | מכונות עצמאיות | קבוצת מכונות לא מנוהלת | MIG עם שמירת מצב | MIG ללא שמירת מצב |
|---|---|---|---|---|
| הקצאה מבוססת-תבנית של קבוצת מכונות | ||||
| שילוב של סוגי מכונות ותמונות | ||||
| כתובות IP קבועות, פנימיות או חיצוניות | ||||
| תיקון אוטומטי של מכונות Compute שנכשלו | ||||
| שליטה בפעולות הפעלה-עצירה והשהיה-המשך של מכונות וירטואליות | ||||
| הגדרת קבוצה של מכונות כמערכת לקצה העורפי של מאזן עומסים | ||||
| שמירת דיסקים ומטא-נתונים, לעומסי עבודה עם שמירת מצב (stateful) | ||||
| עדכון מבוקר של מכונות ספציפיות | ||||
| עדכון אוטומטי בהדרגה (rolling) של כל המכונות | ||||
| שינוי קנה מידה אופקי אוטומטי (וחיזוי) |
בתרשימים הבאים מוצגות פריסות לדוגמה זו לצד זו, כדי לעזור לכם להבין את ההבדלים העיקריים.
| מכונות עצמאיות | MIG עם שמירת מצב | MIG ללא שמירת מצב |
|---|---|---|
| בדוגמה הזו מוצגות שלוש מכונות שנוצרו בנפרד. | בדוגמה הזו מוצגת קבוצת MIG שמכילה שלוש מכונות עם הגדרות דומות, שהוקצו באמצעות תבנית של הגדרות מכונה. |
בדוגמה הזו מוצגת קבוצת MIG שמכילה שלוש מכונות זהות, שנוצרו באמצעות תבנית של הגדרות מכונה. |
|
|
|
|
|
|
אחרי שבדקתם את עומס העבודה ואת אפשרויות הפריסה ב-Compute Engine, אתם יכולים לבחור את גישת הפריסה.
בחירת אסטרטגיית פריסה
ההמלצות שמופיעות כאן מבוססות על מיפוי של מאפייני עומסי עבודה ספציפיים ליכולות של כל אפשרות פריסה ב-Compute Engine.
כדי לקבל החלטה, אפשר להיעזר בתהליך הבא. אם אתם מעדיפים מדריך חזותי, תוכלו לעיין בעץ ההחלטות שמופיע בהמשך המאמר.
בוחרים בין מכונות נפרדות, אשכולות של מכונות וקבוצות של מכונות.
דרישות אסטרטגיית פריסה מומלצת האפליקציה היא עומס עבודה של מחשוב עתיר ביצועים (HPC) או של בינה מלאכותית (AI) שדורש חיבור לרשת עם זמן אחזור קצר ורוחב פס גבוה בין מכונות. בוחרים אשכולות של מכונות.
דלגו על שאר השלבים בתהליך קבלת ההחלטות הזה.
לפחות אחת מהדרישות הבאות חיונית לעומס העבודה שלכם. - האפליקציה צריכה לפעול במכונות שמשתמשות בשילוב של סוגי מכונות או קובצי אימג'.
- לאפליקציה נדרשות כתובות IP פנימיות או כתובות IP חיצוניות קבועות למכונות המחשוב המארחות.
- אתם צריכים שליטה על הטיפול במכונות שנכשלו.
- אתם צריכים שליטה על פעולות ההפעלה-עצירה או ההשהיה-המשך של המכונות שלכם.
- צריך להשתמש בסקריפט בהתאמה אישית או בכלי של צד שלישי כדי להקצות ולהסיר מכונות.
בוחרים מכונות נפרדות.
אם כל המכונות העצמאיות יכולות לפעול באזור, ברשת VPC ובתת-רשת אחת, כדאי להוסיף את המכונות לקבוצת מכונות לא מנוהלת. לאחר מכן תוכלו להשתמש בקבוצת המכונות הלא מנוהלת כ-backend למאזן עומסים.
דלגו על שאר השלבים בתהליך קבלת ההחלטות הזה.
אף אחת מהדרישות האלה לא חיונית לתרחיש לדוגמה שלכם. משתמשים ב-MIG כדי להגדיר טופולוגיה של Compute Engine עם זמינות גבוהה ויכולת התאמה לעומס (scaling).
עוברים לשלב הבא.
בוחרים בין קבוצת MIG עם שמירת מצב לבין קבוצת MIG ללא שמירת מצב.
דרישות סוג ה-MIG המומלץ האפליקציה דורשת שמירה של הדיסק והמטא-נתונים, כלומר היא אפליקציה עם שמירת מצב (stateful). בוחרים קבוצת MIG עם שמירת מצב ומגדירים את הדיסקים ש-Compute Engine צריך לשמור במהלך אירועים משבשים, כמו יצירה מחדש של מכונה, תיקון תוכנה אוטומטי ועדכונים.
עוברים לשלב הבא.
האפליקציה לא שומרת את המצב שלה. בוחרים ב-MIG ללא שמירת מצב (stateless) ומשתמשים ביכולת ההתאמה האוטומטית לעומס. במהלך פעולות שמשבשות את השירות, Compute Engine יוצר מחדש דיסקים לפי התבנית של הגדרות המכונה.
עוברים לשלב הבא.
בוחרים בין קבוצת MIG אזורית לבין קבוצת MIG של אזור נתון.
דרישות סוג ה-MIG המומלץ האפליקציה צריכה לפעול באזור אחד, או שההגנה מפני כשלים באזור לא חיונית. בוחרים קבוצת MIG אזורית. האפליקציה צריכה להמשיך לפעול גם אם יש כשל באזור. בוחרים קבוצת MIG אזורית.
עץ החלטות
התרשים הבא מציג את הגורמים שצריך להביא בחשבון כשמחליטים על אסטרטגיית הפריסה ב-Compute Engine:
