Conectividad y protección de orígenes

Media CDN te permite recuperar fácilmente contenido de la infraestructura de origen, ya sea que el contenido esté alojado en Google Cloud, en otra nube o de forma local.

Cada configuración puede tener uno o más orígenes asociados a ella. La configuración de origen le indica a Media CDN cómo conectarse a la infraestructura, cuándo y cómo realizar la conmutación por error, el reintento y el tiempo de espera, y qué protocolo usar cuando se conecte.

Las siguientes son características de origen:

• Los orígenes se pueden definir como por host y por ruta, lo que permite que un solo servicio de caché de Edge se asigne a varios orígenes que contengan (por ejemplo, manifiestos, segmentos de video y otros contenidos estáticos).
• Se puede acceder a los orígenes mediante HTTP/2, HTTPS y HTTP/1.1 sin encriptar.
• Los reintentos y los comportamientos de conmutación por error se configuran por origen y pueden permitirte conmutar por error graves (como errores de conectividad) o reintentar según las respuestas HTTP 404 (No encontrado) o HTTP 429 (Demasiadas solicitudes).
• Se puede acceder a los recursos privados dentro de Google Cloud o locales si configuras un balanceador de cargas HTTP(S) externo como un origen detrás de Media CDN.
• El siguiente comportamiento de redireccionamiento se configura por origen. Puedes habilitar Media CDN para seguir los redireccionamientos a otros servidores de origen.

Requisitos de origen

Para permitir que la Media CDN almacene las respuestas de origen en caché, un origen debe incluir lo siguiente en los encabezados de respuesta para las solicitudes de HEAD y GET, a menos que se especifique lo contrario:

• Un encabezado de respuesta HTTP Last-Modified o ETag.
• Un encabezado HTTP Date válido.
• Un encabezado Content-Length válido.
• El encabezado de respuesta Accept-Ranges: bytes.
• El encabezado de respuesta Content-Range, en respuesta a una solicitud GET Range. El encabezado Content-Range debe tener un valor válido con el formato bytes x-y/z (en el que z es el tamaño del objeto).

El protocolo de origen predeterminado es HTTP/2. Si tus orígenes solo admiten HTTP/1.1, puedes configurar el campo del protocolo de forma explícita para cada origen.

Nota: Las respuestas pequeñas (menos de 1 MiB) se almacenan en caché en su totalidad y no requieren compatibilidad con el encabezado Accept-Ranges o Content-Range.

Prácticas recomendadas para la conmutación por error de origen

Vista previa

Este producto o función está sujeto a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones específicas del Servicio. Los productos y las funciones que se encuentran en la fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Cuando configures varios orígenes para la conmutación por error o el balanceo de cargas, asegúrate de que el comportamiento del encabezado de contenido multimedia Vary, ETag y Last-Modified sea coherente entre tus orígenes.

Advertencia: La configuración de redireccionamientos desde un servicio de origen no confiable o controlado por un atacante puede exponer tu configuración de Media CDN a fin de abrir vulnerabilidades de redireccionamiento.

Como práctica recomendada, configura el redireccionamiento de origen solo para orígenes que confíes y controles. Asegúrate de confiar en cada origen en una cadena de redireccionamiento, ya que cada origen produce contenido que entrega tu EdgeCacheService.

Protección del origen

Media CDN proporciona una infraestructura de perímetro con muchos niveles diseñada para minimizar el llenado de caché de forma activa siempre que sea posible.

Hay tres capas principales de infraestructura de almacenamiento en caché:

1. Cachés perimetrales profundas, que entregan la mayor parte del tráfico y la descarga dentro de una red de proveedores de servicios.
2. El perímetro de intercambio de tráfico de Google, que está conectado a miles de ISP y actúa como la caché de nivel medio para las cachés perimetrales y, en los casos en que no están presentes dentro de un ISP determinado, la caché orientada al usuario.
3. Las cachés de larga duración se almacenan en caché dentro de la red de Google de las que otras cachés descendentes se llenan antes del origen. Estas memorias caché admiten fan-in significativa y tienen una capacidad de almacenamiento sustancial de caché, y actúan como un "escudo" de origen.

A continuación, se muestra una descripción general de esta topología:

Descripción general de la topología (haz clic para ampliar)

Todas las capas de almacenamiento en caché admiten la reducción de las solicitudes (“fusionadas”) para reducir aún más la carga de origen. Según las cargas de trabajo reales observadas a gran escala:

• Más del 95% del llenado de caché usa un nivel de caché de “cola larga” dedicado dentro de la región, para reducir los costos de llenado de caché y la latencia.
• El llenado de caché entre el origen y la propia infraestructura perimetral de Google se basa completamente en la red troncal privada y global de Google, lo que reduce la latencia de llenado de caché y mejora la confiabilidad. Ambos son beneficios activos para las cargas de trabajo de transmisión en vivo.
• Las memorias caché se llenan entre sí cuando es beneficioso para hacerlo, lo que reduce aún más las tasas de llenado de caché.
• Media CDN tiene una capacidad de almacenamiento significativa en todas las memorias caché, lo que minimiza las tasas de expulsión para el contenido de cola larga y menos popular, incluso con un gran contenido de contenido de cola larga.

Los clientes pueden ver diferentes tasas de descarga en función de la configuración de la caché, la carga de usuarios, las cargas de trabajo (como en vivo o a pedido), la distribución de usuarios y la cantidad de contenido de “cola larga” (tamaño total del corpus) que entregan. a los usuarios en todas las regiones.

Contraer la solicitud

La solicitud de contraer (o fusión) contrae de forma activa varias solicitudes de llenado de caché generadas por el usuario para la misma clave de caché en una sola solicitud de origen por nodo perimetral.

En combinación con la Protección de origen, esto reduce aún más las necesidades de carga de origen y ancho de banda de salida, y es el comportamiento predeterminado para Media CDN.

Las solicitudes contraídas tienen registrada la solicitud orientada al cliente y la solicitud de llenado de caché (contraída). El “líder” de la sesión contraída se usa para realizar la solicitud de llenado de origen, lo que significa que el origen ve los encabezados (incluido el usuario-agente) de ese cliente solo.

Las solicitudes que no comparten la misma clave de caché no se pueden contraer.

Conectividad de origen

En las siguientes secciones, se describe cómo se conecta Media CDN a los orígenes, cómo se realizan las solicitudes HTTP y cómo puedes autenticar las solicitudes.

Protocolos y orígenes compatibles

Media CDN admite de forma directa cualquier extremo HTTP accesible de forma pública como origen, incluidos los siguientes:

• Buckets de Cloud Storage, incluidos los buckets privados a través de cuentas de servicio de Identity and Access Management.
• Balanceadores de cargas HTTP(S) externos
• Buckets compatibles con S3, incluidos los buckets privados que usan AWS Signature versión 4
• Otro almacenamiento de objetos disponibles de forma pública, como Azure Blob Storage
• Servidores web disponibles de forma pública, como VM públicas o hosts locales

La conectividad a los orígenes se realiza mediante túneles seguros y la red troncal global de Google.

En la siguiente tabla, se detallan los protocolos de origen compatibles.

Protocolo	Admitido	SSL (TLS) obligatorio
HTTP/2	Sí (valor predeterminado)	Sí
HTTPS (HTTP/1.1 mediante TLS)	Sí	Sí
HTTP/1.1	Sí	No

Media CDN usa HTTP/2 (h2) para conectarse a un origen de forma predeterminada. HTTP/2 y HTTPS requieren un certificado TLS (SSL) válido y de confianza pública. Un certificado válido es uno que no está vencido, firmado por una autoridad certificada pública y tiene un nombre alternativo del sujeto que coincide con el nombre de host enviado al origen.

Notas:

• Si tu origen no admite HTTP/2, puedes configurar de forma explícita el protocolo (por origen) en HTTP (HTTP/1.1) o HTTPS (HTTP/1.1 a través de TLS).
• Cuando se configura HTTPS o HTTP/1.1 como protocolo de origen, Media CDN no negocia un protocolo alternativo (como HTTP/2). Del mismo modo, cuando se configura HTTP/2, la conexión no "revierte" a HTTP/1.1 para ser explícito con el comportamiento de la conectividad de origen.
• Media CDN usa automáticamente el puerto correcto basado en el protocolo: puerto 80 para HTTP o puerto 443 para HTTPS y HTTP/2.

Encabezados de la solicitud de origen

Cuando se conecta a un origen, Media CDN usa el encabezado del host de la solicitud del cliente de forma predeterminada.

En la siguiente tabla, se documenta lo que ve el origen en la solicitud entrante en diferentes situaciones de configuración:

Solicitud del cliente	EdgeCacheService.hostRewrite	EdgeCacheOrigin.hostRewrite	originAddress	Encabezado del host / SNI de TLS en el origen
media.example.com	Ninguna	Ninguna	backend.example.com	media.example.com
media.example.com	service.example.com	Ninguna	backend.example.com	service.example.com
media.example.com	Ninguna	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	se establece automáticamente en función del nombre del bucket

El origen principal y cualquier origen de conmutación por error ven el mismo encabezado de host si comparten la misma configuración de routeRule o hostRewrite.

Cualquier configuración de hostRewrite se ignora cuando se usa un bucket de Cloud Storage como origen, ya que los valores de encabezado del host alternativos no son compatibles con los buckets de Cloud Storage. El encabezado del host se configura de forma automática en función del nombre del bucket.

El valor de SNI de TLS (indicación de nombre del servidor) en la solicitud (para HTTP/3, HTTP/2 y solicitudes HTTPS) se establece en el mismo valor que el encabezado del host que se envía al origen.

Si deseas obtener información sobre cómo reescribir los encabezados del host para la configuración por ruta, consulta Enrutamiento avanzado. Para obtener información sobre cómo configurar acciones de anulación por origen, consulta Ejemplo: Conmutación por error sin redireccionamiento.

Usa buckets privados de Cloud Storage

Media CDN puede extraer contenido de cualquier extremo HTTP(S) accesible a través de Internet. En algunos casos, es posible que desees solicitar autenticación para permitir solo que Media CDN extraiga contenido y evite el acceso no autorizado. Cloud Storage lo admite a través de los permisos de IAM.

Importante: Para las rutas que están asociadas a un origen privado de Cloud Storage, establece el modo de almacenamiento en caché en FORCE_CACHE_ALL. De lo contrario, se evita el almacenamiento en caché porque los buckets privados de Cloud Storage establecen un encabezado cache-control: private.

Para orígenes de Cloud Storage, puedes hacer lo siguiente:

1. Otorga a la cuenta de servicio de Media CDN el permiso objectViewer de IAM en los buckets de Cloud Storage que usas como origen.
2. Quita el permiso allUsers.
3. Quita el permiso allAuthenticatedUsers (opcional).

Para cambiar los permisos de un bucket de Cloud Storage, necesitas el rol de IAM de administrador de almacenamiento.

La cuenta de servicio de Media CDN es propiedad del proyecto de Media CDN y no aparecerá en la lista de cuentas de servicio de tu proyecto.

La cuenta de servicio tiene el siguiente formato y solo otorga acceso a los recursos de Media CDN en los proyectos que permites de forma explícita.

[e-mail]

Nota: Debes crear al menos un recurso de Media CDN para activar la creación de la cuenta de servicio. En la mayoría de los casos, este es el EdgeCacheOrigin conectado a tu bucket de Cloud Storage.

Para otorgar acceso a la CDN de Media a un bucket, puedes usar la consola de Google Cloud o la herramienta de gsutil a fin de otorgar a la cuenta de servicio al rol objectViewer:

gsutil iam ch \
serviceAccount:[e-mail]:objectViewer gs://BUCKET

Nota: Debes permitir al menos diez minutos para que la configuración se propague, antes de quitar el acceso público a un bucket de almacenamiento existente que se usa como origen de producción.

Para quitar todos los permisos de la función allUsers de un bucket determinado, ejecuta el siguiente comando:

gsutil iam ch -d allUsers gs://BUCKET

Puedes validar que el acceso público se quitó si abres una ventana del navegador de incógnito y, luego, intentas acceder a un objeto de bucket mediante https://storage.googleapis.com/BUCKET/object.ext.

Para permitir que los servicios de almacenamiento en caché perimetral accedan a un bucket de Cloud Storage de otro proyecto, puedes otorgar a la cuenta de servicio de Media CDN de ese proyecto acceso al bucket de almacenamiento.

Para ello, asegúrate de que PROJECT_NUM en [e-mail] sea el número de proyecto con los servicios de caché perimetral que necesitan acceso. Puedes repetir esto para varios proyectos, en especial si tienes varios proyectos que alojan diferentes entornos de Media CDN (desarrollo, etapa de pruebas, producción) y un proyecto independiente que contiene los elementos de video o multimedia.

Puedes proteger el acceso a tu origen de Cloud Storage sin habilitar las solicitudes firmadas para esa ruta.

Configurar Cloud Storage privado no evita que se acceda a tu contenido almacenado en caché directamente desde Media CDN. Para obtener información sobre cómo emitir solicitudes firmadas a usuarios individuales, consulta Solicitudes firmadas.

Autentica solicitudes

Si necesitas confirmar que una solicitud proviene de Media CDN, hay dos enfoques compatibles:

1. Valida que la dirección IP de conexión sea de los rangos de llenado de caché de Media CDN. Estos rangos se comparten entre todos los clientes, pero siempre los usan los servicios de almacenamiento en caché perimetral cuando se conectan a un origen.
2. Agrega un encabezado de solicitud personalizado con un valor de token que valides en el origen (por ejemplo, un valor aleatorio de 16 bytes). Tu origen puede rechazar solicitudes que no incluyen este valor.

Para obtener orientación sobre cómo configurar los encabezados de solicitud por ruta, consulta la documentación sobre encabezados personalizados.

Configura los siguientes redireccionamientos de origen

Vista previa

Este producto o función está sujeto a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones específicas del Servicio. Los productos y las funciones que se encuentran en la fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Media CDN admite los siguientes redireccionamientos que muestra tu origen de forma interna durante el llenado de caché, en lugar de mostrar respuestas de redireccionamiento directamente al cliente. Cuando Media CDN está configurada para seguir los redireccionamientos de origen, este servicio recupera el contenido de la ubicación de redireccionamiento antes de almacenar en caché y mostrar la respuesta redireccionada al cliente. Media CDN sigue los redireccionamientos en todos los dominios.

Advertencia: La configuración de redireccionamientos desde un servicio de origen no confiable o controlado por un atacante puede exponer tu configuración de Media CDN a fin de abrir vulnerabilidades de redireccionamiento.

Como práctica recomendada, configura el redireccionamiento de origen solo para orígenes que confíes y controles. Asegúrate de confiar en cada origen en una cadena de redireccionamiento, ya que cada origen produce contenido que entrega tu EdgeCacheService.

Para habilitar los siguientes redireccionamientos de origen, agrega la siguiente configuración a tu EdgeCacheOrigin:

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

Media CDN solo usa el protocolo especificado para llegar a todos los servidores especificados en los redireccionamientos. Asegúrate de que todos los servidores que Media CDN pueda redireccionarse para admitir los protocolos deseados. En particular, si el protocolo se configura en HTTPS, HTTP/2 o HTTP/3, la CDN de Media no recurre a conexiones HTTP/1.1 para seguir redireccionamientos no seguros. El encabezado del host que se envía al origen redireccionado coincide con la URL redireccionada. Media CDN sigue un solo redireccionamiento por cada intento EdgeCacheOrigin antes de mostrar la respuesta final o evaluar las condiciones de reintento o conmutación por error.

La configuración redirectConditions especifica qué códigos de respuesta HTTP hacen que Media CDN siga un redireccionamiento para cada origen.

Condición	Descripción
MOVED_PERMANENTLY	Sigue el redireccionamiento para el código de respuesta HTTP 301
FOUND	Sigue el redireccionamiento para el código de respuesta HTTP 302
SEE_OTHER	Sigue el redireccionamiento para el código de respuesta HTTP 303
TEMPORARY_REDIRECT	Sigue el redireccionamiento para el código de respuesta HTTP 307
PERMANENT_REDIRECT	Sigue el redireccionamiento para el código de respuesta HTTP 308

Conmutación por error y tiempos de espera

En las siguientes secciones, se describe cómo configurar:

• Tiempos de espera: determina cuánto tiempo espera Media CDN para conectarse a tu origen o responder a una solicitud.
• Reintentos: Determina si Media CDN reintenta una solicitud HTTP de origen a tu origen y en qué condiciones.
• Conmutación por error: determina si la CDN de medios intenta conectarse a un origen de conmutación por error si la primera no está disponible o muestra un código de estado específico.

Ajusta los tiempos de espera de origen

Los tiempos de espera te permiten activar el comportamiento de reintento y la conmutación por error, y reducen el tiempo de espera del cliente antes de activar la conmutación por error del lado del cliente.

A continuación, se describen los tiempos de espera configurables que admite Media CDN:

• connectTimeout y maxAttemptsTimeout limitan el tiempo que lleva Media CDN para encontrar una respuesta que se puede usar.

  Ambos tiempos de espera incluyen el tiempo que tarda el origen en mostrar encabezados y determinar si se debe usar una conmutación por error o un redireccionamiento. connectTimeout se aplica de forma independiente para cada intento de origen, mientras que maxAttemptsTimeout incluye el tiempo necesario para conectarse en todos los intentos de origen, incluidas las conmutaciones por error y los redireccionamientos. Seguir un redireccionamiento cuenta como un intento adicional de conexión al origen y se considera dentro del conjunto maxAttempts para el origen configurado.

  Cuando Media CDN encuentra una respuesta que no es de redireccionamiento, como la de un origen de redireccionamiento o conmutación por error, se aplican los valores readTimeout y responseTimeout. Los orígenes redireccionados usan los valores connectTimeout, readTimeout y responseTimeout configurados para el EdgeCacheOrigin que encontró el redireccionamiento.

• responseTimeout y readTimeout controlan cuánto tiempo puede tardar una respuesta transmitida. Después de que Media CDN determine que usará una respuesta ascendente, ni siquiera connectTimeout ni maxAttemptsTimeout son importantes. En este punto, readTimeout y responseTimeout entran en vigor.

Media CDN realiza como máximo cuatro intentos de origen en todos los orígenes, sin importar el maxAttempts establecido por cada EdgeCacheOrigin. Media CDN usa el valor maxAttemptsTimeout del EdgeCacheOrigin principal. Los valores de tiempo de espera por intento (connectTimeout, readTimeout y responseTimeout) se configuran para el EdgeCacheOrigin de cada intento.

En la siguiente tabla, se describen los campos de tiempo de espera:

Campo	Predeterminada	Descripción
connectTimeout	5 segundos	El tiempo máximo que puede tomar Media CDN desde el inicio de la solicitud hasta el origen hasta que se determine si la respuesta se puede usar. En la práctica, connectTimeout abarca el tiempo que comienza con la creación de la solicitud y, luego, la búsqueda de DNS y el protocolo de enlace TLS, el establecimiento de la conexión TCP/QUIC, mediante la obtención de los encabezados de respuesta que contienen el código de estado HTTP. El tiempo de espera debe ser un valor entre 1 segundo y 15 segundos.
maxAttemptsTimeout	15 segundos	El tiempo máximo de todos los intentos de conexión al origen, incluidos los orígenes de conmutación por error, antes de mostrar un error al cliente. Se muestra un HTTP 504 si se alcanza el tiempo de espera antes de que se muestre una respuesta. El tiempo de espera debe ser un valor entre 1 segundo y 30 segundos. Esta configuración define la duración total de todos los intentos de conexión de origen, incluidos los orígenes de conmutación por error, para limitar el tiempo total que los clientes deben esperar para que se muestre el contenido. comenzar a transmitir. Solo se usa el primer valor maxAttemptsTimeout, en el que el primer se define por el origen configurado para la ruta determinada.
readTimeout	15 segundos	La duración máxima a esperar entre lecturas de una sola respuesta HTTP. El readTimeout está limitado por responseTimeout. Todas las lecturas de la respuesta HTTP deben completarse antes de la fecha límite establecida por el responseTimeout. El tiempo de espera debe ser un valor entre 1 segundo y 30 segundos. Si se alcanza este tiempo de espera antes de que se complete la respuesta, la respuesta se trunca y se registra.
responseTimeout	30 segundos	La duración máxima que permite que se complete una respuesta. El tiempo de espera debe ser un valor entre 1 segundo y 120 segundos. La duración se mide desde el momento en que se reciben los primeros bytes de cuerpo. Si se alcanza este tiempo de espera antes de que se complete la respuesta, la respuesta se trunca y se registra.

Considera los siguientes ejemplos:

• El origen A coincide con las solicitudes a “/segments/” y tiene un maxAttemptsTimeout de 5 segundos, un maxAttempts de 1 y un failover_origin configurado como el origen B. El valor predeterminado de connectTimeout es de 5 segundos. Si intentas conectarte al origen A y falla en 1 segundo debido a un certificado TLS no válido, te quedan unos 4 segundos para realizar una conexión exitosa con el origen B.

• El origen C hace coincidir las solicitudes con “/manifests/*” y tiene un maxAttemptsTimeout de 10 segundos, un maxAttempts de 3 y ningún failover_origin configurado. El valor predeterminado de connectTimeout es de 5 segundos. Media CDN intenta conectarse al origen C hasta tres veces, lo que permite hasta 10 segundos (el maxAttemptsTimeout) para establecer una conexión exitosa.

Reintenta las solicitudes de origen

Media CDN admite reintentos de origen, lo que permite que se vuelvan a realizar solicitudes al origen. Puedes especificar cuántas veces se debe reintentar el origen actual antes de que se intente realizar un origen de conmutación por error (si está configurado).

• Media CDN intenta alcanzar el origen principal hasta el valor maxAttempts configurado, que se establece de forma predeterminada en uno.
• Media CDN reintenta las conexiones de origen hasta un máximo de tres veces antes de fallar y muestra un error de tiempo de espera al usuario. Esto incluye las conexiones de origen de la conmutación por error, que se consideran en el límite de tres.
• Cuando configuras un recurso de origen, puedes configurar un origen principal mediante el campo originAddress y, luego, un failoverOrigin opcional. El failoverOrigin apunta a otro recurso de origen.

El retryConditions para cada origen especifica qué tipos de fallas activan un reintento:

Condición	Predeterminado	Descripción
CONNECT_FAILURE	✔️	Los reintentos en caso de fallas incluyen errores de enrutamiento, DNS y TLS, así como tiempos de espera de TCP/UDP.
HTTP_5XX		Vuelve a intentarlo en cualquier código de respuesta HTTP 5xx.
GATEWAY_ERROR		Similar a 5xx, pero solo se aplica a los códigos de respuesta 502, 503 o 504.
RETRIABLE_4XX		Vuelve a intentarlo para los códigos de respuesta 4xx recuperables, incluidos 409 y 429.
NOT_FOUND		Vuelve a intentarlo en un HTTP 404.
FORBIDDEN		Vuelve a intentarlo en un HTTP 403.

Si necesitas verificaciones de estado activas, round robin o dirección de reconocimiento de carga en los orígenes, puedes configurar un balanceador de cargas de HTTP(S) externo como el origen principal.

Comportamiento de la conmutación por error

En la siguiente tabla, se describe cómo funciona la conmutación por error y qué respuesta observaría un cliente:

Situación	Conmutación por error configurada	Estado para el usuario
Media CDN intenta conectarse a tu origen y no recibe respuesta HTTP después de dos intentos (predeterminado).	No	HTTP 502 (Puerta de enlace incorrecta)
Media CDN intenta conectarse a tu origen principal y no puede conectarse (error de protocolo de enlace TLS). Se realiza un intento en el origen de conmutación por error configurado, que muestra un HTTP 404.	Sí	HTTP 404 (No encontrado)
Media CDN intenta conectarse al origen principal y a la conmutación por error, pero no recibe código de estado HTTP.	Sí	HTTP 502 (Puerta de enlace incorrecta)

Media CDN muestra un código de estado HTTP 502 (Puerta de enlace incorrecta) si todas las conexiones de origen fallan.

Si Media CDN recibe un código de estado, como HTTP 404 (No encontrado) o HTTP 429 (Demasiadas solicitudes), pero las solicitudes posteriores fallan, el último código de estado observado se muestra al cliente.

Ejemplo: Conmutación por error sin redireccionamiento

Vista previa

Este producto o función está sujeto a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones específicas del Servicio. Los productos y las funciones que se encuentran en la fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

La siguiente es una configuración básica de conmutación por error EdgeCacheOrigin:

  name: FAILOVER_ORIGIN
  originAddress: FAILOVER_DOMAIN_NAME

Media CDN vuelve a intentar el origen principal de la ruta un máximo de tres veces antes de intentar un origen de conmutación por error. En esta configuración, después de probar el origen principal tres veces, Media CDN intenta realizar una sola solicitud con el FAILOVER_ORIGIN. Si el origen de la conmutación por error tampoco responde correctamente, Media CDN muestra el último código de estado recibido o, si no se recibe ningún código de estado, una respuesta HTTP 502 (puerta de enlace incorrecta).

La latencia de llenado de caché aumenta con la cantidad de reintentos y eventos de conmutación por error. Aumentar los valores de tiempo de espera de origen (como connectTimeout) afecta aún más la latencia de llenado de caché, ya que aumenta el tiempo de espera de que responda un servidor de origen sobrecargado o ocupado.

En el ejemplo siguiente, se muestra una configuración que envía solicitudes de relleno a MY_ORIGIN. La configuración hace que Media CDN vuelva a intentar los errores de conexión (como los errores de DNS, TCP o TLS), HTTP 5xx de origen o HTTP 404. Después de dos intentos, la conmutación por error pasa a FAILOVER_ORIGIN.

Se realiza un máximo de cuatro intentos en todos los orígenes configurados: el intento original más hasta tres intentos de reintento. Puedes configurar un maxAttempts por origen para determinar cuántos reintentos se realizan antes de intentar la conmutación por error.

  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

Si tu origen requiere una reescritura del host específica de origen o alguna otra modificación de encabezado específico del origen, usa el siguiente ejemplo de configuración originOverrideAction para configurarlos:

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

A continuación, se muestra una configuración completa:

  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

En el ejemplo anterior, la configuración de originOverrideAction.hostRewrite tiene prioridad sobre cualquier reescritura de encabezado existente configurada en rutas que apuntan a este origen.

Puedes usar encabezados requestHeadersToAdd únicos por origen que solicite ese origen en particular. Un caso práctico común agrega encabezados Authorization estáticos. Debido a que estas manipulaciones de encabezados se ejecutan durante la solicitud de origen, los encabezados agregados por origen reemplazan o agregan a los encabezados existentes del mismo nombre de campo. De forma predeterminada, Media CDN adjunta a los encabezados existentes. Para reemplazar encabezados existentes, configura headerAction.replace en true.

Ejemplo: Conmutación por error con redireccionamiento a continuación

Vista previa

Este producto o función está sujeto a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones específicas del Servicio. Los productos y las funciones que se encuentran en la fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Por ejemplo, supongamos que configuraste los siguientes recursos EdgeCacheOrigin y que las rutas de tus recursos EdgeCacheService están configuradas a fin de usar PrimaryOrigin para el llenado de caché:

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]

En este ejemplo, cuando Media CDN realiza un llenado de caché, lee la configuración de PrimaryOrigin y responde según corresponda.

Supongamos que Media CDN se conecta a primary.example.com como el intento #1 para contactar al origen. Si primary.example.com muestra una respuesta correcta, Media CDN usa esa respuesta para el llenado de caché.

Supongamos que primary.example.com muestra un redireccionamiento HTTP 302 en Location: b.example.com. Luego, como el intento #2 para comunicarte con el origen, Media CDN sigue el redireccionamiento a b.example.com. En este caso, Media CDN hace lo siguiente:

• Si b.example.com muestra una respuesta correcta, Media CDN usa esa respuesta para el llenado de caché.
• Si b.example.com muestra un redireccionamiento o una respuesta de falla, Media CDN conmuta por error al SecondaryOrigin configurado. Esto se debe a que, en este ejemplo, PrimaryOrigin está configurado para dos maxAttempts.

Si Media CDN conmuta por error a SecondaryOrigin, Media CDN usa la configuración SecondaryOrigin y, luego, intenta conectarse a secondary.example.com. Este es el intento #1 para comunicarse con el origen y el intento #3 en general.

En este caso, Media CDN hace lo siguiente:

• Si secondary.example.com muestra una respuesta correcta, Media CDN usa esa respuesta para el llenado de caché.
• Si secondary.example.com muestra un redireccionamiento HTTP 302 En Location: c.example.com, Media CDN intenta comunicarse con c.example.com. En este ejemplo, este es el intento #2 para SecondaryOrigin y el intento #4 en general.

Si el intento de contactar a c.example.com muestra una respuesta correcta, Media CDN usa esa respuesta para el llenado de caché. Si el intento muestra un redireccionamiento que la CDN de medios está configurada para seguir, Media CDN muestra un error 502 de puerta de enlace incorrecta porque se agotó el máximo de intentos de comunicarse con un origen. Media CDN realiza como máximo cuatro intentos en todos los orígenes, sin importar la configuración EdgeCacheOrigin. Por último, si Media CDN no puede comunicarse con c.example.com, Media CDN muestra un tiempo de espera de la puerta de enlace 504 o una respuesta 502 Puerta de enlace incorrecta.

Si necesitas verificaciones de estado, round robin o dirección de reconocimiento de carga en los orígenes, puedes configurar un balanceador de cargas de HTTP(S) externo como origen principal.

Configura los orígenes

En las siguientes secciones, se proporcionan ejemplos sobre cómo configurar tipos de orígenes comunes, incluidos los buckets de Cloud Storage y los orígenes externos del balanceador de cargas de HTTP(S).

Integración en Cloud Storage

Media CDN admite buckets de Cloud Storage como backends para contenido. Cada servicio puede hacer referencia a varios buckets mediante la configuración de rutas para el host, las rutas de acceso y otros atributos de la solicitud.

Los buckets de Cloud Storage se configuran con la URL del bucket, como gs://my-bucket, como la dirección de origen cuando se crea un recurso de origen.

Consola

1. En la consola de Google Cloud, ve a la página Orígenes de Media CDN.

   Ir a los orígenes de Media CDN

2. Haz clic en Crear origen.

3. Ingresa un nombre para el origen. Por ejemplo: cloud-storage-origin.

4. Ingresa una descripción opcional para el origen.

5. En Dirección de origen, selecciona Seleccionar un bucket de Google Cloud Storage.

6. Navega a tu bucket de Cloud Storage.

7. Para Cloud Storage, conserva la configuración de puerto y protocolo predeterminada.

8. Selecciona un origen de conmutación por error en caso de que no se pueda acceder a este (opcional). Puedes actualizar este campo más adelante.

9. Selecciona reintentar las condiciones.

10. En Cantidad máxima de intentos, selecciona una cantidad máxima de intentos para llenar la caché desde este origen.

11. Ajusta los tiempos de espera (opcional):

    1. En Tiempo de espera de Connect, selecciona la duración máxima a fin de esperar que se establezca la conexión de origen.
    2. En Tiempo de espera de la respuesta, selecciona la duración máxima para permitir que se complete una respuesta.
    3. En Tiempo de espera de lectura, selecciona la duración máxima para esperar entre las lecturas de una sola conexión HTTP o transmisión.

12. (Opcional) Ingresa una o más etiquetas para este origen.

13. Haz clic en Crear origen.

gcloud

Usa el comando gcloud edge-cache origins create:

gcloud edge-cache origins create cloud-storage-origin --origin-address="gs://my-bucket"

Create request issued for: [cloud-storage-origin]


originAddress: "gs://my-bucket"

Esto es lo mismo si el bucket es multirregional, birregional o regional.

Cuando configuras un servicio, puedes enrutar tu contenido de video on demand a un bucket y transmitir contenido en vivo a un segundo bucket, lo que es útil si tienes equipos diferentes que administran cada flujo de trabajo. Del mismo modo, puedes enrutar eu-media.example.com a un bucket de Cloud Storage multirregional ubicado en la UE para reducir la latencia de llenado de caché y us-media.example.com (o hacer coincidir la ruta, el encabezado o el encabezado) ) a un bucket de almacenamiento ubicado en EE.UU.

Importante: Recomendamos usar un bucket multirregión para el almacenamiento de origen, que proporciona mayor redundancia geográfica para objetos almacenados.

Buckets de Media CDN (haz clic para ampliar)

Para los casos en los que la latencia de escritura es crítica, como la transmisión en vivo de latencia baja, puedes configurar un extremo regional de Cloud Storage lo más cerca posible de tus usuarios.

Usa un balanceador de cargas de HTTP(S) externo como origen

Si necesitas una verificación de estado activa, un round robin o una dirección que tome en cuenta la carga en Compute Engine, GKE o en los orígenes locales, puedes hacer lo siguiente:Configura un balanceador de cargas de HTTP(S) externo como origen.

Esto te permite configurar (por ejemplo, tus paquetes de transmisión en vivo detrás de Media CDN o un grupo de proxies de Envoy administrados por Traffic Director) para volver a conectarse a las instalaciones locales infraestructura.

Los balanceadores de cargas te permiten configurar backends para lo siguiente:

• Grupos de instancias de VM de Compute Engine.
• Grupos de extremos de red (incluidas las VM de Compute Engine y los clústeres de Google Kubernetes Engine).
• Grupos de extremos de red sin servidores (Cloud Run, App Engine y Cloud Functions).

Una arquitectura que combina un origen de balanceador de cargas de HTTP(S) externo a fin de entregar manifiestos de video y un origen de Cloud Storage para el almacenamiento de segmentos sería similar al siguiente, con dos orígenes asignados a diferentes rutas.

Implementación de almacenamiento en caché perimetral (haz clic para ampliar)

Para configurar un balanceador de cargas de HTTP(S) externo como origen, debes crear un recurso de origen con la dirección IP o el nombre de host público que apunte a tulas reglas de reenvío del balanceador de cargas. Se prefiere un nombre de host público (nombre de dominio), ya que esto es necesario para un certificado SSL (TLS) y para versiones HTTP modernas (HTTP/2 y HTTP/3).

También debes asegurarte de lo siguiente:

• El balanceador de cargas tiene una ruta que coincide con el nombre de host que se usa para el servicio de almacenamiento en caché perimetral.
• (o) configuraste un urlRewrite.hostRewrite para las rutas en las que el balanceador de cargas está configurado como el origen.
• Que tu balanceador de cargas tenga un certificado SSL (TLS) de confianza pública configurado para estos nombres de host.

Por ejemplo, si el nombre de dominio público que apunta a la regla de reenvío de tu balanceador de cargas es origin-packager.example.com, deberías crear un origen con el originAddress configurado como este:

Consola

1. Ve a la página Media CDN en la consola de Google Cloud.
   Ir a Media CDN
2. Haz clic en la pestaña Orígenes.
3. Haz clic en Crear origen.
4. Ingresa un nombre para el origen. Por ejemplo: load-balancer-origin.
5. Ingresa una descripción opcional para el origen.
6. En Dirección de origen, selecciona Especificar un FQDN o una dirección IP.
7. Ingresa el FQDN o la dirección IP para tu balanceador de cargas de Google Cloud.
8. Selecciona un protocolo y un puerto para que Media CDN se conecte a tu origen.
9. Selecciona un origen de conmutación por error en caso de que no se pueda acceder a este (opcional). Puedes actualizar este campo más adelante.
10. Selecciona reintentar las condiciones.
11. En Cantidad máxima de intentos, selecciona una cantidad máxima de intentos para llenar la caché desde este origen.
12. (Opcional) Ajusta los tiempos de espera:
    1. En Tiempo de espera de Connect, selecciona la duración máxima a fin de esperar que se establezca la conexión de origen.
    2. En Tiempo de espera de respuesta, selecciona la duración máxima para permitir que se complete una respuesta.
    3. En Tiempo de espera de lectura, selecciona la duración máxima para esperar entre las lecturas de una sola conexión HTTP o transmisión.
13. (Opcional) Ingresa una o más etiquetas para este origen.
14. Haz clic en Crear origen.

gcloud

Usa el comando gcloud edge-cache origins:

gcloud edge-cache origins create lb-origin --origin-address="origin-packager.example.com"

Create request issued for: [lb-origin]


originAddress: "origin-packager.example.com"

Si usas la dirección IP de la regla de reenvío como dirección de origen o no tienes un certificado SSL adjunto al balanceador de cargas, puedes configurar el protocolo como HTTP para volver a no estar encriptado. Solo recomendamos que lo hagas para fines de desarrollo o prueba.

Configura el protocolo de origen

Para orígenes que solo admiten HTTPS (HTTP/1.1 a través de TLS) o HTTP/1.1 (sin TLS), configura el campo protocol de manera explícita mediante los siguientes pasos:

Consola

1. Ve a la página Media CDN en la consola de Google Cloud.
   Ir a Media CDN
2. Haz clic en la pestaña Orígenes.
3. Selecciona tu origen y haz clic en Editar.
4. En el protocolo, selecciona HTTPS o HTTP.
5. Si seleccionaste HTTP, selecciona el puerto 80.
6. Haz clic en Actualizar origen.

gcloud

Usa el comando gcloud edge-cache origins:

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

El comando actualiza el origen y muestra lo siguiente:

Update request issued for: [LEGACY_ORIGIN]
protocol: HTTPS

Si tu origen admite HTTP/2, no necesitas configurar el protocolo explícitamente.

Soluciona problemas de conectividad

Si recibes errores HTTP 50x, como HTTP 502 (tiempo de espera de puerta de enlace) o HTTP 500 (error interno del servidor), considera lo siguiente:

• Prueba que el nombre de host de origen se pueda resolver con el DNS público de Google y que las direcciones IP resueltas coincidan con las expectativas. Si cambiaste recientemente tus registros DNS, es posible que los agentes de resolución aún tengan la dirección anterior en sus memorias caché.

• Si tu origen solo admite HTTP/1.1 y no admite HTTP/2, configura el campo protocol en el origen para usar HTTP o HTTPS. en lugar de HTTP2. La CDN de medios no recurre a conexiones HTTP/1.1, a menos que se especifique lo contrario.

• Comprueba que los registros de solicitud en Cloud Logging contengan la dirección IP de origen correcta.

• Comprueba que el origen tenga un certificado SSL (TLS) público y sin vencer (TLS).

• Los avances HTTP/2 no son compatibles, y las solicitudes a un servidor de origen no incluyen el encabezado de solicitud "TE". Los avances incluidos en una respuesta no se almacenan en caché ni se muestran al cliente.

Soluciona problemas de la conmutación por error de origen

Si una conmutación por error de origen no se comporta como se esperaba, considera lo siguiente:

• Asegúrate de que la reescritura del encabezado de host adecuado esté configurada en tu origen de conmutación por error.

• Asegúrate de que el origen principal esté configurado con suficientes maxAttemptsTimeout, maxAttempts y timeouts para adaptarse a los redireccionamientos y las conmutaciones por error de origen. Los redireccionamientos de origen cuentan como intentos de conexión independientes en la configuración maxAttempts.

¿Qué sigue?

• Usa un bucket privado compatible con s3 como origen
• Dirige el tráfico a orígenes y configuraciones perimetrales específicas