שיטות מומלצות לשימוש בצמתים של דייר יחיד להרצת עומסי עבודה של מכונות וירטואליות

כשמתכננים להריץ עומסי עבודה של מכונות וירטואליות בשרתים לדייר יחיד, צריך קודם להחליט איך לפרוס את השרתים האלה. בפרט, צריך להחליט כמה קבוצות צמתים נדרשות, ובאיזו מדיניות תחזוקה קבוצות הצמתים צריכות להשתמש:

• קבוצות של צמתים: כדי לבחור את המספר הנכון של קבוצות צמתים, צריך לאזן בין הזמינות לבין ניצול המשאבים. שימוש במספר קטן של קבוצות צמתים מאפשר לכם לבצע אופטימיזציה של ניצול המשאבים והעלויות, אבל הוא מגביל אתכם לאזור אחד. פריסת קבוצות של צמתים בכמה אזורים מאפשרת לשפר את הזמינות, אבל עלולה להוביל לניצול נמוך יותר של המשאבים.

• מדיניות בנושא התאמה אוטומטית לעומס ותחזוקה: בהתאם לדרישות הרישוי של מערכות ההפעלה והתוכנות שאתם מתכננים להפעיל, התאמה אוטומטית לעומס של הצמתים והמדיניות שתבחרו בנושא תחזוקה יכולים להשפיע על עלות הרישוי והזמינות.

כדי לקבל את ההחלטה הנכונה לגבי השימוש בצמתים עם דייר יחיד, צריך לשקול בקפידה את הדרישות שלכם.

בדיקת הדרישות

בקטע הבא מפורטות כמה דרישות שכדאי לקחת בחשבון לפני שמחליטים כמה קבוצות של צמתים צריך, ובאיזו מדיניות תחזוקה כדאי להשתמש בקבוצות של הצמתים.

רישוי BYOL ורישוי לפי ליבה

אם אתם מתכננים להשתמש ברישיון משלכם (BYOL) ב-Compute Engine, תוכלו להשתמש בצמתים עם דייר יחיד כדי לעמוד בדרישות החומרה או במגבלות שמוטלות על ידי הרישיונות האלה.

חלק מהתוכנות ומערכות ההפעלה, כמו Windows Server, יכולות להיות מרושיינות לפי ליבת CPU פיזית, ויכול להיות שהן יגדירו מגבלות על התדירות שבה מותר לכם לשנות את החומרה שמתחת למכונות הווירטואליות. התאמה אוטומטית לעומס של צמתים ומדיניות ברירת המחדל בנושא תחזוקה יכולים לגרום לשינוי החומרה בתדירות גבוהה יותר מהמותר בתנאי הרישיון, מה שיכול להוביל לחיובים נוספים על דמי רישיון.

כדי לבצע אופטימיזציה לשימוש ברישיון BYOL לכל ליבה, כדאי לפעול לפי השיטות המומלצות הבאות:

• איזון בין עלות התשתית לעלות הרישוי: כדי לחשב את העלות הכוללת של הרצת עומסי עבודה בשיטת BYOL ב-Compute Engine, צריך להתחשב גם בעלות התשתית וגם בעלות הרישוי. במקרים מסוימים, צמצום עלויות התשתית עלול להגדיל את עלויות הרישוי, או להיפך. לדוגמה, שימוש בסוג צומת עם מספר גבוה של ליבות עשוי להיות הכי טוב מבחינת עלות/ביצועים עבור עומסי עבודה מסוימים, אבל עלול להוביל לעלות רישוי נוספת אם הרישיונות מתומחרים לפי ליבה.

• שימוש בקבוצות נפרדות של צמתים לעומסי עבודה של BYOL ולעומסי עבודה שלא נכללים ב-BYOL: כדי להגביל את מספר ליבות המעבד שצריך לקבל עבורן רישיון, מומלץ לא לערבב בין עומסי עבודה של BYOL לבין עומסי עבודה שלא נכללים ב-BYOL בקבוצת צמתים אחת, אלא להשתמש בקבוצות נפרדות של צמתים.

  אם אתם משתמשים בכמה מודלים שונים של רישוי BYOL (לדוגמה, Windows Server Datacenter ו-Standard), פיצול קבוצות הצמתים לפי מודל הרישוי יכול לעזור לפשט את מעקב הרישיונות ולהפחית את עלות הרישוי.

• הימנעות מהתאמה לעומס (autoscaling) לצמצום: התאמה לעומס (autoscaling) של קבוצת צמתים מאפשרת להגדיל או לצמצם באופן אוטומטי את קבוצת הצמתים בהתאם לביקוש הנוכחי. אם קבוצת הצמתים גדלה וקטנה לעיתים קרובות, זה אומר שאתם משנים לעיתים קרובות את החומרה שעליה המכונות הווירטואליות פועלות.

  אם אתם משנים את החומרה בתדירות גבוהה יותר מהתדירות שבה מותר לכם להעביר רישיונות בין מכונות פיזיות, שינויים כאלה בחומרה עלולים להוביל למצב שבו תצטרכו לקבל רישיון ליותר ליבות ממה שאתם משתמשים בפועל.

  אם יש מגבלות על התדירות שבה מותר לעבור בין מכונות פיזיות, אפשר להימנע מעלויות רישוי מוגזמות על ידי השבתת התאמה אוטומטית לעומס (automatic scaling) או על ידי הגדרת התאמה אוטומטית לעומס (automatic scaling) ללהרחיב אופקית בהתאם לעומס (scale out) בלבד.

• אל תשתמשו במדיניות התחזוקה שמוגדרת כברירת מחדל: מדיניות התחזוקה שמוגדרת כברירת מחדל מאפשרת לכם לבצע אופטימיזציה של הזמינות של מכונות וירטואליות, אבל היא עלולה לגרום לשינויים תכופים בחומרה. כדי לצמצם את השינויים בחומרה ולבצע אופטימיזציה של עלויות הרישוי, מומלץ להשתמש במדיניות migrate within node group maintenance או restart in place.

לעומסי עבודה שלא דורשים רישוי לכל ליבה, כדאי לפעול לפי השיטות המומלצות הבאות:

• שימוש במדיניות ברירת המחדל לתחזוקה: באמצעות העברה פעילה, מדיניות ברירת המחדל לתחזוקה מציעה זמינות טובה יותר מאשר מדיניות ההפעלה מחדש במקום, והיא מאפשרת להימנע מעלויות תשתית נוספות של מדיניות ההעברה במסגרת תחזוקה של קבוצת צמתים.

ניהול

אם יש לכם יותר מעומס עבודה אחד, או אם יש לכם עומסי עבודה של פיתוח ושל ייצור שצריכים לפעול בצמתים של דייר יחיד, כדאי ליישם את השיטות המומלצות הבאות:

• שימוש בקבוצות נפרדות של צמתים לסביבות פיתוח וייצור: שימוש בקבוצות נפרדות של צמתים עוזר לבודד סביבות אחת מהשנייה ולמנוע מצבים כמו הבאים:

  • מכונה וירטואלית לפיתוח עלולה להשפיע על הביצועים של מכונות וירטואליות בסביבת הייצור, אם היא צורכת יותר מדי משאבים של מעבד, דיסק או רשת ('שכן רועש').
  • עומס עבודה של פיתוח עלול למצות את הקיבולת של קבוצת צמתים, ולמנוע יצירה של מכונות וירטואליות חדשות לייצור.

• הגבלת מספר קבוצות הצמתים בכל סביבה: אם מפעילים כמה קבוצות צמתים, יכול להיות שיהיה קשה לנצל את כל קבוצת צמתים באופן מלא. כדי לבצע אופטימיזציה של הניצול, משלבים עומסי עבודה של כל סביבה ומתזמנים אותם במספר קטן של קבוצות צמתים.

• שימוש בפרויקטים ייעודיים לניהול קבוצות צמתים: לכל סביבה, יוצרים פרויקט ייעודי לניהול קבוצות צמתים. לאחר מכן משתפים את קבוצות הצמתים עם פרויקטים שמכילים עומסי עבודה.

  הגישה הזו מאפשרת לפשט את בקרת הגישה באמצעות שימוש בפרויקט נפרד לכל עומס עבודה, וגם לייעל את ניצול המשאבים באמצעות שיתוף של קבוצות צמתים בין עומסי עבודה.

• שיתוף קבוצות צמתים עם פרויקטים ספציפיים: במקום לשתף קבוצת צמתים עם ארגון שלם, אפשר לשתף אותה רק עם פרויקטים ספציפיים. בחירה של פרויקטים בנפרד עוזרת לשמור על הפרדה בין הסביבות, ומונעת חשיפה של מידע על קבוצות צמתים לפרויקטים אחרים.

• הגדרת תהליך להקצאת עלויות פנימית: העלות של הפעלת קבוצת צמתים נצברת בפרויקט שמכיל את קבוצת הצמתים. אם אתם צריכים לשייך את העלות הזו לפרויקטים או לעומסי עבודה ספציפיים, כדאי לעקוב אחרי השימוש במכונות הווירטואליות שלכם עם דייר יחיד ולהשתמש בנתונים האלה כדי לבצע שיוך פנימי של עלויות.

זמינות

יכול להיות שיהיו הבדלים בדרישות הזמינות של עומסי העבודה שלכם, וגם בשאלה אם אפשר להשיג זמינות גבוהה בשכבת האפליקציה או שצריך להטמיע אותה בשכבת התשתית:

• אפליקציות מקובצות: יכול להיות שחלק מעומסי העבודה שלכם מיישמים זמינות גבוהה באפליקציה באמצעות שימוש בטכניקות של קיבוץ, כמו שכפול ואיזון עומסים.

  דוגמאות לעומסי עבודה כאלה כוללות בקרי דומיין של Active Directory, מופעים של אשכולות לגיבוי בעת כשל וקבוצות זמינות של SQL Server, או אפליקציות מאוזנות עומסים באשכולות שפועלות ב-IIS.

  בדרך כלל, אפליקציות מקובצות יכולות לעמוד בהפסקות של מכונות וירטואליות בודדות, כל עוד רוב המכונות הווירטואליות נשארות זמינות.

• אפליקציות לא מקובצות: יכול להיות שחלק מהעומסים שלכם לא יטמיעו יכולות של קיבוץ, וידרשו שהמכונה הווירטואלית עצמה תישאר זמינה.

  דוגמאות לעומסי עבודה כאלה כוללות שרתים של מסדי נתונים שלא משוכפלים או שרתים של אפליקציות עם מצב.

  כדי לבצע אופטימיזציה של הזמינות של מכונות וירטואליות ספציפיות, צריך לוודא שאפשר לבצע העברה פעילה של המכונה הווירטואלית במקרה של אירוע תחזוקה קרוב של הצומת.

  מיגרציה פעילה נתמכת על ידי מדיניות ברירת המחדל לתחזוקה ועל ידי מדיניות התחזוקה העברה בתוך קבוצת צמתים, אבל היא לא נתמכת אם משתמשים במדיניות התחזוקה הפעלה מחדש במקום.

• אפליקציות לא קריטיות: יכול להיות שלא יהיו דרישות זמינות ספציפיות לעומסי עבודה של אצווה, לעומסי עבודה של פיתוח/בדיקה ולעומסי עבודה אחרים בעדיפות נמוכה יותר. יכול להיות שיהיה מקובל שעומסי העבודה האלה לא יהיו זמינים במהלך תחזוקת הצומת, אם מדובר במכונות וירטואליות בודדות.

כדי לעמוד בדרישות הזמינות של עומסי העבודה, מומלץ לפעול לפי השיטות המומלצות הבאות:

• שימוש בקבוצות של צמתים באזורים שונים כדי לפרוס עומסי עבודה מקובצים: צמתים וקבוצות של צמתים עם דייר יחיד הם משאב של תחום מוגדר. כדי להגן על עצמכם מפני הפסקות חשמל אזוריות, כדאי לפרוס כמה קבוצות של צמתים באזורים שונים. אפשר להשתמש בזיקה לצומת כדי לתזמן מכונות וירטואליות כך שכל מופע של האפליקציה המקובצת יפעל בצומת אחר באזור או באזור אחר.

  אם שתי קבוצות צמתים או יותר משתמשות במדיניות ברירת המחדל או במדיניות התחזוקה של הפעלה מחדש במקום, כדאי להגדיר חלונות תחזוקה כך שלא סביר שהם יחפפו.

  אם צריך להפעיל כמה מופעים של האפליקציות המקובצות באזור אחד, צריך להשתמש בשיטת anti-affinity כדי לוודא שהמכונות הווירטואליות מתוזמנות בצמתים שונים או בקבוצות צמתים שונות.

• מומלץ להימנע ממדיניות התחזוקה של הפעלה מחדש במקום לעומסי עבודה לא מקובצים שנדרשת בהם זמינות גבוהה: מדיניות התחזוקה של הפעלה מחדש במקום משביתה מכונות וירטואליות כשהצומת הבסיסי דורש תחזוקה. לכן, מומלץ להשתמש במדיניות תחזוקה שונה לקבוצות צמתים שמריצות עומסי עבודה לא מקובצים שנדרשת בהם זמינות גבוהה.

• שימוש בקבוצות של מופעי מכונה מנוהלים כדי לשפר את העמידות והזמינות של עומסי העבודה: אפשר לשפר עוד יותר את העמידות והזמינות של הפריסה באמצעות קבוצות של מופעי מכונה מנוהלים כדי לעקוב אחרי תקינות עומסי העבודה וליצור מחדש מופעים של מכונות וירטואליות באופן אוטומטי אם יש צורך בכך. אפשר להשתמש בקבוצות מופעי מכונה מנוהלות גם עבור עומסי עבודה בלי שמירת מצב וגם עבור עומסי עבודה עם שמירת מצב.

ביצועים

יכול להיות שהרגישות של עומסי העבודה שלכם לתנודות בביצועים תהיה שונה. באפליקציות פנימיות מסוימות או בעומסי עבודה של בדיקות, אופטימיזציה של העלויות עשויה להיות חשובה יותר מהבטחת ביצועים עקביים במהלך היום. במקרה של עומסי עבודה אחרים, כמו אפליקציות שפונות כלפי חוץ, הביצועים עשויים להיות קריטיים וחשובים יותר מניצול המשאבים.

כדי להפיק את המרב מהשימוש בצמתים עם דייר יחיד, כדאי לפעול לפי השיטות המומלצות הבאות:

• שימוש בהתאמה אוטומטית לעומס של צמתים לעומסי עבודה שרגישים לביצועים: כדי להתאים את הצורך המשתנה במשאבים לעומסי עבודה שרגישים לביצועים, צריך להגדיר את קבוצת הצמתים לשימוש בהתאמה אוטומטית לעומס.

דפוסי פריסה

הדרך הטובה ביותר להשתמש בצמתים עם דייר יחיד תלויה בדרישות הספציפיות שלכם. בקטע הבא מפורטים כמה דפוסים שבהם אפשר להשתמש כנקודת התחלה כדי לגזור ארכיטקטורה שמתאימה לדרישות הספציפיות שלכם.

זמינות גבוהה בכמה אזורים לעומסי עבודה (workloads) עם רישיון לכל ליבה

אם אתם מריצים עומסי עבודה באשכולות שמשתמשים ברישוי לכל ליבה, ואתם רוצים לצמצם את השינויים בחומרה, אתם יכולים להשתמש בכמה קבוצות צמתים עם חלונות תחזוקה לא חופפים כדי ליצור איזון בין זמינות לבין תקורה של רישוי:

• כמה קבוצות של צמתים נפרסות על פני אזורים או תחומים שונים.
• כל קבוצות הצמתים משתמשות במדיניות התחזוקה restart. קבוצות הצמתים משתמשות בחלונות תחזוקה לא חופפים, כך שלא יותר מקבוצת צמתים אחת תחווה הפסקות שירות שקשורות לתחזוקה בכל זמן נתון.
• מכונות וירטואליות שמריצות עומסי עבודה באשכול משתמשות בתוויות שיוך כדי שכל צומת באשכול יתוזמן בקבוצת צמתים באזור אחר.

זמינות גבוהה בכמה אזורים לעומסי עבודה מעורבים עם רישוי לכל ליבה

אם אתם משתמשים ברישוי לכל ליבה, אבל לא כל עומסי העבודה שלכם מקובצים באשכולות, אתם יכולים להרחיב את הדפוס הקודם באמצעות מדיניות תחזוקה הטרוגנית:

• קבוצת הצמתים הראשית נפרסת באזור a ומריצה עומסי עבודה מקובצים ולא מקובצים. כדי לצמצם את ההשבתות שנגרמות בגלל תחזוקת חומרה, קבוצת הצמתים משתמשת במדיניות התחזוקה העברה בתוך קבוצת צמתים.
• קבוצה משנית אחת או יותר של צמתים נפרסים באזורים או בתחומים נוספים. קבוצות הצמתים האלה משתמשות במדיניות התחזוקה restart, אבל בחלונות תחזוקה לא חופפים.
• מכונות וירטואליות שמריצות עומסי עבודה באשכול משתמשות בתוויות שיוך כדי שכל צומת באשכול יתוזמן בקבוצת צמתים באזור אחר.
• מופעי VM שמריצים עומסי עבודה לא מקובצים משתמשים בתוויות שיוך כדי שהם ייפרסו בקבוצת הצמתים הראשית.

אם מתזמנים רק עומסי עבודה מקובצים בקבוצות הצמתים המשניות, אפשר לוודא שההשבתות הזמניות שנגרמות כתוצאה ממדיניות התחזוקה של ההפעלה מחדש ישפיעו באופן מינימלי על הזמינות הכוללת. במקביל, אתם מגבילים את העלויות של הרישוי והתשתית באמצעות מדיניות התחזוקה העברה בתוך קבוצת צמתים רק לקבוצת הצמתים הראשית.

המאמרים הבאים

• מידע נוסף על צמתים של דייר יחיד

• איך משתמשים ברישיונות משלכם