Descripción general de la red de VPC

Una red de nube privada virtual (VPC) es una versión virtual de una red física, que se implementa dentro de la red de producción de Google, mediante Andromeda. Una red de VPC proporciona lo siguiente:

Los proyectos pueden contener varias redes de VPC. A menos que crees una política de la organización que la prohíba, los proyectos nuevos comienzan con una red predeterminada (una red de VPC en modo automático) que tiene una subred (subred) en cada región.

Especificaciones

Las redes de VPC tienen las siguientes propiedades:

  • Las redes de VPC, incluidas sus reglas de firewall y rutas asociadas, son recursos globales. No están asociadas con ninguna región o zona en particular.

  • Las subredes son recursos regionales. Cada subred define un rango de direcciones IP.

  • El tráfico desde y hacia las instancias puede controlarse mediante las reglas de firewall de la red. Las reglas se implementan en las VM, por lo que el tráfico solo se puede controlar y registrar cuando sale o llega a una VM.

  • Los recursos dentro de una red de VPC pueden comunicarse entre sí mediante direcciones IPv4 internas (privadas), sujetas a las reglas de firewall aplicables de la red. Si deseas obtener más información, consulta Comunicación dentro de la red.

  • Las instancias con direcciones IP internas pueden comunicarse con los servicios y las API de Google. Si deseas obtener más información, consulta Opciones de acceso privado a los servicios.

  • La administración de red se puede proteger mediante funciones de Cloud Identity and Access Management (Cloud IAM).

  • Una organización puede usar VPC compartidas para mantener una red de VPC en un proyecto host en común. Los miembros autorizados de Cloud IAM de otros proyectos en la misma organización pueden crear recursos que usen subredes de la red de VPC compartida.

  • Las redes de VPC pueden conectarse con otras redes de VPC de organizaciones o proyectos diferentes mediante el intercambio de tráfico entre redes de VPC.

  • Las redes de VPC pueden conectarse de forma segura en entornos híbridos mediante Cloud VPN o Cloud Interconnect.

  • Las redes de VPC solo son compatibles con el tráfico IPv4 de unidifusión. No son compatibles con el tráfico de transmisión o multidifusión, ni el tráfico IPv6 dentro de la red. Las VM en la red de VPC solo pueden enviar tráfico a destinos IPv4 y recibirlo de fuentes IPv4. Sin embargo, es posible crear una dirección IPv6 para un balanceador de cargas global.

Terminología de red y subred

En GCP Console, se usa el término subred. Este término se usa en la documentación de Google Cloud Console, los comandos de gcloud y las API.

Una subred no es lo mismo que una red (de VPC). Las redes y subredes son diferentes tipos de objetos en Google Cloud.

Redes y subredes

Cada red de VPC consta de una o más particiones útiles del rango de IP llamadas subredes. Cada subred está asociada a una región. Las redes de VPC no tienen ningún rango de direcciones IP asociado. Los rangos de IP se definen para las subredes.

Una red debe tener, al menos, una subred para que puedas usarla. Las redes de VPC de modo automático crean subredes en cada región de forma automática. Las redes de VPC de modo personalizado comienzan sin subredes, lo que te brinda el control total sobre la creación de subredes. Puedes crear más de una subred por región. Para obtener información sobre las diferencias entre las redes de VPC de modo personalizado y de modo automático, consulta los tipos de redes de VPC.

Cuando creas un recurso en Google Cloud, debes elegir una red y una subred. En el caso de otros recursos que no sean plantillas de instancias, también debes seleccionar una zona o una región. Cuando seleccionas una zona, se selecciona una región principal de forma implícita. Debido a que las subredes son objetos regionales, la región que seleccionas para un recurso determina las subredes que puede usar:

  • El proceso de creación de una instancia incluye la selección de una zona, una red y una subred. Las subredes disponibles para la selección están restringidas a aquellas que se encuentran en la región seleccionada. Google Cloud asigna a la instancia una dirección IP del rango de direcciones disponibles en la subred.

  • El proceso de creación de un grupo de instancias administrado incluye la selección de una zona o una región, según el tipo de grupo, y una plantilla de instancias. Las plantillas de instancias disponibles para la selección están restringidas a aquellas cuyas subredes definidas están en la misma región seleccionada para el grupo de instancias administrado.

    • Las plantillas de instancias son recursos globales. El proceso de creación de una plantilla de instancias incluye la selección de una red y una subred. Si seleccionas una red de VPC de modo automático, puedes usar subredes automáticas para diferir la selección de subredes a una que esté disponible en la región seleccionada de cualquier grupo de instancias administrado que use la plantilla. Las redes de VPC de modo automático tienen una subred en cada región por definición.
  • El proceso de creación de un clúster de contenedores de Kubernetes incluye la selección de una zona o una región (según el tipo de clúster), una red y una subred. Las subredes disponibles para la selección están restringidas a aquellas que se encuentran en la región seleccionada.

Modo de creación de subred

Google Cloud ofrece dos tipos de redes de VPC, determinadas por su modo de creación de subred:

  • Cuando se crea una red de VPC de modo automático, se crea de forma automática una subred de cada región dentro de ella. Estas subredes creadas de forma automática usan un conjunto de rangos de IP predefinidos que se ajustan al bloque CIDR 10.128.0.0/9. A medida que las nuevas regiones de Google Cloud estén disponibles, las subredes nuevas de esas regiones se agregarán automáticamente a las redes de VPC de modo automático mediante un rango de IP de ese bloque. Además de las subredes creadas automáticamente, puedes agregar más subredes de forma manual a las redes de VPC de modo automático en las regiones que elijas mediante rangos de IP fuera de 10.128.0.0/9.

  • Cuando se crea una red de VPC de modo personalizado, no se crean subredes de forma automática. Este tipo de red te proporciona control total sobre sus subredes y rangos de IP. Tú decides qué subredes crear en las regiones que elijas mediante los rangos de IP que especifiques.

Puedes cambiar una red de VPC del modo automático al modo personalizado. Esta es una conversión unidireccional. Las redes de VPC de modo personalizado no se pueden cambiar al modo automático. Para ayudarte a decidir qué tipo de red satisface tus necesidades, consulta las consideraciones para las redes de VPC de modo automático.

Red predeterminada

Cada proyecto nuevo comienza con una red predeterminada, a menos que decidas inhabilitarla. La red predeterminada es una red de VPC de modo automático con reglas de firewall ya propagadas.

Si deseas inhabilitar la creación de redes predeterminadas, crea una política de la organización con la restricción compute.skipDefaultNetworkCreation. Los proyectos que hereden esta política no tendrán una red predeterminada.

Consideraciones para las redes de VPC de modo automático

Las redes de VPC de modo automático son fáciles de configurar y usar, y son adecuadas para casos prácticos con estos atributos:

  • La creación automática de subredes en cada región es útil.

  • Los rangos de IP predefinidos de las subredes no se superponen con los rangos que usarías con otros fines (por ejemplo, conexiones de Cloud VPN a recursos locales).

Sin embargo, las redes de VPC de modo personalizado son más flexibles y se ajustan mejor a la producción. Los siguientes atributos destacan casos prácticos en los que se recomienda o requiere el uso de redes de VPC de modo automático:

  • La creación automática de una subred en cada región no es necesaria.

  • La creación automática de subredes a medida que surgen nuevas regiones podría generar una superposición con las direcciones IP usadas por las subredes manuales o rutas estáticas, o podría interferir en la planificación general de la red.

  • Necesitas control total sobre las subredes creadas en tu red de VPC, incluidas las regiones y los rangos de direcciones IP usados.

  • Planeas conectar redes de VPC mediante el intercambio de tráfico entre redes de VPC o Cloud VPN. Debido a que las subredes de todas las redes de VPC de modo automático usan el mismo rango predefinido de direcciones IP, no puedes conectar redes de VPC de modo automático entre sí.

Rangos de subredes

Cuando creas una subred, debes definir su rango de direcciones IP principales. Las direcciones internas principales para los siguientes recursos provienen del rango principal de la subred: instancias de VM, balanceadores de cargas internos y reenvío de protocolo interno. De manera opcional, puedes agregar rangos de direcciones IP secundarias a una subred, que solo usan los rangos de alias de IP. Sin embargo, puedes configurar rangos de alias de IP para instancias del rango principal o secundario de una subred.

Cada rango de IP principal o secundario para todas las subredes en una red de VPC debe ser un bloque CIDR válido. Consulta los límites por red para conocer la cantidad de rangos de IP secundarios que puedes definir.

No es necesario que las subredes formen un bloque CIDR contiguo predefinido, pero puedes configurarlo si así lo deseas. Por ejemplo, las redes de VPC de modo automático sí crean subredes que se ajustan un rango de IP predefinido de modo automático.

Para obtener más información, consulta Trabaja con subredes.

Rangos válidos

Los rangos de direcciones IP principales y secundarias de una subred son direcciones IP internas regionales. En la siguiente tabla, se describen los rangos válidos.

Rango Descripción
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Direcciones IP privadas de RFC 1918
100.64.0.0/10 Espacio de direcciones compartidas de RFC 6598
192.0.0.0/24 Asignaciones de protocolo IETF de RFC 6890
192.0.2.0/24 (TEST-NET-1)
198.51.100.0/24 (TEST-NET-2)
203.0.113.0/24 (TEST-NET-3)
Documentación de RFC 5737
192.88.99.0/24 Retransmisión de IPv6 a IPv4 (obsoleta) de RFC 7526
198.18.0.0/15 Pruebas comparativas de RFC 2544
240.0.0.0/4 RFC 1112 reservado
Direcciones IP públicas reutilizadas de forma privada Incluye direcciones IP que no forman parte de los rangos de RFC enumerados en esta tabla y que no forman parte del conjunto restringido. Cuando usas estas direcciones como rangos de subredes, Google Cloud no enruta el tráfico a ellas de forma pública.

En el intercambio de tráfico entre redes de VPC, las rutas de subredes para direcciones IP públicas no se intercambian de forma automática. Las rutas de subredes se exportan de forma automática, pero las redes de intercambio de tráfico deben configurarse de manera explícita para importarlas a fin de usarlas.

Los rangos de subredes tienen las siguientes restricciones:

  • Los rangos de subredes no pueden coincidir con un rango restringido, ni ser más estrechos ni más amplios que uno de estos rangos. Por ejemplo, 169.0.0.0/8 no es un rango de subred válido porque se superpone con el rango de vínculo local 169.254.0.0/16 (RFC 3927), que es un rango restringido.

  • Los rangos de subredes no pueden abarcar un rango de RFC (descrito en la tabla anterior) y un rango de direcciones IP públicas usado de forma privada. Por ejemplo, 172.16.0.0/10 no es un rango de subred válido porque se superpone con direcciones IP públicas y RFC 1918.

  • Los rangos de subredes no pueden abarcar varios rangos de RFC. Por ejemplo, 192.0.0.0/8 no es un rango de subred válido porque incluye 192.168.0.0/16 (de RFC 1918) y 192.0.0.0/24 (de RFC 6890). Sin embargo, puedes crear dos subredes con diferentes rangos principales, una con 192.0.0.0/16 y otra con 192.0.0.0/24. O bien, puedes usar ambos rangos en la misma subred si haces que uno de ellos sea secundario.

Rangos restringidos

Entre los rangos restringidos se incluyen las direcciones IP públicas de Google y los rangos de RFC que se suelen reservar, como se describe en la siguiente tabla. Estos rangos no se pueden usar para rangos de subredes.

Rango Descripción
Direcciones IP públicas para los servicios y las API de Google, incluidos los netblocks de Google Cloud. Puedes encontrar estas direcciones IP en http://gstatic.com/ipranges/goog.txt.
199.36.153.4/30 y 199.36.153.8/30 Direcciones IP virtuales específicas del acceso privado a Google
0.0.0.0/8 Red actual (local) de RFC 1122
127.0.0.0/8 Host local de RFC 1122
169.254.0.0/16 Vínculo local de RFC 3927
224.0.0.0/4 Multidifusión de RFC 5771
255.255.255.255/32 Dirección de destino de transmisión limitada de RFC 8190 y RFC 919

Direcciones IP reservadas en una subred

Cada subred tiene cuatro direcciones IP reservadas en su rango de IP principal: No hay direcciones IP reservadas en los rangos de IP secundarios.

Dirección IP reservada Descripción Ejemplo
Red La primera dirección en el rango de IP principal de la subred 10.1.2.0 en 10.1.2.0/24
Puerta de enlace predeterminada La segunda dirección en el rango de IP principal de la subred 10.1.2.1 en 10.1.2.0/24
Penúltima dirección Penúltima dirección del rango de IP principal de la subred, que Google Cloud reserva para su posible uso en el futuro 10.1.2.254 en 10.1.2.0/24
Transmisión La última dirección en el rango de IP principal de la subred 10.1.2.255 en 10.1.2.0/24

Rangos de IP de modo automático

En esta tabla, se enumeran los rangos de IP para las subredes creadas automáticamente en una red de VPC de modo automático. Los rangos de IP de estas subredes se ajustan al bloque CIDR 10.128.0.0/9. Las redes de VPC de modo automático se compilan con una subred por región en el momento de la creación y reciben subredes nuevas de forma automática en las regiones nuevas. Las partes no usadas de 10.128.0.0/9 están reservadas para el uso futuro de Google Cloud.

Región Rango de IP (CIDR) Puerta de enlace predeterminada Direcciones utilizables (inclusive)
asia-east1 10.140.0.0/20 10.140.0.1 10.140.0.2 a 10.140.15.253
asia-east2 10.170.0.0/20 10.170.0.1 10.170.0.2 a 10.170.15.253
asia-northeast1 10.146.0.0/20 10.146.0.1 10.146.0.2 a 10.146.15.253
asia-northeast2 10.174.0.0/20 10.174.0.1 10.174.0.2 a 10.174.15.253
asia-northeast3 10.178.0.0/20 10.178.0.1 10.178.0.2 a 10.178.15.253
asia-south1 10.160.0.0/20 10.160.0.1 10.160.0.2 a 10.160.15.253
asia-southeast1 10.148.0.0/20 10.148.0.1 10.148.0.2 a 10.148.15.253
asia-southeast2 10.184.0.0/20 10.184.0.1 10.184.0.2 a 10.184.15.253
australia-southeast1 10.152.0.0/20 10.152.0.1 10.152.0.2 a 10.152.15.253
europe-north1 10.166.0.0/20 10.166.0.1 10.166.0.2 a 10.166.15.253
europe-west1 10.132.0.0/20 10.132.0.1 10.132.0.2 a 10.132.15.253
europe-west2 10.154.0.0/20 10.154.0.1 10.154.0.2 a 10.154.15.253
europe-west3 10.156.0.0/20 10.156.0.1 10.156.0.2 a 10.156.15.253
europe-west4 10.164.0.0/20 10.164.0.1 10.164.0.2 a 10.164.15.253
europe-west6 10.172.0.0/20 10.172.0.1 10.172.0.2 a 10.172.15.253
northamerica-northeast1 10.162.0.0/20 10.162.0.1 10.162.0.2 a 10.162.15.253
southamerica-east1 10.158.0.0/20 10.158.0.1 10.158.0.2 a 10.158.15.253
us-central1 10.128.0.0/20 10.128.0.1 10.128.0.2 a 10.128.15.253
us-east1 10.142.0.0/20 10.142.0.1 10.142.0.2 a 10.142.15.253
us-east4 10.150.0.0/20 10.150.0.1 10.150.0.2 a 10.150.15.253
us-west1 10.138.0.0/20 10.138.0.1 10.138.0.2 a 10.138.15.253
us-west2 10.168.0.0/20 10.168.0.1 10.168.0.2 a 10.168.15.253
us-west3 10.180.0.0/20 10.180.0.1 10.180.0.2 a 10.180.15.253
us-west4 10.182.0.0/20 10.182.0.1 10.182.0.2 a 10.182.15.253

Rutas y reglas de firewall

Rutas

Las rutas definen rutas de acceso para instancias salientes (tráfico de salida). Las rutas de Google Cloud se dividen en dos categorías: generadas por el sistema y personalizadas.

Cada red nueva comienza con dos tipos de rutas generadas por el sistema:

  • La ruta predeterminada define una ruta de acceso para el tráfico que sale de la red de VPC. Proporciona acceso general a Internet a las VM que cumplen con los requisitos de acceso a Internet. También proporciona la ruta de acceso típica para el acceso privado a Google.

  • Se crea una ruta de subred para cada uno de los rangos de IP asociados con una subred. Cada subred tiene al menos una ruta de subred para su rango de IP principal. Se crean rutas de subredes adicionales para una subred si le agregas rangos de IP secundarios. Las rutas de subredes definen rutas para que el tráfico llegue a las VM que usan las subredes. No puedes quitar rutas de subredes de forma manual.

Las rutas personalizadas son rutas estáticas que puedes crear de forma manual o rutas dinámicas que uno o más de tus Cloud Routers mantienen de forma automática. Para obtener más información, consulta Rutas personalizadas.

Para obtener detalles completos sobre el enrutamiento en Google Cloud, consulta Descripción general de las rutas.

Modo de enrutamiento dinámico

Cada red de VPC tiene un modo de enrutamiento dinámico asociado que controla el comportamiento de todos sus Cloud Routers. Los Cloud Routers comparten rutas a tu red de VPC y aprenden las rutas dinámicas personalizadas desde las redes conectadas cuando conectas la red de VPC a otra red con un túnel de Cloud VPN que usa enrutamiento dinámico, o mediante la interconexión dedicada o la interconexión de socio.

  • El enrutamiento dinámico regional es el predeterminado. En este modo, las rutas a recursos locales procesadas por un Cloud Router determinado en la red de VPC solo se aplican a las subredes en la misma región que el Cloud Router. A menos que se modifique mediante anuncios personalizados, cada Cloud Router comparte solo las rutas a subredes de su región con su contraparte local.

  • El enrutamiento dinámico global cambia el comportamiento de todos los Cloud Routers en la red de modo que las rutas a los recursos locales que aprenden estén disponibles en todas las subredes de la red de VPC, sin importar la región. A menos que se modifique mediante anuncios personalizados, cada Cloud Router comparte las rutas a todas las subredes de la red de VPC con su contraparte local.

Para obtener información sobre cómo se puede personalizar el conjunto de rutas que comparte un Cloud Router, consulta Anuncios personalizados.

El modo de enrutamiento dinámico se puede establecer cuando creas o modificas una red de VPC. Puedes cambiar el modo de enrutamiento dinámico de regional a global, y viceversa, sin restricción. Para obtener instrucciones, consulta Cambia el modo de enrutamiento dinámico.

Reglas de firewall

Las reglas de firewall se aplican tanto al tráfico saliente (de salida) como al entrante (de entrada) en la red. Las reglas de firewall controlan el tráfico incluso si se encuentra íntegramente dentro de la red, como la comunicación entre instancias de VM.

Cada red de VPC tiene dos reglas de firewall implícitas. Una regla implícita permite la mayor parte del tráfico de salida, y la otra rechaza todo el tráfico de entrada. No puedes borrar las reglas implícitas, pero puedes anularlas con tus propias reglas. Google Cloud siempre bloquea parte del tráfico, sin importar las reglas de firewall. Para obtener más información, consulta Tráfico bloqueado.

Para supervisar qué regla de firewall permitió o rechazó una conexión en particular, consulta Registro de reglas de firewall.

Comunicaciones y acceso

Comunicación dentro de la red

Las rutas de subredes generadas por el sistema definen las rutas para enviar tráfico entre instancias dentro de la red mediante direcciones IP internas (privadas). Para que una instancia pueda comunicarse con otra, deben configurarse las reglas de firewall adecuadas, ya que cada red tiene una regla de firewall implícita que rechaza el tráfico de entrada.

Excepto en el caso de la red predeterminada, debes crear de forma explícita reglas de firewall de entrada de prioridad más alta para permitir que las instancias se comuniquen entre sí. La red predeterminada incluye varias reglas de firewall, además de las implícitas, incluida la regla default-allow-internal, que permite la comunicación entre instancias dentro de la red. La red predeterminada también incluye reglas de entrada que permiten protocolos como RDP y SSH.

Las reglas que vienen con la red predeterminada también se presentan como opciones para que apliques a las nuevas redes de VPC de modo automático que crees mediante Cloud Console.

Requisitos de acceso a Internet

Se deben cumplir los siguientes criterios para que una instancia tenga acceso a Internet de salida:

  • La red debe tener una ruta de puerta de enlace de Internet predeterminada o una ruta personalizada cuyo rango de IP de destino sea el más general (0.0.0.0/0). Esta ruta define la ruta de acceso a Internet. Para obtener más información, consulta Rutas.

  • Las reglas de firewall deben permitir el tráfico de salida desde la instancia. A menos que esté anulada por una regla de prioridad más alta, la regla implícita para el tráfico de salida permite el tráfico saliente desde todas las instancias.

  • Debe cumplirse una de las siguientes condiciones:

    • La instancia debe tener una dirección IP externa. Una dirección IP externa se puede asignar a una instancia cuando se crea o después de crearla.

    • La instancia debe poder usar Cloud NAT o un proxy basado en instancias que sea el objetivo de una ruta estática 0.0.0.0/0.

Comunicaciones y acceso para App Engine

Las reglas de firewall de VPC se aplican a los recursos que se ejecutan en la red de VPC, como las VM de Compute Engine. Para las instancias de App Engine, las reglas de firewall funcionan de la siguiente manera:

  • Entorno estándar de App Engine: Solo se aplican las reglas de firewall de App Engine al tráfico de entrada. Dado que las instancias del entorno estándar de App Engine no se ejecutan dentro de tu red de VPC, las reglas de firewall de VPC no se aplican a ellas.

  • Entorno flexible de App Engine: Se aplican las reglas de firewall de VPC y de App Engine al tráfico de entrada. El tráfico entrante solo se admite si ambos tipos de reglas de firewall lo permiten. Para el tráfico saliente, se aplican las reglas de firewall de VPC.

Para obtener más información sobre cómo controlar el acceso a las instancias de App Engine, consulta Seguridad de las apps.

Traceroute para direcciones IP externas

Por motivos internos, Google Cloud aumenta el contador de TTL de los paquetes que recorren los siguientes saltos en la red de Google. Es posible que herramientas como traceroute y mtr proporcionen resultados incompletos porque el TTL no vence en algunos de los saltos. Los saltos que están dentro y fuera de la red de Google pueden estar ocultos en las siguientes circunstancias:

  • Cuando envías paquetes de instancias de Compute Engine a direcciones IP externas, incluidas las direcciones IP externas de otros recursos de Google Cloud o destinos en Internet.

  • Cuando envías paquetes a la dirección IP externa asociada a una instancia de Compute Engine o a otro recurso de Google Cloud.

La cantidad de saltos ocultos varía según los niveles de servicio de red de la instancia, la región y otros factores. Si solo hay unos pocos saltos, es posible que todos estén ocultos. Si faltan saltos en un resultado de traceroute o de mtr, no significa que se perderá el tráfico saliente.

No hay ninguna solución para este comportamiento. Debes tenerlo en cuenta si configuras la supervisión de terceros que se conecta a una dirección IP externa asociada con una VM.

Límites de capacidad de procesamiento de salida

En la sección Ancho de banda de red, puedes encontrar información sobre la capacidad de procesamiento de la red está disponible.

Ejemplo de red de VPC

En el siguiente ejemplo, se ilustra una red de VPC de modo personalizado con tres subredes en dos regiones:

Ejemplo de una red de VPC (haz clic para ampliar)
Ejemplo de una red de VPC (haz clic para ampliar)
  • La subred subnet1 está definida como 10.240.0.0/24 en la región us-west1.
    • En esta subred, hay dos instancias de VM en la zona us-west1-a. Sus direcciones IP provienen del rango de direcciones disponible en la subnet1.
  • La subred subnet2 está definida como 192.168.1.0/24 en la región us-east1.
    • En esta subred, hay dos instancias de VM en la zona us-east1-a. Sus direcciones IP provienen del rango de direcciones disponible en la subnet2.
  • La subred subnet3 se define como 10.2.0.0/16, también en la región us-east1.
    • Una instancia de VM en la zona us-east1-a y otra instancia en la zona us-east1-b están en la subnet3, y cada una recibe una dirección IP de su rango disponible. Debido a que las subredes son recursos regionales, las instancias pueden asociar sus interfaces de red con cualquier subred de la misma región que contiene sus zonas.

Rendimiento de la red

Latencia

La latencia medida entre regiones para las redes de Google Cloud se puede encontrar en nuestro panel de transmisiones en vivo. En el panel, se muestran las métricas del rendimiento de la capacidad de procesamiento y la latencia mediana entre regiones de Google Cloud, y la metodología para reproducir estos resultados con PerfKit Benchmarker.

Por lo general, Google Cloud mide las latencias de ida y vuelta de menos de 55 μs en el percentil 50 y las latencias finales de menos de 80 μs en el percentil 99 entre instancias de VM c2-standard-4 en la misma zona.

Por lo general, Google Cloud mide las latencias de ida y vuelta de menos de 45 μs en el percentil 50 y las latencias finales de menos de 60 μs en el percentil 99 entre las instancias de VM c2-standard-4 en la misma red de latencia baja (política de posición de “compactación”). La política de posición de compactación reduce la latencia de la red, ya que garantiza que las VM se encuentren físicamente dentro de la misma red de latencia baja.

Metodología: La latencia dentro de la zona se supervisa mediante un sistema de sondeo de caja negra que ejecuta comparativas de TCP_RR de netperf de forma continua entre un par de VM de tipo c2 en cada zona en que las instancias de c2 estén disponibles. Recopila resultados de P50 y P99 para la configuración con y sin política de posición de compactación. La comparativa de TCP_RR mide el rendimiento de las solicitudes y las respuestas mediante la medición de la tasa de transacciones. Si tus aplicaciones requieren la mejor latencia posible, se recomiendan las instancias de c2.

Pérdida de paquetes

Google Cloud hace un seguimiento de la pérdida de paquetes entre regiones mediante la medición regular de la pérdida de ida y vuelta entre todas las regiones. El objetivo es que el promedio global de esas mediciones sea inferior al 0.01%.

Metodología: Un sistema de sondeo de VM a VM de caja negra supervisa la pérdida de paquetes para cada par de zonas mediante pings y agrega los resultados en una métrica de pérdida global. Se realiza un seguimiento de esta métrica con un período de un día.

Próximos pasos