Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

סקירה כללית על מקורות

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

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

למקורות יש את התכונות הבאות:

אפשר להגדיר מקורות לכל מארח ולכל מסלול, וכך למפות משאב EdgeCacheService יחיד למקורות מרובים שמכילים, לדוגמה, קובצי מניפסט, פלחי וידאו ותוכן סטטי אחר.
אפשר להגיע למקורות באמצעות HTTP/2,‏ HTTPS ו-HTTP/1.1 לא מוצפן.
אפשר להגדיר כללים של חומת אש כדי לאפשר רק כתובות IP ספציפיות של Google, כך שרק Media CDN יוכל לגשת למקורות שלכם.
התנהגויות של ניסיונות חוזרים ומעבר לגיבוי מוגדרות לכל מקור, ויכולות לאפשר לשירות לעבור לגיבוי במקרה של שגיאות חמורות (כמו כשל בקישוריות) או לנסות שוב על סמך תגובות HTTP 404 Not Found או HTTP 429 Too Many Requests. הפעולות האלה מתבצעות רק עבור שיטות HTTP בטוחות יותר, כולל GET, HEAD ו-OPTIONS. מידע נוסף על שיטות HTTP בטוחות זמין ב-RFC 9110.
אפשר להגיע למשאבים פרטיים בתוך Google Cloud או בארגון באמצעות הגדרה של מאזן עומסים של אפליקציות (ALB) חיצוני כמקור מאחורי Media CDN.
ההתנהגות של מעקב ההפניות מוגדרת לכל מקור. אתם יכולים להפעיל את Media CDN כדי לעקוב אחרי הפניות אוטומטיות לשרתי מקור אחרים.

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

כדי לאפשר ל-Media CDN לשמור במטמון תגובות ממקורות שגדולות מ-1 MiB, מקור צריך לכלול את הפרטים הבאים בכותרות התגובה לבקשות GET, אלא אם צוין אחרת:

כותרת תגובת HTTP‏ Last-Modified או ETag (מאמת).
כותרת HTTP Date תקינה.
כותרת Content-Length תקינה.
כותרת התגובה Content-Range בתגובה לבקשה Range GET. הכותרת Content-Range צריכה לכלול ערך תקין בפורמט bytes x-y/z (כאשר z הוא גודל האובייקט).

פרוטוקול המקור שמוגדר כברירת מחדל הוא HTTP/2. אם המקורות שלכם תומכים רק ב-HTTP/1.1, אתם יכולים להגדיר את שדה הפרוטוקול באופן מפורש לכל מקור.

הגנה על מקורות

‫Media CDN מספק תשתית קצה רב-שכבתית שנועדה לצמצם באופן פעיל את מילוי מטמון בכל מקום שאפשר.

יש שלושה רבדים עיקריים של תשתית אחסון במטמון:

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

סקירה כללית של הטופולוגיה הזו מוצגת כאן:

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

הגנה גמישה

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

הגדלת זמן האחזור (latency) של החמצות במטמון כשמיקום ברירת המחדל של ה-shield רחוק גיאוגרפית מהמקור המרכזי
הפחתת העומס על השרת המקורי על ידי פיזור בקשות למילוי המטמון בכמה מיקומי ברירת מחדל גלובליים של שרת proxy במקום לרכז אותן

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

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

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

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

בקשה לכיווץ

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

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

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

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

בשילוב עם הגנה על המקור, איחוד הבקשות מצמצם עוד יותר את עומס המקור ואת רוחב הפס הנדרש לתעבורת נתונים יוצאת (egress), והוא פעולת ברירת המחדל ב-Media CDN.

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

אי אפשר לכווץ בקשות שלא משתפות את אותו מפתח מטמון.

קישוריות למקור

בקטעים הבאים מוסבר איך Media CDN מתחבר למקורות, איך מתבצעות בקשות HTTP ואיך אפשר לאמת בקשות.

מקורות ופרוטוקולים נתמכים

‫Media CDN תומך ישירות בכל נקודת קצה (endpoint) של HTTP שנגישה לכולם כמקור, כולל:

קטגוריות של Cloud Storage, כולל קטגוריות פרטיות דרך חשבונות שירות של Identity and Access Management
מאזני עומסים חיצוניים של אפליקציות (ALB)
קטגוריות שתואמות ל-Amazon S3, כולל קטגוריות פרטיות שמשתמשות ב-AWS Signature Version 4
אחסון אובייקטים אחר שזמין לציבור, כמו Azure Blob Storage
שרתי אינטרנט שזמינים לציבור, כמו מכונות וירטואליות ציבוריות או מארחים מקומיים

הקישוריות למקורות מתבצעת דרך מנהרות מאובטחות ורשת הליבה הגלובלית של Google.

בטבלה הבאה מפורטים פרוטוקולי המקור הנתמכים.

פרוטוקול	נתמך	נדרש SSL ‏ (TLS)
HTTP/2	כן (ברירת מחדל)	כן
HTTPS ‏ (HTTP/1.1 over TLS)	כן	כן
HTTP/1.1	כן	לא

כברירת מחדל, Media CDN משתמש ב-HTTP/2 ‏ (h2) כדי להתחבר למקור. גם HTTP/2 וגם HTTPS דורשים אישור TLS (או SSL) תקף שמהימן באופן ציבורי. אישור תקף הוא אישור שלא פג תוקפו, שנחתם על ידי רשות אישורים ציבורית, ושכולל שם חלופי של בעלים (subject) שתואם לשם המארח שנשלח למקור.

הערות:

אם המקור לא תומך ב-HTTP/2, אפשר להגדיר במפורש את הפרוטוקול (לכל מקור בנפרד) ל-HTTP (HTTP/1.1) או ל-HTTPS (HTTP/1.1 over TLS).
כשמגדירים HTTPS או HTTP/1.1 כפרוטוקול המקור, Media CDN לא מנהל משא ומתן על פרוטוקול חלופי (כמו HTTP/2). באופן דומה, כשמגדירים HTTP/2, החיבור לא חוזר ל-HTTP/1.1, כדי להבהיר את התנהגות הקישוריות למקור.
‫Media CDN משתמש באופן אוטומטי ביציאה הנכונה על סמך הפרוטוקול: יציאה 80 ל-HTTP או יציאה 443 ל-HTTPS ול-HTTP/2.

כותרות בקשות של מקור

כשמתחברים למקור, Media CDN משתמש בכותרת Host מבקשת הלקוח כברירת מחדל.

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

בקשת הלקוח	`EdgeCacheService.hostRewrite`	`EdgeCacheOrigin.hostRewrite`	originAddress	כותרת מארח / TLS SNI במקור
media.example.com	ללא	ללא	backend.example.com	media.example.com
media.example.com	service.example.com	ללא	backend.example.com	service.example.com
media.example.com	ללא	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	gs://vod-content-bucket	מוגדר באופן אוטומטי על סמך שם הקטגוריה

המקור הראשי וכל המקורות לגיבוי רואים את אותו כותר מארח אם הם חולקים את אותה הגדרה של routeRule או hostRewrite.

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

ערך ה-TLS SNI (Server Name Indication) בבקשה (עבור בקשות HTTP/3,‏ HTTP/2 ו-HTTPS) מוגדר לאותו ערך כמו כותרת המארח שנשלחת למקור.

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

מתן הרשאה למקור לקבל תנועה מ-Media CDN

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

בטבלה הבאה מפורטים טווחי כתובות ה-IP הנדרשים של המקור לכללים של חומת האש:

סוג כתובת ה-IP	טווח כתובות ה-IP של מקור הבקשה
IPv4	136.124.4.0/22
IPv6	2001:4860:4864:a::/64

אפשר להשתמש בכתובת ה-URL הבאה כדי לגשת לקובץ ה-JSON שמכיל את טווחי כתובות ה-IP המעודכנים שהוקצו על ידי Google.

https://www.gstatic.com/ipranges/mediacdn.json

מעבר לגיבוי כשל וזמני קצוב לתפוגה

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

פסק זמן (timeout): קובעים כמה זמן Media CDN ימתין לחיבור למקור או לתגובה לבקשה.
ניסיונות חוזרים: קובעים אם Media CDN ינסה שוב לשלוח בקשת HTTP למקור, ובאילו תנאים.
יתירות כשל: קובעים אם Media CDN ינסה להתחבר למקור ליתירות כשל אם המקור הראשון לא זמין או אם הוא מחזיר קוד סטטוס ספציפי.

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

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

בהמשך מפורטים פסק הזמן שניתן להגדרה ש-Media CDN תומך בהם:

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

מומלץ להביא בחשבון את הדוגמאות הבאות:

התנאי Origin A תואם לבקשות אל '/segments/‎' והערך maxAttemptsTimeout שלו הוא 5s, הערך maxAttempts שלו הוא 1 והערך failover_origin שלו הוא Origin B. הערך של connectTimeout הוא ערך ברירת המחדל 5s. אם תנסו להתחבר אל Origin A והחיבור ייכשל תוך שנייה אחת בגלל אישור TLS לא תקין, יישארו לכם בערך 4 שניות להתחבר בהצלחה אל Origin B.
‫Origin C תואם לבקשות אל ‎/manifests/*‎, הערך של maxAttemptsTimeout הוא 10s, הערך של maxAttempts הוא 3, והערך של failover_origin לא מוגדר. הערך של connectTimeout הוא ערך ברירת המחדל 5s. ‫Media CDN מנסה להתחבר אל Origin C עד שלוש פעמים, ומאפשר עד 10 שניות (המגבלה של maxAttemptsTimeout) ליצירת חיבור מוצלח.

ניסיון חוזר של בקשות מהמקור

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

‫Media CDN מנסה לשלוח מחדש רק את הבקשות שמשתמשות בשיטות HTTP בטוחות, GET,‏ HEAD או OPTIONS.

הערה: אם בקשה שנעשית באמצעות שיטה לא בטוחה נכשלת בניסיון הראשון למקור הראשי, Media CDN מגיב ללקוח עם קוד סטטוס HTTP 502 Bad Gateway. הוא לא מנסה לבצע שוב את הפעולה ממקור אחר.
‫Media CDN מנסה להגיע למקור הראשי עד לערך maxAttempts שהוגדר, שערך ברירת המחדל שלו הוא 1.
‫Media CDN מנסה להתחבר למקור עד שלוש פעמים לפני שהוא נכשל ומחזיר שגיאת HTTP 502 Bad Gateway למשתמש. זה כולל את כל החיבורים למקורות ליתירות כשל, שנכללים במגבלה של שלושה חיבורים.
כשמגדירים משאב מקור, אפשר להגדיר מקור ראשי באמצעות השדה originAddress, ואז להגדיר failoverOrigin אופציונלי. הערך failoverOrigin מצביע על משאב אחר של מקור.

הערך retryConditions לכל מקור מציין אילו סוגי כשלים מפעילים ניסיון חוזר:

תנאי	ברירת מחדל	תיאור
CONNECT_FAILURE	✔️	ניסיון חוזר במקרה של כשל כולל שגיאות בניתוב, ב-DNS וב-TLS handshake, ופסק זמן של TCP/UDP.
HTTP_5XX		ניסיון חוזר בכל `5xx` קוד סטטוס HTTP.
GATEWAY_ERROR		בדומה ל-`5xx`, אבל חל רק על קודי סטטוס `502`, `503` או `504`.
RETRIABLE_4XX		ניסיון חוזר עבור קודי סטטוס `4xx` שאפשר לנסות שוב, כולל `409` ו-`429`.
NOT_FOUND		ניסיון חוזר על קוד סטטוס `404` HTTP.
FORBIDDEN		ניסיון חוזר על קוד סטטוס `403` HTTP.

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

התנהגות במעבר לגיבוי (Failover)

ניסיונות המעבר לגיבוי מתבצעים רק עבור בקשות שמשתמשות בשיטות HTTP בטוחות יותר, GET,‏ HEAD או OPTIONS.

בטבלה הבאה מוסבר איך יתירות כשל פועלת, ואיזו תגובה הלקוח יקבל:

תרחיש	הגדרה של מעבר אוטומטי לגיבוי	סטטוס שגלוי למשתמשים
‫Media CDN מנסה להתחבר למקור שלכם, ולא מקבל תגובת HTTP אחרי שני ניסיונות (ברירת מחדל).	לא	HTTP `502 Bad Gateway`
‫Media CDN מנסה להתחבר למקור הראשי שלכם, ולא מצליח להתחבר (שגיאת TLS handshake). המערכת מנסה לגשת למקור ליתירות כשל שהגדרתם, ומקבלת שגיאת HTTP `404`.	כן	HTTP `404 Not Found`
‫Media CDN מנסה להתחבר גם למקור הראשי וגם למקור ליתירות כשל, אבל לא מקבל קוד סטטוס של HTTP.	כן	HTTP `502 Bad Gateway`

אם Media CDN מקבל קוד סטטוס שתואם לאחד מקודי הסטטוס המוגדרים retryConditions, כמו שגיאה מסוג HTTP 404 Not Found או HTTP 429 Too Many Requests, והניסיונות החוזרים הבאים והבקשות למקור ליתירות כשל ממשיכים להיכשל, מוחזרת ללקוח שגיאה מסוג HTTP 502 Bad Gateway אחרי שמוצו כל הניסיונות ליצור קשר עם המקור.

שיטות מומלצות למעבר אוטומטי לגיבוי (failover) של מקור

כשמגדירים כמה מקורות ליתירות כשל או לאיזון עומסים, צריך לוודא שהתנהגות התוכן של המדיה והכותרות Vary, ETag ו-Last-Modified עקבית בין המקורות.

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