Alta disponibilidade do Gateway de RAS
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versões 21H2 e 20H2
Você pode usar este tópico para saber mais sobre as configurações de alta disponibilidade para o Gateway Multilocatário de RAS para SDN (Rede Definida pelo Software).
Este tópico inclui as seções a seguir.
Visão geral do Gateway de RAS
Se a organização for um CSP (Provedor de Serviços de Nuvem) ou uma Empresa com vários locatários, será possível implantar o Gateway de RAS no modo multilocatário para fornecer roteamento de tráfego de rede de e para redes virtuais e físicas, incluindo a Internet.
É possível implantar o Gateway de RAS no modo multilocatário como um gateway de borda para rotear o tráfego de rede de clientes de locatário para recursos e redes virtuais de locatários.
Ao implantar várias instâncias de VMs de Gateway de RAS que fornecem alta disponibilidade e failover, você estará implantando um pool de gateway. No Windows Server 2012 R2, todas as VMs de gateway formavam um único pool, o que dificultava um pouco a separação lógica da implantação do gateway. O gateway do Windows Server 2012 R2 ofereceu uma implantação de redundância 1:1 para as VMs de gateway, o que resultou na subutilização da capacidade disponível para conexões VPN site a site (S2S).
Esse problema foi resolvido no Windows Server 2016, que fornece vários pools de gateway, que podem ser de diferentes tipos para a separação lógica. O novo modo de redundância M+N permite uma configuração de failover mais eficiente.
Para obter mais informações gerais sobre o Gateway de RAS, consulte Gateway de RAS.
Visão geral de pools de Gateway
No Windows Server 2016, é possível implantar gateways em um ou mais pools.
A ilustração a seguir mostra os diferentes tipos de pools de gateway que fornecem roteamento de tráfego entre redes virtuais.
Cada pool tem as seguintes propriedades.
Cada pool é redundante em M+N. Isso significa que um número 'M' de VMs de gateway ativo tem suporte de um número 'N' de VMs de gateway em espera. O valor de N (gateways em espera) é sempre menor ou igual a M (gateways ativos).
Um pool poderá executar qualquer uma das funções de gateway individuais – site a site de IKEv2 (protocolo IKE versão 2), L3 (Camada 3) e GRE (Encapsulamento de Roteamento Genérico) – ou o pool poderá executar todas essas funções.
É possível atribuir um único endereço IP público a todos os pools ou a um subconjunto de pools. Isso reduz muito o número de endereços IP públicos que deverão ser usados porque é possível que todos os locatários conectem a nuvem em um único endereço IP. A seção a seguir, sobre Alta Disponibilidade e Balanceamento de carga, descreve como isso funciona.
É possível escalar verticalmente ou reduzir verticalmente um pool de gateway, adicionando ou removendo com facilidade as VMs de gateway no pool. A remoção ou adição de gateways não interrompe os serviços fornecidos por um pool. Também é possível adicionar e remover pools inteiros de gateways.
As conexões de um único locatário podem ser terminadas em vários pools e em vários gateways em um pool. No entanto, se um locatário tiver conexões que terminam em um pool de gateways de tipo Todos ele não poderá assinar outros pools de gateways de tipo Todos ou de tipo individual.
Os pools de gateway também fornecem a flexibilidade para habilitar cenários adicionais:
Pools de locatário único, é possível criar um pool para ser usado por um locatário.
Se você estiver vendendo serviços de nuvem por meio de canais de parceiros (revendedores), poderá criar conjuntos separados de pools para cada revendedor.
Vários pools podem fornecer a mesma função de gateway, mas com capacidades diferentes. Por exemplo, é possível criar um pool de gateways que dê suporte a conexões site a site de IKEv2 de alta e de baixa taxa de transferência.
Visão geral da implantação do Gateway de RAS
A ilustração a seguir demonstra uma implantação típica do CSP (Provedor de Serviços de Nuvem) do Gateway de RAS.
Com esse tipo de implantação, os pools de gateway são implantados em um SLB (Balanceador de Carga de Software), que permite que o CSP atribua um único endereço IP público para toda a implantação. Várias conexões de gateway de um locatário podem terminar em vários pools de gateway e também em vários gateways em um pool. Isso é ilustrado por meio de conexões site a site de IKEv2 no diagrama acima, mas o mesmo também é aplicável a outras funções de gateway, como gateways GRE e L3.
Na ilustração, o dispositivo BGP de MT é um Gateway Multilocatário de RAS com BGP. BGP multilocatário é usado para roteamento dinâmico. O roteamento para um locatário é centralizado, um ponto único, chamado de RR (refletor de rota), manipula o emparelhamento via protocolo BGP para todos os sites de locatários. O RR em si é distribuído entre todos os gateways em um pool. Isso resulta em uma configuração em que as conexões de um locatário (caminho de dados) terminam em vários gateways, mas o RR para o locatário (ponto de emparelhamento via protocolo BGP, caminho de controle) está em apenas um dos gateways.
O roteador de BGP é separado no diagrama para representar esse conceito de roteamento centralizado. A implementação de BGP do gateway também fornece roteamento de trânsito, o que permite que a nuvem atue como um ponto de trânsito para o roteamento entre dois locais de locatário. Esses recursos de BGP são aplicáveis a todas as funções de gateway.
Integração do Gateway de RAS com o Controlador de Rede
O Gateway de RAS está totalmente integrado ao Controlador de Rede no Windows Server 2016. Quando o Gateway de RAS e o Controlador de Rede são implantados, o Controlador de Rede executa as seguintes funções.
Implantação dos pools de gateway
Configuração de conexões de locatário em cada gateway
Alternar fluxos de tráfego de rede para um gateway em espera no caso de uma falha de gateway
As seções a seguir fornecem as informações detalhadas sobre o Gateway de RAS e o Controlador de Rede.
Provisionamento e Balanceamento de carga de conexões de Gateway (IKEv2, L3 e GRE)
Quando um locatário solicita uma conexão de gateway, a solicitação é enviada ao Controlador de Rede. O Controlador de Rede é configurado com as informações sobre todos os pools de gateway, incluindo a capacidade de cada pool e cada gateway em cada pool. O Controlador de Rede seleciona o pool e o gateway corretos para a conexão. Essa seleção é baseada no requisito de largura de banda para a conexão. O Controlador de Rede usa um algoritmo de "melhor ajuste" para escolher as conexões com eficiência em um pool. Se essa for a primeira conexão do locatário, o ponto de emparelhamento via protocolo BGP para a conexão também será designado neste momento.
Após o Controlador de Rede selecionar um Gateway de RAS para a conexão, o Controlador de Rede fornecerá a configuração necessária para a conexão no gateway. Se a conexão for uma conexão site a site de IKEv2, o Controlador de Rede também provisionará uma regra NAT (conversão de endereços de rede) no pool de SLB. Essa regra NAT no pool de SLB direcionará as solicitações de conexão do locatário para o gateway designado. Os locatários são diferenciados pelo IP de origem, que deverá ser exclusivo.
Observação
As conexões de GRE e L3 ignoram o SLB e conectam diretamente o Gateway de RAS designado. Essas conexões exigem que o roteador do ponto de extremidade remoto (ou outro dispositivo de terceiros) seja configurado corretamente para conectar o Gateway de RAS.
Se o roteamento de BGP estiver habilitado para a conexão, o emparelhamento via protocolo BGP será iniciado pelo Gateway de RAS, e, as rotas serão trocadas entre gateways locais e de nuvem. As rotas que são aprendidas pelo BGP (ou que são rotas configuradas estaticamente se o BGP não for usado) são enviadas ao Controlador de Rede. Em seguida, o Controlador de Rede encaminha as rotas para os hosts do Hyper-V nos quais as VMs de locatário estão instaladas. Neste ponto, o tráfego de locatário poderá ser roteado para o site local correto. O Controlador de Rede também cria políticas de Virtualização de Rede Hyper-V associadas que especificam os locais de gateway e direcionam para os hosts do Hyper-V.
Alta disponibilidade para site a site de IKEv2
Um Gateway de RAS em um pool consiste em conexões e emparelhamento via protocolo BGP de diferentes locatários. Cada pool tem gateways ativos 'M' e gateways em espera 'N'.
O Controlador de Rede manipula a falha dos gateways da maneira a seguir.
O Controlador de Rede executa ping constantemente nos gateways em todos os pools e pode detectar um gateway que falhou ou está falhando. O Controlador de Rede pode detectar os seguintes tipos de falhas de Gateway de RAS.
Falha de VM do Gateway de RAS
Falha do host do Hyper-V no qual o Gateway de RAS está em execução
Falha no serviço do Gateway de RAS
O Controlador de Rede armazena a configuração de todos os gateways ativos implantados. A configuração consiste em configurações de conexão e configurações de roteamento.
Quando um gateway falha, isso afeta as conexões de locatários no gateway, bem como as conexões de locatários localizados em outros gateways, mas cujo RR reside no gateway com falha. O tempo inoperante das últimas conexões é menor que o anterior. Quando o Controlador de Rede detecta um gateway com falha, ele executa as seguintes tarefas.
Remove as rotas das conexões afetadas dos hosts de computação.
Remove as políticas de Virtualização de Rede Hyper-V nesses hosts.
Seleciona um gateway em espera, converte-o em um gateway ativo e configura o gateway.
Altera os mapeamentos da NAT no pool do SLB para apontar conexões para o novo gateway.
Simultaneamente, à medida que a configuração aparece no novo gateway ativo, as conexões site a site de IKEv2 e o emparelhamento via protocolo BGP são restabelecidos. As conexões e o emparelhamento via protocolo BGP podem ser iniciados pelo gateway de nuvem ou pelo gateway local. Os gateways atualizam as rotas e as enviam para o Controlador de Rede. Depois que o controlador de rede aprende as novas rotas descobertas pelos gateways, o Controlador de Rede envia as rotas e as políticas de Virtualização de Rede Hyper-V associadas aos hosts do Hyper-V em que residem as VMs dos locatários afetados pela falha. Essa atividade do Controlador de Rede é semelhante à circunstância de uma nova configuração de conexão, apenas ocorre em uma escala maior.
Alta disponibilidade para GRE
O processo de resposta de failover do Gateway de RAS pelo Controlador de Rede, incluindo detecção de falha, cópia de conexão e configuração de roteamento para o gateway em espera, failover de BGP/roteamento estático das conexões afetadas (incluindo a retirada e a reconexão de rotas em hosts de computação e reemparelhamento via protocolo BGP) e a reconfiguração de políticas de Virtualização de Rede Hyper-V em hosts de computação, é o mesmo para conexões e gateways GRE. No entanto, o restabelecimento das conexões de GRE ocorre de maneira diferente e a solução de alta disponibilidade para GRE possui alguns requisitos adicionais.
No momento da implantação do gateway, cada VM do gateway de RAS recebe um endereço DIP (IP Dinâmico). Além disso, cada VM de gateway também recebe um endereço VIP (IP Virtual) para alta disponibilidade de GRE. Os VIPs são atribuídos apenas a gateways em pools que podem aceitar conexões de GRE e não a pools não GRE. Os VIPs atribuídos são anunciados para os comutadores TOR (top of rack) usando BGP que, em seguida, anuncia os VIPs na rede física de nuvem. Isso torna os gateways acessíveis a partir de roteadores remotos ou dispositivos de terceiros em que reside a outra extremidade da conexão de GRE. Esse emparelhamento via protocolo BGP é diferente do emparelhamento via protocolo BGP no nível dos locatários para a troca de rotas de locatários.
No momento do provisionamento da conexão de GRE, o Controlador de Rede seleciona um gateway, configura um ponto de extremidade de GRE no gateway selecionado e retorna o endereço VIP do gateway atribuído. Em seguida, esse VIP é configurado como o endereço do túnel de GRE de destino no roteador remoto.
Quando um gateway falha, o Controlador de Rede copia o endereço VIP do gateway com falha e outros dados de configuração para o gateway em espera. Quando o gateway de espera se torna ativo, ele anuncia o VIP para o comutador TOR e também para a rede física. Os roteadores remotos continuam conectando os túneis de GRE ao mesmo VIP e a infraestrutura de roteamento garante que os pacotes sejam roteados para o novo gateway ativo.
Alta disponibilidade para Gateways de encaminhamento L3
Um gateway de encaminhamento L3 de Virtualização de Rede Hyper-V é uma ponte entre a infraestrutura física no datacenter e a infraestrutura virtualizada na nuvem de Virtualização de Rede Hyper-V. Em um gateway de encaminhamento L3 multilocatário, cada locatário usa a própria rede lógica marcada por VLAN para conectividade com a rede física do locatário.
Quando um novo locatário cria um novo gateway L3, o Gerenciador de Serviços de Gateway do Controlador de Rede seleciona uma VM de gateway disponível e configura uma nova interface de locatário com um endereço IP de espaço de CA (Endereço do Cliente) altamente disponível (da rede lógica marcada com VLAN do locatário). O endereço IP é usado como o endereço IP de mesmo nível no gateway remoto (rede física) e é o próximo salto para alcançar a rede de Virtualização de Rede Hyper-V do locatário.
Ao contrário das conexões de rede IPsec ou GRE, o comutador TOR não aprenderá a rede marcada por VLAN do locatário dinamicamente. O roteamento para a rede marcada com VLAN do locatário precisa ser configurado no comutador TOR e em todos os comutadores e roteadores intermediários entre a infraestrutura física e o gateway para garantir a conectividade de ponta a ponta. Veja a seguir um exemplo de configuração de Rede Virtual de CSP, conforme descrito na ilustração abaixo.
| Rede | Sub-rede | ID DA VLAN | Gateway Padrão |
|---|---|---|---|
| Rede Lógica L3 da Contoso | 10.127.134.0/24 | 1001 | 10.127.134.1 |
| Rede Lógica L3 da Woodgrove | 10.127.134.0/24 | 1002 | 10.127.134.1 |
A seguir, estão os exemplos de configurações de gateway de locatário, conforme representado na ilustração abaixo.
| Nome do locatário | Endereço IP de gateway L3 | ID DA VLAN | Endereço IP do par |
|---|---|---|---|
| Contoso | 10.127.134.50 | 1001 | 10.127.134.55 |
| Woodgrove | 10.127.134.60 | 1002 | 10.127.134.65 |
A seguir, está a ilustração dessas configurações em um datacenter de CSP.
As falhas de gateway, a detecção de falhas e o processo de failover de gateway no contexto de um gateway de encaminhamento L3 são semelhantes aos processos para Gateways de RAS de IKEv2 e GRE. As diferenças estão na maneira como os endereços IP externos são tratados.
Quando o estado da VM do gateway se torna não íntegro, o Controlador de Rede seleciona um dos gateways em espera do pool e provisiona novamente as conexões de rede e o roteamento no gateway em espera. Ao mover as conexões, o endereço IP do espaço de CA altamente disponível do gateway de encaminhamento L3 também é movido para a nova VM do gateway junto com o endereço IP de BGP do espaço de CA do locatário.
Como o endereço IP de emparelhamento de L3 é movido para a nova VM do gateway durante o failover, a infraestrutura física remota poderá conectar novamente esse endereço IP e, subsequentemente, alcançar a carga de trabalho de Virtualização de Rede Hyper-V. Para o roteamento dinâmico de BGP, conforme o endereço IP de BGP do espaço de CA for movido para a nova VM do gateway, o Roteador BGP remoto poderá restabelecer o emparelhamento e aprender todas as rotas de Virtualização de Rede Hyper-V novamente.
Observação
Será necessário configurar separadamente os comutadores TOR e todos os roteadores intermediários para usar a rede lógica marcada com VLAN para comunicação de locatários. Além disso, o failover de L3 é restrito apenas aos racks configurados dessa forma. Por esse motivo, o pool de gateway L3 deverá ser cuidadosamente configurado e a configuração manual deverá ser concluída separadamente.