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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סוגי צמתים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זיקה (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
    • הערך: מזהה הפרויקט שמכיל את קבוצת הצמתים.

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

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

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

תמחור

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

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

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

מידע נוסף מופיע במאמר בנושא תמחור של שרתים לדייר יחיד (sole-tenant).

זמינות

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

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

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

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

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

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

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

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

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

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

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