כשמתכננים להריץ עומסי עבודה של מכונות וירטואליות בשרתים לדייר יחיד, צריך קודם להחליט איך לפרוס שרתים לדייר יחיד. בפרט, צריך להחליט כמה קבוצות צמתים נדרשות, ובאיזו מדיניות תחזוקה קבוצות הצמתים צריכות להשתמש:
קבוצות של צמתים: כדי לבחור את המספר הנכון של קבוצות צמתים, צריך לאזן בין הזמינות לבין ניצול המשאבים. שימוש במספר קטן של קבוצות צמתים מאפשר לכם לבצע אופטימיזציה של ניצול המשאבים והעלויות, אבל הוא מגביל אתכם לאזור אחד. פריסת קבוצות של צמתים בכמה אזורים מאפשרת לשפר את הזמינות, אבל עלולה להוביל לניצול נמוך יותר של המשאבים.
מדיניות בנושא התאמה אוטומטית לעומס ותחזוקה: בהתאם לדרישות הרישוי של מערכות ההפעלה והתוכנות שאתם מתכננים להפעיל, התאמה אוטומטית לעומס של הצמתים והמדיניות שתבחרו בנושא תחזוקה יכולים להשפיע על עלות הרישוי והזמינות.
כדי לקבל החלטה מושכלת לגבי השימוש בצמתים עם דייר יחיד, צריך לשקול בקפידה את הדרישות שלכם.
בדיקת הדרישות
בקטע הבא מפורטות כמה דרישות שכדאי לקחת בחשבון לפני שמחליטים כמה קבוצות של צמתים צריך, ואיזו מדיניות תחזוקה צריכה להיות לקבוצות הצמתים.
רישוי לפי ליבה ורישוי BYOL
אם אתם מתכננים להשתמש ברישיון משלכם (BYOL) ב-Compute Engine, תוכלו להשתמש בצמתים עם דייר יחיד כדי לעמוד בדרישות החומרה או במגבלות שמוטלות על ידי הרישיונות האלה.
חלק מהתוכנות וממערכות ההפעלה, כמו Windows Server, יכולות להיות מרושיינות לפי ליבת CPU פיזית, ויכול להיות שיוגדרו מגבלות על התדירות שבה מותר לכם לשנות את החומרה שמתחת למכונות הווירטואליות. התאמה אוטומטית לעומס של הצמתים ומדיניות ברירת המחדל בנושא תחזוקה יכולות להוביל לשינוי החומרה בתדירות גבוהה יותר מהמותר בתנאי הרישיון, וכתוצאה מכך לחיוב בדמי רישיון נוספים.
כדי לבצע אופטימיזציה לשימוש ברישיון BYOL לכל ליבה, כדאי לפעול לפי השיטות המומלצות הבאות:
איזון בין אופטימיזציה של עלות התשתית ועלות הרישוי: כדי לחשב את העלות הכוללת של הרצת עומסי עבודה בשיטת BYOL ב-Compute Engine, צריך לקחת בחשבון גם את עלות התשתית וגם את עלות הרישוי. במקרים מסוימים, צמצום עלויות התשתית עשוי להגדיל את עלויות הרישוי, או להיפך. לדוגמה, שימוש בסוג צומת עם מספר גבוה של ליבות עשוי להיות הכי טוב מבחינת עלות/ביצועים עבור עומסי עבודה מסוימים, אבל עלול להוביל לעלות רישוי נוספת אם הרישיונות מתומחרים לפי ליבה.
שימוש בקבוצות נפרדות של צמתים לעומסי עבודה של BYOL ולעומסי עבודה שלא נכללים ב-BYOL: כדי להגביל את מספר ליבות המעבד שאתם צריכים לקבל עבורן רישיון, מומלץ לא לערבב בין עומסי עבודה של BYOL לבין עומסי עבודה שלא נכללים ב-BYOL בקבוצת צמתים אחת, אלא להשתמש בקבוצות נפרדות של צמתים.
אם אתם משתמשים בכמה מודלים שונים של רישוי BYOL (לדוגמה, Windows Server Datacenter ו-Standard), פיצול קבוצות הצמתים לפי מודל הרישוי יכול לעזור לפשט את מעקב הרישיונות ולהפחית את עלות הרישוי.
שימוש ב-CPU overcommit ובסוגי צמתים עם יחס גבוה בין ליבות לזיכרון: סוגי הצמתים שונים ביחס בין השקעים, הליבות והזיכרון. שימוש בסוג צומת עם יחס ליבה:זיכרון גבוה יותר וCPU overcommit יכולים לעזור לצמצם את מספר הליבות שנדרשות לרישיון.
הימנעות מהתאמה לעומס (autoscaling) של הקטנה: התאמה לעומס (autoscaling) של קבוצת צמתים מאפשרת להגדיל או להקטין באופן אוטומטי את קבוצת הצמתים בהתאם לביקוש הנוכחי. אם קבוצת הצמתים גדלה וקטנה לעיתים קרובות, זה אומר שאתם משנים לעיתים קרובות את החומרה שעליה פועלות מכונות וירטואליות.
אם אתם משנים את החומרה בתדירות גבוהה יותר מהתדירות שבה מותר לכם להעביר רישיונות בין מכונות פיזיות, שינויים כאלה בחומרה עלולים להוביל למצב שבו תצטרכו לקבל רישיון ליותר ליבות ממה שאתם משתמשים בפועל.
אם יש הגבלות על התדירות שבה מותר לעבור בין מכונות פיזיות, אפשר להשבית את ההתאמה האוטומטית לעומס או להגדיר אותה כך שתתבצע רק הרחבה כדי להימנע מעלויות רישוי מוגזמות.
לא להשתמש במדיניות התחזוקה שמוגדרת כברירת מחדל: מדיניות התחזוקה שמוגדרת כברירת מחדל מאפשרת לכם לבצע אופטימיזציה של הזמינות של מכונות וירטואליות, אבל היא עלולה לגרום לשינויים תכופים בחומרה. כדי לצמצם את השינויים בחומרה ולבצע אופטימיזציה של עלויות הרישוי, מומלץ להשתמש במדיניות העברה במסגרת תחזוקת קבוצת הצמתים או הפעלה מחדש במקום.
לעומסי עבודה שלא דורשים רישוי לכל ליבה, כדאי להשתמש בשיטות המומלצות הבאות:
- שימוש במדיניות התחזוקה שמוגדרת כברירת מחדל: באמצעות מיגרציה פעילה, מדיניות התחזוקה שמוגדרת כברירת מחדל מציעה זמינות טובה יותר מאשר מדיניות ההפעלה מחדש במקום, והיא מאפשרת להימנע מעלויות תשתית נוספות של מדיניות המיגרציה במסגרת תחזוקת קבוצת הצמתים.
ניהול
אם יש לכם יותר מעומס עבודה אחד, או אם יש לכם עומסי עבודה של פיתוח ושל ייצור שצריכים לפעול בצמתים עם דייר יחיד, כדאי ליישם את השיטות המומלצות הבאות:
שימוש בקבוצות נפרדות של צמתים לסביבות פיתוח וייצור: שימוש בקבוצות נפרדות של צמתים עוזר לבודד סביבות אחת מהשנייה ולמנוע מצבים כמו הבאים:
- מכונה וירטואלית לפיתוח עלולה להשפיע על הביצועים של מכונות וירטואליות בסביבת הייצור, אם היא צורכת יותר מדי משאבי CPU, דיסק או רשת ('שכן רועש').
- יכול להיות שעומס עבודה של פיתוח ינצל את כל הקיבולת של קבוצת צמתים, וימנע יצירה של מכונות וירטואליות חדשות לייצור.
הגבלת מספר קבוצות הצמתים בכל סביבה: אם מפעילים כמה קבוצות צמתים, יכול להיות שיהיה קשה לנצל את כל קבוצת צמתים באופן מלא. כדי לבצע אופטימיזציה של הניצול, משלבים את עומסי העבודה של כל סביבה ומתזמנים אותם במספר קטן של קבוצות צמתים.
שימוש בפרויקטים ייעודיים לניהול קבוצות צמתים: לכל סביבה, יוצרים פרויקט ייעודי לניהול קבוצות צמתים. לאחר מכן משתפים את קבוצות הצמתים עם פרויקטים שמכילים עומסי עבודה.
הגישה הזו מאפשרת לפשט את בקרת הגישה באמצעות שימוש בפרויקט נפרד לכל עומס עבודה, וגם לייעל את ניצול המשאבים באמצעות שיתוף של קבוצות צמתים בין עומסי עבודה.
שיתוף קבוצות של צמתים עם פרויקטים ספציפיים: במקום לשתף קבוצה של צמתים עם ארגון שלם, אפשר לשתף אותה רק עם פרויקטים ספציפיים. בחירה של פרויקטים בנפרד עוזרת לשמור על הפרדה בין הסביבות, ומונעת חשיפה של מידע על קבוצות צמתים לפרויקטים אחרים.
הגדרת תהליך להקצאת עלויות פנימית: העלות של הפעלת קבוצת צמתים נצברת בפרויקט שמכיל את קבוצת הצמתים. אם אתם צריכים לשייך את העלות הזו לפרויקטים או לעומסי עבודה ספציפיים, כדאי לעקוב אחרי השימוש במכונות הווירטואליות שלכם עם דייר יחיד ולהשתמש בנתונים האלה כדי לבצע שיוך פנימי של עלויות.
זמינות
יכול להיות שיהיו הבדלים בין עומסי העבודה שלכם בדרישות הזמינות שלהם, וגם בשאלה אם אפשר להשיג זמינות גבוהה בשכבת האפליקציה או שצריך להטמיע אותה בשכבת התשתית:
אפליקציות מקובצות: יכול להיות שחלק מעומסי העבודה שלכם מיישמים זמינות גבוהה באפליקציה באמצעות טכניקות של קיבוץ, כמו שכפול ואיזון עומסים.
דוגמאות לעומסי עבודה כאלה כוללות בקרי דומיין של Active Directory, מופעים של אשכולות לגיבוי בעת כשל וקבוצות זמינות של SQL Server, או אפליקציות מאוזנות עומסים באשכולות שפועלות ב-IIS.
בדרך כלל, אפליקציות מקובצות יכולות לעמוד בהפסקות של מכונות וירטואליות ספציפיות, כל עוד רוב המכונות הווירטואליות נשארות זמינות.
אפליקציות לא מקובצות: יכול להיות שחלק מעומסי העבודה לא יטמיעו יכולות של אשכולות, וידרשו שהמכונה הווירטואלית עצמה תישאר זמינה.
דוגמאות לעומסי עבודה כאלה כוללות שרתי מסדי נתונים שלא משוכפלים או שרתי אפליקציות עם מצב.
כדי לבצע אופטימיזציה של הזמינות של מכונות וירטואליות ספציפיות, צריך לוודא שאפשר לבצע מיגרציה פעילה של המכונה הווירטואלית במקרה של אירוע תחזוקה קרוב של הצומת.
מיגרציה פעילה נתמכת על ידי מדיניות התחזוקה שמוגדרת כברירת מחדל ועל ידי מדיניות התחזוקה העברה בתוך קבוצת צמתים, אבל היא לא נתמכת אם משתמשים במדיניות התחזוקה הפעלה מחדש במקום.
אפליקציות לא קריטיות: יכול להיות שלא יהיו דרישות זמינות ספציפיות לעומסי עבודה של אצווה, לעומסי עבודה של פיתוח או בדיקה ולעומסי עבודה אחרים בעדיפות נמוכה יותר. בעומסי העבודה האלה, יכול להיות שיהיה מקובל אם מכונות וירטואליות (VM) לא יהיו זמינות במהלך תחזוקת הצומת.
כדי לעמוד בדרישות הזמינות של עומסי העבודה, מומלץ לפעול לפי השיטות המומלצות הבאות:
שימוש בקבוצות של צמתים באזורים שונים או באזורים שונים כדי לפרוס עומסי עבודה מקובצים: צמתים וקבוצות של צמתים עם דייר יחיד הם משאב של תחום מוגדר. כדי להגן על עצמכם מפני הפסקות חשמל אזוריות, כדאי לפרוס כמה קבוצות של צמתים באזורים שונים. אפשר להשתמש בזיקה לצומת כדי לתזמן מכונות וירטואליות כך שכל מופע של האפליקציה המקובצת יפעל בצומת אחר באזור או באזור אחר.
אם שתי קבוצות צמתים או יותר משתמשות במדיניות ברירת המחדל או במדיניות התחזוקה של הפעלה מחדש במקום, כדאי להגדיר חלונות תחזוקה כך שלא סביר שהם יחפפו.
אם צריך להפעיל כמה מופעים של האפליקציות המקובצות באזור אחד, צריך להשתמש באנטי-אפיניות כדי לוודא שהמופעים של המכונות הווירטואליות מתוזמנים בצמתים שונים או בקבוצות צמתים שונות.
מומלץ להימנע ממדיניות התחזוקה 'הפעלה מחדש במקום' לעומסי עבודה לא מקובצים שנדרשת בהם זמינות גבוהה: מדיניות התחזוקה הפעלה מחדש במקום משביתה מכונות וירטואליות כשהצומת הבסיסי דורש תחזוקה. לכן, מומלץ להשתמש במדיניות תחזוקה שונה לקבוצות צמתים שמריצות עומסי עבודה לא מקובצים שנדרשת בהם זמינות גבוהה.
שימוש בקבוצות של מופעי מכונה מנוהלים (MIG) כדי לשפר את העמידות והזמינות של עומסי העבודה: כדי לשפר עוד יותר את העמידות והזמינות של הפריסה, אפשר להשתמש בקבוצות של מופעי מכונה מנוהלים כדי לעקוב אחרי תקינות עומסי העבודה וליצור מחדש באופן אוטומטי מופעים של מכונות וירטואליות אם יש צורך בכך. אפשר להשתמש בקבוצות מופעי מכונה מנוהלות גם עבור עומסי עבודה בלי שמירת מצב וגם עבור עומסי עבודה עם שמירת מצב.
ביצועים
יכול להיות שהרגישות של עומסי העבודה שלכם לתנודות בביצועים תהיה שונה. באפליקציות פנימיות מסוימות או בעומסי עבודה של בדיקות, אופטימיזציה של העלויות עשויה להיות חשובה יותר מהבטחת ביצועים עקביים לאורך היום. במקרה של עומסי עבודה אחרים, כמו אפליקציות שפונות כלפי חוץ, יכול להיות שהביצועים יהיו קריטיים וחשובים יותר מניצול המשאבים.
כדי להפיק את המרב מהשימוש בצמתים עם דייר יחיד, מומלץ לפעול לפי השיטות המומלצות הבאות:
שימוש בקבוצות צמתים ייעודיות וב-CPU overcommit לעומסי עבודה שלא רגישים לביצועים: CPU overcommit מאפשר להגדיל את צפיפות המכונות הווירטואליות בצמתים של דייר יחיד, ויכול לעזור לצמצם את מספר הצמתים של דייר יחיד שנדרשים.
כדי להשתמש ב-CPU overcommit, צריך להשתמש בסוג צומת שתומך ב-CPU overcommit. הפעלת CPU overcommit לקבוצת צמתים גורמת לחיובים נוספים לכל שרת לדייר יחיד (sole-tenant).
השימוש ב-CPU overcommit יכול להיות הכי חסכוני אם משתמשים בקבוצת צמתים ייעודית לעומסי עבודה שמתאימים ל-CPU overcommit, ומפעילים את התכונה הזו רק בקבוצת הצמתים הזו. מומלץ להשאיר את האפשרות 'הקצאת יתר של CPU' מושבתת בכל קבוצות הצמתים שצריכות להריץ עומסי עבודה שרגישים לביצועים.
שימוש בסוג צומת עם יחס גבוה בין ליבה לזיכרון עבור CPU overcommit: CPU overcommit מאפשר לכם לשתף ליבות בין VMs, אבל לא לשתף זיכרון בין VMs. שימוש בסוג צומת עם יותר זיכרון יחסית לכל ליבת CPU עוזר לוודא שהזיכרון לא יהפוך לגורם מגביל.
- שימוש בהתאמה אוטומטית לעומס של צמתים לעומסי עבודה שרגישים לביצועים: כדי להתאים את הצרכים המשתנים של משאבים לעומסי עבודה שרגישים לביצועים, צריך להגדיר את קבוצת הצמתים לשימוש בהתאמה אוטומטית לעומס.
דפוסי פריסה
הדרך הטובה ביותר להשתמש בצמתים עם דייר יחיד תלויה בדרישות הספציפיות שלכם. בקטע הבא מתוארים כמה דפוסים שאפשר להשתמש בהם כנקודת התחלה כדי להסיק מהם ארכיטקטורה שמתאימה לדרישות הספציפיות שלכם.
כמה קבוצות של צמתים לדרישות ביצועים מעורבות
אם יש לכם שילוב של עומסי עבודה שרגישים לביצועים (לדוגמה, אפליקציות שפונות ללקוחות) ועומסי עבודה שלא רגישים לביצועים (לדוגמה, אפליקציות פנימיות), אתם יכולים להשתמש בכמה קבוצות צמתים שמשתמשות בסוגים שונים של צמתים:
- קבוצת צמתים אחת משתמשת ב-CPU overcommit ובסוג צומת עם יחס של 1:8 בין vCPU לזיכרון. קבוצת הצמתים הזו משמשת לעומסי עבודה שלא רגישים לביצועים.
- קבוצת צמתים שנייה משתמשת בסוג צומת מותאמת לצריכת מעבד גבוהה (compute-optimized) עם יחס של 1:4 בין vCPU לזיכרון, ללא CPU overcommit. קבוצת הצמתים הזו משמשת לעומסי עבודה קריטיים לביצועים, והיא מוגדרת להגדלה ולהקטנה של הקיבולת לפי דרישה.
זמינות גבוהה בכמה אזורים לעומסי עבודה (workloads) עם רישיון לכל ליבה
אם אתם מריצים עומסי עבודה באשכולות שמשתמשים ברישוי לכל ליבה, ואתם רוצים לצמצם את השינויים בחומרה, אתם יכולים להשתמש בכמה קבוצות צמתים עם חלונות תחזוקה לא חופפים כדי ליצור איזון בין זמינות לבין תקורה של רישוי:
- כמה קבוצות של צמתים נפרסות באזורים או בתחומים שונים.
- כל קבוצות הצמתים משתמשות במדיניות התחזוקה restart. קבוצות הצמתים משתמשות בחלונות תחזוקה לא חופפים, כך שלא יותר מקבוצת צמתים אחת תחווה הפסקות זמניות שקשורות לתחזוקה בכל זמן נתון.
- מכונות וירטואליות שמריצות עומסי עבודה באשכול משתמשות בתוויות שיוך כדי שכל צומת באשכול יתוזמן בקבוצת צמתים באזור אחר.
זמינות גבוהה בכמה אזורים לעומסי עבודה מעורבים עם רישוי לכל ליבה
אם אתם משתמשים ברישוי לכל ליבה, אבל לא כל עומסי העבודה שלכם מקובצים באשכולות, אתם יכולים להרחיב את הדפוס הקודם באמצעות מדיניות תחזוקה הטרוגנית:
- קבוצת הצמתים הראשית נפרסת באזור
aומריצה עומסי עבודה מקובצים ולא מקובצים. כדי לצמצם את ההשבתות שנגרמות בגלל תחזוקת חומרה, קבוצת הצמתים משתמשת במדיניות התחזוקה העברה בתוך קבוצת הצמתים. - קבוצת צמתים משנית אחת או יותר נפרסת באזורים או בתחומים נוספים. קבוצות הצמתים האלה משתמשות במדיניות התחזוקה restart, אבל בחלונות תחזוקה לא חופפים.
- מכונות וירטואליות שמריצות עומסי עבודה באשכול משתמשות בתוויות שיוך כדי שכל צומת באשכול יתוזמן בקבוצת צמתים באזור אחר.
- מופעי VM שמריצים עומסי עבודה לא מקובצים משתמשים בתוויות שיוך כדי שהם ייפרסו בקבוצת הצמתים הראשית.
אם מתזמנים רק עומסי עבודה מקובצים בקבוצות הצמתים המשניות, אפשר לוודא שההשבתות הזמניות שנגרמות כתוצאה ממדיניות התחזוקה של ההפעלה מחדש ישפיעו באופן מינימלי על הזמינות הכוללת. במקביל, אפשר להגביל את העלויות של הרישוי ותקורה של התשתית באמצעות מדיניות התחזוקה migrate within node group (העברה בתוך קבוצת הצמתים) רק לקבוצת הצמתים הראשית.