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