Condivisione della tecnologia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

L'architettura ad alta disponibilità nel cluster lvs è solo per l'alta disponibilità dello scheduler.

Implementa gli scheduler principali e di backup basati su vrrp

Architettura HA a disponibilità elevata

Pianificatore principale e pianificatore di backup (possono esserci più pianificatori di backup)

Quando lo scheduler funziona normalmente, l'apparecchiatura è completamente ridondata (standby). Non partecipa al funzionamento del cluster. Solo quando lo scheduler principale fallisce, il backup assumerà il lavoro dello scheduler principale. Dopo che lo scheduler principale avrà ripristinato la sua funzione, il master continuerà a fungere da ingresso al cluster e il backup continuerà a essere in uno stato ridondante (a seconda della priorità).

Keepalive si basa sul protocollo vrrp per implementare la soluzione ad alta disponibilità LVS.

1. Indirizzo multicast:

224.0.0.18 comunica in base all'indirizzo multicast I dispositivi primari e secondari inviano messaggi per determinare se l'altra parte è viva.

2. Determinare le posizioni primarie e secondarie in base alla priorità.

3. Failover, se la macchina primaria riattacca, la macchina di backup continuerà a funzionare. Quando la macchina master si ripristina, la macchina di backup continuerà ad attendere.

4. Il passaggio tra primario e secondario corrisponde al passaggio dell'indirizzo VIP.

Keepalive appare specificatamente per LVS, ma non è esclusivo per LVS.

modulo core: il modulo core di keepalive, responsabile dell'avvio e del mantenimento del processo principale e del caricamento dei file di configurazione globale

Modulo vrrp: il modulo che implementa il protocollo vrrp, che è il modulo funzionale principale

modulo di controllo: responsabile del controllo dello stato e può anche controllare lo stato del real server in background.

Sulla base dell'esperimento della modalità DR nel capitolo precedente, aggiungiamo alcune configurazioni. Questa volta vengono utilizzati due pianificatori, uno primario e uno di backup.

Per prima cosa installa keepalive sullo scheduler

yum -y install keepalived

Al termine dell'installazione

Cambiamo il file keepalived.conf

[root@test1 ~]# vim /etc/keepalived/keepalived.conf
   notification_email_from [email protected]
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_01
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
   vrrp_iptables
}
 
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 120
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.124.100
    }
}
 
virtual_server 192.168.124.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    persistence_timeout 50
    protocol TCP
 
    real_server 192.168.124.40 80 {
        weight 1
            TCP_CHECK {
            connect_port 80
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
 
    real_server 192.168.124.50 80 {
                                                                     9,1           36%

Copiare il file di configurazione dal primo scheduler al secondo scheduler

scp root@192.168.233.10:/etc/keepallved/keepallved.conf
/etc/keepallved

Quindi modificare la configurazione

Priorità tra primaria e secondaria

Aggiungi un'opzione iptables

In questo modo, l'accesso alle regole keepalive non verrà interrotto nella tabella delle regole ipetables.

[root@localhost ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.124.100:80 rr persistent 50
  -> 192.168.124.40:80            Route   1      0          0
  -> 192.168.124.50:80            Route   1      0          0

Controlla

Poi riavvia tutto

Dai un'occhiata ai risultati del cliente

Spegniamo prima lo scheduler principale

stsemctl stop keepalived.servers

Lo scheduler di backup assume il lavoro del master e continua a funzionare.

Questo è l'indirizzo VIP che è stato caricato nello scheduler preparato Il client vi sta accedendo.

Può ancora accedere

---

Riassumere

Keepalived ha principalmente tre moduli: core (modulo core, responsabile dell'avvio del processo principale, della manutenzione e del caricamento e dell'analisi dei file di configurazione globale), check (modulo di controllo dello stato) e vrrp (implementazione del protocollo vrrp).

Il principio di funzionamento di Keepalived si basa sul protocollo VRRP. Più server che forniscono le stesse funzioni sono riuniti in un gruppo di server che dispone di un master e di più backup. C'è un VIP sul master che fornisce servizi al mondo esterno (il percorso predefinito di altre macchine nella LAN in cui si trova il server è questo VIP. Il master invierà multicast quando il backup non può ricevere il pacchetto VRRP). penserà che il master è inattivo e quindi, in base alla priorità del livello VRRP, eleggerà un backup per diventare il nuovo master.

Quando si configura LVS + Keepalived, di solito è necessario installare il software correlato (come ipvsadm, keepalived) sui nodi master e backup e configurare il file keepalived.conf. Ad esempio, nel file di configurazione del nodo master, è necessario specificare lo stato (state) come master, interfaccia di rete (interface), ID percorso virtuale (virtual_router_id), priorità (priority), intervallo pubblicitario (advert_int), informazioni di autenticazione (autenticazione) E indirizzo IP virtuale (virtual_ipaddress), ecc.; la configurazione del nodo di backup è simile, ma lo stato è backup e la priorità è solitamente inferiore a quella del master.

Una volta completata la configurazione, riavviare il servizio keepalived per ottenere un bilanciamento del carico ad alta disponibilità. Quando il nodo master si guasta, VIP passerà automaticamente al nodo di backup per garantire il normale accesso al servizio dopo il ripristino del master, fungerà nuovamente da nodo di carico principale; Inoltre anche il Real Server (rs) può essere configurato di conseguenza. Ad esempio, quando si utilizza il modello DR per la comunicazione, lo deve essere configurato come VIP sulla scheda di rete di rs.

In questo modo la combinazione LVS + Keepalived può raggiungere i seguenti obiettivi: il client accede al servizio tramite VIP e la richiesta verrà distribuita secondo le regole di configurazione quando il nodo di bilanciamento del carico del master fallisce, potrà passare automaticamente al backup; nodo per garantire che il servizio sia normale; quando un determinato rs Quando un nodo fallisce, il nodo può essere rimosso automaticamente e può essere aggiunto nuovamente al cluster dopo il ripristino.

Nelle applicazioni reali è necessario prestare attenzione a questioni rilevanti, ad esempio l'indirizzo IP configurato da virtual_ipaddress nel file di configurazione Keepalived deve essere nello stesso segmento di rete maggiore è il valore di priorità, maggiore è la probabilità che il nodo diventi master; nodo; minore è il valore advert_int, maggiore è la probabilità che il nodo invii messaggi VRRP. Allo stesso tempo, per garantire la stabilità e il funzionamento efficiente dell’intero sistema, è necessario considerare anche fattori come l’ambiente di rete e le prestazioni del server.