Vários frontends para Balanceador de Carga do Azure

Balanceador de Carga do Azure permite carregar serviços de equilíbrio em várias portas, vários endereços IP, ou ambos. Pode utilizar definições de balançadores de carga públicas e internas para carregar fluxos de equilíbrio através de um conjunto de VMs.

Este artigo descreve os fundamentos desta capacidade, conceitos importantes e constrangimentos. Se pretender expor os serviços num endereço IP, pode encontrar instruções simplificadas para configurações de balançadores de carga públicos ou internos . Adicionar vários frontends é incremental a uma única configuração frontal. Utilizando os conceitos deste artigo, pode expandir uma configuração simplificada a qualquer momento.

Quando define uma Balanceador de Carga do Azure, uma configuração frontal e uma configuração de piscina de backend estão ligadas às regras. A sonda de saúde referenciada pela regra é usada para determinar como novos fluxos são enviados para um nó na piscina de backend. O frontend (também conhecido como VIP) é definido por um endereço IP composto por um endereço IP (público ou interno), um protocolo de transporte (UDP ou TCP), e um número de porta da regra de equilíbrio de carga. O pool backend é uma coleção de configurações IP da Máquina Virtual (parte do recurso NIC) que referem o pool de backend Balanceador de Carga.

A tabela a seguir contém algumas configurações de frontend de exemplo:

Front-end Endereço IP protocolo porta
1 65.52.0.1 TCP 80
2 65.52.0.1 TCP 8080
3 65.52.0.1 UDP 80
4 65.52.0.2 TCP 80

A mesa mostra quatro frontends diferentes. Frontends #1, #2 e #3 são um frontend único com várias regras. O mesmo endereço IP é utilizado mas a porta ou protocolo é diferente para cada frontend. Os frontends #1 e #4 são um exemplo de múltiplos frontends, onde o mesmo protocolo frontal e porta são reutilizados em vários frontends.

Balanceador de Carga do Azure proporciona flexibilidade na definição das regras de equilíbrio da carga. Uma regra declara como um endereço e porta na parte frontal é mapeado para o endereço de destino e porto no backend. Se as portas de backend são ou não reutilizadas através das regras depende do tipo de regra. Cada tipo de regra tem requisitos específicos que podem afetar a configuração do hospedeiro e o design da sonda. Existem dois tipos de regras:

  1. A regra padrão sem reutilização da porta de backend
  2. A regra IP flutuante onde as portas de backend são reutilizadas

Balanceador de Carga do Azure permite misturar ambos os tipos de regras na mesma configuração do balançador de carga. O equilibrador de carga pode usá-los simultaneamente para um determinado VM, ou qualquer combinação, desde que cumpra os constrangimentos da regra. O tipo de regra que escolher depende dos requisitos da sua aplicação e da complexidade de suportar essa configuração. Deve avaliar quais os tipos de regras que são melhores para o seu cenário.

Exploramos ainda mais estes cenários a partir do comportamento padrão.

Regra tipo #1: Sem reutilização da porta de backend

Multiple frontend illustration with green and purple frontend

Neste cenário, os frontends são configurados da seguinte forma:

Front-end Endereço IP protocolo porta
green frontend 1 65.52.0.1 TCP 80
purple frontend 2 65.52.0.2 TCP 80

O DIP é o destino do fluxo de entrada. Na piscina de backend, cada VM expõe o serviço desejado numa porta única num DIP. Este serviço está associado ao frontend através de uma definição de regra.

Definimos duas regras:

Regra Frontend do mapa Para apoiar piscina
1 green frontend Frontend1:80 green backend DIP1:80, green backend DIP2:80
2 VIP Frontend2:80 purple backend DIP1:81, purple backend DIP2:81

O mapeamento completo em Balanceador de Carga do Azure é agora o seguinte:

Regra Endereço IP frontend protocolo porta Destino porta
green rule 1 65.52.0.1 TCP 80 Endereço IP DIP 80
purple rule 2 65.52.0.2 TCP 80 Endereço IP DIP 81

Cada regra deve produzir um fluxo com uma combinação única de endereço IP de destino e porta de destino. Ao variar a porta de destino do fluxo, várias regras podem fornecer fluxos para o mesmo DIP em diferentes portas.

As sondas de saúde são sempre direcionadas para o DIP de um VM. Deve certificar-se de que a sua sonda reflete a saúde do VM.

Regra nº 2: reutilização da porta de backend utilizando IP flutuante

Balanceador de Carga do Azure proporciona a flexibilidade para reutilizar a porta frontal através de vários frontends, independentemente do tipo de regra utilizado. Além disso, alguns cenários de aplicação preferem ou exigem que a mesma porta seja usada por múltiplas instâncias de aplicação num único VM na piscina de backend. Exemplos comuns de reutilização portuária incluem agrupamento para alta disponibilidade, aparelhos virtuais de rede e exposição de vários pontos finais TLS sem reen encriptação.

Se pretender reutilizar a porta de backend através de várias regras, deve ativar o IP flutuante na definição de regra.

"IP flutuante" é a terminologia de Azure para uma parte do que é conhecido como Retorno do Servidor Direto (DSR). A DSR é constituída por duas partes: uma topologia de fluxo e um esquema de mapeamento de endereços IP. A nível da plataforma, Balanceador de Carga do Azure opera sempre numa topologia de fluxo DSR, independentemente de o IP flutuante estar ou não ativado. Isto significa que a parte de saída de um fluxo é sempre corretamente reescrita para fluir diretamente de volta à origem.

Com o tipo de regra padrão, o Azure expõe um esquema tradicional de mapeamento de endereço IP de equilíbrio de carga para facilitar a utilização. Permitir alterações ip flutuantes o sistema de mapeamento de endereços IP para permitir uma flexibilidade adicional, conforme explicado abaixo.

O seguinte diagrama ilustra esta configuração:

Multiple frontend illustration with green and purple frontend with DSR

Para este cenário, cada VM na piscina de backend tem três interfaces de rede:

  • DIP: um NIC Virtual associado ao VM (configuração IP do recurso NIC da Azure)
  • Frontend 1: uma interface loopback dentro do so convidado que está configurado com endereço IP do Frontend 1
  • Frontend 2: uma interface loopback dentro do so convidado que está configurado com endereço IP do Frontend 2

Para cada VM na piscina de backend, executar os seguintes comandos num Windows Comando De comando.

Para obter a lista de nomes de interface que tem no seu VM, digite este comando:

netsh interface show interface 

Para o VM NIC (Azure gerido), digite este comando:

netsh interface ipv4 set interface “interfacename” weakhostreceive=enabled

(substituir o nome de interface pelo nome desta interface)

Para cada interface de backback que adicionou, repita estes comandos:

netsh interface ipv4 set interface “interfacename” weakhostreceive=enabled 

(substituir o nome de interface pelo nome desta interface loopback)

netsh interface ipv4 set interface “interfacename” weakhostsend=enabled 

(substituir o nome de interface pelo nome desta interface loopback)

Importante

A configuração das interfaces loopback é realizada dentro do so convidado. Esta configuração não é executada ou gerida pela Azure. Sem esta configuração, as regras não funcionarão. As definições da sonda de saúde utilizam o DIP do VM em vez da interface loopback que representa o DSR Frontend. Por isso, o seu serviço deve fornecer respostas de sonda numa porta DIP que reflitam o estado do serviço oferecido na interface loopback que representa o DSR Frontend.

Vamos assumir a mesma configuração frontal que no cenário anterior:

Front-end Endereço IP protocolo porta
green frontend 1 65.52.0.1 TCP 80
purple frontend 2 65.52.0.2 TCP 80

Definimos duas regras:

Regra Front-end Mapa para piscina de backend
1 green rule Frontend1:80 green backend Frontend1:80 (em VM1 e VM2)
2 purple rule Frontend2:80 purple backend Frontend2:80 (em VM1 e VM2)

A tabela a seguir mostra o mapeamento completo no equilibrador de carga:

Regra Endereço IP frontend protocolo porta Destino porta
green rule 1 65.52.0.1 TCP 80 o mesmo que frontend (65.52.0.1) o mesmo que frontend (80)
purple rule 2 65.52.0.2 TCP 80 o mesmo que frontend (65.52.0.2) o mesmo que frontend (80)

O destino do fluxo de entrada é o endereço IP frontend na interface loopback no VM. Cada regra deve produzir um fluxo com uma combinação única de endereço IP de destino e porta de destino. Ao variar o endereço IP de destino do fluxo, a reutilização portuária é possível no mesmo VM. O seu serviço está exposto ao equilibrador de carga ligando-o ao endereço IP e porta da respetiva interface loopback.

Note que este exemplo não altera a porta de destino. Apesar de este ser um cenário de IP flutuante, Balanceador de Carga do Azure também suporta a definição de uma regra para reescrever a porta de destino backend e torná-la diferente da porta de destino frontend.

O tipo de regra IP flutuante é a base de vários padrões de configuração do balançador de carga. Um exemplo que está atualmente disponível é a configuração SQL AlwaysOn com múltiplos ouvintes. Com o tempo, documentaremos mais destes cenários.

Limitações

  • Várias configurações frontend são suportadas apenas com IaaS VMs e conjuntos de escala de máquina virtual.
  • Com a regra IP flutuante, a sua aplicação deve utilizar a configuração IP primária para fluxos SNAT de saída. Se a sua aplicação se ligar ao endereço IP frontal configurado na interface loopback no so convidado, o SNAT de saída do Azure não está disponível para reescrever o fluxo de saída e o fluxo falha. Rever cenários de saída.
  • O IP flutuante não é atualmente suportado em configurações ip secundárias para cenários internos de equilíbrio de carga.
  • Os endereços IP públicos têm um efeito na faturação. Para mais informações, consulte os preços do endereço IP
  • Aplicam-se limites de subscrição. Para mais informações, consulte os limites de Serviço para mais detalhes.

Passos seguintes