Auditar el rendimiento de la red

Suponga que es un administrador de red que brinda asistencia a una red que incluye varias aplicaciones de balanceador de cargas. Se le ha pedido que audite las configuraciones de red que admiten esas aplicaciones para garantizar que las configuraciones sean consistentes con el estado esperado de su red. Al realizar esta auditoría, puede asegurarse de que los clientes obtengan la menor latencia posible para sus aplicaciones.

El siguiente caso de uso demuestra cómo la Topología de red puede ayudarlo a verificar sus configuraciones existentes. Por ejemplo, puede verificar que todas las solicitudes de los clientes sean entregadas por instancias de aplicaciones de la región de Google Cloud más cercana al cliente. También puede asegurarse de que el tráfico entre regiones sea bajo porque ese tráfico proviene de bases de datos que replican datos globalmente.

Descripción general de la topología

La implementación abarca tres regiones de Google Cloud (us-central1, europe-west1 y asia-east1). Todas las solicitudes de clientes externos son entregadas por un único balanceador de carga HTTP(S), que tiene múltiples backends en cada una de las tres regiones. 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.

El siguiente gráfico muestra la jerarquía de nivel superior para la implementación:

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 carga). 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.

Espera que el tráfico proveniente de ciertos 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 carga al backend checkout en la región asia-east1.
  • El tráfico a una instancia de 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 bases de datos. Por ejemplo, el tráfico entre us-central1 y europe-west1 viaja solo entre instancias de bases de datos en esas regiones.

Flujo de tráfico inesperado

En esta situación, descubre que el tráfico de la región comercial EMEA ahora va 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.

  2. Mantenga el puntero sobre cada región comercial para resaltar la comunicación a esa región.

    Cuando mantiene el puntero sobre Américas y APAC, puede ver el tráfico que va a la región de Google Cloud más cercana: us-central1 y asia-east1 respectivamente. Sin embargo, cuando mantiene el puntero sobre EMEA, puede ver que el tráfico va a us-central1 y europe-west1. Idealmente, para reducir la latencia, todo el tráfico de EMEA debe ir a europe-west1.

  3. Luego, haga clic en EMEA para estudiar la capacidad de procesamiento entre este y las regiones de Google Cloud. La topología de red superpone los valores de ancho de banda en cada conexión. Verá que unos 10 MBps se dirigen a us-central1 y 90 MBps a europe-west1. Usted sabe que la mayor parte del tráfico se dirige como era de esperar, pero parte del tráfico fluye a us-central1.

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

  4. Para seguir investigando, expande us-central1 para ver hacia dónde va el tráfico. Debido a que solo hay una red con una única subred en esa región, la topología de red no muestra esos niveles de la jerarquía y salta a los grupos de instancias.

    Verá que el tráfico va a un grupo de instancias asociado con el servicio de backend del balanceador de carga. 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.

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

  5. Para confirmar su conclusión, expanda la región us-central1 hasta llegar a la instancia asociada con el mismo servicio de backend del balanceador de carga. La topología de red muestra gráficos de series temporales en el panel de detalles de la instancia.

    En el gráfico, puede ver que la tasa de utilización de la CPU es del 82% para la instancia. El umbral para este ejemplo es del 80%, lo que indica que la instancia está suscrita en exceso. Puede resolver este problema escalando verticalmente el grupo de instancias para que el tráfico vuelva al flujo ideal.

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

Tráfico entre regiones

En la siguiente sección, verifica que el tráfico interno entre regiones se limita solo al tráfico de la instancia de la base de datos.

  1. Para centrarse en el tráfico interno, anule la selección de las entidades Clientes externos y Balanceadores de carga de la lista de entidades. Debido a que solo está viendo el tráfico dentro de su aplicación, no necesita ver clientes externos y tráfico de balanceador de carga externo.

  2. Expande la región asia-east1 y ve 5 grupos de instancias. No se agregan por red, subred, zona o segmento de infraestructura porque todos están en la misma red, subred, etc.

    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.

    Continúa expandiendo el grupo db-group-asia hasta llegar a la entidad base. En esta situación, la entidad base es una instancia de VM (db-instance-asia) que actúa como un servidor de base de datos. Se está comunicando con otras regiones para replicar datos, que es lo que esperaba, por lo que no se requieren más investigaciones.

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

Qué sigue