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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סוגי צמתים

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

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

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

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

בטבלה הבאה מוצגים סוגי הצמתים הזמינים. כדי לראות רשימה של סוגי הצמתים שזמינים לפרויקט, מריצים את הפקודה 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
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 הוא צומת לשימוש כללי, שאפשר לתזמן בו מכונות מסוג custom. המלצות לגבי סוג הצומת שכדאי לבחור זמינות במאמר המלצות לגבי סוגי מכונות. מידע על הביצועים זמין במאמר בנושא פלטפורמות CPU.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי לוודא שיש קיבולת למיגרציה פעילה, מערכת Compute Engine שומרת 1 holdback node לכל 20 nodes שאתם שומרים. באיור הבא מוצגת אנימציה של מדיניות תחזוקת המארח 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

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

אפשר להצמיד מכונה לכמה קבוצות של צמתים באמצעות 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 שבועות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זמינות

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

  • לפני שמשתמשים ביחידות 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 מינימלית.

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

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

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

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

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

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

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

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

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

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