במאמר הזה מפורטות המכסות והמגבלות של המערכת שחלות על 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. |
| מחיקות של רשומות משאבים לכל שינוי | המספר המקסימלי של ResourceRecordSets שאפשר למחוק בכל ChangesCreateRequest הוא ResourceRecordSets. |
| קבוצות של רשומות משאבים לכל אזור מנוהל | המספר המקסימלי המותר של 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. | |
| מספר אזורי הקישוריות לכל רשת | 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 שאילתות בפרק זמן של עשר שניות (10s) באזור Google Cloud , לדוגמה us-central1-a |
| מספר כללי המדיניות לתגובה לכל רשת VPC | 1 |
| מספר התוויות לכל אזור מנוהל | 64 תוויות ו-128 בייט לכל מפתח או ערך |
| מספר יעדי ההעברה באזור העברה | 50 |
| מספר יעדי ההעברה בשרת שמות חלופי | 50 |
מגבלות על שרתי שמות
Cloud DNS מקצה כל תחום ציבורי מנוהל לאחד מתוך חמישה פיצולים (shards) של שרתי שמות. פיצולים (shards) הם האות שלפני המספר בשם של שרת שמות מוסמך, כך ש-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) עם הכי פחות אזורים מנוהלים (או עם האזורים המנוהלים הכי פחות חשובים).
- מייצאים אזורים ב-shard X (ומשנים את ההקצאות שלהם) לשירות DNS אחר.
- אחרי שתוקף ה-TTL יפוג עבור ההקצאות המקוריות, צריך למחוק את האזורים המנוהלים עבור תת-הדומיינים של שבר X.
- יוצרים את האזור המנוהל לדומיין ההורה, והוא מוקצה לשבר X.
- משחזרים את האזורים המנוהלים שנמחקו עבור תתי-הדומיינים, משחזרים תתי-דומיינים לפני תתי-תתי-הדומיינים שלהם. הם נמצאים ב-shards חדשים, ולכן צריך לעדכן את כל ההרשאות שלהם.
בדיקת המגבלות
כדי לחפש את המגבלות של הפרויקט, מריצים את הפקודה הבאה. בדוגמה הבאה מוצגות המגבלות הכוללות לסוגים השונים של אובייקטים בפרויקט 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
אפשר לראות את השם של פרויקט ברירת המחדל ושל פרויקטים נוספים בחלק העליון של הדף דף הבית ב- Google Cloud console.
ניהול מכסות
Cloud DNS אוכפת מכסות על השימוש במשאבים מסיבות שונות. לדוגמה, המכסות מגינות על קהילת המשתמשים של Google Cloud על ידי מניעת עלייה חדה ובלתי צפויה בשימוש. המכסות עוזרות גם למשתמשים שמנסים את Google Cloud בתוכנית ללא תשלום להישאר במסגרת תקופת הניסיון.
כל הפרויקטים מתחילים עם אותן מכסות, ואפשר לשנות אותן על ידי בקשה למכסה נוספת. יכול להיות שחלק מהמכסות יגדלו באופן אוטומטי על סמך השימוש שלכם במוצר.
הרשאות
כדי להציג מכסות או לבקש הגדלות של מכסות, לחשבונות משתמשים בניהול זהויות והרשאות גישה (IAM) צריך להיות אחד מהתפקידים הבאים.
| משימה | התפקיד הנדרש |
|---|---|
| בדיקת המכסות של פרויקט | אחד מהפרטים הבאים:
|
| שינוי מכסות ובקשת מכסה נוספת | אחד מהפרטים הבאים:
|
בדיקת המכסה
המסוף
- נכנסים לדף Quotas Google Cloud במסוף.
- כדי לחפש את המכסה שרוצים לעדכן, משתמשים בטבלת הסינון. אם אתם לא יודעים מה שם המכסה, תוכלו להשתמש במקום זאת בקישורים שבדף הזה.
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 . מידע נוסף זמין במאמר שליחת בקשה לשינוי מכסה.
המסוף
- נכנסים לדף Quotas Google Cloud במסוף.
- בדף Quotas, בוחרים את המכסות שרוצים לשנות.
- בחלק העליון של הדף, לוחצים על Edit quotas.
- בשדה Name, מזינים את השם שלכם.
- אופציונלי: בשדה טלפון, מזינים מספר טלפון תקין.
- שולחים בקשת תמיכה. עיבוד הבקשות להגדלת מכסות נמשך בין 24 ל-48 שעות.
זמינות המשאבים
כל מכסה מייצגת את המספר המקסימלי של משאבים מסוג מסוים שאפשר ליצור, אם המשאב הזה זמין. חשוב לציין שמכסות לא מבטיחות את זמינות המשאבים. גם אם יש לכם מכסה פנויה, לא תוכלו ליצור משאב חדש אם הוא לא זמין.
לדוגמה, יכול להיות שיש לכם מכסה מספקת כדי ליצור כתובת IP חיצונית אזורית חדשה באזור us-central1. עם זאת, אי אפשר לעשות זאת אם אין באזור כתובות IP חיצוניות זמינות. הזמינות של משאבים בתחום יכולה גם להשפיע על היכולת שלכם ליצור משאב חדש.
מצבים שבהם משאבים לא זמינים באזור שלם הם נדירים. עם זאת, יכול להיות שמדי פעם המשאבים בתחום מסוים ינוצלו במלואם, בדרך כלל ללא השפעה על הסכם רמת השירות (SLA) של סוג המשאב. מידע נוסף זמין בהסכם רמת השירות הרלוונטי של המשאב.