מכסות ומגבלות

במסמך הזה מפורטות המכסות והמגבלות המערכתיות שחלות על Cloud DNS.

• מכסות מציינות את כמות המשאב המשותף שניתן למדוד שתוכלו להשתמש בו. המכסות מוגדרות על ידי Google Cloud שירותים כמו Cloud DNS.
• מגבלות מערכת הן ערכים קבועים שלא ניתן לשנות.

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

מערכת המכסות ב-Cloud מבצעת את הפעולות הבאות:

• מעקב אחרי הצריכה של Google Cloud מוצרים ושירותים
• הגבלת השימוש במשאבים האלה
• מאפשרת לבקש שינויים בערך המכסה ולבצע אוטומציה של התאמות המכסות

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

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

יש גם מגבלות מערכת על משאבי Cloud DNS. אי אפשר לשנות את המגבלות המערכתיות.

מכסות

במאמר בקשה להגדלת מכסה מוסבר איך משנים מכסה.

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

פריט	תיאור
מגבלת קריאה לדקה באזור	המספר המקסימלי של בקשות API שמשתמש IAM יכול לשלוח ל-Cloud DNS API בפרק זמן של דקה אחת. המכסה הזו רלוונטית רק לקריאות ל-API. אין מכסות לעיבוד שאילתות DNS.
מפתחות DNSSEC לכל תחום מנוהל	המספר המקסימלי של מפתחות DNSSEC לכל תחום מנוהל.
תחומים מנוהלים לכל פרויקט	המספר המקסימלי של תחומים מנוהלים שמותר ליצור בפרויקט.
תחומים מנוהלים לכל רשת VPC	המספר המקסימלי של תחומים מנוהלים שאפשר לצרף לרשת VPC.
משאבי מדיניות לכל פרויקט	המספר המקסימלי של כללי מדיניות של שרתי DNS לכל פרויקט.
מדיניות רשתות לכל תגובה	המספר המקסימלי של רשתות VPC לכל מדיניות תגובה.
מדיניות ניתוב עם בדיקת תקינות האינטרנט לכל פרויקט	מספר כללי מדיניות הניתוב של DNS עם בדיקת תקינות האינטרנט המרבי המותר לכל פרויקט.
פריטים לכל מדיניות ניתוב	המספר המקסימלי של פריטים לכל מדיניות ניתוב.
אשכולות GKE לכל תחום מנוהל	המספר המקסימלי של אשכולות Google Kubernetes Engine ‏ (GKE) שאפשר לצרף אליהם תחום ברמת פרטיות.
אשכולות GKE לכל מדיניות	המספר המקסימלי של אשכולות GKE לכל מדיניות.
תחומים מנוהלים לכל אשכול GKE	המספר המקסימלי של תחומים מנוהלים שאפשר לצרף לאשכול GKE.
הוספות של רשומות משאבים לכל שינוי	המספר המקסימלי של ResourceRecordSets שאפשר להוסיף לכל ChangesCreateRequest.
מחיקות של רשומות משאבים לכל שינוי	המספר המקסימלי של ResourceRecordSets שאפשר למחוק לכל ChangesCreateRequest.
קבוצות של רשומות משאבים לכל תחום מנוהל	המספר המקסימלי של ResourceRecordSets לכל תחום בפרויקט.
רשומות משאבים לכל קבוצת רשומות משאבים	המספר המקסימלי של ResourceRecords לכל ResourceRecordSet. לכל הענקת גישה (קבוצות של רשומות משאבים מסוג NS) יכולים להיות עד שמונה שרתי שמות.
מדיניות תגובה לכל פרויקט	המספר המקסימלי של כללי מדיניות התגובה לכל פרויקט.
מגבלת הכתיבה של כללי מדיניות התגובה לדקה באזור	המספר המקסימלי של כללי מדיניות התגובה שאפשר לכתוב בדקה באזור.
כללי מדיניות התגובה לכל פעולת אצווה	המספר המקסימלי של פעולות ניהול של מדיניות התגובה לכל אצווה לדקה.
כללי מדיניות התגובה לפי מדיניות	המספר המקסימלי של כללי מדיניות התגובה שאפשר ליצור לכל מדיניות.
שרתי שמות יעד לפי מדיניות העברה	המספר המקסימלי של שרתי שמות יעד לכל מדיניות העברה.
שרתי שמות יעד לכל תחום מנוהל	המספר המקסימלי של שרתי שמות יעד לכל תחום העברה מנוהל.
הגודל הכולל של נתוני קבוצת רשומות המשאבים (בייטים) לכל שינוי	הגודל המקסימלי המותר ל-rrdata כולו הוא ChangesCreateRequest בייטים.
רשתות VPC לכל תחום מנוהל	המספר המקסימלי של רשתות VPC שאפשר לצרף לאזור ברמת הפרטיות.
רשתות VPC לפי מדיניות	המספר המקסימלי של רשתות VPC שמותר לכל מדיניות שרת של Cloud DNS.
מגבלת הכתיבה לדקה באזור	המספר המקסימלי של פעולות כתיבה ב-DNS לכל אזור לדקה. המכסה הזו משמשת לכל פעולת כתיבה שיוצרת, משנה או מוחקת רשומת DNS.

מגבלות

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

שימוש ב-API

מספר הבקשות (שאילתות) ל-API ביום נקבע ברמת הפרויקט. כל בקשות ה-API נספרות במסגרת המגבלה הזו, כולל בקשות שנשלחות מ-Google Cloud CLI וממסוף Google Cloud .

מגבלות על משאבים

פריט	הגבלה
כדי לבקש עדכון של המגבלות האלה, פנו אל Cloud Customer Care.
מספר תחומי ה-peering בכל רשת	1,000
שרתי שמות לכל הענקת גישה	8
הוספות לכל שינוי	1,000
מחיקה לכל שינוי	1,000
גודל הנתונים של רשומות המשאבים לכל שינוי	100,000 בייטים
מספר השילובים של התוויות	1,000
מספר הכללים לכל מדיניות תגובה	10,000
מספר הפריטים לכל מדיניות ניתוב	100
מספר האזורים המנוהלים שמקושרים לרשת VPC	10,000
הגודל הגדול ביותר של תגובה ל-DNS (UDP)	1,440 בייטים
הגודל הגדול ביותר של תגובה ל-DNS (TCP)	65,533 בייטים
אי אפשר להגדיל את המגבלות האלה.
קצב השאילתות המקסימלי לכל רשת VPC בכל תחום	100,000 שאילתות בתקופה של עשר שניות (10 שניות) באזור Google Cloud , לדוגמה us-central1-a
מספר כללי המדיניות לתגובה לכל רשת VPC	1
מספר התוויות בכל תחום מנוהל	64 תוויות ו-128 בייטים לכל מפתח או ערך
מספר יעדי ההעברה באזור העברה	50
מספר יעדי ההעברה בשרת שמות חלופי	50

מגבלות על שרתי שמות

מערכת Cloud DNS מקצה כל תחום ציבורי מנוהל לאחד מחמשת הפיצולים של שרתי השמות. הפיצולים הם האות לפני המספר בשם של שרת שמות מוסמך, כך ש-ns-cloud-e1 עד ns-cloud-e4 הם הפיצול E.

אי אפשר להקצות תחום מנוהל חדש של דומיין, למשל domain.example.tld, לפלחי נתונים אם כבר קיים באותו פלחי נתונים אחד מהפריטים הבאים:

• תחום מנוהל עם אותו שם DNS, למשל domain.example.tld
• תת-דומיין של שם ה-DNS, למשל sub.domain.example.tld
• דומיין הורה של שם ה-DNS, למשל example.tld

בגלל ההגבלות האלה, המגבלות הבאות חלות על תחומים ציבוריים מנוהלים:

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

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

אפשר להקצות כמה תת-דומיינים של אותו דומיין הורה, למשל domain.example.tld ו-otherdomain.example.tld, לאותו שבר. עם זאת, יכול להיות שמערכת Cloud DNS תבחר כל שבר זמין אחרי שתשקלל את המגבלות. אם יוצרים תת-דומיינים כאלה בכל שבר, לא ניתן ליצור תחום לדומיין ההורה example.tld.

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

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

1. בודקים את שרתי השמות של כל תחום של תת-דומיין כדי לקבוע את הפלח שלו.
2. מחפשים את הפלח (X) עם הכי פחות תחומים מנוהלים (או הכי פחות חשובים).
3. מייצאים אזורים שבשברון X (ומחליפים את הענקת הגישה שלהם) לשירות DNS אחר.
4. אחרי שתוקף זמן החיים (TTL) יפוג להענקות הגישה המקוריות, מוחקים את האזורים המנוהלים של תת-הדומיינים של שריד X.
5. יוצרים את האזור המנוהל לדומיין ההורה. הוא יוקצה לפלחי X.
6. משחזרים את תחומי הניהול שנמחקו עבור תתי-הדומיינים, משחזרים את תתי-הדומיינים לפני כל אחד מתתי-הדומיינים שלהם. הם נמצאים בפלחים חדשים, ולכן צריך לעדכן את כל ההענקות שלהם.

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

בדיקת המגבלות

אפשר להריץ את הפקודה הבאה כדי לבדוק את המגבלות של הפרויקט. בדוגמה הבאה מוצגות המגבלות הכוללות על סוגי האובייקטים השונים בפרויקט my-project. המכסה totalRrdataSizePerChange נמדדת ביחידות ביייט והיא כוללת את סך כל ההוספות והמחיקות של שינוי.

gcloud dns project-info describe my-project

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

id: my-project,
kind: "dns#project",
number: "123456789012",
quota:
    kind: dns#quota,
    managedZones: 10000,
    resourceRecordsPerRrset: 10000,
    rrsetAdditionsPerChange: 3000,
    rrsetDeletionsPerChange: 3000,
    rrsetsPerManagedZone: 10000,
    totalRrdataSizePerChange: 100000,
    labelSets: 1000

השם של פרויקט ברירת המחדל ושל פרויקטים נוספים מופיע בחלק העליון של הדף Home בקטע Google Cloud console.

Manage quotas

Cloud DNS enforces quotas on resource usage for various reasons. For example, quotas protect the community of Google Cloud users by preventing unforeseen spikes in usage. Quotas also help users who are exploring Google Cloud with the free tier to stay within their trial.

All projects start with the same quotas, which you can change by requesting additional quota. Some quotas might increase automatically based on your use of a product.

Permissions

To view quotas or request quota increases, Identity and Access Management (IAM) principals need one of the following roles.

Task	Required role
Check quotas for a project	One of the following: Project Owner (roles/owner) Project Editor (roles/editor) Quota Viewer (roles/servicemanagement.quotaViewer)
Modify quotas, request additional quota	One of the following: Project Owner (roles/owner) Project Editor (roles/editor) Quota Administrator (roles/servicemanagement.quotaAdmin) A custom role with the serviceusage.quotas.update permission

Check your quota

Console

1. In the Google Cloud console, go to the Quotas page.

   Go to Quotas

2. To search for the quota that you want to update, use the Filter table. If you don't know the name of the quota, use the links on this page instead.

gcloud

Using the Google Cloud CLI, run the following command to check your quotas.

Replace PROJECT_ID with your own project ID.

    gcloud dns project-info describe PROJECT_ID
    

Errors when exceeding your quota

If you exceed a quota with a gcloud command, gcloud outputs a quota exceeded error message and returns with the exit code 1.

If you exceed a quota with an API request, Google Cloud returns the following HTTP status code: 413 Request Entity Too Large.

Request additional quota

To adjust most quotas, use the Google Cloud console. For more information, see Request a quota adjustment.

Console

1. In the Google Cloud console, go to the Quotas page.

   Go to Quotas

2. On the Quotas page, select the quotas that you want to change.
3. At the top of the page, click Edit quotas.
4. For Name, enter your name.
5. Optional: For Phone, enter a valid phone number.
6. Submit your request. Quota requests take 24 to 48 hours to process.

Resource availability

Each quota represents a maximum number for a particular type of resource that you can create, if that resource is available. It's important to note that quotas do not guarantee resource availability. Even if you have available quota, you can't create a new resource if it is not available.

For example, you might have sufficient quota to create a new regional, external IP address in the us-central1 region. However, that is not possible if there are no available external IP addresses in that region. Zonal resource availability can also affect your ability to create a new resource.

Situations where resources are unavailable in an entire region are rare. However, resources within a zone can be depleted from time to time, typically without impact to the service level agreement (SLA) for the type of resource. For more information, review the relevant SLA for the resource.