Utilizzo di Keepalived per la gestione del failover semplice nei cluster

Quando si sente il termine "disponibilità elevata", si potrebbe pensare ad ambienti grandi e complessi con tecnologie arcane che sono oltre la portata dell'amministratore di sistema medio. Ma l'HA di base non deve essere complicato:in questa serie imparerai come implementare servizi di base ad alta disponibilità usando Keepalived . Ti guiderò attraverso semplici situazioni di failover, nonché una configurazione più complessa utilizzata per rispondere a eventi esterni e attivare i failover. Per prima cosa, inizieremo con i fondamenti di Keepalived e il Virtual Router Redundancy Protocol (VRRP).

Questo articolo è il primo di una serie di tre articoli che coprono tutto, dalla configurazione di base ai concetti avanzati di HA per Linux.

Nozioni di base su Keepalived e VRRP

Simboli di rete nei diagrammi disponibili tramite VRT Network Equipment Extension, CC BY-SA 3.0.

Se hai letto alcuni degli articoli di Enable Sysadmin networking, allora sai che tutti gli amministratori di sistema possono trarre vantaggio da una solida conoscenza dei fondamenti della rete. Conoscenza di Keepalived non è diverso. Il protocollo alla base del failover HA è il Virtual Router Redundancy Protocol (VRRP) e Keepalived fornisce sia un'implementazione della versione 2 che una versione 3 di questo protocollo.

Potrebbe sembrare strano che stiamo usando un protocollo creato per i router sui nostri server. Si scopre che la stessa tecnologia di rete utilizzata per fornire ridondanza alle apparecchiature di rete può fornire ridondanza anche negli ambienti server. I router sono spesso distribuiti in coppia, in cui un router è attivo e un altro è in standby, pronto per l'uso in caso di guasto del router attivo. Questi stessi concetti possono essere applicati ai server.

VRRP utilizza il concetto di indirizzo IP virtuale (VIP). Uno o più host (router, server, ecc.) partecipano a un'elezione per determinare l'host che controllerà quel VIP. Solo un host (il master) controlla il VIP alla volta. Se il master fallisce, VRRP fornisce meccanismi per rilevare tale errore e eseguire rapidamente il failover su un host in standby. Nella topologia sopra, il server1 è il master ed è responsabile dell'indirizzo IP 192.168.122.200. Se il server1 fallisce, il server2 assume questo IP.

Vale anche la pena sapere che Keepalived fornisce più di un semplice VRRP implementazione. Keepalived ha anche la possibilità di configurare server virtuali IP Linux per il bilanciamento del carico. La configurazione di IPVS non rientra nell'ambito di questa serie, ma è bene sapere che è possibile utilizzare Keepalived per configurare un sistema di bilanciamento del carico ridondante all-in-one per il tuo ambiente.

Operazione protocollo VRRP

VRRP Il comportamento di è specificato da RFC 3768 (versione 2) e RFC 5798 (versione 3). Userò la versione 2 in questa serie di articoli. Sebbene la revisione dell'RFC sia il modo migliore per comprendere appieno il comportamento del protocollo, non è necessario essere un esperto per iniziare a utilizzare Keepalived di implementazione nel tuo ambiente. Tuttavia, conoscenza di base di VRRP Il comportamento di ' ti posizionerà meglio per operare e risolvere i problemi nel tuo ambiente.

Il primo passo in VRRP L'operazione consiste nell'elezione di un master per determinare quale server (o router, nella specifica del protocollo) conterrà l'indirizzo IP condiviso. VRRP i server sono configurati con un valore di priorità, che può essere considerato come un peso. Il server con la priorità più alta sarà il proprietario di un VRRP indirizzo. La specifica indica che la priorità del master dovrebbe essere 255 , con eventuali server di backup con un valore inferiore a 255 . In pratica, una priorità di 255 non è strettamente necessario in quanto il protocollo selezionerà il server con la priorità più alta, anche se non è 255.

Una volta stabilito un master, tutti gli altri server ascoltano i messaggi periodici inviati dal master per indicare che è ancora attivo. Il master invia questi annunci a intervalli regolari. Finché il master è in vita, servirà il traffico per il VIP e invierà annunci pubblicitari. Se il master va offline per qualche motivo, il server di backup con la priorità più alta prenderà il posto. Allo stesso modo, una funzione chiamata prelazione può consentire a qualsiasi server con priorità più alta di diventare automaticamente master quando è online.

Quando un master si collega per la prima volta e acquisisce un indirizzo IP, trasmette un ARP gratuito. Questo messaggio informa gli altri server sulla rete dell'indirizzo MAC associato al VIP in modo che possano indirizzare correttamente il proprio traffico al livello 2. Inoltre rende più veloce il failover VIP:gli host non devono attendere la scadenza dei loro timer ARP e possono aggiorna semplicemente le loro tabelle ARP con l'indirizzo MAC corretto per l'host che possiede il VIP.

Formato pacchetto

Approfondire gli aspetti teorici del funzionamento di un protocollo può essere un po' noioso, ma è fondamentale per capire come funziona una tecnologia (e per risolverla quando si rompe). Se dai un'occhiata alla struttura dei pacchetti di un VRRP pubblicità utilizzando Wireshark, alcune cose diventano più chiare.

Innanzitutto, noterai che sia l'indirizzo di destinazione Ethernet che quello IP sono multicast indirizzi. Il traffico multicast, come suggerisce il nome, viene inviato a più host su una rete che stanno "ascoltando" quell'indirizzo multicast. La maggior parte delle reti evita una configurazione multicast complessa, quindi il traffico multicast per VRRP diventerà traffico di trasmissione sul segmento di rete locale e andrà a tutti gli host.

Puoi anche vedere quel VRRP non è né TCP né UDP. VRRP utilizza il protocollo IP numero 112 per il suo funzionamento. Conoscere questo numero di protocollo può essere importante, perché potrebbe essere necessario configurare il firewall dell'host per consentire questo traffico dal VRRP server nel tuo ambiente.

Una volta che inizi a guardare il VRRP sezione del pacchetto, noterai che contiene tutte le informazioni necessarie per eleggere un master e informare gli altri server del master attuale:

• Virtual Router ID (VRID) è un identificatore univoco per un VRRP istanza e i suoi indirizzi IP (possono essercene più di uno) su una rete. Dovresti evitare di riutilizzare i VRID sulla stessa LAN, ma possono essere tranquillamente riutilizzati su diverse reti Layer 2.
• La priorità è la priorità per l'host che invia l'annuncio. Una volta eletto un master, questa è qualunque sia la priorità definita dal master. La stretta aderenza alle specifiche dovrebbe utilizzare 255 per la priorità del master, ma molte configurazioni scelgono un valore diverso.
• Tipo di autenticazione e stringa di autenticazione contengono una semplice password di testo per autenticare i membri del VRRP gruppo l'uno con l'altro.
• Advertisement Interval indica la frequenza con cui gli annunci verranno inviati dal master. In questo caso, il master invierà un annuncio ogni secondo.
• L'indirizzo IP contiene uno o più indirizzi IP di cui è responsabile il master. Sebbene questa serie riguardi solo il failover di un singolo indirizzo IP, è possibile avere VRRP gestire più IP.

Conclusione

Questo articolo ti ha guidato attraverso il protocollo di base alla base di Keepalived , un'implementazione software di VRRP su Linux. Sebbene la revisione delle specifiche del protocollo possa sembrare noiosa, è fondamentale comprendere i protocolli di rete che operano nel proprio ambiente in modo da poterli configurare e risolvere in modo efficace. Nel prossimo articolo imparerai come installare e configurare Keepalived .

[ Hai bisogno di saperne di più sull'amministrazione del sistema Linux? Prendi in considerazione un corso di amministrazione di sistema Red Hat. ]