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

במסמך הזה מפורטות המכסות והמגבלות המערכתיות שחלות על 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.

ניהול מכסות

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

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

הרשאות

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

משימה	התפקיד הנדרש
בדיקת המכסות של פרויקט	אחד מהפרטים הבאים: בעלי הפרויקט (roles/owner) עריכת פרויקט (roles/editor) Quota Viewer (roles/servicemanagement.quotaViewer)
שינוי מכסות ובקשת מכסה נוספת	אחד מהפרטים הבאים: בעלי הפרויקט (roles/owner) עריכת פרויקט (roles/editor) אדמין מכסות (roles/servicemanagement.quotaAdmin) תפקיד בהתאמה אישית עם ההרשאה serviceusage.quotas.update

בדיקת המכסה

המסוף

1. נכנסים לדף Quotas Google Cloud במסוף.

   לפתיחת הדף Quotas

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

gcloud

כדי לבדוק את המכסות, מריצים את הפקודה הבאה ב-Google Cloud CLI.

מחליפים את PROJECT_ID במזהה הפרויקט שלכם.

    gcloud dns project-info describe PROJECT_ID
    

שגיאות שקשורות לחריגה מהמכסה

אם תחרגו ממכסה באמצעות הפקודה gcloud, הפלט של gcloud יהיה הודעת השגיאה quota exceeded וקוד היציאה יהיה 1.

אם תחרגו ממכסה עם בקשת API, Google Cloud המערכת תחזיר את קוד הסטטוס הבא של HTTP: 413 Request Entity Too Large.

שליחת בקשה למכסה נוספת

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

המסוף

1. נכנסים לדף Quotas Google Cloud במסוף.

   לפתיחת הדף Quotas

2. בדף Quotas, בוחרים את המכסות שרוצים לשנות.
3. בחלק העליון של הדף, לוחצים על Edit quotas.
4. בשדה Name, מזינים את השם שלכם.
5. אופציונלי: בשדה טלפון, מזינים מספר טלפון תקין.
6. שולחים בקשת תמיכה. עיבוד הבקשות להגדלת מכסות נמשך בין 24 ל-48 שעות.

זמינות המשאבים

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

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

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