Caso práctico: Audita el rendimiento de la red

Imagina que eres un administrador de red que admite una red que incluye varias aplicaciones con balanceo de cargas. Se te solicitó auditar las configuraciones de red que admiten esas aplicaciones para garantizar que sean coherentes con el estado esperado de tu red. Si realizas esta auditoría, puedes asegurarte de que los clientes obtengan la menor latencia posible en tus aplicaciones.

En el siguiente caso de uso, se muestra cómo la topología de red puede ayudarte a verificar tu configuración existente. Por ejemplo, puedes verificar que las instancias de la aplicación entregan todas las solicitudes de cliente desde la región de Google Cloud más cercana al cliente. También puedes asegurarte de que el tráfico entre regiones sea bajo, ya que el tráfico proviene de bases de datos que replican datos a nivel global.

Descripción general de la topología

La implementación abarca tres regiones de Google Cloud (us-central1, europe-west1 y asia-east1). Un solo balanceador de cargas de aplicaciones externo que tiene múltiples backends en cada una de las tres regiones entrega las solicitudes de clientes externos. Las solicitudes de los clientes que provienen de una de las tres regiones comerciales (América, EMEA y APAC) son entregadas por instancias de aplicación en la región de Google Cloud más cercana.

En el siguiente gráfico, se muestra la jerarquía de nivel superior de la implementación.

Topología de ejemplo de la topología de red (haz clic para ampliar)

Recursos y rutas de tráfico

En este ejemplo, el proyecto contiene los siguientes recursos de Google Cloud:

• 1 balanceador de cargas HTTPS

• 4 servicios de backend: browse, shopping_cart, checkout y feeds

• 12 grupos de instancias (que son los backends del balanceador de cargas)

  Hay un grupo de instancias para cada servicio de backend en cada una de las tres regiones.

• 3 instancias de bases de datos, una en cada región

Debes esperar a que el tráfico de algunos países vaya a las siguientes ubicaciones:

• El tráfico de los países en la región comercial Americas se dirige hacia los backends en la región us-central1. Por ejemplo, el tráfico de un cliente externo en Canadá viaja a través del balanceador de carga al backend checkout en la región us-central1.
• El tráfico de los países en la región comercial EMEA se dirige hacia los backends en la región europe-west1. Por ejemplo, el tráfico de un cliente externo en Polonia viaja a través del balanceador de carga al backend checkout en la región europe-west1.
• El tráfico de los países en la región comercial APAC se dirige hacia los backends en la región asia-east1. Por ejemplo, el tráfico de un cliente externo en Japón viaja a través del balanceador de cargas al backend checkout en la región asia-east1.
• El tráfico a una instancia de una base de datos proviene de un backend en la misma región. Por ejemplo, los backends en asia-east1 envían datos solo a la instancia de la base de datos en asia-east1.
• El tráfico entre regiones se limita a la replicación de la base de datos. Por ejemplo, el tráfico entre us-central1 y europe-west1 solo viaja entre las instancias de las bases de datos de esas regiones.

Flujo de tráfico inesperado

En esta situación, descubres que el tráfico de la región empresarial EMEA ahora se dirige a dos regiones diferentes de Google Cloud, us-central1 y europe-west1. Cuando utiliza la topología de red, descubre que uno de los backends tienen un uso excesivo.

1. Desea verificar que el tráfico externo que pasa por el balanceador de carga finalmente vaya a la región correcta de Google Cloud. Filtra el gráfico para mostrar solo el tráfico de su balanceador de carga externo shopping-site-lb.

   Después de aplicar el filtro, la topología de red muestra solo las conexiones relacionadas con el balanceador de carga, como se muestra en el siguiente ejemplo.

   

   Filtro de un balanceador de carga (haga clic para ampliar)

2. Debes mantener el puntero sobre cada región empresarial para destacar la comunicación con esa región.

   Si mantienes el puntero sobre América y APAC, verás que el tráfico que se dirige a la región de Google Cloud más cercana: us-central1 y asia- east1, respectivamente. Sin embargo, si mantienes el puntero sobre EMEA, verás el tráfico que se dirige a us-central1 y europe-west1. Lo ideal es que, para reducir la latencia, todo el tráfico de EMEA se dirija a europe-west1.

3. A continuación, haz clic en EMEA para estudiar la capacidad de procesamiento entre esta región y las regiones de Google Cloud. La topología de red superpone los valores del ancho de banda en cada conexión. Verás que alrededor de 0.58 bytes por segundo se dirigen a us-central1 y 29.9 kilobytes por segundo se dirigen a europe-west1. Sabes que la mayor parte del tráfico se dirige como se espera, pero parte del tráfico fluye hacia us-central1.

   

   Valores del ancho de banda superpuestos¹ (haz clic para agrandar)

   ¹ La figura es de referencia. Sus datos no reflejan el caso práctico.

4. Si deseas investigar más, puedes expandir us-central1 para ver hacía dónde se dirige el tráfico. Debido a que solo hay una red con una sola subred en esa región, la topología de red no muestra esos niveles de la jerarquía y se omite en los grupos de instancias.

   Verás que el tráfico se dirige a un grupo de instancias que está asociado con el servicio de backend del balanceador de cargas. Debido a que es una cantidad relativamente pequeña de tráfico que se dirige a europe-west1, es posible que los recursos en europe-west1 tengan un uso excesivo y causen que el tráfico se desborde a us-central1.

   

   Ruta de acceso del tráfico ¹ (haga clic para ampliar)

   ¹ La figura es de referencia. Sus datos no reflejan el caso práctico.

5. Para confirmar tu conclusión, expande la región europe-west1 hasta que llegues a la instancia asociada con el mismo servicio de backend del balanceador de cargas. La topología de red muestra gráficos de series temporales en el panel de detalles de la instancia.

   En el gráfico, notas que la frecuencia de uso de CPU es de un 81% para la instancia. El umbral para este ejemplo es de un 80%, lo que indica que la instancia tiene una suscripción excesiva. Para solucionar este problema, escala verticalmente el grupo de instancias de modo que el tráfico vuelva al flujo ideal.

   

   Gráfico de series temporales para una instancia ¹ (haga clic para ampliar)

   ¹ La figura es de referencia. Sus datos no reflejan el caso práctico.

Tráfico entre regiones

En la siguiente sección, debes verificar que el tráfico interno entre las regiones se limite solo al tráfico de las instancias de las bases de datos.

1. Para enfocarte en el tráfico interno, en la lista Configuración de topología, selecciona solo las casillas de verificación Instancias y Puertas de enlace de Cloud NAT. Debido a que solo estás viendo el tráfico dentro de tu aplicación, no necesitas ver el tráfico de los clientes externos ni del balanceador de cargas externo.

   

   Muestre solo tráfico interno (haga clic para ampliar)

2. Expande la región asia-east1 y verás cinco grupos de instancias. No se agregan por red, subred o zona porque todos están en la misma red, subred, etcétera.

   Observa que solo un grupo de instancias (db-group-asia) contiene una ruta para el tráfico entre regiones. Todos los demás grupos de instancias se comunican dentro de la región.

   Puedes seguir expandiendo el grupo db-group-asia hasta llegar a la entidad base. En esta situación, la entidad base es una instancia de máquina virtual (VM) (db-instance-asia) que actúa como un servidor de bases de datos. Se comunica con otras regiones para replicar los datos, que es lo que esperabas, por lo que no se requieren más investigaciones. ̦

   

   Tráfico entre regiones¹ (haz clic para agrandar)

   ¹ La figura es de referencia. Sus datos no reflejan el caso práctico.

¿Qué sigue?

• Supervisa la configuración de red con la topología de red
• Caso de uso: Soluciona problemas de conectividad de red
• Soluciona problemas de la topología de red