כשמתכננים להריץ עומסי עבודה של מכונות וירטואליות בשרתים לדייר יחיד (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 overcommit.
הימנעות מהתאמה לעומס (autoscaling) של צמצום אופקי: התאמה לעומס של קבוצת צמתים מאפשרת להגדיל או להקטין באופן אוטומטי קבוצת צמתים על סמך הביקוש הנוכחי. אם קבוצת הצמתים גדלה וקטנה לעיתים קרובות, זה אומר שאתם משנים לעיתים קרובות את החומרה שעליה המכונות הווירטואליות פועלות.
אם אתם מחליפים חומרה בתדירות גבוהה יותר מהתדירות שבה מותר לכם להעביר רישיונות בין מכונות פיזיות, שינויי החומרה האלה יכולים להוביל למצב שבו תצטרכו לרכוש רישיונות ליותר ליבות ממה שאתם משתמשים בפועל.
אם יש הגבלות על התדירות שבה מותר לעבור בין מכונות פיזיות, אפשר להימנע מעלויות רישוי מוגזמות על ידי השבתת התאמה אוטומטית לעומס (automatic scaling) או על ידי הגדרת התאמה אוטומטית לעומס (automatic scaling) להרחבה אופקית בהתאם לעומס (scale out) בלבד.
אל תשתמשו במדיניות התחזוקה שמוגדרת כברירת מחדל: מדיניות התחזוקה שמוגדרת כברירת מחדל מאפשרת לכם לבצע אופטימיזציה של הזמינות של מכונות וירטואליות, אבל היא עלולה לגרום לשינויים תכופים בחומרה. כדי לצמצם את השינויים בחומרה ולבצע אופטימיזציה של עלות הרישוי, השתמשו במדיניות העברה במסגרת תחזוקה של קבוצת צמתים או הפעלה מחדש במקום.
לעומסי עבודה שלא דורשים רישוי לכל ליבה, כדאי להשתמש בשיטות המומלצות הבאות:
- שימוש במדיניות התחזוקה שמוגדרת כברירת מחדל: באמצעות מיגרציה פעילה, מדיניות התחזוקה שמוגדרת כברירת מחדל מציעה זמינות טובה יותר ממדיניות ההפעלה מחדש במקום, והיא חוסכת את עלות התשתית הנוספת של מדיניות המיגרציה במסגרת תחזוקת קבוצת הצמתים.
ניהול
אם יש לכם יותר מעומס עבודה אחד, או אם יש לכם עומסי עבודה גם בפיתוח וגם בייצור שצריכים לפעול בשרתים לדייר יחיד (sole-tenant), כדאי ליישם את השיטות המומלצות הבאות:
שימוש בקבוצות צמתים נפרדות לסביבות פיתוח וייצור: שימוש בקבוצות צמתים נפרדות עוזר לבודד סביבות זו מזו ולמנוע מצבים כמו הבאים:
- מכונה וירטואלית לפיתוח עלולה להשפיע על הביצועים של מכונות וירטואליות בסביבת הייצור, אם היא צורכת יותר מדי משאבי מעבד, דיסק או רשת ("שכן רועש").
- עומס עבודה של פיתוח עלול לנצל את כל הקיבולת של קבוצת צמתים, ולמנוע יצירה של מכונות וירטואליות חדשות בסביבת הייצור.
הגבלת מספר קבוצות הצמתים בכל סביבה: אם מריצים כמה קבוצות של צמתים, יכול להיות שיהיה קשה לנצל באופן מלא כל קבוצת צמתים. כדי לבצע אופטימיזציה של הניצול, כדאי לשלב עומסי עבודה של כל סביבה ולתזמן אותם במספר קטן של קבוצות צמתים.
שימוש בפרויקטים ייעודיים לניהול קבוצות של צמתים: לכל סביבה, צרו פרויקט ייעודי לניהול קבוצות של צמתים. לאחר מכן משתפים את קבוצות הצמתים עם פרויקטים שמכילים עומסי עבודה.
הגישה הזו מאפשרת לפשט את בקרת הגישה באמצעות שימוש בפרויקט נפרד לכל עומס עבודה, וגם לאפשר אופטימיזציה של ניצול המשאבים באמצעות שיתוף של קבוצות צמתים בין עומסי עבודה.
שיתוף קבוצות צמתים עם פרויקטים בודדים: במקום לשתף קבוצת צמתים עם ארגון שלם, אפשר לשתף אותה רק עם פרויקטים בודדים. בחירת פרויקטים בנפרד עוזרת לשמור על הפרדה בין סביבות, ומונעת חשיפת מידע על קבוצות צמתים לפרויקטים אחרים.
הגדרת תהליך לשיוך עלויות פנימיות: העלות של הפעלת קבוצת צמתים נצברת בפרויקט שמכיל את קבוצת הצמתים. אם אתם צריכים לשייך את העלות הזו לפרויקטים או לעומסי עבודה ספציפיים, כדאי לעקוב אחרי השימוש במכונות הווירטואליות שלכם בדייר יחיד ולהשתמש בנתונים האלה כדי לבצע שיוך עלויות פנימי.
זמינות
לעומסי העבודה שלכם יכולות להיות דרישות זמינות שונות, וייתכן שיהיה אפשר להשיג זמינות גבוהה בשכבת האפליקציה או שיהיה צורך להטמיע אותה בשכבת התשתית:
אפליקציות באשכולות: בחלק מעומסי העבודה שלכם יכול להיות שתטמיעו זמינות גבוהה באפליקציה באמצעות טכניקות של אשכולות, כמו שכפול ואיזון עומסים.
דוגמאות לעומסי עבודה כאלה כוללות בקרי דומיין של Active Directory, SQL Server Failover Cluster Instances ו-Availability Groups, או אפליקציות מקובצות לאיזון עומסים שפועלות ב-IIS.
בדרך כלל, אפליקציות מקובצות יכולות לעמוד בהפסקות של מכונות וירטואליות ספציפיות, כל עוד רוב המכונות הווירטואליות ממשיכות להיות זמינות.
אפליקציות ללא אשכולות: יכול להיות שחלק מעומסי העבודה לא מיישמים יכולות של אשכולות, ובמקום זאת דורשים שהמכונה הווירטואלית עצמה תהיה זמינה.
דוגמאות לעומסי עבודה כאלה כוללות שרתי מסדי נתונים לא משוכפלים או שרתי אפליקציות עם שמירת מצב (stateful).
כדי לשפר את הזמינות של מכונות וירטואליות ספציפיות, צריך לוודא שאפשר לבצע מיגרציה פעילה של המכונה הווירטואלית במקרה של אירוע תחזוקה קרוב של הצומת.
אפשר לבצע מיגרציה פעילה באמצעות מדיניות ברירת המחדל לתחזוקה ומדיניות התחזוקה להעברה בתוך קבוצת הצמתים, אבל אי אפשר לבצע אותה באמצעות מדיניות התחזוקה להפעלה מחדש במקום.
אפליקציות לא קריטיות: יכול להיות שלא יהיו דרישות זמינות ספציפיות לעומסי עבודה של אצווה, לעומסי עבודה של פיתוח/בדיקה ולעומסי עבודה אחרים בעדיפות נמוכה יותר. בעומסי עבודה כאלה, יכול להיות שזה בסדר אם מכונות וירטואליות מסוימות לא יהיו זמינות בזמן התחזוקה של הצומת.
כדי לעמוד בדרישות הזמינות של עומסי העבודה, כדאי לפעול לפי השיטות המומלצות הבאות:
שימוש בקבוצות של צמתים בתחומים או באזורים שונים כדי לפרוס עומסי עבודה מקובצים: שרתי לדייר יחיד (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) עוזר לוודא שהזיכרון לא יהפוך לגורם מגביל.
- שימוש בהתאמה אוטומטית לעומס של צמתים לעומסי עבודה שרגישים לביצועים: כדי להתאים את עצמכם לצרכים משתנים של משאבים לעומסי עבודה שרגישים לביצועים, כדאי להגדיר את קבוצת הצמתים לשימוש בהתאמה אוטומטית לעומס.
תבניות פריסה
הדרך הטובה ביותר להשתמש בשרתים לדייר יחיד (sole-tenant) תלויה בדרישות הספציפיות שלכם. בקטע הבא מפורטים כמה דפוסים שבהם אפשר להשתמש כנקודת התחלה כדי ליצור ארכיטקטורה שמתאימה לדרישות הספציפיות שלכם.
קבוצות של כמה צמתים לדרישות ביצועים מעורבות
אם יש לכם שילוב של עומסי עבודה שרגישים לביצועים (לדוגמה, אפליקציות שפונות ללקוחות) ועומסי עבודה שלא רגישים לביצועים (לדוגמה, אפליקציות פנימיות), אתם יכולים להשתמש בכמה קבוצות צמתים שמשתמשות בסוגים שונים של צמתים:
- קבוצת צמתים אחת משתמשת ב-CPU overcommit ובסוג צומת עם יחס של 1:8 בין vCPU לזיכרון. קבוצת הצמתים הזו משמשת לעומסי עבודה שלא רגישים לביצועים.
- קבוצת צמתים שנייה משתמשת בסוג צומת מותאמת לצריכת מעבד גבוהה (compute-optimized) עם יחס של 1:4 בין vCPU לזיכרון, ללא CPU overcommit. קבוצת הצמתים הזו משמשת לעומסי עבודה קריטיים לביצועים, והיא מוגדרת להרחבה ולהקטנה לפי דרישה.
זמינות גבוהה בכמה אזורים לעומסי עבודה באשכולות עם רישיון לכל ליבה
אם אתם מריצים עומסי עבודה באשכולות שמשתמשים ברישוי לכל ליבה, ואתם צריכים לצמצם את השינויים בחומרה, אתם יכולים לאזן בין הזמינות לבין התקורה של הרישוי באמצעות כמה קבוצות של צמתים עם חלונות זמן לתחזוקה שלא חופפים:
- כמה קבוצות של צמתים נפרסות על פני אזורים או תחומים שונים.
- כל קבוצות הצמתים משתמשות במדיניות התחזוקה restart. לקבוצות הצמתים יש חלונות זמן לתחזוקה שלא חופפים, כדי שלא יותר מקבוצת צמתים אחת תחווה הפסקות שקשורות לתחזוקה בכל פעם.
- מכונות וירטואליות שמריצות עומסי עבודה באשכול משתמשות בתוויות שיוך כדי שכל צומת באשכול יתוזמן בקבוצת צמתים באזור אחר.
זמינות גבוהה בכמה אזורים לעומסי עבודה מעורבים עם רישיון לכל ליבה
אם אתם משתמשים ברישוי לכל ליבה, אבל לא כל עומסי העבודה שלכם מקובצים, אתם יכולים להרחיב את הדפוס הקודם באמצעות מדיניות תחזוקה הטרוגנית:
- קבוצת הצמתים הראשית נפרסת באזור
aומריצה עומסי עבודה מקובצים ולא מקובצים. כדי למזער את ההשבתות שנגרמות בגלל תחזוקת חומרה, קבוצת הצמתים משתמשת במדיניות התחזוקה העברה בתוך קבוצת צמתים. - קבוצה משנית אחת או יותר של צמתים נפרסים באזורים או בתחומים נוספים. קבוצות הצמתים האלה משתמשות במדיניות התחזוקה restart, אבל משתמשות בחלונות זמן לתחזוקה שלא חופפים.
- מכונות וירטואליות שמריצות עומסי עבודה באשכולות משתמשות בתוויות של זיקה, כדי שכל צומת באשכול יתוזמן בקבוצת צמתים באזור אחר.
- במכונות וירטואליות שמריצות עומסי עבודה שלא שייכים לאשכולות, משתמשים בתוויות של שיוך כדי לפרוס אותן בקבוצת הצמתים הראשית.
אם תזמנו רק עומסי עבודה באשכולות בקבוצות הצמתים המשניות, תוכלו לוודא שההפסקות הזמניות שנגרמות על ידי מדיניות התחזוקה של ההפעלה מחדש ישפיעו באופן מינימלי על הזמינות הכוללת. במקביל, אתם מגבילים את התקורה של הרישוי והתשתית באמצעות מדיניות התחזוקה העברה בתוך קבוצת צמתים לקבוצת הצמתים הראשית בלבד.
המאמרים הבאים
- מידע נוסף על שרתים לדייר יחיד (sole-tenant)