Caso de uso 1: hub privado e spoke com VNF transparente e tráfego de spoke para spoke

A Figura 1 ilustra um VNF transparente sendo usado dentro da VPC de trânsito (hub) para processar o tráfego de dados dentro dos spokes da VPC.

Os recursos a seguir são configurados:

• O hub VPC contém o NLB privado, que é configurado em "Modo de roteamento" e os VNFs transparentes são incluídos no seu conjunto para ativar o HA.
• VPC-spoke#1 contém um IBM Cloud Application Load Balancer (ALB) for VPC privado com um conjunto que contém as sub-redes de carga de trabalho para zone1 (10.174.0.0/24) e zone2 (10.174.4.0/24).
• VPC-spoke#2 contém um ALB privado com um conjunto que contém a sub-rede de carga de trabalho para zone1 (10.174.2.0/24).
• Um gateway de trânsito gerencia as interconexões entre o hub e os spokes.
• A spoofing de IP na interface VNF é o próximo hop no hub.

Uma carga de trabalho em VPC-spoke#1 zone1 que precisa se comunicar com uma carga de trabalho em VPC-spoke#2 zone1 deve atravessar o VNF no VPC-hub. Uma rota de egresso da sub-rede VPC-spoke#1 (10.174.0.0/24) destinada a VPC-spoke#2 (10.174.2.0/24) que salta por meio do VPC-hub NLB (10.175.0.4) permite que o tráfego de saída chegue ao seu destino. Uma rota de egresso semelhante é criada em VPC-spoke#2, o que permite que a resposta também atravesse o VPC-hub. Para cargas de trabalho em VPC-spoke#1 zone2, uma rota de egresso semelhante também é criada para o tráfego de saída.

Por fim, como o NLB pode sofrer uma falha e exigir uma atualização do próximo salto, é criada uma rota de entrada com o gateway de trânsito como origem, a fim de garantir que o endereço IP do NLB seja atualizado em caso de falha. O NLB pode atualizar rotas customizadas somente dentro de sua VPC (VPC-hub) e não pode atualizar rotas automaticamente nas VPCs spoke.

Caso de uso 2: VNF transparente de HA ativo/ativo (VPC de região única multizona)

A Figura 2 ilustra uma Virtual Network Function (VNF) ativa/ativa transparente e altamente disponível. Esta topologia de implementação assegura que a rede e seus serviços estejam sempre ativados, sempre acessíveis e que as sessões ativas sejam sempre mantidas sem interrupção.

Como esse VNF é transparente, o cliente (origem) faz uma solicitação TCP para a instância de servidor virtual de destino (destino) em 10.241.66.5 em vez do endereço IP do firewall.

Uma rota customizada de egresso foi criada para assegurar que pacotes de dados do cliente (10.241.0.6) direcionados ao destino (10.241.66.5) saltem por meio do NLB. Como o NLB é configurado com o modo de roteamento ativado, as solicitações TCP em todas as portas são encaminhadas automaticamente para seus destinos. Como os VNFs estão no conjunto do NLB, eles são o próximo hop depois do NLB. Neste exemplo de região única Ativa/Ativa, uma rota de egresso também é necessária para assegurar que o pacote de retorno do destino salte por meio do NLB na trip de retorno, em seguida, por meio do mesmo VNF pelo qual foi enviado e, finalmente, de volta para o cliente. Nesse caso de uso, o cliente está em uma zona diferente do destino, mas o destino está na mesma zona que o NLB e o VNF.

Caso de uso 3: Multizona e alta disponibilidade por meio de roteamento assimétrico

A configuração a seguir só pode ser usada com um NLB privado habilitado para o modo de rota e com um algoritmo de pool de encaminhamento ponderado.

A Figura 3 ilustra um balanceador de carga de rede (NLB) em modo de rota privada, projetado para fornecer alta disponibilidade em múltiplas zonas por meio de roteamento assimétrico. Nessa arquitetura, o tráfego dos consumidores chega ao VPC do hub do provedor por meio de um link direto, um gateway de trânsito ou pela internet. O NLB no modo de rota privada, então, encaminha o tráfego por meio de um Transit Gateway para instâncias de servidor virtual localizadas na VPC spoke. Quando o encaminhamento ponderado está ativado, o tráfego que se origina e termina na mesma zona segue um caminho simétrico. O projeto também oferece suporte ao roteamento assimétrico, permitindo que o tráfego de retorno siga um caminho diferente do da solicitação original, sem depender do estado de uma conexão existente.

Por exemplo, um pacote de solicitação pode entrar no serviço por meio de um NLB na Zona 1 e ser encaminhado para um servidor virtual na VPC 1, enquanto o pacote de resposta retorna por meio do NLB na Zona 2. Como o encaminhamento é independente do caminho da conexão original, a resposta é aceita e encaminhada corretamente. Os pesos configurados continuam a influenciar a forma como o tráfego é distribuído em cada NLB, permitindo que os operadores direcionem mais tráfego para back-ends de maior capacidade, ao mesmo tempo em que mantêm a alta disponibilidade em várias zonas.

Essa arquitetura também oferece alta disponibilidade regional. Os anúncios de rota são automaticamente retirados em caso de interrupção na zona, perda de todas as instâncias ativas do firewall ou indisponibilidade de todos os dispositivos NLB ativos. Esse comportamento ajuda a evitar que o tráfego seja direcionado para recursos indisponíveis e garante que ele seja roteado apenas para zonas em bom estado.

Antes de Iniciar

Assegure-se de que você tenha as permissões necessárias do IAM para configurar o roteamento customizado e ativar o spoofing de IP.

Introdução

Siga estas etapas básicas para configurar a alta disponibilidade para VNFs da IBM Cloud suportados:

1. Analise os problemas conhecidos das funções de rede virtual.
2. Configure recursos de VPC.
3. Configure grupos de segurança.
4. Implemente um VNF.
5. Crie um balanceador de carga de rede com o modo de roteamento.
6. Configure rotas customizadas.

Limitações do VNF

As implementações de função de rede virtual (VNF) de alta disponibilidade (HA) têm a seguinte limitação conhecida:

• O Virtual Network Function (VNF) deve compartilhar uma sub-rede com o Balanceador de Carga de Rede (NLB).