Caso de uso: auditar o desempenho da rede

Suponha que você seja um administrador de rede que ofereça suporte a uma rede que inclua vários aplicativos com balanceamento de carga. Você foi solicitado a auditar as configurações de rede que suportam esses aplicativos para garantir que as configurações sejam consistentes com o estado esperado da rede. Ao fazer essa auditoria, você garante que os clientes estejam conseguindo a menor latência possível para seus aplicativos.

O caso de uso a seguir demonstra como a Topologia de Rede pode ajudá-lo a verificar suas configurações atuais. Por exemplo, você pode verificar se todas as solicitações de clientes estão sendo atendidas por instâncias de aplicativos da região do Google Cloud mais próxima do cliente. Você também pode garantir que o tráfego entre regiões seja baixo porque esse tráfego vem de bancos de dados que replicam dados globalmente.

Visão geral da topologia

A implantação abrange três regiões do Google Cloud (us-central1, europe-west1 e asia-east1). Todas as solicitações de clientes externos são veiculadas por um único balanceador de carga de aplicativo externo que tem vários back-ends em cada uma das três regiões. Solicitações de clientes provenientes de uma das três regiões de negócios (Américas, EMEA e APAC) são atendidas por instâncias de aplicativos na região mais próxima do Google Cloud.

O gráfico a seguir mostra a hierarquia de nível superior para a implantação.

Recursos e caminhos de tráfego

Neste exemplo, o projeto contém os seguintes recursos do Google Cloud:

  • 1 Balanceador de carga HTTPS

  • 4 serviços de back-end: browse, shopping_cart, checkout e feeds

  • 12 grupos de instâncias (que são os backends do balanceador de carga)

    Há um grupo de instâncias para cada serviço de back-end em cada uma das três regiões.

  • 3 instâncias de banco de dados, uma em cada região

Você espera que o tráfego de determinados países chegue aos seguintes locais:

  • O tráfego de países na região de negócios Americas vai para back-end na região us-central1. Por exemplo, o tráfego de um cliente externo no Canadá viaja pelo balanceador de carga para o back-end checkout na região us-central1.
  • O tráfego de países na região de negócios EMEA vai para back-end na região europe-west1. Por exemplo, o tráfego de um cliente externo na Polônia viaja pelo balanceador de carga para o back-end checkout na região europe-west1.
  • O tráfego de países na região de negócios APAC vai para back-end na região asia-east1. Por exemplo, o tráfego de um cliente externo no Japão viaja pelo balanceador de carga para o back-end checkout na região asia-east1.
  • O tráfego para uma instância de banco de dados vem de um back-end na mesma região. Por exemplo, os back-end em asia-east1 enviam dados apenas para a instância do banco de dados em asia-east1.
  • O tráfego entre regiões é limitado à replicação do banco de dados. Por exemplo, o tráfego entre us-central1 e europe-west1 viaja apenas entre instâncias de banco de dados nessas regiões.

Fluxo de tráfego inesperado

Nesse cenário, você descobre que o tráfego da região de negócios EMEA agora está indo para duas regiões diferentes do Google Cloud: us-central1 e europe-west1. Usando a Topologia de rede, você descobre que um dos back-ends está superutilizado.

  1. Você quer verificar se o tráfego externo que está passando pelo balanceador de carga acaba indo para a região correta do Google Cloud. Você filtra o gráfico para mostrar apenas o tráfego do seu balanceador de carga externo shopping-site-lb.

    Depois de aplicar o filtro, a Topologia de Rede mostra apenas as conexões relacionadas ao balanceador de carga, conforme mostrado no exemplo a seguir.

  2. Você mantém o ponteiro sobre cada região de negócios para destacar a comunicação com essa região.

    Quando você mantém o ponteiro sobre Américas e APAC, vê o tráfego indo para a região mais próxima do Google Cloud: us-central1 e asia- east1, respectivamente. No entanto, quando você mantém o ponteiro sobre EMEA, vê o tráfego indo para us-central1 e europe-west1. Idealmente, para reduzir a latência, todo o tráfego da EMEA precisa ir para europe-west1.

  3. Em seguida, clique em EMEA para estudar a taxa de transferência entre ela e as regiões do Google Cloud. A topologia de rede sobrepõe os valores da largura de banda em cada conexão. Você observa que cerca de 0,58 bytes por segundo são enviados para us-central1 e 29,9 kilobytes por segundo são enviados para europe-west1. Você sabe que a maior parte do tráfego está sendo direcionada como seria de esperar, mas algum tráfego está fluindo para us-central1.

    1 A figura é para referência. Seus dados não refletem o caso de uso.

  4. Para investigar mais, expanda us-central1 para ver para onde o tráfego está indo. Como há apenas uma rede com uma única sub-rede nessa região, a Topologia de Rede não mostra esses níveis da hierarquia e pula para os grupos de instâncias.

    Você vê que o tráfego está indo para um grupo de instâncias associado ao serviço de back-end do balanceador de carga. Como é uma quantidade relativamente pequena de tráfego indo para europe-west1, é possível que os recursos em europe-west1 sejam superutilizados fazendo com que o tráfego seja direcionado para us-central1.

    1 A figura é para referência. Seus dados não refletem o caso de uso.

  5. Para confirmar sua conclusão, expanda a região europe-west1 até chegar à instância que está associada ao mesmo serviço de back-end do balanceador de carga. A topologia de rede mostra gráficos de séries temporais no painel de detalhes da instância.

    No gráfico, você percebe que a taxa de utilização da CPU é de 81% para a instância. O limite para este exemplo é 80%, indicando que a instância está com excesso de assinaturas. Você resolve esse problema escalando o grupo de instâncias para que o tráfego retorne ao fluxo ideal.

    1 A figura é para referência. Seus dados não refletem o caso de uso.

Tráfego entre regiões

Na seção a seguir, verifique se o tráfego interno entre regiões está limitado apenas ao tráfego da instância do banco de dados.

  1. Para se concentrar no tráfego interno, na lista Configuração de topologia, marque apenas as caixas de seleção Instâncias e Gateways do Cloud NAT. Como você está visualizando apenas o tráfego no seu aplicativo, não precisa ver clientes externos nem o tráfego do balanceador de carga externo.

  2. Você expande a região asia-east1 e vê cinco grupos de instâncias. Eles não são agregados por rede, sub-rede ou zona, porque estão todos na mesma rede, sub-rede e assim por diante.

    Você percebe que apenas um grupo de instâncias (db-group-asia) contém um caminho para o tráfego entre regiões. Todos os outros grupos de instâncias estão se comunicando na região.

    Você continua a expandir o grupo db-group-asia até chegar à entidade base. Nesse cenário, a entidade base é uma instância de máquina virtual (VM, na sigla em inglês) (db-instance-asia) que atua como um servidor de banco de dados. Ele está se comunicando com outras regiões para replicar dados, o que você esperava, portanto, nenhuma investigação adicional é necessária. ̦

    1 A figura é para referência. Seus dados não refletem o caso de uso.

A seguir