Prácticas recomendadas de Cloud Interconnect

Sigue estas prácticas recomendadas al planificar y configurar Cloud Interconnect.

Trabajar con Google Cloud proyectos

Si tu arquitectura de red lo permite, configura tus proyectos de Cloud Interconnect como se recomienda en esta sección.

Aprovisionar conexiones físicas de Cloud Interconnect en un proyecto independiente

Aprovisionar conexiones físicas (puertos) para Cloud Interconnect en un proyecto, pero aprovisionar vinculaciones de VLAN en otros proyectos. Los demás proyectos deben estar en la misma Google Cloud organización que el proyecto que contiene las conexiones físicas.

Las vinculaciones de VLAN que conectan una conexión física a una región a través de un router de Cloud no tienen por qué estar en el mismo proyecto que la conexión física. Para obtener más información, consulta Usar conexiones en otros proyectos.

Esta práctica facilita los siguientes pasos de configuración:

  • Puedes asociar una cuenta de facturación interna independiente al proyecto que contenga las conexiones físicas.
  • Puedes configurar roles y permisos de Gestión de Identidades y Accesos (IAM) en el proyecto que contiene las conexiones físicas.
  • Si quieres eliminar o actualizar un recurso que no sea una conexión física, puedes hacerlo sin que afecte a las conexiones físicas.

Configurar vinculaciones de VLAN en el proyecto host de la VPC compartida

En una red de VPC compartida, configura todas las vinculaciones de VLAN, no las conexiones físicas de Cloud Interconnect (puertos), en el proyecto host. Para obtener más información sobre cómo conectar adjuntos a redes de VPC compartidas, consulta Opciones para conectarse a varias redes de VPC.

Crear conexiones redundantes de Cloud Interconnect con capacidad suficiente

En esta sección se describen las prácticas recomendadas para crear conexiones de Cloud Interconnect redundantes que tengan suficiente capacidad en un escenario de conmutación por error. Si sigues estas prácticas, te asegurarás de que eventos como el mantenimiento programado o los fallos de hardware no provoquen tiempos de inactividad.

Las conexiones de Cloud Interconnect protegen hasta el 50% del tráfico de red en la capacidad agregada cuando la capacidad se divide de forma equitativa entre los dominios de disponibilidad de los extremos. De esta forma, se asegura que haya capacidad suficiente en caso de fallo o mantenimiento programado. Si se usa más del 50% de la capacidad de Cloud Interconnect, la conexión puede estar sujeta a limitación durante los periodos de congestión de la red. Por ejemplo, si tienes previsto enviar 100 Gbps de tráfico protegido entre tu red local y Google Cloud, asegúrate de aprovisionar conexiones de Cloud Interconnect redundantes con una capacidad de al menos 200 Gbps.

Puedes crear conexiones de Cloud Interconnect según una de estas topologías recomendadas:

Cuando creas conexiones de Cloud Interconnect según estas topologías, creas pares de conexiones en una o varias áreas metropolitanas. En una misma área metropolitana, puedes colocar conexiones de Cloud Interconnect en diferentes dominios de disponibilidad de periferia.

Te recomendamos que crees conexiones redundantes mediante grupos de conexiones. Para obtener más información, consulta Opciones de resiliencia y SLA.

Asegurar que haya suficiente capacidad en cada dominio de disponibilidad perimetral

Si hay un tiempo de inactividad o mantenimiento en uno de los dominios de disponibilidad de la periferia de un área metropolitana, el tráfico se transfiere al otro dominio de disponibilidad de la periferia.

Para evitar la pérdida de paquetes si falla un solo dominio de disponibilidad de perímetro, sigue estas instrucciones:

Tipo de capacidad Asesoramiento
Capacidad de conexión de Cloud Interconnect Asegúrate de que cada dominio de disponibilidad de edge tenga suficiente capacidad de conexión para gestionar todo el tráfico de producción.
Capacidad de vinculación de VLAN

Asegúrate de que cada dominio de disponibilidad de periferia tenga suficiente capacidad de vinculación de VLAN para gestionar todo el tráfico de producción de la red de VPC de destino.

El tráfico de VPC en las conexiones de Cloud Interconnect se transmite a través de vinculaciones de VLAN, que vinculan la conexión a redes de VPC. Aunque cada dominio de disponibilidad de periferia tenga suficiente capacidad de conexión, también debe tener suficiente capacidad de vinculación de VLAN.

Capacidad de vinculación de VLAN y varias redes de VPC

Si usas tus conexiones de Cloud Interconnect para acceder a más de una red de nube privada virtual (VPC), crea vinculaciones de VLAN desde cada red de VPC a cada conexión de Cloud Interconnect. En cada red de VPC, asegúrate de que haya suficiente capacidad de vinculación de VLAN para gestionar todo el tráfico de producción de esa red de VPC si se produce una conmutación por error.

Supongamos que tienes las siguientes redes de VPC y cargas de trabajo:

  • vpc-1 recibe 2 Gbps de tráfico total de tu red local.
  • vpc-2 también recibe 2 Gbps de tráfico total de tu red local.

En la siguiente tabla se describe la cantidad mínima de capacidad de vinculación que necesitas en cada dominio de disponibilidad de borde para cada red de VPC:

Dominio de disponibilidad de Edge Capacidad de conexión Capacidad de los archivos adjuntos
EDGE_DOMAIN_1 1 x 10 Gbps 2 x 1 Gbps a vpc-1
2 x 1 Gbps a vpc-2
EDGE_DOMAIN_2 1 x 10 Gbps 2 x 1 Gbps a vpc-1
2 x 1 Gbps a vpc-2

Cuando añades vinculaciones de VLAN a través de una conexión de Cloud Interconnect, la capacidad configurada de la vinculación puede superar la capacidad total de la conexión. Aunque esta configuración es válida, el tráfico real no puede superar la capacidad total de la conexión. Asegúrate de que tu carga de trabajo no genere más tráfico que la capacidad de la conexión.

Usar vinculaciones de VLAN activo-activo

Hay dos formas de configurar vinculaciones de VLAN redundantes:

  • Una configuración activo-activo que divide el tráfico entre las vinculaciones de VLAN.
  • Una configuración activo-pasivo que usa solo una vinculación de VLAN a la vez.

Te recomendamos que uses una configuración activo-activo, ya que así podrás determinar fácilmente si todas las vinculaciones de VLAN funcionan correctamente durante el funcionamiento normal. Cuando uses una configuración activa-activa, monitoriza tus patrones de uso para asegurarte de que tienes suficiente capacidad si se produce un fallo.

En una configuración activa/pasiva, es posible que las vinculaciones de VLAN se configuren incorrectamente sin que te des cuenta. Si utilizas esta configuración, asegúrate de probar la conmutación por error antes de añadir tráfico de producción.

Información sobre la conmutación por error entre regiones

El tráfico de red que sale de una región prefiere usar la ruta con la métrica más baja, tal como se describe en la sección Efectos del modo de enrutamiento dinámico de la descripción general de Cloud Router. En un uso habitual, esto significa que el tráfico de salida se envía a través de la región Google Cloud más cercana que tenga vinculaciones de VLAN activas, siendo la región local la más cercana.

Imagina que creas la topología para aplicaciones de nivel de producción y tienes una red de VPC con lo siguiente:

  • Vinculaciones de VLAN en dos regiones
  • Enrutamiento dinámico global habilitado

El tráfico prefiere salir de las vinculaciones de VLAN de la región local, aunque las vinculaciones de esa región estén sobrecargadas. El tráfico solo se dirige a la otra región si todas las vinculaciones de VLAN de la región local están inoperativas. Esto significa que cada una de las cuatro conexiones de Cloud Interconnect de la topología debe tener suficiente capacidad de vinculación de VLAN para transportar todo el tráfico de producción.

Situaciones

En esta sección se describen los escenarios en los que se configuran recursos de Cloud Interconnect. También se describe cómo gestiona cada configuración tu carga de trabajo durante el funcionamiento normal y la conmutación por error. Cada situación incluye una recomendación relacionada con las prácticas recomendadas de redundancia y capacidad.

Situación 1: Capacidad suficiente

En este caso, aprovisionas dos conexiones de interconexión dedicada en dos dominios de disponibilidad de borde diferentes, tal como se muestra en la siguiente tabla:

Dominio de disponibilidad de Edge Capacidad de conexión Capacidad de los archivos adjuntos Región de los archivos adjuntos
EDGE_DOMAIN_1 1 x 10 Gbps 1 x 10 Gbps ATTACHMENT_REGION_1
EDGE_DOMAIN_2 1 x 10 Gbps 1 x 10 Gbps ATTACHMENT_REGION_1

En la siguiente tabla se describe cómo gestiona esta configuración tu carga de trabajo durante el funcionamiento normal y la conmutación por error:

Recurso Descripción
Tamaño de la carga de trabajo 10 Gbps de tráfico total entre ATTACHMENT_REGION_1 y tu red local.
Capacidad durante el funcionamiento normal

Capacidad suficiente

20 Gbps de capacidad desde ATTACHMENT_REGION_1 hasta tu red local. Tu carga de trabajo de 10 Gbps se ejecuta correctamente.
Capacidad durante la conmutación por error

Capacidad suficiente si falla alguna de las conexiones de Cloud Interconnect.

Por ejemplo, si falla la conexión en EDGE_DOMAIN_1, la capacidad disponible es la conexión en EDGE_DOMAIN_2. Esta conexión de Cloud Interconnect tiene una capacidad de 10 Gbps. Los 10 Gbps de capacidad de vinculación que has creado en ella son suficientes para gestionar tu carga de trabajo de producción.

Si tu carga de trabajo aumenta a más de 10 Gbps de tráfico, superará la capacidad de tu vinculación y es posible que se produzca una pérdida de paquetes.
Recomendación Aprovisiona la capacidad de tu conexión de Cloud Interconnect y de tu vinculación de VLAN para que cada dominio de disponibilidad de borde tenga capacidad suficiente para toda tu carga de trabajo de producción.

Situación 2: Capacidad insuficiente durante la conmutación por error

En este caso, aprovisionas dos conexiones de interconexión dedicada en dos dominios de disponibilidad de borde diferentes, tal como se muestra en la siguiente tabla:

Dominio de disponibilidad de Edge Capacidad de conexión Capacidad de los archivos adjuntos Región de los archivos adjuntos
EDGE_DOMAIN_1 1 x 100 Gbps 100 Gbps (2 x 50 Gbps) ATTACHMENT_REGION_1
EDGE_DOMAIN_2 1 x 100 Gbps 100 Gbps (2 x 50 Gbps) ATTACHMENT_REGION_1

En la siguiente tabla se describe cómo gestiona esta configuración tu carga de trabajo durante el funcionamiento normal y la conmutación por error:

Recurso Descripción
Tamaño de la carga de trabajo 150 Gbps de tráfico total entre ATTACHMENT_REGION_1 y tu red on-premise.
Capacidad durante el funcionamiento normal

Capacidad suficiente

200 Gbps de capacidad desde ATTACHMENT_REGION_1 hasta tu red local. Tu carga de trabajo de 150 Gbps se ejecuta correctamente.
Capacidad durante la conmutación por error

Capacidad insuficiente si se interrumpe alguna de las conexiones de Cloud Interconnect.

Si una de tus conexiones de Cloud Interconnect deja de funcionar por mantenimiento, toda tu carga de trabajo de 150 Gbps intentará conmutar por error a una sola conexión de 100 Gbps. Esto supera la capacidad de la conexión, por lo que se produce congestión y pérdida de paquetes.
Recomendación Para asegurar la disponibilidad total durante un evento de fallo, asegúrese de que el tráfico combinado de cada conexión no supere la capacidad total de un solo dominio de disponibilidad de edge. En este caso, necesitas al menos 200 Gbps de capacidad de conexión y 3 x 50 Gbps de capacidad de vinculación en cada dominio de disponibilidad de borde para tener suficiente capacidad durante la conmutación por error.

Situación 3: Vinculaciones de VLAN desequilibradas

En este caso, aprovisionas dos conexiones de interconexión dedicada en dos dominios de disponibilidad de borde diferentes, como se muestra en la siguiente tabla. Inicialmente, aprovisionas 1 x 10 Gbps de capacidad de vinculación en EDGE_DOMAIN_1. Más adelante, te das cuenta de que tu carga de trabajo ha aumentado a 20 Gbps, por lo que actualizas solo la capacidad de la vinculación en EDGE_DOMAIN_1 a 2 x 10 Gbps.

Dominio de disponibilidad de Edge Capacidad de conexión Capacidad de los archivos adjuntos Región de los archivos adjuntos
EDGE_DOMAIN_1 1 x 100 Gbps 1 x 10 Gbps (provisionado inicialmente)
2 x 10 Gbps (actualizado más adelante)		 ATTACHMENT_REGION_1
EDGE_DOMAIN_2 1 x 100 Gbps 1 x 10 Gbps ATTACHMENT_REGION_1

En la siguiente tabla se describe cómo gestiona esta configuración tu carga de trabajo durante el funcionamiento normal y la conmutación por error:

Recurso Descripción
Tamaño de la carga de trabajo 20 Gbps de tráfico total entre ATTACHMENT_REGION_1 y tu red on-premise.
Capacidad durante el funcionamiento normal

Capacidad suficiente

30 Gbps de capacidad desde ATTACHMENT_REGION_1 hasta tu red local. Tu carga de trabajo de 20 Gbps se ejecuta correctamente.
Capacidad durante la conmutación por error

Capacidad suficiente si la conexión de Cloud Interconnect de EDGE_DOMAIN_2 deja de funcionar.
Capacidad insuficiente si la conexión de Cloud Interconnect de EDGE_DOMAIN_1 deja de funcionar.

Si tu conexión de Cloud Interconnect en EDGE_DOMAIN_2 falla, seguirás teniendo 20 Gbps de capacidad de vinculación de la conexión restante y tu carga de trabajo se ejecutará correctamente.

Sin embargo, si tu conexión de Cloud Interconnect en EDGE_DOMAIN_1 se interrumpe, solo habrá 10 Gbps de capacidad de vinculación de la conexión restante, por lo que experimentarás congestión y pérdida de paquetes.
Recomendación Asegúrate de que tienes la misma capacidad en ambos dominios de disponibilidad perimetral de un área metropolitana. Esto se aplica tanto a las conexiones de Cloud Interconnect como a las vinculaciones de VLAN. En este caso, necesitas al menos 2 conexiones de 10 Gbps de capacidad de vinculación en cada dominio de disponibilidad de borde para asegurarte de que haya suficiente capacidad si falla alguna de las conexiones de Cloud Interconnect.

Usar el mismo MTU para todas las vinculaciones de VLAN

Le recomendamos que utilice el mismo MTU para todas las vinculaciones de VLAN que estén conectadas a la misma red de VPC y que defina el MTU de la red de VPC con el mismo valor. Aunque es la práctica recomendada, no es obligatorio que los MTUs de las vinculaciones de VLAN y los de las redes de VPC coincidan. Sin embargo, puedes experimentar pérdidas de paquetes, especialmente en protocolos distintos de TCP, si haces lo siguiente:

  • Usa MTUs de vinculación de VLAN diferentes para las vinculaciones de VLAN conectadas a la misma red de VPC.
  • Configura MTUs de vinculación de VLAN que sean inferiores al MTU de la red de VPC que contenga las vinculaciones de VLAN.

Para obtener información general sobre cómo gestionan los protocolos las MTUs que no coinciden, consulta MTUs que no coinciden, ajuste de MSS y descubrimiento de MTU de ruta en la documentación sobre MTU de VPC.

Los paquetes enviados a través de una vinculación de VLAN se procesan de la siguiente manera:

Situación Comportamiento
Paquetes SYN y SYN-ACK de TCP Google Cloud realiza el ajuste de MSS, cambiando el MSS para que los paquetes se ajusten a la MTU de la vinculación de VLAN. Por ejemplo, si la MTU de la vinculación de VLAN es de 1500 bytes, el ajuste de MSS usa un tamaño máximo de segmento de 1460 bytes.
Paquetes IP de hasta la MTU de la vinculación de VLAN (incluida) Google Cloud no hace ningún cambio en el paquete, excepto en los paquetes SYN y SYN-ACK, como se ha explicado en la primera fila.
Comprobaciones de MTU para paquetes IP
  • La MTU de los paquetes enviados por los recursos a través de una vinculación de VLAN está limitada por la MTU de la vinculación de VLAN. Google Cloud Por ejemplo, cuando una instancia de VM envía paquetes a un destino al que se puede acceder mediante una ruta dinámica cuyo siguiente salto es una vinculación de VLAN, los paquetes que superen la MTU de la vinculación de VLAN se descartarán:
    • Google Cloud elimina el paquete y envía un mensaje de Fragmentation Needed (ICMP sobre IPv4) o Packet Too Big (ICMPv6) cuando el bit Don't Fragment (DF) está activado y también cuando está desactivado.
    • Debes configurar las reglas de cortafuegos de VPC de entrada permitidas o las reglas de las políticas de cortafuegos de forma que se permita ICMP (para IPv4) o ICMPv6 (para IPv6) desde las fuentes que coincidan con los destinos de los paquetes originales.
    • Las reglas de reenvío de los balanceadores de carga de red internos de tipo pasarela y del reenvío de protocolos internos deben usar el protocolo L3_DEFAULT para que procesen tanto ICMP para la detección de MTU de ruta (PMTUD) como el protocolo usado por el paquete original.
  • Cloud Interconnect no aplica el MTU de la vinculación de VLAN a los paquetes recibidos de una red on-premise. En su lugar, Google Cloud aplica el MTU al recurso Google Cloud que recibe el paquete:
    • Si el recurso que recibe el paquete es una instancia de VM, Google Cloud aplica la MTU de la red de VPC Google Cloud que usa la interfaz de red de la VM receptora, como si la VM receptora hubiera recibido un paquete enrutado dentro de la red de VPC.
    • Los paquetes que se envían a las APIs y los servicios de Google desde las instalaciones locales a través de una vinculación de VLAN se procesan de la misma forma que los paquetes que se envían desde instancias de VM a las APIs y los servicios de Google. Para obtener más información, consulta el artículo sobre la comunicación con las APIs y los servicios de Google.
Paquetes enviados a través de la VPN de alta disponibilidad mediante Cloud Interconnect La VPN de alta disponibilidad mediante Cloud Interconnect usa una MTU de pasarela de 1440 bytes, y las MTUs de carga útil son más pequeñas, en función de los cifrados utilizados. Para obtener más información, consulta las consideraciones sobre la MTU en la documentación de Cloud VPN.

Siguientes pasos