Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
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 entreguen todas las solicitudes de cliente desde la región de Google Cloud
que esté más cerca del 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). Todas las solicitudes de clientes externos son entregadas por un único balanceador de cargas de aplicaciones externo 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 deGoogle 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 comercial EMEA ahora se dirige a dos regiones Google Cloud diferentes, us-central1 y europe-west1. Cuando utiliza la topología de red, descubre que uno de los backends tienen un uso excesivo.
Deseas 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 tu balanceador de cargas 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)
Debes mantener el puntero sobre cada región empresarial para destacar la comunicación con esa región.
Si mantienes el puntero sobre Américas 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.
A continuación, haz clic en EMEA para estudiar la capacidad de procesamiento entre esta región y las regiones deGoogle 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 superpuestos1 (haz clic para agrandar)
1 La figura es de referencia. Sus datos no reflejan el caso práctico.
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 1 (haga clic para ampliar)
1 La figura es de referencia. Sus datos no reflejan el caso práctico.
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 1 (haga clic para ampliar)
1 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.
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)
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 regiones1 (haz clic para agrandar)
1 La figura es de referencia. Sus datos no reflejan el caso práctico.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[],[],null,["# Use case: Audit network performance\n===================================\n\nAssume that you're a network administrator who supports a network that includes\nseveral load-balanced applications. You've been asked to audit the network\nconfigurations that support those applications to ensure that the configurations\nare consistent with the expected state of your network. By doing this audit, you\ncan ensure that customers are getting the lowest possible latency to your\napplications.\n\nThe following use case demonstrates how Network Topology can help you\ncheck your existing configurations. For example, you can check that all client\nrequests are being served by application instances from the Google Cloud\nregion that's closest to the client. You can also ensure that cross-region\ntraffic is low because that traffic comes from databases that replicate data\nglobally.\n\nTopology overview\n-----------------\n\nThe deployment spans three Google Cloud regions (`us-central1`,\n`europe-west1`, and `asia-east1`). All external client requests are served by a\nsingle external Application Load Balancer that has multiple backends in each of the three\nregions. Client requests that come from one of three business regions (Americas,\nEMEA, and APAC) are served by application instances in the closest\nGoogle Cloud region.\n\nThe following graph shows the top-level hierarchy for the deployment.\n[](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-topology.png) Network Topology example topology (click to enlarge)\n\n### Resources and traffic paths\n\nIn this example, the project contains the following Google Cloud\nresources:\n\n- 1 HTTPS load balancer\n\n- 4 backend services: `browse`, `shopping_cart`, `checkout`, and `feeds`\n\n- 12 instance groups (which are the load balancer's backends)\n\n There is one instance group for each backend service in each of the three\n regions.\n- 3 database instances, one in each region\n\nYou expect that traffic from certain countries goes to the following\nlocations:\n\n- Traffic from countries in the `Americas` business region goes to backends in the `us-central1` region. For example, traffic from an external client in Canada travels through the load balancer to the `checkout` backend in the `us-central1` region.\n- Traffic from countries in the `EMEA` business region goes to backends in the `europe-west1` region. For example, traffic from an external client in Poland travels through the load balancer to the `checkout` backend in the `europe-west1` region.\n- Traffic from countries in the `APAC` business region goes to backends in the `asia-east1` region. For example, traffic from an external client in Japan travels through the load balancer to the `checkout` backend in the `asia-east1` region.\n- Traffic to a database instance comes from a backend in the same region. For example, the backends in `asia-east1` send data only to the database instance in `asia-east1`.\n- Cross-region traffic is limited to database replication. For example, traffic between `us-central1` and `europe-west1` travels only between database instances in those regions.\n\nUnexpected traffic flow\n-----------------------\n\nIn this scenario, you discover that traffic from the `EMEA` business region\nis now going to two different Google Cloud regions, `us-central1` and\n`europe-west1`. By using Network Topology, you discover that one of\nthe backends is overutilized.\n\n1. You want to check that external traffic that is going through the load\n balancer eventually goes to the correct Google Cloud region. You filter\n the graph to show only the traffic for your external load balancer\n `shopping-site-lb`.\n\n After you apply the filter, Network Topology shows only the\n connections related to the load balancer, as shown in the following example.\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-filter.png) Filter for a load balancer (click to enlarge)\n2. You hold the pointer over each business region to highlight the communication\n to that region.\n\n When you hold the pointer over **Americas** and **APAC** , you see traffic\n going to the nearest Google Cloud region: `us-central1` and `asia-\n east1` respectively. However, when you hold the pointer over **EMEA** , you\n see traffic going to `us-central1` and `europe-west1`. Ideally, to reduce\n latency, all traffic from EMEA should go to `europe-west1`.\n3. Next, you click **EMEA** to study the throughput between it and the\n Google Cloud regions. Network Topology overlays bandwidth\n values on each connection. You see that about 0.58 bytes per second is\n going to `us-central1` and 29.9 kilobytes per second is going\n to `europe-west1`. You know that most of the traffic is being directed as\n you would expect, but some traffic is flowing to `us-central1`.\n\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-bandwidth.png) Overlaid bandwidth values^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the use\n case.\n4. To investigate further, you expand `us-central1` to view where traffic is\n going. Because there's only one network with a single subnet in that region,\n Network Topology doesn't show those levels of the hierarchy and\n skips to the instance groups.\n\n You see that traffic is going to an instance group that's associated with the load\n balancer's backend service. Because it's a relatively small amount of traffic\n going to `europe-west1`, it's possible that resources in `europe-west1` are\n overutilized and causing traffic to overflow to `us-central1`.\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-traffic.png) Traffic path^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the use\n case.\n5. To confirm your conclusion, you expand the `europe-west1` region until you\n reach the instance that is associated with the same load balancer's backend\n service. Network Topology shows time-series charts in the details\n pane for the instance.\n\n In the chart, you notice that the CPU utilization rate is at 81% for the\n instance. The threshold for this example is 80%, indicating that the instance\n is oversubscribed. You resolve this issue by scaling up the instance group so\n that traffic returns to the ideal flow.\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-chart.png) Time-series chart for an instance^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the\n use case.\n\nInter-region traffic\n--------------------\n\nIn the following section, you check that internal traffic between regions\nis limited to only database instance traffic.\n\n1. To focus on internal traffic, in the **Topology configuration** list, you select\n only the **Instances** and **Cloud NAT gateways** checkboxes. Because you are only\n viewing traffic within your application, you don't need to see external clients\n and external load balancer traffic.\n\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-internalonly.png) Showing internal-only traffic (click to enlarge)\n2. You expand the `asia-east1` region, and you see five instance groups. They are\n not aggregated by network, subnet, or zone because\n they are all in the same network, subnet, and so on.\n\n You notice that only one instance group (`db-group-asia`) contains a path\n for inter-region traffic. All other instance groups are communicating within\n the region.\n\n You continue to expand the `db-group-asia` group until you reach the base\n entity. In this scenario, the base entity is a virtual machine (VM) instance\n (`db-instance-asia`) that acts as a database server. It's communicating with\n other regions to replicate data, which is what you expected, so no further\n investigations are required.\n ̦\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-dbtraffic.png) Inter-region traffic^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the\n use case.\n\n \u003cbr /\u003e\n\nWhat's next\n-----------\n\n- [Monitor your networking configuration with Network Topology](/network-intelligence-center/docs/network-topology/how-to/audit-troubleshoot-networking-issues)\n- [Use case: Troubleshoot network connectivity](/network-intelligence-center/docs/network-topology/concepts/troubleshooting-network-connectivity)\n- [Troubleshoot Network Topology](/network-intelligence-center/docs/network-topology/support/troubleshooting)"]]
