Trabalhando com a alta disponibilidade (HA) e o VRRP
O IBM Cloud® Virtual Router Appliance (VRA) suporta o Virtual Router Redundancy Protocol (VRRP) como um protocolo de alta disponibilidade. A implementação de dispositivos é feita de uma maneira ativa/passiva, na qual uma máquina é a principal e a outra é o backup. Todas as interfaces em ambas as máquinas são um membro do mesmo "sync-group", portanto, se uma interface sofrer uma falha, as outras no mesmo grupo também sofrerão falhas e o dispositivo deixará de ser principal. O backup atual detecta que o principal não está mais transmitindo mensagens keep-alive/pulsação, assume o controle dos IPs virtuais do VRRP e se torna principal.
O VRRP é a parte mais importante da configuração ao provisionar gateways. A funcionalidade de alta disponibilidade depende das mensagens de pulsação, portanto, certificar-se de que elas não estejam bloqueadas é essencial.
Endereços de IP virtual (VIP) do VRRP
O IP virtual do VRRP para dp0bond1
ou dp0bond0
, ou VIP, é o endereço IP flutuante que muda do dispositivo principal para o de backup quando ocorre failover. Quando um VRA é implementado, ele tem uma conexão de rede
de ligação pública e privada e IPs reais designados em cada interface. Um VIP também é designado em ambas as interfaces, independentemente de o dispositivo ser independente ou estar em um par de HA. O tráfego que tem um IP de destino em sub-redes
em VLANs associadas ao VRA é enviado diretamente para esses VIPs do VRRP por meio de uma rota estática no FCR/BCR.
Não é necessário mudar endereços IP virtuais do VRRP para qualquer grupo de gateways nem desativar a interface do VRRP. Esses endereços IP são o método pelo qual o tráfego é roteado para o gateway quando uma VLAN está associada. Como resultado, se eles estiverem inativos, o tráfego de VLAN também estará inativo. Se o endereço IP não estiver presente, então não será possível encaminhar o tráfego do BCR/FCR para o próprio VRA. Esse endereço virtual ou VIP não é mutável neste momento. Essa limitação pode mudar no futuro, mas, atualmente, nem a migração de um VRA entre PODs/FCRs/BCRs nem a mudança do VIP são suportadas.
A seguir, está um exemplo das configurações padrão dos VIPs dp0bond0
e dp0bond1
para um VRA específico. Observe que seus endereços IP e vrrp-groups
podem ser diferentes desse exemplo.
set interfaces bonding dp0bond0 vrrp vrrp-group 2 virtual-address '10.127.170.1/26'
set interfaces bonding dp0bond1 vrrp vrrp-group 2 virtual-address '159.8.98.209/29'
Para obter mais informações, consulte Sub-redes de VLAN associadas ao VRRP.
Por padrão, o VRRP é configurado como desativado. Isso assegura que novas provisões e recarregamentos não causem indisponibilidades no dispositivo principal. Para que o tráfego de VLAN funcione, o VRRP deve ser reativado após o fornecimento ou um recarregamento ser concluído. O exemplo a seguir detalha a configuração padrão:
set interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
set interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'
Para ativar o VRRP nessas duas interfaces após uma provisão ou recarregamento, que é necessário para os pares independentes e de HA, execute os comandos a seguir. Em seguida, confirme a mudança:
delete interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
delete interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'
Grupo do VRRP
Um grupo do VRRP consiste em um cluster de interfaces ou interfaces virtuais que fornecem redundância para uma interface primária (ou principal) no grupo. O grupo VRRP define o virtual_router_id
na configuração do Keepalive. No
próprio protocolo VRRP, ele é referido como o VRID. O grupo do VRRP tem um identificador numérico exclusivo e pode ter até 20 endereços IP virtuais designados.
O ID de grupo do VRRP é designado pela IBM Cloud e não deve ser mudado. Quando um novo grupo de gateway é provisionado além de um Frontend Customer Router (FCR)/Backend Customer Router (BCR) pela primeira vez, ele recebe um grupo VRRP de 1. As provisões subsequentes do grupo de gateways incrementam esse valor para evitar conflitos. Por exemplo, o próximo grupo tem o grupo 2, depois o grupo 3 e assim por diante. Isso é, então, calculado e designado pelo processo de fornecimento. Alterar esse valor arrisca a colisão com outros grupos ativos e, em seguida, a contenção principal/principal, o que provavelmente causa uma indisponibilidade nos grupos de gateway.
Se você migrar de uma configuração anterior, recomenda-se que verifique sua configuração do código para garantir que o ID do grupo do VRRP não seja designado estaticamente.
O ID de grupo do VRRP é persistido no banco de dados, portanto, o mesmo valor de ID do grupo é usado durante um recarregamento ou um upgrade do S.O. Qualquer ID de grupo do VRRP modificado pelo usuário é sobrescrito pelo valor designado pelo sistema durante um recarregamento do S.O.
Prioridade do VRRP
A primeira máquina em um grupo de gateways tem uma prioridade de 254, e esse valor é decrescido para o próximo dispositivo provisionado. Você nunca deve configurar uma prioridade como 255, pois isto define o "proprietário do endereço" VIP e pode resultar em comportamento indesejado quando a máquina é colocada on-line com uma configuração que difere da principal ativa em execução.
Preempção do VRRP
A preempção deve sempre ser desativada em todas as interfaces do VRRP, para que um novo dispositivo ou um que está passando pelo recarregamento de seu SO não tente assumir o cluster.
Intervalo de aviso do VRRP
Para sinalizar que ela ainda está em serviço, a interface principal ou VIF envia pacotes de “pulsação“ chamados “propagandas“ para o segmento de LAN, usando os endereços multicast designados por IANA para o VRRP (224.0.0.18
para
IPv4 e FF02:0:0:0:0:0:0:12
para IPv6).
Por padrão, o intervalo é definido como 1. Este valor pode ser aumentado, mas não é recomendado definir um valor acima de 5. Em uma rede ocupada, pode levar muito mais de um segundo para que todos os avisos de VRRP cheguem ao dispositivo de backup principal, portanto, um valor de 2 deve ser usado para redes de alto tráfego.
Sincronização do VRRP (sync-group)
As interfaces em um grupo de sincronização do VRRP (“grupo de sincronização”) serão sincronizadas de modo que, se uma das interfaces no grupo efetuar failover para o backup, todas as interfaces no grupo efetuem failover para o backup. Por exemplo, se uma interface em um roteador principal falhar, o roteador inteiro falhará em um roteador de backup.
Esse valor é diferente do grupo do VRRP, já que ele define quais interfaces em um dispositivo falham quando uma interface nesse grupo registra uma falha. Recomenda-se que todas as interfaces pertençam ao mesmo sync-group; caso contrário, algumas interfaces serão principais e terão IPs de gateway, e outras serão de backup e o tráfego não avançará corretamente mais. Configurações ativo/ativo não são suportadas.
rfc-compatibility do VRRP
A compatibilidade RFC ativa ou desativa endereços MAC RFC 3768 para VRRP em uma interface. Isso deve ser ativado nas interfaces nativas, mas não ativado em quaisquer VIFs configurados. Alguns comutadores virtuais (principalmente VMware) têm problemas com essa ativação e fazem com que o tráfego seja eliminado e não seja enviado para o IP de gateway da máquina host do hypervisor. Deixe essa configuração sozinha e não defina a configuração para nenhum VIF.
Autenticação do VRRP
Se uma senha for configurada para autenticação do VRRP, o tipo de autenticação também deverá ser definido. Se a senha for configurada e o tipo de autenticação não for definido, o sistema gerará um erro ao tentar confirmar a configuração.
Da mesma forma, não é possível excluir a senha do VRRP sem também excluir o tipo de autenticação do VRRP. Se você o fizer, o sistema gerará um erro quando você tentar confirmar a configuração. Se você excluir a senha de autenticação e o tipo de autenticação do VRRP, a autenticação do VRRP será desativada.
O IETF decidiu que a autenticação não deve ser usada para o VRRP versão 3. Para obter mais informações, consulte o RFC 5798 VRRP.
Suporte da Versão 2/3
O VRA suporta ambos os protocolos do VRRP, versão 2 (padrão) e versão 3. Na versão 2, não é possível ter IPv4 e IPv6 juntos; no entanto, na Versão 3, é possível ter IPv4 e IPv6 ao mesmo tempo.
VPN de alta disponibilidade com VRRP
O VRA fornece a capacidade de manter a conectividade por meio de um túnel IPsec usando um parde IBM Cloud® Virtual Router Appliances com VRRP. Quando um roteador falha ou é desativado para manutenção, o novo roteador principal do VRRP restaura a conectividade do Internet Protocol Security entre as redes local e remota.
Ao configurar uma VPN de HA com VRRP, sempre que um endereço virtual do VRRP é incluído em uma interface do VRA, deve-se reinicializar o daemon do Internet Protocol Security porque o serviço do Internet Protocol Security atende apenas a conexões com os endereços que estão presentes no VRA quando o daemon de serviço de troca de chave da Internet (IKE) é inicializado.
Execute o comando a seguir nos roteadores principal e de backup para que, após o failover, os daemons do Internet Protocol Security sejam reiniciados em um novo dispositivo principal após o trânsito do VIP, conforme mostrado no exemplo a seguir:
vyatta@vrouter# set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify ipsec
Firewalls de alta disponibilidade com VRRP
Quando dois dispositivos estão em um par de HA, deve-se tomar cuidado em seu dispositivo principal para que você não bloqueie o acesso do outro dispositivo. A porta 443 deve ser permitida entre os dispositivos para que a sincronização de configuração
funcione, e o VRRP deve ser autorizado a ser enviado e recebido, incluindo o intervalo de multicast de 224.0.0.0/24
.
Sub-redes de VLAN associadas ao VRRP
Para qualquer configuração do VIF com o VRRP, é necessário um endereço IP virtual (o primeiro IP utilizável na sub-rede, o IP de gateway para o qual tudo nesse sub-rede será roteado) e também um endereço IP de interface real para o VIF nos dispositivos.
Para conservar IPs utilizáveis, recomenda-se que os IPs de interface real usem um intervalo fora de banda, como 192.168.0.0/30
, em que um dispositivo tem o .1 e o outro dispositivo tem o endereço .2. É possível ter diversos IPs
virtuais do VRRP, mas é necessário apenas um endereço real em cada VIF.
Aqui está um exemplo de uma configuração de VRRP com duas VLANs privadas e três sub-redes:
set interfaces bonding dp0bond0 address '10.100.11.39/26'
set interfaces bonding dp0bond0 mode 'lacp'
set interfaces bonding dp0bond0 vif 10 address '192.168.255.81/30'
set interfaces bonding dp0bond0 vif 10 description 'VLAN 10 - Two private subnets/VIPs'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 advertise-interval '1'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 virtual-address '10.100.105.177/28'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 virtual-address '10.100.38.1/26'
set interfaces bonding dp0bond0 vif 11 address '192.168.255.89/30'
set interfaces bonding dp0bond0 vif 11 description 'VLAN 11 - One private subnet/VIP'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 advertise-interval '1'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 virtual-address '10.100.212.65/26'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 'rfc-compatibility'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 virtual-address '10.100.11.5/26'
set interfaces bonding dp0bond1 address '169.110.20.28/29'
set interfaces bonding dp0bond1 mode 'lacp'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify 'ipsec'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 'rfc-compatibility'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 virtual-address '169.110.21.26/29'
- Um grupo de sincronização do VRRP é diferente de um grupo VRRP. Quando uma interface que pertence a um grupo de sincronização mudar de estado, todos os outros membros do mesmo grupo de sincronização serão transicionados para o mesmo estado.
- O número de grupos vrrp das interfaces VLAN (VIFs) deve quase sempre ser o mesmo que sua interface nativa correspondente. Por exemplo,
dp0bond1.789
deve sempre ter o mesmo número de grupos vrrp comodp0bond1
, a menos que as duas interfaces compartilhem o mesmo grupo de sincronização. Ter um número de grupo diferente no VIF e a interface nativa pode causar uma condição de "cérebro dividido" quando emparelhados com diferentes grupos de sincronização. Quando duas interfaces compartilham o mesmo grupo de sincronização, mesmo que estejam em diferentes grupos de vrrp, elas fazem a transição entre o principal e o backup ao mesmo tempo, evitando o cérebro dividido. Por outro lado, se a interface nativa estiver configurada com um número de grupo de vrrp diferente e um grupo de sincronização diferente como uma interface VLAN, como as sub-redes configuradas nas interfaces de VLAN são estaticamente roteadas para o endereço virtual na interface nativa, se a interface da VLAN estiver sendo mostrada como backup e a interface nativa for a principal, o roteador ainda enviará o tráfego de interface de VLAN para o VRA no qual a interface nativa é principal, embora a interface de VLAN seja secundária e não ativa no VRA. Essa situação específica causa um "split-brain" e uma indisponibilidade. É por isso que é importante estar consciente de como os sync-groups são configurados em conjunto com os grupos de vrrp-groups. Também é importante não usar os mesmos números de vrrp-group entre vários pares de VRA de HA na mesma VLAN de trânsito, uma vez que quatro Vyattas que usam o mesmo grupo fazem com que três VRAs assumam potencialmente o estado de Backup, enquanto apenas um é Principal, causando uma indisponibilidade. - Os endereços da interface real nas VLANs nativas (por exemplo, dp0bond1: 169.110.20.28/29) nem sempre estão na mesma sub-rede que seus VIPs (169.110.21.26/29).
Failover manual do VRRP
Se for necessário forçar um failover do VRRP, isso poderá ser feito executando o comando a seguir no dispositivo que atualmente é o VRRP principal:
vyatta@vrouter$ reset vrrp master interface dp0bond0 group 1
O ID do grupo é o ID do grupo VRRP das interfaces nativas e, conforme mencionado acima, pode ser diferente em seu par.
Sincronização de conexão
Quando dois dispositivos VRA estão em um par de HA, pode ser útil rastrear conexões stateful entre eles para que, se um failover acontecer, o estado atual de todas as conexões no dispositivo com falha seja replicado para o dispositivo de backup. Não é necessário que sessões ativas atuais (como conexões SSL) sejam reconstruídas do zero, o que pode resultar em uma experiência de usuário interrompida.
Isso é chamado de sincronização de rastreamento de conexão.
Para configurá-la, deve-se declarar qual é o método de failover, qual interface é usada para o envio das informações de rastreamento de conexão, além do IP do peer remoto:
set service connsync failover-mechanism vrrp sync-group SYNC1
set service connsync interface dp0bond0
set service connsync remote-peer 10.124.10.4
O outro VRA tem a mesma configuração, mas um remote-peer
diferente.
Observe que isso poderá saturar um link se houver um alto número de conexões sendo recebidas por outras interfaces e haverá competição com outro tráfego no link declarado.
Recurso de atraso de início do VRRP
O S.O. Vyatta versão 1801p e superior inclui um novo comando vrrp
.
vrrp
especifica um protocolo de eleição que designa dinamicamente a responsabilidade de um roteador virtual a um dos roteadores VRRP em uma LAN. O roteador VRRP que controla os endereços IPv4 ou IPv6 associados a um roteador virtual
é chamado de Principal e ele encaminha pacotes que são enviados para esses endereços IPv4 ou IPv6. O processo de eleição fornece failover dinâmico na responsabilidade de encaminhamento, caso o Principal se torne indisponível. Todo o sistema
de mensagens de protocolo é executado usando datagramas multicast IPv4 ou IPv6; como resultado, o protocolo pode operar em uma variedade de tecnologias de LAN multiacesso que suportam multicast IPv4/IPv6.
Para minimizar o tráfego de rede, somente o Principal para cada roteador virtual envia mensagens de anúncio periódicas do VRRP. Um roteador de backup não tenta priorizar o Principal, a menos que ele tenha prioridade mais alta. Isso elimina a interrupção do serviço, a menos que um caminho mais preferencial se torne disponível. Também é possível proibir, administrativamente, todas as tentativas de preempção. Se o Principal ficar indisponível, o backup de prioridade mais alta transitará para o Principal após um atraso curto, proporcionando uma transição controlada da responsabilidade do roteador virtual com interrupção mínima do serviço.
Nas implementações provisionadas da IBM Cloud, o valor de atraso de início é configurado para o valor padrão. É possível que você deseje alterar isso a seu critério à medida que você testa seus métodos de failover e alta disponibilidade.
Preempção versus nenhuma preempção
O protocolo vrrp
define a lógica que decide qual peer do VRRP em uma rede tem a prioridade mais alta e, como tal, o melhor peer para executar a função como Principal. Com uma configuração padrão, o VRRP é ativado para executar
uma preempção, o que significa que um novo peer de prioridade superior na rede força o failover da função Principal.
Quando a preempção for desativada, um peer de prioridade mais alta só executará failover da função Principal se o peer de prioridade inferior existente não estiver mais disponível na rede. A desativação da preempção é, às vezes, útil em cenários mundiais reais, uma vez que lida melhor com situações nas quais o peer de prioridade mais alta pode ter começado a oscilar periodicamente devido a problemas de confiabilidade com o próprio peer ou uma de suas conexões de rede. Também é útil evitar o failover prematuro em um novo peer de prioridade mais alta que não tenha concluído a convergência de rede.
Suposições e limitações da preempção
Se os peers do VRRP forem configurados para desativar a preempção, haverá alguns casos nos quais a preempção poderá "parecer" ocorrer, mas, na realidade, o cenário será apenas um failover padrão do VRRP. Conforme descrito acima, o VRRP usa datagramas IP multicast como um meio de confirmar a disponibilidade do roteador Principal atualmente selecionado. Como é um protocolo da camada 3 que está detectando falha de um peer VRRP, é importante que a detecção de failover no VRRP seja atrasada até que o VRRP e a camada 1 a 2 da pilha de rede estejam prontas e convergidas. Em alguns casos, a interface de rede que executa o VRRP pode confirmar para o protocolo que a interface está ativa, mas outros serviços subjacentes como Spanning Tree ou Bonding podem não ter concluído. Como resultado, a conectividade IP entre os peers não pode ser estabelecida. Se isso ocorrer, o VRRP em um novo peer superior se tornará principal, pois não será possível detectar mensagens de VRRP do peer principal atual na rede. Após a convergência, o breve período de tempo durante o qual há dois peers principais do VRRP resulta na execução da lógica de principal duplo do VRRP. O peer de prioridade mais alta permanece Principal, e a prioridade mais baixa torna-se backup. Esse cenário pode parecer demonstrar uma falha na funcionalidade de "nenhuma preempção".
Recurso de atraso de início
Para acomodar os problemas associados ao atraso na convergência dos níveis inferiores da pilha de rede durante um evento ativo de interface, assim como outros fatores contributivos, um novo recurso chamado "Atraso de início" é introduzido na correção 1801p. Esse recurso faz com que o estado do VRRP em uma máquina que foi "recarregada" permaneça no estado INIT até depois de um atraso predefinido, que pode ser configurado pelo operador de rede. A flexibilidade nesse valor de atraso permite que o operador de rede customize as características de sua rede e dispositivos em condições do mundo real.
Detalhes do comando
vrrp {
start-delay <0-600>
}
start-delay
pode ter um valor entre 0 (padrão) e 600 segundos.
Configuração de exemplo
interfaces {
bonding dp0bond1 {
address 161.202.101.206/29 mode balanced
vrrp {
start-delay 120
vrrp-group 211 {
preempt false
priority 253
virtual-address 161.202.101.204/29
} }
}