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

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

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

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

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

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

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

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

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

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

  • עומסי עבודה של משחקים עם דרישות ביצועים

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

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

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

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

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

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

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

סוגי צמתים

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

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

כשיוצרים קבוצת צמתים באמצעות תבנית צמתים, כל צומת בקבוצת הצמתים יורש את המפרטים של סוג הצומת בתבנית הצמתים. סוג הצומת חל על כל צומת בודד בקבוצת צמתים, ולא על כל הצמתים בקבוצה באופן אחיד. לכן, אם יוצרים קבוצת צמתים עם שני צמתים ששניהם מסוג הצומת 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 1360 ‫1:14.17 2 24 48 1
a2-ultragpu-node-96-1360-lssd 1 Cascade Lake 96 1360 ‫1:14.17 2 24 48 1
a3-highgpu-node-208-1872-lssd 1 Sapphire Rapids 208 1872 1:9 2 56 112 8
a3-megagpu-node-208-1872-lssd 1 Sapphire Rapids 208 1872 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 48 96 44
c3-node-176-704 Sapphire Rapids 176 704 1:4 2 48 96 44
c3-node-176-704-lssd Sapphire Rapids 176 704 1:4 2 48 96 40
c3-node-176-1408 Sapphire Rapids 176 1408 1:8 2 48 96 44
c3d-node-360-708 AMD EPYC Genoa 360 708 1:2 2 96 192 34
c3d-node-360-1440 AMD EPYC Genoa 360 1440 1:4 2 96 192 40
c3d-node-360-2880 AMD EPYC Genoa 360 2880 1:8 2 96 192 40
c4-node-192-384 Emerald Rapids 192 384 1:2 2 60 120 26
c4-node-192-720 Emerald Rapids 192 720 1:3.75 2 60 120 26
c4-node-192-1488 Emerald Rapids 192 1,488 1:7.75 2 60 120 26
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 22
c4a-node-72-576 Google Axion 72 576 1:8 1 80 80 36
c4d-node-384-720 AMD EPYC Turin 384 720 1:2 2 128 256 24
c4d-node-384-1488 AMD EPYC Turin 384 1488 1:4 2 128 256 25
c4d-node-384-3024 AMD EPYC Turin 384 3024 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
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 48 96 1
h4d-node-192-720 AMD EPYC Turin 192 720 1:2 2 96 192 1
h4d-node-192-1488 AMD EPYC Turin 192 1488 1:4 2 96 192 1
m1-node-96-1433 Skylake 96 1433 1:14.93 2 28 56 1
m1-node-160-3844 Broadwell E7 160 3844 1:24 4 22 88 4
m2-node-416-8832 Cascade Lake 416 8832 ‫1:21.23 8 28 224 1
m2-node-416-11776 Cascade Lake 416 11776 1:28.31 8 28 224 2
m3-node-128-1952 Ice Lake 128 1952 1:15.25 2 36 72 2
m3-node-128-3904 Ice Lake 128 3904 1:30.5 2 36 72 2
m4-node-224-2976 Emerald Rapids 224 2976 1:13.3 2 60 120 12
m4-node-224-5952 Emerald Rapids 224 5952 ‫1:26.7 2 60 120 1
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 Ice Lake 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 1792 1:8 2 64 128 112
n4-node-224-1372 Emerald Rapids 224 1372 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, דיסקים מקומיים של SSD מצורפים גם הם כברירת מחדל אם לא מצוין סיומת. כדי להקצות את סוגי הצמתים האלה בלי דיסקים של SSD מקומי, צריך להשתמש בסיומת -nolssd (לדוגמה, a3-megagpu-node-208-1872-nolssd או a2-ultragpu-node-96-1360-nolssd).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תמחור

  • כדי לעזור לכם לצמצם את העלויות של צמתי הדייר היחיד, ב-Compute Engine יש הנחות תמורת התחייבות לשימוש (CUD) והנחות על שימוש קבוע (SUD). שימו לב: על חיובים על שימוש ב-Sole-tenancy אפשר לקבל רק הנחות גמישות תמורת התחייבות לשימוש (CUD) והנחות על שימוש מתמשך (SUD), אבל לא הנחות תמורת התחייבות לשימוש במשאבים.

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

  • אם אתם מקצים צמתים של דייר יחיד עם יחידות GPU או דיסקים מקומיים של SSD, אתם מחויבים על כל יחידות ה-GPU או הדיסקים המקומיים של SSD בכל צומת שאתם מקצים. הפרמיה על שימוש ב-Sole-tenancy מבוססת רק על ה-vCPU והזיכרון שבהם אתם משתמשים עבור צומת ה-Sole-tenancy, ולא כוללת יחידות GPU או דיסקים מקומיים של SSD.

מידע נוסף מפורט במאמר בנושא תמחור של צמתים עם דייר יחיד.

זמינות

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

  • לפני שמשתמשים ב-GPU או בדיסקים של SSD מקומי בצמתים של דייר יחיד, צריך לוודא שיש מספיק מכסה של GPU או של SSD מקומי באזור שבו מזמינים את המשאב.

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

    סוג ה-GPU מספר ה-GPU סוג השרת לדייר יחיד
    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 P100 4 n1
    NVIDIA P4 4 n1
    NVIDIA T4 4 n1
    NVIDIA V100 8 n1

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

הגבלות

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

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

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

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

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

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

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

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

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

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

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

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