Utilizzo di HA (High Availability) e VRRP

IBM Cloud® Virtual Router Appliance (VRA) supporta VRRP (Virtual Router Redundancy Protocol) come protocollo ad alta disponibilità. La distribuzione dei dispositivi viene eseguita in modo attivo/passivo, in cui una macchina è quella master e l'altra quella di backup. Tutte le interfacce su entrambe le macchine sono un membro dello stesso "sync-group", quindi se un'interfaccia riscontra un errore, anche le altre interfacce nello stesso gruppo hanno un errore e il dispositivo smette di essere master. Il backup corrente rileva che il master non sta più trasmettendo messaggi keepalive / heartbeat, assume il controllo degli IP virtuali VRRP e diventa master.

VRRP non è la parte più importante della configurazione durante il provisioning dei gateway. La funzionalità di alta disponibilità dipende dai messaggi heartbeat, quindi assicurarsi che non siano bloccati è fondamentale.

Indirizzi VIP (VRRP virtual IP)

Il VIP (virtual IP) VRRP per dp0bond1 o dp0bond0, oppure VIP, è l'indirizzo IP mobile che viene modificato dal dispositivo master a quello di backup quando viene eseguito il failover. Quando una VRA viene distribuita, ha una connessione di rete collegata pubblica e privata e IP reali assegnati su ciascuna interfaccia. Un VIP viene assegnato anche su entrambe le interfacce, se il dispositivo è autonomo o in una coppia HA. Il traffico che ha un IP di destinazione nelle sottoreti nelle VLAN associate al VRA viene inviato direttamente ai VIP VRRP tramite un instradamento statico sul FCR/BCR.

Non è necessario modificare gli indirizzi IP virtuali VRRP per qualsiasi gruppo gateway né disabilitare l'interfaccia VRRP. Questi indirizzi IP sono il metodo con cui il traffico viene instradato al gateway quando viene associata una VLAN. Di conseguenza, se sono inattivi, anche il traffico VLAN è inattivo. Se l'indirizzo IP non è presente, il traffico non può essere inoltrato dalla BCR/FCR alla VRA stessa. Questo indirizzo virtuale o VIP non è attualmente modificabile. Questa limitazione potrebbe cambiare in futuro, ma attualmente non è supportata né la migrazione di un VRA tra PODs/FCR/BCR né la modifica del VIP.

Il seguente è un esempio delle configurazioni predefinite dei VIP dp0bond0 e dp0bond1 per uno specifico VRA. Notare che i tuoi indirizzi IP e vrrp-groups potrebbero essere diversi da questo esempio.

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'

Per ulteriori informazioni, consultare sottoreti VLAN associati con VRRP.

Per impostazione predefinita, VRRP è impostato su disabilitato. Questo garantisce che nuovi provisioning e ricaricamenti non causino interruzioni sul dispositivo master. Perché il traffico VLAN funzioni, VRRP deve essere riabilitato una volta completato il provisioning o un ricaricamento. Il seguente esempio indica in dettaglio la configurazione predefinita:

set interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
set interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'

Per abilitare VRRP su queste due interfacce dopo un provisioning o un ricaricamento, necessario per le coppie autonome e HA, esegui i seguenti comandi. Quindi, impegnare la modifica:

delete interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
delete interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'

Gruppo VRRP

Un gruppo VRRP è costituito da un cluster di interfacce o interfacce virtuali che forniscono la ridondanza per un'interfaccia primaria (o principale) nel gruppo. Il gruppo VRRP definisce il virtual_router_id nella configurazione Keepalive. Nel protocollo VRRP stesso, si parla di VRID. Il gruppo VRRP ha un identificativo numerico e possono essere assegnati fino a 20 indirizzi VIP (Virtual IP).

L'ID gruppo VRRP è assegnato da IBM Cloud e non deve essere modificato. Quando un nuovo gruppo di gateway viene provisionale dietro a un Frontend Customer Router (FCR) /Backend Customer Router (BCR) per la prima volta, riceve un gruppo VRRP di 1. Le successive disposizioni del gruppo gateway incrementano questo valore per prevenire i conflitti. Ad esempio, il gruppo successivo ha il gruppo 2, poi il gruppo 3 e così via. Viene quindi calcolato e assegnato dal processo di provisioning. La modifica di questo valore rischia di entrare in conflitto con altri gruppi attivi e quindi con il conflitto master / master, che probabilmente causa un'interruzione su entrambi i gruppi gateway.

Se esegui la migrazione da una configurazione precedente, si consiglia di ricontrollare il tuo codice di configurazione per assicurarti che l'ID del gruppo VRRP non sia assegnato staticamente.

L'ID gruppo VRRP è persistente nel database, quindi lo stesso valore di ID gruppo viene utilizzato durante un ricaricamento o un aggiornamento del sistema operativo. Qualsiasi ID gruppo VRRP modificato dall'utente viene sovrascritto con il valore assegnato dal sistema durante un ricaricamento del sistema operativo.

Priorità VRRP

La prima macchina in un gruppo gateway ha una priorità di 254 e questo valore viene decrementato per il successivo dispositivo di cui è stato eseguito il provisioning. Non dovresti mai impostare una priorità di 255, perché definisce il "proprietario dell'indirizzo" VIP e può causare comportamenti non voluti quando la macchina viene messa online con una configurazione diversa da quella del master attivo in esecuzione.

Precedenza VRRP

La precedenza dovrebbe sempre essere disabilitata su tutte le interfacce VRRP, in modo che un nuovo dispositivo o uno nel processo di ricaricamento del proprio SO non tenta di subentrare al cluster.

Intervallo di avviso VRRP

Per segnalare che è ancora in servizio, l'interfaccia master o VIF invia pacchetti di “heartbeat” denominati “advertisements” al segmento LAN, utilizzando gli indirizzi multicast assegnati IANA per il VRRP (224.0.0.18 per IPv4 e FF02:0:0:0:0:0:0:12 per IPv6).

Per impostazione predefinita, l'intervallo è impostato su 1. Questo valore può essere aumentato, ma non è consigliato impostare un valore su 5. Su una rete trafficata può richiedere molto più di un secondo per tutti gli avvisi VRRP per arrivare sul dispositivo di backup dal master, quindi un valore di 2 dovrebbe essere utilizzato per le reti ad alto traffico.

Sincronizzazione VRRP (sync-group)

Le interfacce in un gruppo di sincronizzazione VRRP (“sync group”) sono sincronizzate in modo che, se il backup di una delle interfacce nel gruppo ha esito negativo, si verifica un failover del backup per tutte le interfacce. Ad esempio, se un'interfaccia su un router master ha esito negativo, l'intero router ha esito negativo su un router di backup.

Questo valore è diverso dal gruppo VRRP, in quanto definisce quali interfacce su un'unità eseguono il failover quando un'interfaccia in tale gruppo registra un errore. Si consiglia che tutte le interfacce appartengano allo stesso gruppo di sincronizzazione; in caso contrario, alcune interfacce sono master e dispongono di IP gateway e altre sono di backup e il traffico non viene più inoltrato correttamente. Le configurazioni attiva/attiva non sono supportate.

Compatibilità rfc VRRP

La compatibilità rfc abilita o disabilita gli indirizzi RFC 3768 MAC per VRRP in un'interfaccia. Questa dovrebbe essere abilitata nelle interfacce native, ma non su tutti i VIF configurati. Alcuni switch virtuali (principalmente vmware) hanno problemi con l'abilitazione e causano l'eliminazione del traffico e non l'invio all'IP del gateway dalla macchina host dell'hypervisor. Lascia questa impostazione autonoma e non configurarla per i VIF.

Autenticazione VRRP

Se viene impostata una password per l'autenticazione VRRP, deve inoltre essere definito il tipo di autenticazione. Se la password è impostata e il tipo di autenticazione non è definito, il sistema genera un errore quando si tenta di eseguire il commit della configurazione.

Allo stesso modo, non puoi eliminare la password VRRP senza anche eliminare il tipo di autenticazione VRRP. Se fai ciò, il sistema genera un errore quando tenti di eseguire il commit della configurazione. Se elimini sia il tipo che la password di autenticazione VRRP, l'autenticazione VRRP viene disabilitata.

L'IETF ha deciso che l'autenticazione non deve essere utilizzata per la versione VRRP 3. Per ulteriori informazioni, consultare RFC 5798 VRRP.

Supporto versione 2/3

La VRA supporta sia i protocolli VRRP versione 2 (predefinito) che versione 3. Nella versione 2 non è possibile avere insieme IPv4 e IPv6 ; tuttavia, nella versione 3, è possibile avere IPv4 e IPv6 contemporaneamente.

VPN ad alta disponibilità con VRRP

La VRA fornisce la possibilità di mantenere la connettività tramite un tunnel IPsec utilizzando una coppia di IBM Cloud® Virtual Router Appliance con VRRP. Quando si verifica un malfunzionamento di un router o viene disattivo per manutenzione, il nuovo router master VRRP ripristina la connettività IPsec tra le reti locali e remote.

Quando configuri una VPN HA con VRRP, ogni volta che un indirizzo virtuale VRRP viene aggiunto a un'interfaccia VRA, devi reinizializzare il daemon IPsec perché il servizio IPsec è in ascolto solo per le connessioni agli indirizzi presenti sul VRA quando il daemon del servizio IKE (Internet Key Exchange) viene inizializzato.

Esegui il seguente comando sui router master e di backup, in modo che quando si verifica il failover, i daemon IPsec vengono riavviati su un nuovo dispositivo master dopo il transito VIP, come mostrato nel seguente esempio:

vyatta@vrouter# set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify ipsec

Firewall ad alta disponibilità con VRRP

Quando due dispositivi sono in una coppia HA, devi prestare attenzione al tuo dispositivo master perché non ne devi bloccare l'accesso da altri dispositivi. La porta 443 deve essere consentita tra entrambi i dispositivi per il funzionamento di config - sync e VRRP deve essere consentito l'invio e la ricezione, incluso l'intervallo multicast di 224.0.0.0/24.

Sottoreti VLAN associate a VRRP

Per qualsiasi configurazione VIF con VRRP, è necessario un indirizzo IP virtuale (il primo IP utilizzabile nella sottorete, l'IP gateway a cui verrà instradato tutto in tale sottorete) e anche un indirizzo IP dell'interfaccia reale per il VIF su entrambi i dispositivi. Per conservare IP utilizzabili, si consiglia che gli IP dell'interfaccia reale utilizzino un intervallo fuori banda, come ad esempio 192.168.0.0/30, dove un dispositivo ha .1 e l'altro dispositivo ha l'indirizzo .2. È possibile avere più IP virtuali VRRP, ma è necessario un solo indirizzo reale su ciascun VIF.

Questo è un esempio di una configurazione VRRP con due VLAN private e tre sottoreti:

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'

Un VRRP sync-group è differente da un gruppo VRRP. Quando un'interfaccia che appartiene a un sync-group modifica lo stato, tutti gli altri membri dello stesso sync-group passeranno allo stesso stato.
Il numero del vrrp-group delle interfacce VLAN (VIF) dovrebbe quasi sempre essere lo stesso di quello della sua interfaccia nativa corrispondente. Ad esempio, dp0bond1.789 dovrebbe sempre avere lo stesso numero di vrrp-group di dp0bond1, a meno che le due interfacce non condividano lo stesso sync-group. Avere un numero di gruppi differente sulla VIF e nell'interfaccia nativa può causare una condizione "split brain" in caso di accoppiamento a gruppi di sincronizzazione differenti. Quando due interfacce condividono lo stesso sync-group, anche se sono su vrrp-group differenti, eseguiranno entrambe la transizione tra master e backup contemporaneamente, evitando una condizione di split brain. D'altro canto, se l'interfaccia nativa è configurata con un numero di vrrp-group differente e un sync-group differente come interfaccia VLAN, poiché le sottoreti configurate sulle interfacce VLAN vengono instradate staticamente al virtual-address sull'interfaccia nativa, se l'interfaccia VLAN si presenta come quella di backup e l'interfaccia nativa è quella master, il router invierà comunque il traffico dell'interfaccia VLAN alla VRA dove l'interfaccia nativa è quella master anche se l'interfaccia VLAN è secondaria e non attiva sulla VRA. Questa situazione specifica causa una "spaccatura del cervello" e un'interruzione. Questo è il motivo per cui è importante essere consapevoli di come i sync - groups sono configurati insieme a vrrp - groups. È anche importante non utilizzare gli stessi numeri vrrp - group tra più coppie HA VRA nella stessa VLAN di transito, poiché quattro Vyatta che utilizzano lo stesso gruppo fanno sì che stre VRA assumano potenzialmente lo stato Backup, mentre solo uno è Master, causando un'interruzione.
Gli indirizzi dell'interfaccia reali nelle VLAN native (ad esempio dp0bond1: 169.110.20.28/29) non sono sempre nella stessa sottorete come i loro VIP (169.110.21.26/29).

Failover VRRP manuale

Se devi forzare un failover VRRP, può essere ottenuto eseguendo quanto segue nel dispositivo che al momento è il master VRRP:

vyatta@vrouter$ reset vrrp master interface dp0bond0 group 1

L'ID del gruppo è l'ID del gruppo VRRP delle interfacce native e, come menzionato precedentemente, potrebbe essere differente nella tua coppia.

Sincronizzazione della connessione

Quando due dispositivi VRA si trovano in una coppia HA, potrebbe essere utile tenere traccia delle connessioni statiche tra i due dispositivi in modo che se dovesse accadere un failover, lo stato attuale di tutte le connessioni che si trovano sul dispositivo non riuscito vengono replicate sul dispositivo di backup. Non è necessario che le sessioni attive correnti (come connessioni SSL) siano ricostruite da zero, il che può comportare un'esperienza utente dirompente.

Questa operazione si chiama sincronizzazione della traccia di connessione.

Per configurarlo, è necessario dichiarare quale è il metodo di failover, quale interfaccia si utilizza per inviare le informazioni di traccia della connessione e l'IP del 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

L'altro VRA ha la stessa configurazione, ma un remote-peer differente.

Notare che questo può saturare un link se c'è un numero elevato di connessioni in entrata su altre interfacce e compete con altro traffico sul link dichiarato.

Funzione Start Delay (Ritardo dell'avvio) VRRP

Vyatta OS versione 1801p e successive include un nuovo comando vrrp.

vrrp specifica un protocollo di elezione che assegna dinamicamente la responsabilità per un router virtuale a uno dei router VRRP su una LAN. Il router VRRP che controlla gli indirizzi IPv4 o IPv6 associati ad un router virtuale viene denominato Master e inoltra i pacchetti inviati a questi indirizzi IPv4 o IPv6. Il processo di elezione fornisce un failover dinamico nella responsabilità di inoltro se il Master dovesse diventare non disponibile. Tutta la messaggistica di protocollo viene eseguita utilizzando i datagrammi multicast IPv4 o IPv6; come risultato, il protocollo può operare su una varietà di tecnologie LAN multiaccesso che supportano il multicast IPv4/IPv6.

Per ridurre al minimo il traffico di rete, solo il Master per ogni router virtuale invia messaggi di avviso VRRP periodici. Un router di backup non tenta di anticipare il Master a meno che non abbia una priorità più alta. Questo elimina l'interruzione del servizio a meno che non diventi disponibile un percorso maggiormente preferito. È anche possibile vietare amministrativamente tutti i tentativi di prelazione. Se il Master diventa non disponibile, il backup con priorità più alta passa a Master dopo un breve ritardo, fornendo una transizione controllata della responsabilità del router virtuale con un'interruzione minima del servizio.

Nelle distribuzioni con provisioning IBM Cloud, il valore di ritardo di avvio è impostato sul valore predefinito. È possibile che si desideri modificarlo a propria discrezione mentre si testano i metodi di failover e alta disponibilità.

Preventivo contro nessuna predizione

Il protocollo vrrp definisce la logica che decide quale peer VRRP su una rete ha la priorità più alta e, come tale, il peer migliore per eseguire il ruolo di Master. Con una configurazione predefinita, VRRP è abilitato per eseguire la prelazione, il che significa che un nuovo peer con priorità più alta sulla rete forza il failover del ruolo Master.

Quando la prelazione è disabilitata, un peer con una priorità più alta eseguirà il failover del ruolo Master solo se il peer con priorità più bassa esistente non è più disponibile sulla rete. La disabilitazione della prelazione è a volte utile negli scenari del mondo reale, in quanto affronta meglio le situazioni in cui il peer con priorità più alta potrebbe aver iniziato a eseguire periodicamente il flap a causa di problemi di affidabilità con il peer stesso o con una delle sue connessioni di rete. È anche utile per evitare il failover prematuro a un nuovo peer con una priorità più alta che non ha completato la convergenza di rete.

Presupposti e limitazioni della prelazione

Se i peer VRRP sono configurati per disabilitare la prelazione, ci sono alcuni casi in cui la prelazione può "apparire", ma in realtà lo scenario è solo un failover VRRP standard. Come descritto in precedenza, VRRP utilizza i datagrammi multicast IP come mezzo per confermare la disponibilità del router Master attualmente eletto. Poiché è un protocollo di livello 3 che sta rilevando il malfunzionamento di un peer VRRP, è importante che il rilevamento del failover in VRRP sia ritardato finché VRRP e i livelli da 1 a 2 dello stack di rete non siano pronti e convergenti. In alcuni casi, l'interfaccia di rete che esegue VRRP potrebbe confermare al protocollo che l'interfaccia è attiva, ma altri servizi sottostanti come Spanning Tree o Bonding potrebbero non essere stati completati. Di conseguenza, la connettività IP tra i peer non può essere stabilita. Se ciò si verifica, VRRP su un nuovo peer superiore diventa Master poiché non è in grado di rilevare i messaggi VRRP dal peer Master corrente sulla rete. Dopo la convergenza, il breve periodo di tempo in cui ci sono due peer Master VRRP si traduce nella logica dual Master di VRRP eseguita. Il peer prioritario più alto rimane Master e la priorità più bassa diventa backup. Questo scenario potrebbe indicare un errore nella funzionalità "nessuna prelazione".

Funzione Start Delay (Ritardo dell'avvio)

Per risolvere i problemi associati al ritardo nella convergenza dei livelli più bassi dello stack di rete durante un evento di aggiornamento dell'interfaccia, nonché altri fattori contributori, è stata introdotta una nuova funzione denominata "Ritardo di avvio" nella patch 1801p. Questa funzione fa sì che lo stato VRRP su una macchina che è stata "ricaricata" rimanga nello stato INIT fino a dopo un ritardo predefinito, che può essere configurato dall'operatore di rete. La flessibilità in questo valore di ritardo consente all'operatore di rete di personalizzare le caratteristiche della sua rete e dei suoi dispositivi in condizioni reali.

Informazioni dettagliate sui comandi

vrrp {
start-delay <0-600>
}

start-delay può avere un valore compreso tra 0 (valore predefinito) e 600 secondi.

Configurazione di esempio

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
} }
}