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

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

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

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

מערכת המכסות ב-Cloud:

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

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

בדרך כלל, המכסות ב- Cloud de Confiance הן ברמת הפרויקט. כלומר, השימוש במשאב מסוים בפרויקט כלשהו לא משפיע על המכסה שלכם בפרויקטים אחרים. ברמת הפרויקט ב- Cloud de Confiance , המכסות משותפות לכל האפליקציות וכתובות ה-IP.

לסקירה כללית על מכסות ב-Cloud

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

מכסות

כדי לשנות מכסה, קראו את המאמר בקשת מכסה נוספת.

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

מגבלות

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

שימוש ב-API

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

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

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

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

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

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

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

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

המגבלות האלה חלות על כל הפרויקטים והמשתמשים ב- Cloud de Confiance. תת-דומיינים לא מוקצים והקצאות שמתארחות בשירותי 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. משחזרים את האזורים המנוהלים שנמחקו של תת-הדומיינים, ומשחזרים את תת-הדומיינים לפני שמשחזרים את תת-הדומיינים שלהם. הם נמצאים במקטעים חדשים, ולכן צריך לעדכן את כל ההקצאות שלהם.

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

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

gcloud dns project-info describe my-project

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

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

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

ניהול מכסות

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

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

הרשאות

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

בדיקת המכסה

    gcloud dns project-info describe PROJECT_ID
    

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

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

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

בקשה להגדלת המכסה

כדי לשנות את רוב המכסות, משתמשים במסוף Cloud de Confiance . מידע נוסף זמין במאמר בנושא שליחת בקשה לשינוי המכסות.

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

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

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

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