במסמך הזה מפורטות המכסות והמגבלות המערכתיות שחלות על 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
.
כדי להימנע מהמגבלות האלה, תמיד צריך ליצור תחומים מנוהלים לדומיינים ההורים לפני שיוצרים תחומים לדומיינים המשניים שלהם.
אם תתי-הדומיינים כבר חוסמים את כל הפיצולים, צריך לפעול לפי השלבים הבאים כדי לפנות פיצול לדומיין ההורה:
- בודקים את שרתי השמות של כל תחום של תת-דומיין כדי לקבוע את הפלח שלו.
- מחפשים את הפלח (X) עם הכי פחות תחומים מנוהלים (או הכי פחות חשובים).
- מייצאים אזורים שבשברון X (ומחליפים את הענקת הגישה שלהם) לשירות DNS אחר.
- אחרי שתוקף זמן החיים (TTL) יפוג להענקות הגישה המקוריות, מוחקים את האזורים המנוהלים של תת-הדומיינים של שריד X.
- יוצרים את האזור המנוהל לדומיין ההורה. הוא יוקצה לפלחי X.
- משחזרים את תחומי הניהול שנמחקו עבור תתי-הדומיינים, משחזרים את תתי-הדומיינים לפני כל אחד מתתי-הדומיינים שלהם. הם נמצאים בפלחים חדשים, ולכן צריך לעדכן את כל ההענקות שלהם.
בדיקת המגבלות
אפשר להריץ את הפקודה הבאה כדי לבדוק את המגבלות של הפרויקט. בדוגמה הבאה מוצגות המגבלות הכוללות על סוגי האובייקטים השונים בפרויקט 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:
|
Modify quotas, request additional quota | One of the following:
|
Check your quota
Console
- In the Google Cloud console, go to the Quotas page.
- 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.
ReplacePROJECT_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
- In the Google Cloud console, go to the Quotas page.
- On the Quotas page, select the quotas that you want to change.
- At the top of the page, click Edit quotas.
- For Name, enter your name.
- Optional: For Phone, enter a valid phone number.
- 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.