יצירה בכמות גדולה של מכונות וירטואליות (VM) מאפשרת ליצור מספר גדול של מכונות וירטואליות זהות שלא תלויות זו בזו. כשיוצרים מכונות וירטואליות בכמות גדולה, אפשר:
צמצום צריכת המכסות של קצב יצירת הבקשות ב-API. בקשות ליצירת מכונות וירטואליות בכמות גדולה צורכות מגבלות קצב של API כאילו יצרתם מכונה וירטואלית אחת.
פיזור של יצירת מכונות וירטואליות על פני כמה אזורים באזור מסוים. בבקשות אזוריות, מערכת Compute Engine קובעת את התחום שבו ייצרו את המכונות הווירטואליות על סמך התחומים שבהם יש חומרה זמינה, תוך התחשבות בקיבולת הזמינה בכל תחום ובשמירת המקום שלכם.
מערכת Compute Engine לא מנהלת מכונות וירטואליות שיוצרים בכמות גדולה. כדי ליצור קבוצה של מכונות וירטואליות מנוהלות, משתמשים בקבוצות של מופעי מכונה מנוהלים.
יצירת מכונות וירטואליות בכמות גדולה לעומת יצירת בקשות API בקבוצות
יצירת מכונות וירטואליות בכמות גדולה שונה מאיגוד בקשות API באמצעות השיטה instances.insert. בטבלה הבאה מוצגת השוואה בין שתי הדרכים האלה ליצירת כמה מכונות וירטואליות:
| פונקציונליות | קיבוץ בקשות API | יצירת מכונות וירטואליות בכמות גדולה |
|---|---|---|
|
בחירת אזור נבחר באופן אוטומטי על סמך שיקולים כמו זמינות משאבים ומכסת שימוש |
גלילה ידנית | אוטומטי כשמשתמשים בנקודת הקצה האזורית |
|
אימות מראש הבקשה נכשלת באופן מיידי אם היא לא אפשרית |
לא | עם קיבולת ומכסה |
|
יצירת שמות של מכונות וירטואליות נוצר באופן אוטומטי על סמך תבנית שם שצוינה |
גלילה ידנית | אפשרות ליצור באופן אוטומטי |
|
חזרה אוטומטית לגרסה קודמת הבקשה חוזרת אוטומטית לגרסה קודמת אם Compute Engine לא יכול ליצור את מספר מכונות ה-VM שצוין |
לא | הפעלה אופציונלית |
|
מגבלת קצב בקשות ל-API איך בקשות משפיעות על מגבלת קצב הבקשות ל-API |
בקשה אחת לכל מכונה וירטואלית | בקשה אחת לכל פעולה בכמות גדולה |
מגבלות
ברשימה הבאה מפורטות ההגבלות שחלות כשיוצרים מכונות וירטואליות בכמות גדולה:
מפתחות הצפנה באספקת הלקוח (CSEK). אי אפשר ליצור מכונות וירטואליות עם דיסקים שמוגנים באמצעות מפתחות הצפנה באספקת הלקוח (CSEK) (הוצא משימוש). הדיסקים חייבים להשתמש ב Google-owned and managed keys או במפתחות הצפנה בניהול הלקוח.
דיסקים לאתחול מתוך קובצי snapshot. אי אפשר להשתמש ב-snapshot כדי ליצור את דיסקי האתחול של המכונות הווירטואליות. במקום זאת, צריך להשתמש באימג' בהתאמה אישית כשיוצרים מכונות וירטואליות בכמות גדולה.
DNS גלובלי. אם אתם משתמשים ב-DNS גלובלי, יכול להיות שיהיו התנגשויות בשמות כי שם הדומיין שמוגדר במלואו (FQDN) לא מכיל את האזור. כדי להימנע מכך, צריך להשתמש ב-DNS אזורי. אם אי אפשר לעבור ל-DNS אזורי, מומלץ להימנע משימוש באותו דפוס שמות באזורים שונים. מידע נוסף זמין במאמר סוגים של שמות DNS פנימיים.
תמונות של מכונות. אי אפשר ליצור מכונות וירטואליות מתמונות של מכונות.
מספר המכונות הווירטואליות. אפשר ליצור עד 5,000 מכונות וירטואליות בכל קריאה. בנוסף, אפשר ליצור עד 8,000 מופעים בו-זמנית בכל שלב. המגבלה הזו על מספר הפעולות בו-זמנית משותפת ל-
instances.insertול-instances.bulkInsert.שרתים לדייר יחיד (sole-tenant). אי אפשר ליצור מכונות וירטואליות שמשתמשות בתוויות זיקה של שרת לדייר יחיד.
מאפייני מכונה וירטואלית. כל מאפייני המכונות הווירטואליות, למעט השמות ושמות המארחים המותאמים אישית, חייבים להיות זהים. אי אפשר להשתמש במאפיינים של מכונות וירטואליות שאינם יכולים להיות משותפים בין מכונות וירטואליות, כולל, בין היתר, כתובות IP חיצוניות סטטיות וכתובות IP פנימיות סטטיות.
יומני ביקורת
כשמבצעים את קריאת ה-API וכשהיא מסתיימת, Compute Engine רושם ביומן הביקורת של פעילות האדמין מידע על יצירת מכונות וירטואליות בכמות גדולה.
בנוסף, שירות Compute Engine יוצר יומני ביקורת נפרדים לכל מכונה וירטואלית. כדי למצוא את יומן הביקורת של מכונה וירטואלית ספציפית, צריך להתאים את הערך של protoPayload.resourceName לשם המכונה הווירטואלית שנוצר על ידי תבנית השמות שצוינה בבקשה.
תמחור
אין חיובים נוספים על שימוש ביצירת מכונות VM בכמות גדולה. בדומה ליצירת מכונות וירטואליות בודדות, החיוב מתחיל כשיוצרים את המכונות הווירטואליות.
לא מחויבים על מכונות וירטואליות ש-Compute Engine לא הצליח ליצור.