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

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

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

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

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

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

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

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

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

מכסות

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

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

מגבלות

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

שימוש ב-API

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

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

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

מערכת 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.
• לכל דומיין הורה אפשר ליצור עד חמש רמות של תת-דומיינים.

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

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

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

gcloud dns project-info describe my-project

למרות שמדובר במגבלות, Trusted 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 בקטע Trusted Cloud console.

ניהול מכסות

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

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

הרשאות

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

בדיקת המכסה

    gcloud dns project-info describe PROJECT_ID
    

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

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

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

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

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

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

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

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

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