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

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

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

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

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

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

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

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

ל-Media CDN יש גם מגבלות מערכת. שאי אפשר לשנות.

מכסות

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

הגדרות אישיות

פריט מכסת ברירת מחדל
המספר המקסימלי של EdgeCacheService משאבים בכל פרויקט 20
המספר המקסימלי של EdgeCacheOrigin משאבים בכל פרויקט 30
המספר המקסימלי של EdgeCacheKeyset משאבים בכל פרויקט 10

מגבלות מערכת

המגבלות הבאות חלות על Media CDN.

הגדרות אישיות

פריט מגבלות הערות
המספר המקסימלי של משאבי RouteRules לכל EdgeCacheService 200

בכל EdgeCacheService אפשר להגדיר עד 200 משאבי RouteRules.

המספר המקסימלי של משאבי PathMatchers לכל EdgeCacheService 50

כל EdgeCacheService יכול להגדיר עד 50 משאבי PathMatchers.

מספר אישורי ה-SSL המקסימלי לכל שירות 5 כדאי לעיין במכסה לכל פרויקט בנושא אישורי SSL.
מספר מקסימלי של מפתחות ציבוריים לכל EdgeCacheKeyset 3 כמה מפתחות בערכת מפתחות מאפשרים רוטציה של מפתחות. להסיר מפתחות שלא נמצאים בשימוש לאורך זמן.
מספר מקסימלי של מפתחות משותפים לאימות לכל EdgeCacheKeyset 3 העיצוב של כמה מפתחות בערכת מפתחות נועד לאפשר רוטציה של מפתחות: מומלץ להסיר מפתחות ישנים ולא בשימוש לאורך זמן.

כותרות, בקשות וקודי סטטוס של HTTP

פריט מגבלות הערות
הגודל המקסימלי של כותרת הבקשה, כולל נתיב הבקשה ‎16 KiB אי אפשר להגדיל את המכסה הזו.

בהתאם לפרוטוקול הבסיסי, חיבור הבקשה נסגר בלי שקוד תגובה נכתב, או שהבקשה נדחית עם תגובת HTTP 431 Request Header Fields Too Long.

אם הרישום ביומן מופעל, הבקשות האלה נרשמות ביומן עם statusDetails של headers_too_long.

גודל מקסימלי של גוף הבקשה ‎16 KiB אי אפשר להגדיל את המכסה הזו.

בקשות עם גוף שגדול מהמגבלה הזו נדחות עם קוד הסטטוס 413 Content Too Large של HTTP.

גודל מקסימלי של כותרת תגובה בערך ‎128 KiB

תגובות מהמקור עם כותרות שחורגות מהמגבלה הזו גורמות לשליחת קוד הסטטוס 502 Bad Gateway‏ HTTP ללקוח. הפעולות האלה מתועדות ביומן עם הערך statusDetails של statusDetails, אם הרישום ביומן מופעל.backend_response_headers_too_long

גודל מקסימלי של אובייקטים שאפשר לשמור במטמון ‫‎100 GiB

זהו הגודל המקסימלי של אובייקטים במקור ש-Media CDN יכולה לשמור במטמון. אובייקטים גדולים יותר נחשבים כאובייקטים שלא ניתן לשמור במטמון.

אפשר להגדיל את המגבלה הזו עד ל-1TiB. אם אתם צריכים מגבלה גבוהה יותר, אתם יכולים לפנות לנציג התמיכה שלכם ב-Google.

גודל מקסימלי של תשובה שלא ניתן לשמור במטמון ‫10239 MiB

זהו המספר המקסימלי של בייטים בתגובה (כולל כותרות) ש-Media CDN מעביר דרך שרתי proxy כשאי אפשר לשמור אובייקט במטמון. תשובות שלא ניתן לשמור במטמון נחתכות אחרי שהן מגיעות למגבלה.

המרת אותיות רישיות באותיות קטנות בכותרות תמיד, עבור Media CDN ‫Media CDN פועל לפי המוסכמות של HTTP/2 לגבי רישיות של אותיות בכותרות של בקשות ותגובות.

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

לדוגמה, Host הופך ל-host, ו-Keep-Alive הופך ל-keep-alive.

האותיות הקטנות והגדולות בערכי הכותרות לא משתנות.

מגבלות על קצב בקשות ה-API

אם אתם צריכים קצב גבוה יותר של יצירת בקשות ל-API, אתם יכולים לבדוק את השימוש הנוכחי ולבקש הגדלה.

פריט מגבלות
ביטולי תוקף לכל EdgeCacheService ‫10 לדקה
כל השיחות שלא נמצאות במרחב השמות networkservices לכל פרויקט ‫1,200 קריאות לדקה
קריאה בלבד: GetEdgeCache*, ListEdgeCache* לכל פרויקט ‫100 לדקה
קריאה/כתיבה: כל מה שנמצא במרחב השמות networkservices שלא סומן כקריאה בלבד לכל פרויקט ‫100 לדקה

מומלץ לשלוח בקשות לעדכון, כמו create,‏ patch ו-delete, אחת בכל פעם. ה-API מכניס לתור כמה בקשות בו-זמניות, אבל שליחת הבקשות האלה בו-זמנית עלולה להוביל לזמן אחזור ארוך יותר ולזמני עיבוד ארוכים יותר, כי המערכת מעבדת כל פריט בנפרד.

הזמן הקצוב לתפוגה של הלקוח

זמן קצוב לתפוגה משך זמן מקסימלי קוד סטטוס תיאור
Maximum request duration ‫5 דקות HTTP 408 Request Timeout המשך המקסימלי של בקשת תגובה יחידה.
Header timeout ‫10 שניות HTTP 408 Request Timeout כמה זמן יש ללקוח לשלוח את כל כותרות הבקשות.

הזמן הקצוב לתפוגה של מקור

  • connectTimeout ו-maxAttemptsTimeout מגבילים את משך הזמן שנדרש ל-Media CDN כדי למצוא תגובה שניתן להשתמש בה.

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

    כש-Media CDN נתקל בתגובה שאינה הפניה אוטומטית, למשל ממקור הפניה אוטומטית או ממקור ליתירות כשל, הערכים readTimeout ו-responseTimeout חלים. מקורות שהופנו מחדש משתמשים בערכים connectTimeout, readTimeout, ו-responseTimeout שהוגדרו עבור EdgeCacheOrigin שנתקל בהפניה מחדש.

  • הפרמטרים responseTimeout ו-readTimeout קובעים כמה זמן יכולה להימשך תגובה שמוזרמת. אחרי שמערכת Media CDN קובעת שהיא תשתמש בתשובה של שרת במעלה הזרם, לא משנה אם התשובה היא connectTimeout או maxAttemptsTimeout. בשלב הזה, התנאים readTimeout ו-responseTimeout נכנסים לתוקף.

‫Media CDN מבצע לכל היותר ארבעה ניסיונות מקור בכל המקורות, ללא קשר לערך maxAttempts שמוגדר בכל EdgeCacheOrigin. ‫Media CDN משתמש בערך maxAttemptsTimeout מה-EdgeCacheOrigin הראשי. ערכי הזמן הקצוב לתפוגה לכל ניסיון (connectTimeout,‏ readTimeout ו-responseTimeout) מוגדרים ל-EdgeCacheOrigin של כל ניסיון.

בטבלה הבאה מתוארים שדות הזמן הקצוב לתפוגה:

שדה ברירת מחדל תיאור
connectTimeout ‫5 שניות

משך הזמן המקסימלי שיכול לעבור מרגע ש-Media CDN מתחיל את הבקשה לשרת המקור ועד שהוא קובע אם אפשר להשתמש בתגובה. מבחינה מעשית, connectTimeout מכסה את הזמן שמתחיל ביצירת הבקשה, ואז בחיפושי DNS, ואז בלחיצות יד של TLS, בהקמת חיבור TCP/QUIC, ועד לקבלת כותרות התגובה שמכילות את קוד סטטוס של HTTP.

הערך של הזמן הקצוב לתפוגה צריך להיות בין שנייה אחת ל-15 שניות.

maxAttemptsTimeout ‫15 שניות

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

הערך של הזמן הקצוב לתפוגה צריך להיות בין שנייה אחת ל-30 שניות.

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

readTimeout ‫15 שניות

משך ההמתנה המקסימלי בין קריאות של תגובת HTTP יחידה. הערך של readTimeout מוגבל על ידי responseTimeout. כל פעולות הקריאה של תגובת ה-HTTP צריכות להסתיים עד למועד האחרון שנקבע על ידי responseTimeout. הערך של הזמן הקצוב לתפוגה צריך להיות בין שנייה אחת ל-30 שניות. אם מגיעים לזמן הקצוב לתפוגה לפני שהתשובה הושלמה, התשובה נחתכת ונרשמת ביומן.

responseTimeout ‫30 שניות

משך הזמן המקסימלי שמוקצב להשלמת התשובה.

הערך של הזמן הקצוב לתפוגה צריך להיות בין שנייה אחת ל-120 שניות.

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

ניהול מכסות

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

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

הרשאות

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

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

בדיקת המכסה

המסוף

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

    לפתיחת הדף Quotas

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

gcloud

מריצים את הפקודה הבאה באמצעות Google Cloud CLI כדי לבדוק את המכסות. מחליפים את PROJECT_ID במזהה הפרויקט שלכם.

    gcloud compute project-info describe --project PROJECT_ID

כדי לבדוק את המכסה שנוצלה באזור מסוים, מריצים את הפקודה הבאה:

    gcloud compute regions describe example-region
    

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

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

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

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

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

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

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

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

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