סקירה כללית של דיירות יחידה

דיירות יחידה מספקת גישה בלעדית לצומת לדייר יחיד (sole-tenant), שרת פיזי של Compute Engine שמיועד לאירוח של המכונות הווירטואליות של הפרויקט שלכם בלבד. אתם יכולים להשתמש בצמתים של דיירים יחידים כדי להפריד פיזית בין המכונות הווירטואליות שלכם לבין מכונות וירטואליות בפרויקטים אחרים, או כדי לקבץ את המכונות הווירטואליות שלכם יחד באותה חומרת מארח, כפי שמוצג בתרשים הבא. אתם יכולים גם ליצור קבוצת שרתים לדייר יחיד (sole-tenant) ולציין אם אתם רוצים לשתף אותה עם פרויקטים אחרים או עם הארגון כולו.

מארח עם כמה דיירים לעומת שרת לדייר יחיד (sole-tenant).
איור 1: מארח עם כמה דיירים לעומת שרת לדייר יחיד.

מכונות וירטואליות שפועלות בשרתים לדייר יחיד (sole-tenant) יכולות להשתמש באותן תכונות של Compute Engine כמו מכונות וירטואליות אחרות, כולל תזמון שקוף ואחסון בלוקים, אבל עם שכבה נוספת של בידוד חומרה. כדי לתת לכם שליטה מלאה על המכונות הווירטואליות בשרת הפיזי, כל צומת של שרת לדייר יחיד שומר על מיפוי של אחד לאחד לשרת הפיזי שמגבה את הצומת.

בשרת לדייר יחיד (sole-tenant), אתם יכולים להקצות כמה מכונות וירטואליות בסוגי מכונות בגדלים שונים, וכך להשתמש ביעילות במשאבים הבסיסיים של חומרת המארח הייעודי. בנוסף, אם אתם בוחרים לא לשתף את החומרה המארחת עם פרויקטים אחרים, אתם יכולים לעמוד בדרישות האבטחה או התאימות באמצעות עומסי עבודה שדורשים בידוד פיזי מעומסי עבודה או ממכונות וירטואליות אחרות. אם עומס העבודה שלכם דורש שכירות יחידה רק באופן זמני, אתם יכולים לשנות את השכירות של המכונה הווירטואלית לפי הצורך.

שרתים לדייר יחיד (sole-tenant) יכולים לעזור לכם לעמוד בדרישות של חומרה ייעודית בתרחישים של החברה מביאה את הרישיון שלה (BYOL), שבהם נדרשים רישיונות לכל ליבה או לכל מעבד. כשמשתמשים בשרתים לדייר יחיד (sole-tenant), יש לכם גישה מסוימת לחומרה הבסיסית, שמאפשרת לכם לעקוב אחרי השימוש בליבה ובמעבד. כדי לעקוב אחרי השימוש הזה, Compute Engine מדווח על המזהה של השרת הפיזי שבו מתוזמנת המכונה הווירטואלית. לאחר מכן, באמצעות Cloud Logging, תוכלו לראות את היסטוריית השימוש בשרת של מכונה וירטואלית.

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

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

שיקולים שקשורים לעומסי עבודה

סוגי עומסי העבודה הבאים יכולים להפיק תועלת משימוש בשרתים לדייר יחיד (sole-tenant):

  • עומסי עבודה של גיימינג עם דרישות ביצועים

  • עומסי עבודה בתחום הפיננסים או הבריאות עם דרישות אבטחה ותאימות

  • עומסי עבודה ב-Windows עם דרישות רישוי

  • עומסי עבודה של למידת מכונה, עיבוד נתונים או רינדור תמונות. לעומסי העבודה האלה, כדאי להזמין מראש מעבדי GPU.

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

תבניות של צמתים

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

כשיוצרים תבנית צומת, צריך לציין את סוג הצומת. כשיוצרים תבנית צומת, אפשר לציין תוויות של שיוך לצומת. אפשר לציין תוויות של שיוך (affinity) לצומת רק בתבנית צומת. אי אפשר לציין תוויות של שיוך צמתים בקבוצת צמתים.

סוגי הצמתים

כשמגדירים תבנית של צומת, צריך לציין את סוג הצומת שיוחל על כל הצמתים בקבוצת הצמתים שנוצרה על סמך תבנית הצומת. סוג הצומת של השרת לדייר יחיד, שאליו מפנה תבנית הצומת, מציין את הכמות הכוללת של ליבות ה-vCPU והזיכרון של צמתים שנוצרו בקבוצות של צמתים שמשתמשות בתבנית הזו. לדוגמה, לסוג הצומת n2-node-80-640 יש 80 מעבדי vCPU וזיכרון בנפח 640GB.

המכונות הווירטואליות שמוסיפים לשרת לדייר יחיד (sole-tenant) צריכות להיות מאותו סוג מכונה כמו סוג הצומת שצוין בתבנית הצומת. לדוגמה, סוגי צמתים לדייר יחיד (sole-tenant) ב-n2 תואמים רק למכונות וירטואליות שנוצרו עם סוג המכונה n2. אפשר להוסיף מכונות וירטואליות לשרת לדייר יחיד (sole-tenant) עד שהכמות הכוללת של מעבדי ה-vCPU או הזיכרון חורגת מהקיבולת של השרת.

כשיוצרים קבוצת צמתים באמצעות תבנית צומת, כל צומת בקבוצת הצמתים מקבל בירושה את המפרטים של סוג הצומת של תבנית הצומת. סוג הצומת חל על כל צומת בנפרד בתוך קבוצת צמתים, ולא על כל הצמתים בקבוצה באופן אחיד. לכן, אם יוצרים קבוצת צמתים עם שני צמתים מסוג n2-node-80-640, לכל צומת מוקצים 80 מעבדי vCPU וזיכרון בנפח 640GB.

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

בטבלה הבאה מוצגים סוגי הצמתים הזמינים. כדי לראות רשימה של סוגי הצמתים שזמינים לפרויקט, מריצים את הפקודה gcloud compute sole-tenancy node-types list או יוצרים בקשת REST מסוג nodeTypes.list.

סוג הצומת מעבד מידע vCPU GB vCPU:GB שקעים ליבות:שקע סה"כ ליבות מספר המכונות הווירטואליות המקסימלי שמותר
a2-highgpu-node-96-680 Cascade Lake 96 680 1:7.08 2 24 48 8
a2-megagpu-node-96-1360 Cascade Lake 96 1,360 1:14.17 2 24 48 1
a2-ultragpu-node-96-1360-lssd 1 Cascade Lake 96 1,360 1:14.17 2 24 48 8
a3-highgpu-node-208-1872-lssd 1 Sapphire Rapids 208 1,872 1:9 2 56 112 8
a3-megagpu-node-208-1872-lssd 1 Sapphire Rapids 208 1,872 1:9 2 56 112 1
c2-node-60-240 Cascade Lake 60 240 1:4 2 18 36 15
c3-node-176-352 Sapphire Rapids 176 352 1:2 2 56 112 44
c3-node-176-704 Sapphire Rapids 176 704 1:4 2 56 112 40
c3-node-176-704-lssd
(עם 32 כונני SSD מקומיים)		 Sapphire Rapids 176 704 1:4 2 56 112 40
c3-node-176-1408 Sapphire Rapids 176 1,408 1:8 2 56 112 44
c3d-node-360-708 AMD EPYC Genoa 360 708 1:2 2 96 192 34
c3d-node-360-1440 AMD EPYC Genoa 360 1,440 1:4 2 96 192 40
c3d-node-360-2880 AMD EPYC Genoa 360 2,880 1:8 2 96 192 40
c4-node-288-576 Granite Rapids 288 576 1:2 2 78 156 20
c4-node-288-1080 Granite Rapids 288 1,080 1:3.75 2 78 156 20
c4-node-288-1080-lssd
(עם 48 כונני SSD מקומיים)		 Granite Rapids 288 1,080 1:3.75 2 78 156 20
c4-node-288-2232 Granite Rapids 288 2,232 1:7.75 2 78 156 20
c4-node-288-2232-lssd
(עם 48 כונני SSD מקומיים)		 Granite Rapids 288 2,232 1:7.75 2 78 156 20
c4a-node-72-144 Google Axion 72 144 1:2 1 80 80 22
c4a-node-72-288 Google Axion 72 288 1:4 1 80 80 16
c4a-node-72-576 Google Axion 72 576 1:8 1 80 80 34
c4d-node-384-720 AMD EPYC Turin 384 720 1:2 2 128 256 25
c4d-node-384-1488 AMD EPYC Turin 384 1,488 1:4 2 128 256 25
c4d-node-384-3024 AMD EPYC Turin 384 3,024 1:8 2 128 256 25
c4n-node-192-384 Emerald Rapids 192 384 1:2 2 60 120 26
c4n-node-192-720 Emerald Rapids 192 720 1:3.75 2 60 120 26
c4n-node-192-1488 Emerald Rapids 192 1,488 1:7.75 2 60 120 26
g2-node-96-384 Cascade Lake 96 384 1:4 2 28 56 8
g4-node-384-1440 AMD EPYC Turin 384 1440 1:3.75 2 96 192 64
g2-node-96-432 Cascade Lake 96 432 1:4.5 2 28 56 8
h3-node-88-352 Sapphire Rapids 88 352 1:4 2 56 112 1
h4d-node-192-720 AMD EPYC Turin 192 720 1:4 2 128 256 1
h4d-node-192-1488 AMD EPYC Turin 192 1,488 1:8 2 128 256 1
h4d-node-192-3024 AMD EPYC Turin 192 3024 1:16 2 128 256 1
h4d-node-192-3024-lssd AMD EPYC Turin 192 3024 1:16 2 128 256 1
m1-node-96-1433 Skylake 96 1,433 1:14.93 2 28 56 1
m1-node-160-3844 Broadwell E7 160 3,844 1:24 4 22 88 4
m2-node-416-8832 Cascade Lake 416 8,832 1:21.23 8 28 224 1
m2-node-416-11776 Cascade Lake 416 11,776 1:28.31 8 28 224 2
m3-node-128-1952 אגם קפוא 128 1,952 1:15.25 2 36 72 2
m3-node-128-3904 אגם קפוא 128 3,904 1:30.5 2 36 72 2
m4-node-224-2976 Emerald Rapids 224 2,976 1:13.3 2 60 120 16
m4-node-224-5952 Emerald Rapids 224 5,952 1:26.7 2 60 120 16
n1-node-96-624 Skylake 96 624 1:6.5 2 28 56 96
n2-node-80-640 Cascade Lake 80 640 1:8 2 24 48 80
n2-node-128-864 אגם קפוא 128 864 1:6.75 2 36 72 128
n2d-node-224-896 AMD EPYC Milan 224 896 1:4 2 64 128 108
n2d-node-224-1792 AMD EPYC Milan 224 1,792 1:8 2 64 128 112
n4-node-224-1372 Emerald Rapids 224 1,372 1:6 2 60 120 90
n4a-node-96-624 Google Axion 96 624 1:6.5 1 96 96 72

‫1סוגי צמתים עם SSD מקומי: הסיומת -lssd מציינת שדיסקים של SSD מקומי מחוברים לצומת. בסוגי הצמתים A3 High,‏ A3 Mega ו-A2 Ultra, כברירת מחדל גם דיסקים מסוג Local SSD מצורפים אם לא מצוינת סיומת. כדי להקצות את סוגי הצמתים האלה בלי דיסקים של SSD מקומי, צריך להשתמש בסיומת -nolssd (לדוגמה, a3-megagpu-node-208-1872-nolssd או a2-ultragpu-node-96-1360-nolssd).

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

קבוצות של צמתים והקצאת מכונות וירטואליות

כדי להקצות מכונות וירטואליות בשרתים לדייר יחיד (sole-tenant), מבצעים את המשימות הבאות לפי הסדר:

  1. יוצרים תבנית של צומת לדייר יחיד.
  2. יצירת קבוצת צמתים של שרת לדייר יחיד.
  3. הקצאת מכונות וירטואליות בשרתים לדייר יחיד.

קבוצת צמתים היא קבוצה הומוגנית של שרתים לדייר יחיד (sole-tenant) באזור ספציפי. קבוצות של צמתים יורשות מאפיינים מתבנית הצומת שעליה הן מבוססות, ויכולות להכיל כמה מכונות וירטואליות מאותה סדרת מכונות שפועלות בסוגי מכונות בגדלים שונים, כל עוד לסוג המכונה יש 2 יחידות vCPU או יותר.

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

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

מדיניות התחזוקה של המארח

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

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

מדיניות ברירת המחדל לתחזוקת המארח

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

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

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

באיור הבא מוצגת אנימציה של מדיניות ברירת המחדל לתחזוקת המארח.

אנימציה של מדיניות ברירת המחדל לתחזוקת מארחים.
איור 2: אנימציה של מדיניות ברירת המחדל לתחזוקת המארח.

מכונות וירטואליות שלא תומכות במיגרציה פעילה

במכונות וירטואליות שלא תומכות במיגרציה פעילה (כמו חלק מ-Confidential VMs), במהלך אירוע תחזוקה של המארח, Compute Engine מקצה שרת לדייר יחיד (sole-tenant) חדש, מסיים את המכונות הווירטואליות בצומת הישן ואז מפעיל אותן מחדש באופן אוטומטי בצומת החדש. ההפרעה למכונה הווירטואלית דומה להפעלה מחדש רגילה.

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

כדי לצמצם את זמן ההשבתה, מגדירים את מדיניות התחזוקה של שרת לדייר יחיד (sole-tenant) לערך Default, ומגדירים את המכונות הווירטואליות כך שיסתיימו בזמן תחזוקת המארח עם הפעלה מחדש אוטומטית (onHostMaintenance=TERMINATE ו-automaticRestart=true).

מדיניות תחזוקה של מארח להפעלה מחדש במקום

כשמשתמשים במדיניות הזו לתחזוקת המארח, Compute Engine מפסיק את המכונות הווירטואליות במהלך אירועים במארח, ואז מפעיל אותן מחדש באותו שרת פיזי אחרי האירוע במארח. כשמשתמשים במדיניות הזו, צריך להגדיר את הערך של on host maintenance של המכונה הווירטואלית ל-TERMINATE.

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

באמצעות המדיניות הזו, אפשר להקצות את המכונה לקבוצת הצמתים באמצעות node-name, node-group-name או תווית של שיוך לצומת.

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

בתרשים הבא מוצגת אנימציה של מדיניות התחזוקה Restart in place.

אנימציה של מדיניות התחזוקה של המארח "הפעלה מחדש במקום"
איור 3: אנימציה של מדיניות התחזוקה Restart in place במארח.

מדיניות התחזוקה של המארח "העברה בתוך קבוצת צמתים"

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

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

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

במדיניות הזו, אי אפשר להקצות או לבצע מיגרציה פעילה ידנית של מכונה וירטואלית לצומת ספציפי באמצעות תווית הזיקה (Affinity) node-name. אתם יכולים להשתמש בכל תוויות של זיקה לצומת בהתאמה אישית בשביל ה-VMs, כל עוד אתם מציינים גם את תווית הזיקה node-group-name ולא את node-name.

כדי לוודא שיש מספיק קיבולת למיגרציה פעילה, המערכת של Compute Engine שומרת צומת אחד לכל 20 צמתים שאתם שומרים. באיור הבא מוצגת אנימציה של מדיניות התחזוקה של המארח Migrate within node group.

אנימציה של מדיניות התחזוקה של המארח "העברה בתוך קבוצת צמתים".
איור 4: אנימציה של מדיניות התחזוקה של המארח Migrate within node group.

בטבלה הבאה מפורט מספר הצמתים ש-Compute Engine שומר כגיבוי, בהתאם למספר הצמתים שאתם שומרים לקבוצת הצמתים.

סה"כ צמתים בקבוצה צמתים שמורים להעברה פעילה
1 לא רלוונטי. צריך להזמין לפחות 2 צמתים.
‫2 עד 20 1
‫21 עד 40 2
41 עד 60 3
61 עד 80 4
81 עד 100 5

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

הצמדת מכונה לכמה קבוצות של צמתים

אפשר להצמיד מכונה לכמה קבוצות של צמתים באמצעות node-group-name תווית השיוך בתנאים הבאים:

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

לדוגמה, אם רוצים להצמיד מכונה test-node לשתי קבוצות של צמתים, node-group1 ו-node-group2, צריך לוודא את הדברים הבאים:

  • מדיניות התחזוקה של המארח test-node היא Migrate VM instance.
  • מדיניות התחזוקה של המארח של node-group1 ו-node-group2 היא העברה בתוך קבוצת צמתים.

חלונות זמן לתחזוקה

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

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

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

הדמיה של אירוע תחזוקה של מארח

אתם יכולים לדמות אירוע תחזוקה של מארח כדי לבדוק איך עומסי העבודה שפועלים בשרתים לדייר יחיד (sole-tenant) מתנהגים במהלך אירוע תחזוקה של מארח. כך אפשר לראות את ההשפעות של מדיניות התחזוקה של המארח של המכונה הווירטואלית ב-Sole-Tenant Node על האפליקציות שפועלות במכונות הווירטואליות.

שגיאות שקשורות למארח

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

  1. הוצאה משימוש של השרת הפיזי והמזהה הייחודי שלו.

  2. מבטלת את הגישה של הפרויקט לשרת הפיזי.

  3. החלפת החומרה הפגומה בשרת פיזי חדש עם מזהה ייחודי חדש.

  4. העברת המכונות הווירטואליות מהחומרה הפגומה לצומת החלופי.

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

זיקה (affinity) ואנטי-זיקה של צומת

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

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

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

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

תוויות ברירת מחדל של תחומי עניין

מערכת Compute Engine מקצה לכל צומת את תוויות השיוך הבאות כברירת מחדל:

  • תווית לשם של קבוצת הצמתים:
    • מפתח: compute.googleapis.com/node-group-name
    • ערך: שם קבוצת הצמתים.
  • תווית לשם הצומת:
    • מפתח: compute.googleapis.com/node-name
    • ערך: השם של הצומת הספציפי.
  • תווית לפרויקטים שקבוצת הצמתים משותפת איתם:
    • מפתח: compute.googleapis.com/project
    • ערך: מזהה הפרויקט שמכיל את קבוצת הצמתים.

תוויות של קהלים בהתאמה אישית עם תחום עניין משותף

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

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

זמינות

  • שרתים לדייר יחיד (sole-tenant) זמינים באזורים נבחרים. כדי לוודא זמינות גבוהה, תזמנו מכונות וירטואליות בשרתים לדייר יחיד באזורים שונים.

  • לפני שמשתמשים במעבדי GPU או בדיסקים מסוג SSD מקומי בשרתים לדייר יחיד (sole-tenant), צריך לוודא שיש מספיק מכסה למעבדי GPU או ל-SSD מקומי בתחום (zone) שבו אתם שומרים את המשאב.

  • ב-Compute Engine יש תמיכה במעבדים גרפיים בסוגי הצמתים לדייר יחיד n1,‏ g2,‏ g4,‏ a2-highgpu,‏ a2-megagpu,‏ a2-ultragpu,‏ a3-highgpu ו-a3-megagpu שנמצאים באזורים עם תמיכה במעבדים גרפיים. בטבלה הבאה מוצגים סוגי ה-GPU שאפשר לצרף לצמתים מסוג n1,‏ g2,‏ g4,‏ a2 ו-a3, וכמה יחידות GPU צריך לצרף כשיוצרים את תבנית הצומת.

    סוג ה-GPU כמות ה-GPU סוג הצומת של שרת לדייר יחיד (sole-tenant)
    NVIDIA A100 40GB 8 a2-highgpu
    NVIDIA A100 40GB 16 a2-megagpu
    NVIDIA A100 80GB 8 a2-ultragpu
    NVIDIA H100 8 a3-highgpu
    NVIDIA H100 8 a3-megagpu
    NVIDIA L4 8 g2
    NVIDIA RTX PRO 6000 8 g4
    NVIDIA P4 4 n1
    NVIDIA T4 4 n1
    NVIDIA V100 8 n1

  • ב-Compute Engine יש תמיכה בדיסקים מסוג SSD מקומי בסוגי הצמתים לדייר יחיד n1,‏ n2,‏ n2d,‏ g2,‏ g4,‏ a2-ultragpu,‏ a3-highgpu ו-a3-megagpu, שמשמשים באזורים שתומכים בסדרות המכונות האלה.

הגבלות

  • אי אפשר להשתמש במכונות וירטואליות עם דייר יחיד בסדרות ובסוגי המכונות הבאים: T2D, T2A, E2, C2D, A3 Ultra, A3 Edge, A4, A4X, או מכונות Bare Metal.

  • במכונות וירטואליות של דייר יחיד אי אפשר לציין פלטפורמת CPU מינימלית.

  • אי אפשר להעביר מכונה וירטואלית לשרת לדייר יחיד אם במכונה הווירטואלית הזו צוינה פלטפורמת מעבד מינימלית. כדי להעביר מכונה וירטואלית לשרת לדייר יחיד (sole-tenant), מסירים את המפרט של פלטפורמת ה-CPU המינימלית על ידי הגדרה שלו כאוטומטי לפני שמעדכנים את תוויות השיוך לצומת של המכונה הווירטואלית.

  • בשרתים לדייר יחיד אין תמיכה במכונות וירטואליות (VM) זמניות.

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

  • במאמר המגבלות של מיגרציה פעילה מוסבר איך השימוש במעבדים גרפיים משפיע על מיגרציה פעילה.

  • ב-Confidential VMs שלא תומכות במיגרציה פעילה, ההתנהגות וההגבלות שונות בשלושת הסוגים של מדיניות התחזוקה של שרתי דייר יחיד (sole-tenant). למידע נוסף, קראו את המאמרים מדיניות תחזוקה של מארח ופתרון בעיות במיגרציה פעילה של Confidential VM.

  • בשרתים לדייר יחיד (sole-tenant) עם GPUs אין תמיכה במכונות וירטואליות בלי GPUs.

  • רק צומתי N1,‏ N2,‏ N2D ו-N4 לדייר יחיד תומכים בהקצאת יתר של מעבדים.

  • מכונות וירטואליות מסוג C3,‏ C3D,‏ C4,‏ C4A,‏ C4D,‏ G4,‏ N4 ו-M4 מתוזמנות בהתאמה לארכיטקטורת NUMA הבסיסית של שרת לדייר יחיד. תזמון של תבניות VM מלאות ותבניות VM של sub-NUMA באותו צומת עלול להוביל לפרגמנטציה, שבה לא ניתן להריץ תבנית גדולה יותר, אבל אפשר להריץ כמה תבניות קטנות יותר עם אותן דרישות משאבים.

  • בצמתים לדייר יחיד מסוג C3 ו-C4, למכונות הווירטואליות צריך להיות אותו יחס בין vCPU לזיכרון כמו לסוג הצומת. לדוגמה, אי אפשר להציב מכונה וירטואלית מסוג c3-standard בצומת מסוג -highmem.

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

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