Exemplo de utilização: auditar o desempenho da rede

Suponha que é um administrador de rede que suporta uma rede que inclui várias aplicações com equilíbrio de carga. Foi-lhe pedido que audite as configurações de rede que suportam essas aplicações para garantir que as configurações são consistentes com o estado esperado da sua rede. Ao fazer esta auditoria, pode garantir que os clientes estão a receber a latência mais baixa possível para as suas aplicações.

O exemplo de utilização seguinte demonstra como a topologia de rede pode ajudar a verificar as suas configurações existentes. Por exemplo, pode verificar se todos os pedidos de clientes estão a ser publicados por instâncias da aplicação da região mais próxima do cliente. Google CloudTambém pode garantir que o tráfego entre regiões é baixo, uma vez que esse tráfego provém de bases de dados que replicam dados a nível global.

Vista geral da topologia

A implementação abrange três Google Cloud regiões (us-central1, europe-west1 e asia-east1). Todos os pedidos de clientes externos são publicados por um único Application Load Balancer externo que tem vários back-ends em cada uma das três regiões. Os pedidos de clientes provenientes de uma das três regiões empresariais (Américas, EMEA e APAC) são publicados por instâncias da aplicação naGoogle Cloud região mais próxima.

O gráfico seguinte mostra a hierarquia de nível superior da implementação.

Recursos e caminhos de tráfego

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

  • 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 back-ends do balanceador de carga)

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

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

Espera que o tráfego de determinados países se dirija às seguintes localizações:

  • O tráfego de países na região empresarial Americas é encaminhado para back-ends na região us-central1. Por exemplo, o tráfego de um cliente externo no Canadá viaja através do balanceador de carga para o back-end checkout na região us-central1.
  • O tráfego de países na região empresarial EMEA é encaminhado para back-ends na região europe-west1. Por exemplo, o tráfego de um cliente externo na Polónia passa pelo balanceador de carga para o back-end checkout na região europe-west1.
  • O tráfego de países na região empresarial APAC é encaminhado para back-ends na região asia-east1. Por exemplo, o tráfego de um cliente externo no Japão passa pelo balanceador de carga para o back-end checkout na região asia-east1.
  • O tráfego para uma instância da base de dados provém de um back-end na mesma região. Por exemplo, os backends em asia-east1 enviam dados apenas para a instância da base de dados em asia-east1.
  • O tráfego entre regiões está limitado à replicação da base de dados. Por exemplo, o tráfego entre us-central1 e europe-west1 viaja apenas entre instâncias da base de dados nessas regiões.

Fluxo de tráfego inesperado

Neste cenário, descobre que o tráfego da EMEAregião empresarial Google Cloud está agora a ser direcionado para duas regiões diferentes: us-central1 e europe-west1. Ao usar a topologia de rede, descobre que um dos back-ends está sobreutilizado.

  1. Quer verificar se o tráfego externo que passa pelo balanceador de carga acaba por ir para a Google Cloud região correta. 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 ligações relacionadas com o equilibrador de carga, conforme mostrado no exemplo seguinte.

  2. Passe o ponteiro sobre cada região empresarial para realçar a comunicação para essa região.

    Quando passa o ponteiro do rato sobre Américas e APAC, vê o tráfego que se dirige para a Google Cloud região mais próxima: us-central1 e asia- east1, respetivamente. No entanto, quando passa o cursor sobre EMEA, vê o tráfego a direcionar-se para us-central1 e europe-west1. Idealmente, para reduzir a latência, todo o tráfego da região EMEA deve ser encaminhado para europe-west1.

  3. Em seguida, clique em EMEA para estudar o débito entre esta e as regiõesGoogle Cloud . A topologia de rede sobrepõe valores de largura de banda em cada ligação. Vê que cerca de 0,58 bytes por segundo estão a ser enviados para us-central1 e 29,9 kilobytes por segundo estão a ser enviados para europe-west1. Sabe que a maior parte do tráfego está a ser direcionada como esperado, mas algum tráfego está a fluir para us-central1.

    1A figura é para referência. Os respetivos dados não refletem o exemplo de utilização.

  4. Para investigar mais aprofundadamente, expanda us-central1 para ver para onde o tráfego está a ir. Uma vez que existe apenas uma rede com uma única sub-rede nessa região, a topologia de rede não mostra esses níveis da hierarquia e passa para os grupos de instâncias.

    Verifica que o tráfego está a ser encaminhado para um grupo de instâncias associado ao serviço de back-end do balanceador de carga. Uma vez que se trata de uma quantidade relativamente pequena de tráfego que se destina ao europe-west1, é possível que os recursos no europe-west1 estejam sobreutilizados e a causar um excesso de tráfego para o us-central1.

    1A figura é para referência. Os respetivos dados não refletem o exemplo de utilização.

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

    No gráfico, repara que a taxa de utilização da CPU é de 81% para a instância. O limite para este exemplo é de 80%, o que indica que a instância tem subscrições em excesso. Resolva este problema ao aumentar a escala do grupo de instâncias para que o tráfego regresse ao fluxo ideal.

    1A figura é para referência. Os respetivos dados não refletem o exemplo de utilização.

Tráfego entre regiões

Na secção seguinte, verifica se o tráfego interno entre regiões está limitado apenas ao tráfego de instâncias da base de dados.

  1. Para se concentrar no tráfego interno, na lista Configuração da topologia, selecione apenas as caixas de verificação Instâncias e Gateways NAT da nuvem. Uma vez que só está a ver o tráfego na sua aplicação, não precisa de ver clientes externos nem tráfego do equilibrador de carga externo.

  2. Expande a região asia-east1 e vê cinco grupos de instâncias. Não são agregados por rede, sub-rede ou zona porque estão todos na mesma rede, sub-rede, etc.

    Repara 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 a comunicar na região.

    Continua a expandir o grupo db-group-asia até chegar à entidade base. Neste cenário, a entidade base é uma instância de máquina virtual (VM) (db-instance-asia) que funciona como um servidor de base de dados. Está a comunicar com outras regiões para replicar dados, que é o que esperava, pelo que não são necessárias mais investigações. ̦

    1A figura é para referência. Os respetivos dados não refletem o exemplo de utilização.

O que se segue?