Ursprungskonnektivität und -abschirmung

Mit Media CDN können Sie ganz einfach Inhalte aus Ihrer Ursprungsinfrastruktur abrufen, unabhängig davon, ob Inhalte in Google Cloud, in einer anderen Cloud oder lokal gehostet werden.

Jeder Konfiguration können ein oder mehrere Ursprünge zugeordnet sein. Ursprungskonfigurationen teilen Media CDN mit, wie eine Verbindung zu Ihrer Infrastruktur hergestellt wird, wann und wie ein Failover, ein Wiederholungsversuch und eine Zeitüberschreitung ausgeführt wird und welches Protokoll für die Herstellung der Verbindung verwendet wird.

Im Folgenden sind Ursprungsfeatures aufgeführt:

  • Ursprünge können pro Host und pro Route definiert werden, sodass ein einzelner Edge-Cache-Dienst zu mehreren Ursprüngen zuordnen kann, die (beispielsweise) Manifeste, Videosegmente und andere statische Inhalte enthalten.
  • Ursprünge können über HTTP/2, HTTPS und unverschlüsseltes HTTP/1.1 erreicht werden.
  • Verhaltensweisen bei Wiederholungsversuchen und Failover sind pro Ursprung konfiguriert und erlauben es Ihnen möglicherweise, ein Failover für schwerwiegende Fehler (z. B. Verbindungsfehler) oder einen Wiederholungsversuch basierend auf HTTP 404 (Nicht gefunden) oder HTTP 429 (Zu viele Anfragen) durchzuführen.
  • Private Ressourcen, sowohl lokale als auch solche innerhalb von Google Cloud, können durch die Konfiguration eines externen HTTP(S)-Load-Balancers als Ursprung hinter Media CDN erreicht werden.
  • Das Verhalten für das Folgen von Weiterleitungen wird pro Ursprung konfiguriert. Sie können es Media CDN ermöglichen, Weiterleitungen zu anderen Ursprungsservern zu folgen.

Ursprungsanforderungen

Damit Media CDN Ursprungsantworten im Cache speichern kann, muss ein Ursprung in den Antwortheadern für HEAD- und GET-Anfragen Folgendes enthalten, sofern nicht anders angegeben:

  • Einen Last-Modified- oder ETag-HTTP-Antwortheader.
  • Einen gültiger HTTP-Date-Header.
  • Einen gültigen Content-Length-Header.
  • Den Accept-Ranges: bytes-Antwortheader.
  • Den Content-Range-Antwortheader als Antwort auf eine Range-GET-Anfrage. Der Header Content-Range muss einen gültigen Wert im Format bytes x-y/z haben (wobei z die Objektgröße ist).

Das Standardursprungsprotokoll ist HTTP/2. Wenn Ihre Ursprünge nur HTTP/1.1 unterstützen, können Sie das Protokollfeld für jeden Ursprung explizit festlegen.

Best Practices für das Ursprungs-Failover

Achten Sie beim Konfigurieren mehrerer Ursprünge für das Failover oder Load-Balancing darauf, dass das Verhalten Ihrer Medieninhalte und der Vary-, ETag- und Last-Modified-Header zwischen Ihren Ursprüngen konsistent ist.

Als Best Practice konfigurieren Sie die Ursprungsweiterleitung nur für Ursprünge, denen Sie vertrauen und die Sie steuern. Prüfen Sie, ob Sie jedem Ursprung in einer Weiterleitungskette vertrauen, da jeder Ursprung Inhalte erstellt, die von Ihrem EdgeCacheService bereitgestellt werden.

Ursprungsabschirmung

Media CDN bietet eine deutlich abgestufte Edge-Infrastruktur, die so konzipiert ist, dass die Cache-Füllung wenn möglich aktiv minimiert wird.

Es gibt drei primäre Ebenen der Caching-Infrastruktur:

  1. Deep Edge-Caches, die den Großteil des Traffics und der Auslagerung innerhalb eines Dienstanbieternetzwerks bereitstellen.
  2. Das Peering-Edge von Google, das mit Tausenden von Internetanbietern verbunden ist und als Cache der mittleren Ebene für Edge-Caches fungiert. Für Fälle, in denen diese nicht innerhalb eines bestimmten ISP vorhanden sind, fungiert es als nutzerseitiger Cache.
  3. "Longtail"-Caches innerhalb des Google-Netzwerks, die von anderen nachgelagerten Caches vor dem Ursprung gefüllt werden. Diese Caches unterstützen erhebliches Fan-In und verfügen über eine umfangreiche Cache-Speicherkapazität und fungieren als Ursprungs-"Schild".

Hier finden Sie eine Übersicht über diese Topologie:

Topologieübersicht
Topologieübersicht (zum Vergrößern klicken)

Alle Caching-Ebenen unterstützen das Minimieren von Anfragen ("Zusammenführen"), um die Ursprungslast weiter zu reduzieren. Basierend auf beobachteten, realen Arbeitslasten in großem Maßstab:

  • > 95% der Cache-Füllung verwenden eine dedizierte "Longtail"-Cache-Ebene innerhalb der Region, um die Kosten und die Latenz der Cache-Füllung zu reduzieren.
  • Die Cache-Füllung zwischen dem Ursprung und der eigenen Edge-Infrastruktur von Google erfolgt vollständig über das globale private Backbone-Netzwerk von Google. Dies reduziert die Latenz bei der Cache-Füllung und verbessert die Zuverlässigkeit. Beides sind aktive Vorteile für Livestreaming-Arbeitslasten.
  • Caches füllen sich gegenseitig, wenn dies vorteilhaft ist, wodurch die Cache-Füllungsraten weiter reduziert werden.
  • Media CDN verfügt über erhebliche Speicherkapazität über Caches hinweg, die die Entfernungsraten für Longtail-Inhalte minimieren, die weniger beliebt sind, auch bei einem großen Korpus von Longtail-Inhalten.

Bei Kunden treten möglicherweise unterschiedliche Auslagerungsraten auf, abhängig von ihrer Cache-Konfiguration, der Nutzerlast, den Arbeitslasten (z. B. Live vs. On-Demand), der Nutzerverteilung und der Menge an "Longtail"-Inhalten (Gesamtkorpusgröße), die sie Nutzern über Regionen hinweg bereitstellen.

Anfrageminimierung

Die Anfrageminimierung (oder Zusammenführung) minimiert aktiv mehrere nutzergesteuerte Cache-Füllungsanfragen für denselben Cache-Schlüssel in einer einzigen Ursprungsanfrage pro Edge-Knoten.

In Kombination mit der Ursprungsabschirmung reduziert dies die Anforderungen an die Ursprungslast und die Bandbreite des ausgehenden Traffics weiter und stellt das Standardverhalten für Media CDN dar.

Bei minimierten Anfragen werden sowohl die clientseitige Anfrage als auch die (minimierte) Cache-Füllungsanfrage protokolliert. Der "Leader" wird zum Erstellen der Füllanfrage für den Ursprung verwendet, was bedeutet, dass der Ursprung nur die Header (einschließlich des User-Agents) dieses Clients sieht.

Anfragen, die nicht denselben Cache-Schlüssel teilen, können nicht minimiert werden.

Ursprungskonnektivität

In den folgenden Abschnitten wird beschrieben, wie Media CDN eine Verbindung zu Ursprüngen herstellt, wie HTTP-Anfragen gestellt werden und wie Sie Anfragen authentifizieren können.

Unterstützte Ursprünge und Protokolle

Media CDN unterstützt alle öffentlich erreichbaren HTTP-Endpunkte direkt als Ursprung, darunter:

  • Cloud Storage-Buckets, einschließlich privater Buckets über Identity and Access Management-Dienstkonten
  • Externe HTTP(S)-Load-Balancer
  • S3-kompatible Buckets, einschließlich privater Buckets, die AWS-Signaturversion 4 verwenden
  • Andere öffentlich verfügbare Objektspeicher wie Azure Blob Storage
  • Öffentlich verfügbare Webserver wie öffentliche VMs oder lokale Hosts

Die Verbindung zu Ursprüngen erfolgt über sichere Tunnel und das globale Backbone-Netzwerk von Google.

In der folgenden Tabelle sind die unterstützten Ursprungsprotokolle aufgeführt.

Protokoll Unterstützt SSL (TLS) erforderlich
HTTP/2 Ja (Standardeinstellung) Ja
HTTPS (HTTP/1.1 über TLS) Ja Ja
HTTP/1.1 Ja Nein

Media CDN verwendet standardmäßig HTTP/2 (h2), um eine Verbindung zu einem Ursprung herzustellen. HTTP/2 und HTTPS erfordern ein gültiges, öffentlich vertrauenswürdiges TLS-(SSL-)Zertifikat. Ein gültiges Zertifikat ist ein nicht abgelaufenes, von einer öffentlichen Zertifizierungsstelle signiertes Zertifikat mit einem alternativen Antragstellernamen, der dem an den Ursprung gesendeten Hostnamen entspricht.

Hinweise:

  • Wenn Ihr Ursprung HTTP/2 nicht unterstützt, können Sie das Protokoll (pro Ursprung) explizit auf HTTP (HTTP/1.1) oder HTTPS (HTTP/1.1 über TLS) setzen.
  • Beim Konfigurieren von HTTPS oder HTTP/1.1 als Ursprungsprotokoll handelt Media CDN kein alternatives Protokoll (wie HTTP/2) aus. Gleichermaßen führt die Verbindung beim Konfigurieren von HTTP/2 kein "Fallback" auf HTTP/1.1 aus, um das Verhalten der Ursprungskonnektivität explizit zu machen.
  • Media CDN verwendet automatisch den richtigen Port gemäß dem Protokoll: Port 80 für HTTP oder Port 443 für HTTPS und HTTP/2.

Ursprungsanfrageheader

Beim Herstellen einer Verbindung zu einem Ursprung verwendet Media CDN standardmäßig den Host-Header aus der Clientanfrage.

In der folgenden Tabelle wird dokumentiert, was der Ursprung in der eingehenden Anfrage in verschiedenen Konfigurationsszenarien sieht:

Clientanfrage EdgeCacheService.hostRewrite EdgeCacheOrigin.hostRewrite originAddress Host-Header /
TLS SNI am Ursprung
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 wird automatisch anhand des Bucket-Namens festgelegt

Der primäre Ursprung und alle Failover-Ursprünge sehen denselben Host-Header, wenn sie dieselbe routeRule- oder hostRewrite-Konfiguration verwenden.

Wenn Sie einen Cloud Storage-Bucket als Ursprung verwenden, werden alle hostRewrite-Einstellungen ignoriert, da alternative Host-Header-Werte von Cloud Storage-Buckets nicht unterstützt werden. Der Host-Header wird automatisch anhand des Bucket-Namens festgelegt.

Der Wert für TLS SNI (Server Name Indication) in der Anfrage (für HTTP/3-, HTTP/2- und HTTPS-Anfragen) wird auf den gleichen Wert wie der Host-Header gesetzt, der an den Ursprung gesendet wird.

Informationen zum Neuschreiben von Host-Headern für die routenspezifische Konfiguration finden Sie unter Erweitertes Routing. Informationen zum Festlegen von Überschreibungsaktionen pro Ursprung finden Sie unter Beispiel: Failover ohne Folgen von Weiterleitungen.

Private Cloud Storage-Buckets verwenden

Media CDN kann Inhalte von jedem über das Internet erreichbaren HTTP(S)-Endpunkt abrufen. In einigen Fällen kann es sein, dass Sie eine Authentifizierung erforderlich machen möchten, damit nur Media CDN Inhalte abrufen kann und nicht autorisierter Zugriff verhindert wird. Cloud Storage unterstützt dies mithilfe von IAM-Berechtigungen.

Für Cloud Storage-Ursprünge können Sie:

  1. Dem Media CDN-Dienstkonto die IAM-Berechtigung objectViewer für den Cloud Storage-Bucket oder die Cloud Storage Buckets gewähren, den oder die Sie als Ursprung verwenden.
  2. Die Berechtigung allUsers entfernen.
  3. (Optional) Die Berechtigung allAuthenticatedUsers entfernen.

Zum Ändern der Berechtigungen eines Cloud Storage-Buckets benötigen Sie die IAM-Rolle "Storage-Administrator".

Das Media CDN-Dienstkonto gehört zum Media CDN-Projekt und wird nicht in der Liste der Dienstkonten Ihres Projekts angezeigt.

Das Dienstkonto hat das folgende Format und gewährt nur Zugriff auf Media CDN-Ressourcen in den Projekten, die Sie explizit zulassen.

service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com

Um Media CDN Zugriff auf einen Bucket zu gewähren, können Sie die Google Cloud Console oder das gsutil-Tool verwenden, um dem Dienstkonto die Rolle objectViewer zuzuweisen:

gsutil iam ch \
serviceAccount:service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com:objectViewer gs://BUCKET

Führen Sie folgenden Befehl aus, um alle Berechtigungen der Rolle allUsers für den jeweiligen Bucket zu entfernen:

gsutil iam ch -d allUsers gs://BUCKET

Sie können prüfen, ob der öffentliche Zugriff entfernt wurde. Öffnen Sie dazu ein Inkognito-Browserfenster und versuchen Sie, mit https://storage.googleapis.com/BUCKET/object.ext auf ein Bucket-Objekt zuzugreifen.

Damit Edge-Cache-Dienste in einem Projekt Zugriff auf einen Cloud Storage-Bucket in einem anderen Projekt haben, können Sie dem Media CDN-Dienstkonto in diesem Projekt Zugriff auf den Storage-Bucket gewähren.

Achten Sie dabei darauf, dass die PROJECT_NUM in service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com die Projektnummer des Projekts mit den Edge-Cache-Diensten ist, die Zugriff benötigen. Sie können dies für mehrere Projekte wiederholen, insbesondere wenn Sie mehrere Projekte mit unterschiedlichen Media CDN-Umgebungen (Entwicklung, Staging, Produktion) und einem separaten Projekt mit Ihren Video- oder Medien-Assets haben.

Sie können den Zugriff auf Ihren Cloud Storage-Ursprung schützen, ohne signierte Anfragen für diese Route zu aktivieren.

Die Konfiguration von privatem Cloud Storage verhindert nicht, dass von Media CDN direkt auf Ihre im Cache gespeicherten Inhalte zugegriffen wird. Informationen darüber, wie Sie signierte Anfragen an einzelne Nutzer senden können, finden Sie unter signierte Anfragen.

Anfragen authentifizieren

Wenn Sie bestätigen müssen, dass eine Anfrage von Media CDN kommt, gibt es zwei unterstützte Ansätze:

  1. Prüfen Sie, ob die Verbindungs-IP-Adresse aus den Cache-Füllbereichen von Media CDN stammt. Diese Bereiche werden von allen Kunden gemeinsam genutzt, werden aber immer von Edge Cache-Diensten verwendet, wenn eine Verbindung zu einem Ursprung hergestellt wird.
  2. Fügen Sie einen benutzerdefinierten Anfrageheader mit einem Tokenwert hinzu, den Sie am Ursprung validieren (z. B. ein zufälliger 16-Byte-Wert). Ihr Ursprung kann dann Anfragen ablehnen, die diesen Wert nicht enthalten.

Eine Anleitung zum Festlegen von Anfrageheadern pro Route finden Sie in der Dokumentation zu benutzerdefinierten Headern.

Folgen von Ursprungsweiterleitungen konfigurieren

Media CDN unterstützt das Folgen von Weiterleitungen, die von Ihrem Ursprung intern während der Cache-Füllung zurückgegeben werden, anstatt Weiterleitungsantworten direkt an den Client zurückzugeben. Wenn Media CDN so konfiguriert ist, dass es Ursprungsweiterleitungen folgt, ruft Media CDN Inhalte vom Weiterleitungsstandort ab, bevor die weitergeleitete Antwort an den Client im Cache gespeichert und zurückgegeben wird. Media CDN folgt Weiterleitungen domainübergreifend.

Als Best Practice konfigurieren Sie die Ursprungsweiterleitung nur für Ursprünge, denen Sie vertrauen und die Sie steuern. Prüfen Sie, ob Sie jedem Ursprung in einer Weiterleitungskette vertrauen, da jeder Ursprung Inhalte erstellt, die von Ihrem EdgeCacheService bereitgestellt werden.

Fügen Sie die folgende Konfiguration zu Ihrer EdgeCacheOrigin hinzu, um das Folgen von Ursprungsweiterleitungen zu aktivieren:

name: MY_ORIGIN
  originAddress: "DOMAIN_NAME"
  maxAttempts: 2
  originRedirect:
    redirectConditions: [FOUND, TEMPORARY_REDIRECT]

Media CDN verwendet nur das angegebene Protokoll, um alle in den Weiterleitungen angegebenen Server zu erreichen. Achten Sie darauf, dass alle Server, an die Media CDN weitergeleitet werden könnte, Ihre gewünschten Protokolle unterstützen. Speziell wenn das Protokoll auf HTTPS, HTTP/2 oder HTTP/3 gesetzt ist, führt Media CDN kein Fallback auf HTTP/1.1-Verbindungen aus, um unsicheren Weiterleitungen zu folgen. Der Host-Header, der an den weitergeleiteten Ursprung gesendet wird, stimmt mit der weitergeleiteten URL überein. Media CDN folgt einer einzelnen Weiterleitung pro EdgeCacheOrigin-Versuch, bevor die endgültige Antwort zurückgegeben oder Wiederholungs- oder Failover-Bedingungen ausgewertet werden.

Die Einstellung redirectConditions gibt an, welche HTTP-Antwortcodes dazu führen, dass Media CDN einer Weiterleitung für jeden Ursprung folgt.

Bedingung Beschreibung
MOVED_PERMANENTLY Weiterleitung für Antwortcode HTTP 301 folgen
FOUND Weiterleitung für Antwortcode HTTP 302 folgen
SEE_OTHER Weiterleitung für Antwortcode HTTP 303 folgen
TEMPORARY_REDIRECT Weiterleitung für Antwortcode HTTP 307 folgen
PERMANENT_REDIRECT Weiterleitung für Antwortcode HTTP 308 folgen

Failover und Zeitlimits

In den folgenden Abschnitten wird die Konfiguration dieser Elemente beschrieben:

  • Zeitlimits: Legen Sie fest, wie lange Media CDN wartet, bis es eine Verbindung zu Ihrem Ursprung herstellt wird oder bis es eine Anfrage beantwortet.
  • Wiederholungsversuche: Legen Sie fest, ob Media CDN eine Ursprungs-HTTP-Anfrage an Ihren Ursprung wiederholt und unter welchen Bedingungen.
  • Failover: Legen Sie fest, ob Media CDN versucht, eine Verbindung zu einem Failover-Ursprung herzustellen, wenn der erste nicht verfügbar ist oder einen bestimmten Statuscode zurückgibt.

Ursprungszeitlimits anpassen

Mit Zeitlimits können Sie das Wiederholungs- und Failover-Verhalten auslösen und die Wartezeit des Clients vor dem Auslösen des clientseitigen Failovers reduzieren.

Im Folgenden werden konfigurierbare Zeitlimits beschrieben, die von Media CDN unterstützt werden:

  • connectTimeout und maxAttemptsTimeout beschränken die Zeit, die Media CDN benötigt, um eine nutzbare Antwort zu finden.

    Beide Zeitlimits umfassen die Zeit, die der Ursprung benötigt, um Header zurückzugeben, und um zu bestimmen, ob ein Failover oder eine Weiterleitung verwendet werden soll. connectTimeout gilt unabhängig für jeden Ursprungsversuch, während maxAttemptsTimeout die Zeit einschließt, die für die Verbindung bei allen Ursprungsversuchen erforderlich ist, einschließlich Failovers und Weiterleitungen. Das Folgen einer Weiterleitung zählt als zusätzlicher Versuch, eine Verbindung zum Ursprung herzustellen, und wird auf die für den konfigurierten Ursprung festgelegten maxAttempts angerechnet.

    Wenn Media CDN auf eine Nicht-Weiterleitungsantwort stößt, z. B. von einem Weiterleitungs- oder Failover-Ursprung, gelten die Werte readTimeout und responseTimeout. Weitergeleitete Ursprünge verwenden die Werte connectTimeout, readTimeout und responseTimeout, die für den EdgeCacheOrigin konfiguriert sind, der auf die Weiterleitung gestoßen ist.

  • responseTimeout und readTimeout steuern, wie lange eine gestreamte Antwort dauern kann. Nachdem Media CDN feststellt, dass eine vorgelagerte Antwort verwendet wird, sind weder connectTimeout noch maxAttemptsTimeout relevant. An diesem Punkt werden readTimeout und responseTimeout wirksam.

Media CDN führt maximal vier Ursprungsversuche über alle Ursprünge hinweg aus, unabhängig von den von jedem EdgeCacheOrigin festgelegten maxAttempts. Media CDN verwendet den Wert maxAttemptsTimeout vom primären EdgeCacheOrigin. Die Zeitlimitwerte pro Versuch (connectTimeout, readTimeout und responseTimeout) werden für den EdgeCacheOrigin jedes Versuchs konfiguriert.

In der folgenden Tabelle werden die Zeitlimitfelder beschrieben:

Feld Standard Beschreibung
connectTimeout 5 Sekunden

Der maximale Zeitraum, den Media CDN ab dem Starten der Anfrage an den Ursprung benötigen darf, bis Media CDN bestimmt, ob die Antwort verwendbar ist. In der Praxis deckt connectTimeout den Zeitraum ab, der mit dem Erstellen der Anfrage beginnt und in der Folge das Ausführen von DNS-Lookups und TLS-Handshakes, das Herstellen einer TCP/QUIC-Verbindung und schließlich das Abrufen der Antwortheader umfasst, die den HTTP-Statuscode enthalten.

Das Zeitlimit muss ein Wert zwischen 1 Sekunde und 15 Sekunden sein.

maxAttemptsTimeout 15 Sekunden

Die maximale Zeit für alle Verbindungsversuche zum Ursprung, einschließlich Failover-Ursprünge, bevor ein Fehler an den Client zurückgegeben wird. Wenn das Zeitlimit erreicht ist, bevor eine Antwort zurückgegeben wird, wird der HTTP-Fehler 504 zurückgegeben.

Das Zeitlimit muss ein Wert zwischen 1 Sekunde und 30 Sekunden sein.

Diese Einstellung definiert die Gesamtdauer für alle Ursprungsverbindungsversuche, einschließlich Failover-Ursprünge, um die Gesamtzeit zu begrenzen, die Clients warten müssen, bis das Streamen von Inhalten startet. Es wird nur der erste maxAttemptsTimeout-Wert verwendet, wobei der erste durch den für die angegebene Route konfigurierten Ursprung definiert wird.

readTimeout 15 Sekunden

Die maximale Wartezeit zwischen Lesevorgängen einer einzelnen HTTP-Antwort. Das readTimeout wird durch das responseTimeout begrenzt. Alle Lesevorgänge der HTTP-Antwort müssen innerhalb der durch das responseTimeout festgelegten Frist abgeschlossen werden. Das Zeitlimit muss ein Wert zwischen 1 Sekunde und 30 Sekunden sein. Wenn dieses Zeitlimit erreicht ist, bevor die Antwort abgeschlossen ist, wird die Antwort abgeschnitten und protokolliert.

responseTimeout 30 Sekunden

Die maximale Dauer, bis eine Antwort abgeschlossen sein muss.

Das Zeitlimit muss ein Wert zwischen 1 Sekunde und 120 Sekunden sein.

Die Dauer wird ab dem Zeitpunkt gemessen, zu dem die ersten Textbyte empfangen werden. Wenn dieses Zeitlimit erreicht ist, bevor die Antwort abgeschlossen ist, wird die Antwort abgeschnitten und protokolliert.

Betrachten Sie hierzu folgende Beispiele:

  • Ursprung A stimmt Anfragen mit "/segments/" ab und hat ein maxAttemptsTimeout von 5 s, ein maxAttempts von 1 und eine failover_origin, der als Ursprung B konfiguriert ist. Das connectTimeout hat den Standardwert von 5 s. Wenn Sie versuchen, eine Verbindung zu Ursprung A herzustellen, und diese innerhalb von einer Sekunde aufgrund eines ungültigen TLS-Zertifikats fehlschlägt, haben Sie noch ~4 Sekunden, um eine erfolgreiche Verbindung zu Ursprung B herzustellen.

  • Ursprung C stimmt Anfragen mit "/manifests/*" ab, hat ein maxAttemptsTimeout von 10 s, ein maxAttempts von 3 und keinen failover_origin konfiguriert. Das connectTimeout hat den Standardwert von 5 s. Media CDN versucht, bis zu dreimal eine Verbindung zu Ursprung C herzustellen, wobei bis zu 10 Sekunden (maxAttemptsTimeout) zulässig sind, um eine erfolgreiche Verbindung herzustellen.

Ursprungsanfragen wiederholen

Media CDN unterstützt Ursprungs-Wiederholungsversuche, sodass Anfragen an den Ursprung wiederholt werden können. Sie können angeben, wie oft für den aktuellen Ursprung Wiederholungsversuche ausgeführt werden sollen, bevor ein Failover-Ursprung (falls konfiguriert) versucht wird.

  • Media CDN versucht, den primären Ursprung bis zum konfigurierten maxAttempts-Wert zu erreichen, der standardmäßig auf eins gesetzt ist.
  • Media CDN wiederholt Ursprungsverbindungen bis zu dreimal, bevor der Prozess fehlschlägt und ein Zeitüberschreitungsfehler an den Nutzer zurückgegeben wird. Dies umfasst alle Failover-Ursprungsverbindungen, die auf das Limit von drei angerechnet werden.
  • Beim Konfigurieren einer Ursprungsressource können Sie einen primären Ursprung mithilfe des Felds originAddress und dann eines optionalen failoverOrigin konfigurieren. failoverOrigin verweist auf eine andere Ursprungsressource.

Die retryConditions für jeden Ursprung geben an, welche Fehlerarten eine Wiederholung auslösen:

Bedingung Standard Beschreibung
CONNECT_FAILURE ✔️ Zu Wiederholungsversuchen bei Fehlern gehören Routing-, DNS- und TLS-Handshakefehler sowie TCP/UDP-Zeitüberschreitungen.
HTTP_5XX Wiederholung bei jedem HTTP 5xx-Antwortcode.
GATEWAY_ERROR Ähnlich wie bei 5xx, gilt aber nur für die Antwortcodes 502, 503 oder 504.
RETRIABLE_4XX Wiederholung bei wiederholbaren 4xx-Antwortcodes, einschließlich 409 und 429.
NOT_FOUND Wiederholung bei einem HTTP 404.
FORBIDDEN Wiederholung bei einem HTTP 403.

Wenn Sie eine aktive Systemdiagnose, Round Robin- oder lastenabhängiges Steuern über Ursprünge hinweg benötigen, können Sie einen externen HTTP(S)-Load-Balancer als primären Ursprung konfigurieren.

Failover-Verhalten

In der folgenden Tabelle wird beschrieben, wie der Failover funktioniert und welche Antwort ein Client beobachten würde:

Szenario Failover konfiguriert Für Nutzer sichtbarer Status
Media CDN versucht, eine Verbindung zu Ihrem Ursprung herzustellen, und erhält nach zwei Versuchen (standardmäßig) keine HTTP-Antwort. Nein HTTP 502 (Fehlerhaftes Gateway)
Media CDN versucht, eine Verbindung zu Ihrem primären Ursprung herzustellen und schlägt fehl (TLS-Handshakefehler). Es wird versucht, Ihren konfigurierten Failover-Ursprung zu erreichen, der einen HTTP 404 zurückgibt. Ja HTTP 404 (Nicht gefunden)
Media CDN versucht, eine Verbindung sowohl zu Ihrem primären als auch zu Ihrem Failover-Ursprung herzustellen, erhält jedoch keinen HTTP-Statuscode. Ja HTTP 502 (Fehlerhaftes Gateway)

Media CDN gibt den Statuscode HTTP 502 (Fehlerhaftes Gateway) zurück, wenn alle Ursprungsverbindungen fehlschlagen.

Wenn Media CDN einen Statuscode wie einen HTTP 404 (Nicht gefunden) oder HTTP 429 (Zu viele Anfragen) empfängt, aber nachfolgende Anfragen fehlschlagen, wird der letzte beobachtete Statuscode an den Client zurückgegeben.

Beispiel: Failover ohne Folgen der Weiterleitung

Im Folgenden ist eine grundlegende Failover-EdgeCacheOrigin-Konfiguration aufgeführt:

  name: FAILOVER_ORIGIN
  originAddress: FAILOVER_DOMAIN_NAME

Media CDN wiederholt den primären Ursprung der Route maximal dreimal, bevor ein Failover-Ursprung versucht wird. In dieser Konfiguration probiert Media CDN, nachdem der primäre Ursprung dreimal versucht wurde zu erreichen, eine einzelne Anfrage mit FAILOVER_ORIGIN. Wenn der Failover-Ursprung ebenfalls nicht erfolgreich reagiert, gibt Media CDN entweder den letzten empfangenen Statuscode oder, wenn kein Statuscode empfangen wird, eine HTTP 502-Antwort (Fehlerhaftes Gateway) zurück.

Die Latenz beim Füllen des Cache erhöht sich mit der Anzahl der Wiederholungen und der Failover-Ereignisse. Das Erhöhen der Ursprungs-Zeitlimitwerte (z. B. connectTimeout) wirkt sich weiter auf die Cache-Füllungslatenz aus, weil dadurch die Zeit erhöht wird, die mit dem Warten auf die Antwort eines überlasteten oder ausgelasteten Ursprungsservers verbracht wird.

Das folgende Beispiel zeigt eine Konfiguration, die Füllungsanfragen an MY_ORIGIN sendet. Die Konfiguration bewirkt, dass Media CDN bei Verbindungsfehlern (wie DNS-, TCP- oder TLS-Fehlern), HTTP 5xx-Antworten vom Ursprung oder einem HTTP 404 Wiederholungsversuche unternimmt. Nach zwei Versuchen erfolgt ein Failover auf FAILOVER_ORIGIN.

Insgesamt werden für die konfigurierten Ursprünge maximal vier Versuche vorgenommen: der ursprüngliche Versuch sowie bis zu drei Wiederholungsversuche. Sie können ein maxAttempts pro Ursprung konfigurieren, um zu bestimmen, wie viele Wiederholungsversuche ausgeführt werden, bevor ein Failover durchgeführt wird.

  name: MY_ORIGIN
  originAddress: DOMAIN_NAME
  maxAttempts: 2 # the number of attempts to make before trying the failoverOrigin
  failoverOrigin: FAILOVER_ORIGIN
  # what conditions trigger a retry or failover
  retryConditions:
  - CONNECT_FAILURE
  - HTTP_5xx # any HTTP 5xx response
  - NOT_FOUND # retry on a HTTP 404
  timeout:
    maxAttemptsTimeout: 10s # set a deadline for all retries and failover

Wenn Ihr Ursprung eine ursprungsspezifische Host-Umschreibung oder eine andere ursprungsspezifische Header-Änderung erfordert, verwenden Sie das folgende originOverrideAction-Konfigurationsbeispiel, um sie festzulegen:

  name: FAILOVER_ORIGIN
    originAddress: "FAILOVER_ORIGIN_HOST"
    originOverrideAction:
      urlRewrite:
        hostRewrite: "FAILOVER_ORIGIN_HOST"
      headerAction:
        requestHeadersToAdd:
        - headerName: "Authorization"
          headerValue: "AUTH-KEY"
          replace: true

Bei der folgenden Konfiguration handelt es sich um eine abgeschlossene:

  name: MY_ORIGIN
  originAddress: DOMAIN_NAME
  maxAttempts: 2 # the number of attempts to make before trying the failoverOrigin
  failoverOrigin: FAILOVER_ORIGIN
  # what conditions trigger a retry or failover
  retryConditions:
  - CONNECT_FAILURE
  - HTTP_5xx # any HTTP 5xx response
  - NOT_FOUND # retry on a HTTP 404
  timeout:
    maxAttemptsTimeout: 10s # set a deadline for all retries and failover
  name: FAILOVER_ORIGIN
    originAddress: "FAILOVER_ORIGIN_HOST"
    originOverrideAction:
      urlRewrite:
        hostRewrite: "FAILOVER_ORIGIN_HOST"
      headerAction:
        requestHeadersToAdd:
        - headerName: "Authorization"
          headerValue: "AUTH-KEY"
          replace: true

Im vorherigen Beispiel hat die Einstellung originOverrideAction.hostRewrite Vorrang vor vorhandenen Header-Umschreibungen, die auf Routen konfiguriert sind, die auf diesen Ursprung verweisen.

Sie können mit requestHeadersToAdd eindeutige Header pro Ursprung verwenden, die von diesem bestimmten Ursprung angefordert werden. Ein häufiger Anwendungsfall fügt statische Authorization-Header hinzu. Da die Header-Manipulationen während der Ursprungsanfrage ausgeführt werden, ersetzen Header, die pro Ursprung hinzugefügt werden, entweder vorhandene Header desselben Feldnamens oder sie werden diesen angefügt. Standardmäßig fügt Media CDN an vorhandene Header an. Wenn Sie vorhandene Header ersetzen möchten, setzen Sie headerAction.replace auf true.

Beispiel: Failover mit Folgen von Weiterleitungen

Angenommen, Sie haben die folgenden EdgeCacheOrigin-Ressourcen konfiguriert und die Routen Ihrer EdgeCacheService-Ressource sind so konfiguriert, dass sie PrimaryOrigin zum Füllen des Cache verwenden:

name: PrimaryOrigin
  originAddress: "primary.example.com"
  maxAttempts: 2
  failoverOrigin: "SecondaryOrigin"
  retryConditions: [CONNECT_FAILURE]
  originRedirect:
    redirectConditions: [FOUND, TEMPORARY_REDIRECT]
name: SecondaryOrigin
  originAddress: "secondary.example.com"
  maxAttempts: 3
  originRedirect:
    redirectConditions: [FOUND, TEMPORARY_REDIRECT]

In diesem Beispiel liest Media CDN, wenn es eine Cache-Füllung durchführt, die Konfiguration der PrimaryOrigin und reagiert entsprechend.

Angenommen, Media CDN stellt als Versuch Nr. 1, den Ursprung zu kontaktieren, eine Verbindung zu primary.example.com her. Wenn primary.example.com eine erfolgreiche Antwort zurückgibt, verwendet Media CDN diese Antwort für die Cache-Füllung.

Angenommen weiter, primary.example.com gibt einen HTTP 302 (Weiterleitung gefunden) an Location: b.example.com zurück. Als Versuch Nr. 2, den Ursprung zu kontaktieren, folgt Media CDN der Weiterleitung zu b.example.com. In diesem Fall führt Media CDN Folgendes aus:

  • Wenn b.example.com eine erfolgreiche Antwort zurückgibt, verwendet Media CDN diese Antwort für die Cache-Füllung.
  • Wenn b.example.com eine Weiterleitung oder eine Fehlerantwort zurückgibt, erfolgt ein Failover von Media CDN auf den konfigurierten SecondaryOrigin. Dies liegt daran, dass in diesem Beispiel PrimaryOrigin für zwei maxAttempts konfiguriert ist.

Wenn Media CDN ein Failover auf SecondaryOrigin ausführt, verwendet Media CDN die SecondaryOrigin-Konfiguration und versucht, eine Verbindung zu secondary.example.com herzustellen. Dies ist Versuch Nr. 1, den Ursprung zu kontaktieren, und Versuch Nr. 3 insgesamt.

In diesem Fall führt Media CDN folgende Schritte aus:

  • Wenn secondary.example.com eine erfolgreiche Antwort zurückgibt, verwendet Media CDN diese Antwort für die Cache-Füllung.
  • Wenn secondary.example.com einen HTTP 302 (Weiterleitung gefunden) an Location: c.example.com zurückgibt, versucht Media CDN, c.example.com zu kontaktieren. In diesem Beispiel ist dies Versuch Nr. 2 für SecondaryOrigin und Versuch Nr. 4 insgesamt.

Wenn der Versuch, c.example.com zu kontaktieren, eine erfolgreiche Antwort zurückgibt, verwendet Media CDN diese Antwort für die Cache-Füllung. Wenn der Versuch eine Weiterleitung zurückgibt, für dessen Folgen Media CDN konfiguriert ist, gibt Media CDN den Fehler 502 (Fehlerhaftes Gateway) zurück, da die maximale Anzahl von Versuchen zur Kontaktaufnahme mit einem Ursprung erschöpft ist. Media CDN führt unabhängig von EdgeCacheOrigin-Konfigurationen höchstens vier Versuche über alle Ursprünge hinweg durch. Wenn Media CDN schließlich bei der Kontaktaufnahme mit c.example.com fehlschlägt, gibt Media CDN entweder eine "504 Gateway"-Zeitüberschreitung oder eine "502 Fehlerhaftes Gateway"-Antwort zurück.

Wenn Sie eine Systemdiagnose, Round Robin- oder lastenabhängiges Steuern über Ursprünge hinweg benötigen, können Sie einen externen HTTP(S)-Load-Balancer als primären Ursprung konfigurieren.

Ursprünge konfigurieren

In den folgenden Abschnitten finden Sie Beispiele zum Konfigurieren gängiger Ursprungstypen, einschließlich Cloud Storage-Buckets und Ursprüngen externer HTTP(S)-Load-Balancers.

Cloud Storage-Integration

Media CDN unterstützt Cloud Storage-Buckets als Back-Ends für Inhalte. Jeder Dienst kann auf mehrere Buckets verweisen, indem er Routen für den Host, Pfade und andere Anfrageattribute konfiguriert.

Cloud Storage-Buckets werden konfiguriert, indem die Bucket-URL, z. B. gs://my-bucket, als Ursprungsadresse beim Erstellen einer Ursprungsressource verwendet wird.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Media CDN-Ursprünge auf.

    Zur Seite "Media CDN-Ursprünge“

  2. Klicken Sie auf Ursprung erstellen.

  3. Geben Sie einen Namen für den Ursprung ein. Beispiel: cloud-storage-origin.

  4. Geben Sie eine optionale Beschreibung für den Ursprung ein.

  5. Wählen Sie als Ursprungsadresse die Option Google Cloud Storage-Bucket auswählen aus.

  6. Rufen Sie Ihren Cloud Storage-Bucket auf.

  7. Behalten Sie für Cloud Storage die Standardeinstellungen für Protokoll und Port bei.

  8. (Optional) Wählen Sie einen Failover-Ursprung aus, der für den Fall versucht wird, dass dieser Ursprung nicht mehr erreichbar ist. Sie können dieses Feld später aktualisieren.

  9. Wählen Sie Wiederholungsbedingungen aus.

  10. Wählen Sie unter Maximale Versuche eine maximale Anzahl von Versuchen aus, den Cache von diesem Ursprung zu füllen.

  11. (Optional) Passen Sie die Zeitlimits an:

    1. Wählen Sie für Verbindungszeitlimit die maximale Dauer aus, die auf das Herstellen der Ursprungsverbindung gewartet werden soll.
    2. Wählen Sie für Antwortzeitlimit die maximale Dauer aus, die für den Abschluss einer Antwort zulässig sein soll.
    3. Wählen Sie für Lesezeitlimit die maximale Dauer aus, die zwischen Lesevorgängen einer einzelnen HTTP-Verbindung oder eines Streams gewartet werden soll.
  12. (Optional) Geben Sie ein oder mehrere Labels für diesen Ursprung ein.

  13. Klicken Sie auf Ursprung erstellen.

gcloud

Führen Sie den Befehl gcloud edge-cache origins create aus:

gcloud edge-cache origins create cloud-storage-origin --origin-address="gs://my-bucket"
Create request issued for: [cloud-storage-origin]

originAddress: "gs://my-bucket"

Dies ist unabhängig davon, ob der Bucket multiregional, biregional oder regional ist.

Wenn Sie einen Dienst konfigurieren, können Sie Ihre Video-on-Demand-Inhalte an einen Bucket weiterleiten und Livestreaming-Inhalte an einen zweiten Bucket streamen: Dies ist nützlich, wenn diese Workflows von verschiedenen Teams verwaltet werden. Ebenso können Sie eu-media.example.com an einen multiregionalen Cloud Storage-Bucket in der EU weiterleiten, um die Latenz für die Cache-Füllung zu reduzieren, und us-media.example.com (oder eine Übereinstimmung in Pfad, Header oder Abfrageparameter) an einen US-basierten Storage-Bucket weiterleiten.

Media CDN-Buckets
Media CDN-Buckets (zum Vergrößern klicken)

In Fällen, in denen die Schreiblatenz von kritischer Bedeutung ist, z. B. beim Livestreaming mit niedriger Latenz, können Sie einen regionalen Cloud Storage-Endpunkt so nah wie möglich bei Ihren Nutzern konfigurieren.

Externen HTTP(S)-Load-Balancer als Ursprung verwenden

Wenn Sie eine aktive Systemdiagnose, Round Robin- oder lastenabhängiges Steuern über Compute Engine-, GKE- oder lokale Ursprünge hinweg benötigen, können Sie einen externen HTTP(S)-Load-Balancer als Ursprung konfigurieren.

Auf diese Weise können Sie (beispielsweise) Ihre Livestreaming-Verpacker hinter Media CDN oder eine Gruppe von Envoy-Proxys konfigurieren, die von Traffic Director verwaltet werden, um eine Verbindung zurück zur lokalen Infrastruktur herzustellen.

Mit Load-Balancern können Sie Back-Ends für folgende Komponenten konfigurieren:

Eine Architektur, die einen externen HTTP(S)-Load-Balancer-Ursprung für die Bereitstellung von Videomanifesten und einen Cloud Storage-Ursprung für die Segmentspeicherung kombiniert, würde folgendermaßen aussehen, wobei zwei Ursprünge verschiedenen Routen zugeordnet werden.

Edge-Cache-Bereitstellung
Edge-Cache-Bereitstellung (zum Vergrößern klicken)

Zum Konfigurieren eines externen HTTP(S)-Load-Balancers als Ursprung müssen Sie eine Ursprungsressource erstellen, wobei die IP-Adresse oder der öffentliche Hostname auf die Weiterleitungsregel(n) Ihres Load-Balancers verweist. Ein öffentlicher Hostname (Domainname) wird bevorzugt, da dies für ein SSL-(TLS-)Zertifikat und für moderne HTTP-Versionen (HTTP/2 und HTTP/3) erforderlich ist.

Außerdem müssen Sie Folgendes gewährleisten:

  • Ihr Load-Balancer hat eine Route, die dem Hostnamen entspricht, der für Ihren Edge-Cache-Dienst verwendet wird.
  • (oder) Sie haben einen urlRewrite.hostRewrite für Routen konfiguriert, bei denen Ihr Load-Balancer als Ursprung konfiguriert ist.
  • Ihr Load-Balancer verfügt über ein öffentlich vertrauenswürdiges SSL-(TLS-)Zertifikat, das für diese Hostnamen konfiguriert ist.

Wenn beispielsweise der Name der öffentlichen Domain, der auf die Weiterleitungsregel Ihres Load-Balancers verweist, origin-packager.example.com lautet, dann erstellen Sie einen Ursprung, bei dem die originAddress auf diesen Namen festgelegt ist:

Console

  1. Rufen Sie in der Google Cloud Console die Seite „Media CDN“ auf.
    Zu Media CDN
  2. Klicken Sie auf den Tab Ursprünge.
  3. Klicken Sie auf Ursprung erstellen.
  4. Geben Sie einen Namen für den Ursprung ein. Beispiel: load-balancer-origin.
  5. Geben Sie eine optionale Beschreibung für den Ursprung ein.
  6. Wählen Sie unter Ursprungsadresse die Option FQDN oder IP-Adresse angeben aus.
  7. Geben Sie den FQDN oder die IP-Adresse für den Google Cloud-Load-Balancer ein.
  8. Wählen Sie ein Protokoll und einen Port aus, über die Media CDN eine Verbindung zu Ihrem Ursprung herstellen soll.
  9. (Optional) Wählen Sie einen Failover-Ursprung aus, der für den Fall versucht wird, dass dieser Ursprung nicht mehr erreichbar ist. Sie können dieses Feld später aktualisieren.
  10. Wählen Sie Wiederholungsbedingungen aus.
  11. Wählen Sie unter Maximale Versuche eine maximale Anzahl von Versuchen aus, den Cache von diesem Ursprung zu füllen.
  12. (Optional) Passen Sie die Zeitlimits an:
    1. Wählen Sie für Verbindungszeitlimit die maximale Dauer aus, die auf das Herstellen der Ursprungsverbindung gewartet werden soll.
    2. Wählen Sie für Antwortzeitlimit die maximale Dauer aus, die für den Abschluss einer Antwort zulässig sein soll.
    3. Wählen Sie für Lesezeitlimit die maximale Dauer aus, die zwischen Lesevorgängen einer einzelnen HTTP-Verbindung oder eines Streams gewartet werden soll.
  13. (Optional) Geben Sie ein oder mehrere Labels für diesen Ursprung ein.
  14. Klicken Sie auf Ursprung erstellen.

gcloud

Führen Sie den Befehl gcloud edge-cache origins aus:

gcloud edge-cache origins create lb-origin --origin-address="origin-packager.example.com"
Create request issued for: [lb-origin]

originAddress: "origin-packager.example.com"

Wenn Sie die IP-Adresse Ihrer Weiterleitungsregel als Ursprungsadresse verwenden oder an Ihren Load-Balancer kein SSL-Zertifikat angehängt ist, können Sie das Protokoll auf HTTP setzen, um ein Fallback auf unverschlüsselte Verbindungen auszuführen. Wir empfehlen, dies nur zu Entwicklungs- oder Testzwecken zu tun.

Ursprungsprotokoll konfigurieren

Legen Sie für Ursprünge, die nur HTTPS (HTTP/1.1 über TLS) oder HTTP/1.1 (ohne TLS) unterstützen, das Feld protocol explizit fest. Gehen Sie dazu so vor:

Console

  1. Rufen Sie in der Google Cloud Console die Seite „Media CDN“ auf.
    Zu Media CDN
  2. Klicken Sie auf den Tab Ursprünge.
  3. Wählen Sie den Ursprung aus und klicken Sie auf Bearbeiten.
  4. Wählen Sie als Protokoll HTTPS oder HTTP aus.
  5. Wenn Sie HTTP ausgewählt haben, wählen Sie Port 80 aus.
  6. Klicken Sie auf Ursprung aktualisieren.

gcloud

Führen Sie den Befehl gcloud edge-cache origins aus:

gcloud edge-cache origins update LEGACY_ORIGIN \
    --protocol=HTTPS

Der Befehl aktualisiert den Ursprung und gibt Folgendes zurück:

Update request issued for: [LEGACY_ORIGIN]
protocol: HTTPS

Wenn Ihr Ursprung HTTP/2 unterstützt, müssen Sie das Protokoll nicht explizit festlegen.

Verbindungsprobleme beheben

Wenn Sie HTTP 50x-Fehler wie HTTP 502 (Gateway-Zeitüberschreitung) oder HTTP 500 (Interner Serverfehler) erhalten, beachten Sie Folgendes:

  • Testen Sie, ob der Ursprungshostname mit Google Public DNS aufgelöst werden kann und dass die aufgelösten IP-Adressen den Erwartungen entsprechen. Wenn Sie kürzlich Ihre DNS-Einträge geändert haben, haben Resolver möglicherweise noch die alte Adresse in ihren Caches.

  • Wenn Ihr Ursprung nur HTTP/1.1 und kein HTTP/2 unterstützt, konfigurieren Sie das protocol-Feld am Ursprung so, dass HTTP oder HTTPS anstelle von HTTP2 verwendet wird. Media CDN führt kein Fallback auf HTTP/1.1-Verbindungen aus, außer dies ist angegeben.

  • Prüfen Sie, ob die Anfragelogs in Cloud Logging die korrekte Quell-IP-Adresse enthalten.

  • Prüfen Sie, ob der Ursprung ein gültiges (öffentlich vertrauenswürdiges) und nicht abgelaufenes SSL-(TLS-)Zertifikat hat.

  • HTTP/2-Trailer werden nicht unterstützt und Anfragen an einen Ursprungsserver enthalten nicht den "TE"-Anfrageheader. In einer Antwort enthaltene Trailer werden nicht im Cache gespeichert oder an den Client zurückgegeben.

Fehlerbehebung beim Ursprungs-Failover

Wenn ein Ursprungs-Failover nicht wie erwartet funktioniert, beachten Sie Folgendes:

  • Sorgen Sie dafür, dass auf dem Failover-Ursprung die entsprechende Umschreibung des Host-Headers konfiguriert ist.

  • Achten Sie darauf, dass Ihr primärer Ursprung mit ausreichenden maxAttemptsTimeout-, maxAttempts- und timeouts-Werten konfiguriert ist, um Ursprungsweiterleitungen und -Failovers zu berücksichtigen. Ursprungsweiterleitungen werden als separate Verbindungsversuche auf die maxAttempts-Einstellung angerechnet.

Nächste Schritte