Condivisione della tecnologia

Cluster lvs, modalità NAT e modalità DR, keepalive

2024-07-12

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

Sommario

concetto di cluster lvs

Tipi di cluster: tre tipi

Indice di affidabilità del sistema

Terminologia nel cluster lvs

Come funziona lvs

Modalità NAT

strumenti lvs

algoritmo

sperimentare

flusso di dati

fare un passo

1. Configurazione dello scheduler (test1 192.168.233.10)

2. Configurazione RS (nginx1 e nginx2)

3. Traduzione dell'indirizzo (test1 192.168.233.10)

Risultati sperimentali

Modalità DR

concetto

Diagramma del flusso di dati

domanda:

1.Conflitto di indirizzo VIP

2. Quando il messaggio viene restituito, l'indirizzo VIP è ancora presente. Come può il client ricevere la risposta?

Implementazione della modalità DR

fare un passo

1. Configurazione dello scheduler (test1 192.168.233.10)

2. Configurazione RS (nginx1 e nginx2) [deve essere modificata entrambe le volte]

Risultati sperimentali

Riassumere

Esperimento riassuntivo

LVS implementa l'inoltro a quattro livelli + nginx implementa l'inoltro a sette livelli (dinamico). L'accesso all'indirizzo VIP di LVS può ottenere la separazione dinamica e statica.

Diagramma del flusso di dati

Passaggi sperimentali

Risultati sperimentali

Tre modalità di lavoro di lvs

Architettura HA a disponibilità elevata

concetto

esperimento keepalive

Passaggi sperimentali

ospite

Modificare

Preparare

Risultati sperimentaliModifica


concetto di cluster lvs

Il nome completo è Linux Virtual Server, ovvero un software che implementa il bilanciamento del carico a livello del kernel Linux.

Funzione principale: forma più server back-end in un cluster di server altamente disponibile e ad alte prestazioni e distribuisce le richieste dei client ai server back-end tramite algoritmi di bilanciamento del carico per ottenere elevata disponibilità e bilanciamento del carico.

Il saldo del loab del server SLB di Alibaba è implementato utilizzando lvs+keepalive.

Raggruppato e distribuito

Come espandere il sistema:

Scaling verticale: scalabilità verso l'alto per creare computer più potenti.Collo di bottiglia: limitazioni dell'attrezzatura propria del computer; colli di bottiglia prestazionali dell'hardware stesso

Espansione orizzontale: espandi verso l'esterno e aggiungi attrezzature.Esegui più servizi in parallelo e fai affidamento sulla rete per risolvere problemi di comunicazione interna, cluster cluster

Cluster: un unico sistema formato combinando più computer per risolvere un problema specifico

Tipi di cluster: tre tipi

LIBBRE: bilanciamento del carico cluster di bilanciamento del carico, composto da più host, ogni host sopporta solo una parte delle richieste di accesso

AH : elevata disponibilità: durante la progettazione del sistema vengono adottate determinate misure per garantire che, in caso di guasto di un componente o di una parte del sistema, l'intero sistema possa ancora funzionare normalmente.Per mantenere la disponibilità, l’affidabilità e la tolleranza agli errori del sistema

Alta pressione sanguigna:Cluster ad alte prestazioni di calcolo ad alte prestazioni, con requisiti più elevati in termini di tempi di risposta e potenza di elaborazione

Indice di affidabilità del sistema

Il mio BF:Tempo medio tra guasti Tempo medio tra guasti

Tempo medio di consegna:Tempo medio di riparazione: tempo medio di ripristino

A=MTBF/(MTBF+MTTR)

L'indice A deve essere compreso tra 0 e 1. L'indice A è una misura della disponibilità del sistema. 0 significa che il sistema è meno disponibile, 1 significa che il sistema è più disponibile.

L'indicatore A dovrebbe essere infinitamente vicino a 1 (98%-99% qualificato; 90%-95% non qualificato)

Tutti sono in ore (8760 ore in 1 anno, 365 giorni)

I tempi di inattività e quelli pianificati non sono inclusi

Il tempo non pianificato, ovvero il tempo di guasto, è il tempo totale che intercorre tra il verificarsi del guasto e la sua risoluzione. Il tempo non pianificato è un indicatore a cui dobbiamo prestare attenzione.

Scenari applicabili LVS:

I cluster piccoli non hanno bisogno di utilizzare lvs, utilizzare nginx, i cluster di grandi dimensioni utilizzano lvs

Terminologia nel cluster lvs

VS: il nome logico del servizio lvs del server virtuale, che è l'indirizzo IP e la porta che utilizziamo quando accediamo al cluster lvs esternamente.

DS: il server principale nel cluster Director Server lvs, ovvero lo scheduler (ovvero il server proxy nginx), è il nucleo del cluster. Lo scheduler viene utilizzato per accettare le richieste del client e inoltrarle al back-end server.

RS: Il real server nel cluster real server lvs, il server back-end, viene utilizzato per accettare le richieste inoltrate da DS e rispondere ai risultati.

CIP: ip client L'indirizzo del client, ovvero l'indirizzo del client che ha avviato la richiesta

VIP: indirizzo IP virtuale utilizzato dal cluster lvs, indirizzo IP virtuale che fornisce l'accesso al cluster esterno

DIP: ip del direttore è l'indirizzo dello scheduler nel cluster, utilizzato per comunicare con RS

RIP: IP reale L'indirizzo IP del server back-end nel cluster

Come funziona lvs

Modalità NAT: la modalità riceve risposta al client dallo scheduler (traduzione dell'indirizzo)

Modalità DR (modalità routing diretto): il real server risponde direttamente al client

Modalità TUN: modalità tunnel

Modalità comunemente utilizzate: modalità NAT e modalità DR

Modalità NAT

In modalità NAT, LVS modificherà l'indirizzo IP e la porta di destinazione nel messaggio di richiesta dal client all'indirizzo IP e alla porta all'interno di LVS, quindi inoltrerà la richiesta al server back-end.

Quando il risultato della risposta viene restituito al client, il messaggio di risposta viene elaborato da lvs e l'IP e la porta di destinazione vengono modificati nell'indirizzo IP e nella porta del client.

Principio: in primo luogo, quando il sistema di bilanciamento del carico riceve il pacchetto di richiesta del cliente, determina a quale backend real server (RS) inviare la richiesta in base all'algoritmo di pianificazione.
Il sistema di bilanciamento del carico modifica quindi l'indirizzo IP di destinazione e la porta del pacchetto di richiesta inviato dal client nell'indirizzo IP (RIP) del real server back-end.
Dopo che il real server ha risposto alla richiesta, controlla il percorso predefinito e invia il pacchetto di dati di risposta al bilanciatore del carico. Dopo aver ricevuto il pacchetto di risposta, il bilanciatore del carico
Modificare l'indirizzo di origine del pacchetto in un indirizzo virtuale (VIP) e inviarlo al client.

Vantaggi: i server nel cluster possono utilizzare qualsiasi sistema operativo che supporti TCP/IP, purché il sistema di bilanciamento del carico disponga di un indirizzo IP legale.

Svantaggi: scalabilità limitata quando i nodi del server crescono troppo, poiché tutte le richieste e le risposte devono passare attraverso il bilanciatore del carico,
Pertanto il bilanciamento del carico diventerà il collo di bottiglia dell’intero sistema.

Caratterizzato dalla traduzione dell'indirizzo

Traduzione dell'indirizzo: rete interna - rete esterna, l'indirizzo IP di origine viene convertito SNAT

Rete esterna-rete interna converte l'indirizzo IP di destinazione DNAT

strumenti lvs

ipvsadmStrumenti per la configurazione e la gestione dei cluster lvs

-A aggiunge il server virtuale VIP

-D elimina l'indirizzo del server virtuale

-s specifica l'algoritmo di pianificazione del bilanciamento del carico

-a aggiunge un server reale

-d elimina il server reale

-t specifica l'indirizzo VIP e la porta

-r specifica l'indirizzo e la porta di rip

-m Utilizza la modalità NAT

-g Usa la modalità DR

-i Usa la modalità tunnel

-w imposta il peso

-p 60 mantiene la connessione per 60 secondi Imposta il tempo di attesa della connessione

-l visualizzazione elenco

-n display digitale

algoritmo

Sondaggio rr

Polling ponderato wrr

Connessione minima lc

collegamento minimo pesato WLC

sperimentare

flusso di dati

nginx 1 RS1 192.168.233.20

nginx2 RS2 192.168.233.30

test1 pianificatore ens33 192.168.233.10 ens36 12.0.0.1

cliente test2 12.0.0.10

fare un passo
1. Configurazione dello scheduler (test1 192.168.233.10)

yum -y installa ipvsadm* -y

Configura ens33

systemctl riavvia la rete

Configura ens36

cd /etc/sysconfig/script-di-rete/

cp ifcfg-ens33 ifcfg-ens36

vim ifcfg-ens36

systemctl riavvia la rete

2. Configurazione RS (nginx1 e nginx2)

Configura nginx1 192.168.233.20 Modifica gateway

systemctl riavvia la rete

Configura nginx2 192.168.233.30 Modifica gateway

systemctl riavvia la rete

vim /usr/local/nginx/html/index.html

Modificare il contenuto della pagina visitata

Controlla se l'accesso è connesso

3. Traduzione dell'indirizzo (test1 192.168.233.10)

iptables -t nat -vnL Controlla se la tabella nat ha una politica

1.

iptables -t nat -A POSTROUTING -s 192.168.233.0/24 -o ens36 -j SNAT --to 12.0.0.1

L'indirizzo del dispositivo da 192.168.233.0/24 viene convertito in 12.0.0.1

2.

ipvsadm -C cancella la policy originale

ipvsadm -A -t 12.0.0.1:80 -s rr Specifica l'indirizzo VIP e la porta

Aggiungi prima il VIP, l'IP e la porta del server virtuale, quindi aggiungi il server reale

3.

Il comando ipvsadm -a -t 12.0.0.1:80 -r 192.168.233.20:80 -m

-a aggiungere un server reale

-t specifica l'indirizzo VIP

-r specifica l'indirizzo e la porta del real server

-m specifica la modalità come modalità nat

ipvsadm -ln vista

4.

ipvsadm-salva salva

ipvsadm -D -t 192.168.233.10:80 elimina criterio

ipvsadm -d -r 192.168.233.20: -t 12.0.0.1:80 elimina il server del nodo

5. Abilita la funzione di instradamento e inoltro

vim /etc/sysctl.conf

net.ipv4.ip_forward=1

4. Cliente (test2 12.0.0.10)

Modificare l'indirizzo IP e il gateway di test2

Risultati sperimentali

sondaggio ponderato

Modalità DR

concetto

è la modalità di routing diretto

Modalità NAT: lo scheduler è il più importante nell'intero cluster LVS, è responsabile della ricezione delle richieste, dell'inoltro del traffico secondo l'algoritmo di bilanciamento del carico e dell'invio delle risposte al client.

Modalità DR: lo scheduler è ancora responsabile della ricezione delle richieste e inoltre inoltra il traffico a RS secondo l'algoritmo di bilanciamento del carico e la risposta viene inviata direttamente al client da RS.

Routing diretto: è una modalità di inoltro di livello 2. Il livello 2 inoltra i frame di dati e li inoltra in base all'indirizzo MAC di origine e all'indirizzo MAC di destinazione senza modificare l'IP di origine e l'IP di destinazione del pacchetto di dati. Inoltra in base all'indirizzo MAC del pacchetto dati.

In modalità DR, LVS mantiene anche un indirizzo IP virtuale e tutte le richieste vengono inviate a questo VIP Poiché viene utilizzato l'inoltro di livello 2, quando la richiesta del client raggiunge lo scheduler, viene selezionata una RS in base all'algoritmo di bilanciamento del carico e al server VIP. viene modificato. Il mac di destinazione diventa l'indirizzo mac di RS. Dopo che RS ha elaborato la richiesta, può inviare direttamente la risposta al client in base all'indirizzo mac di origine del client nel messaggio, senza passare attraverso lo scheduler.

Principio: in primo luogo, quando il sistema di bilanciamento del carico riceve il pacchetto di richiesta del cliente, determina a quale backend real server (RS) inviare la richiesta in base all'algoritmo di pianificazione.
Il bilanciatore del carico modifica quindi l'indirizzo MAC di destinazione del pacchetto di richiesta inviato dal client nell'indirizzo MAC (R-MAC) del real server backend.
Dopo che il real server ha risposto alla richiesta, controlla il percorso predefinito e invia il pacchetto di risposta direttamente al client senza passare attraverso il bilanciatore del carico.

Vantaggi: il bilanciatore del carico è responsabile solo della distribuzione dei pacchetti di richiesta ai server del nodo back-end, mentre RS invia i pacchetti di risposta direttamente agli utenti.
Pertanto, la grande quantità di flusso di dati attraverso il sistema di bilanciamento del carico viene ridotta. Il sistema di bilanciamento del carico non è più il collo di bottiglia del sistema e può gestire un'enorme quantità di richieste.

Svantaggi: sia il bilanciatore di carico che il real server RS ​​devono avere una scheda di rete connessa allo stesso segmento di rete fisica e devono trovarsi nello stesso ambiente LAN.

Diagramma del flusso di dati

domanda:
1.Conflitto di indirizzo VIP

Motivo: lo scheduler è configurato con VIP e anche la RS è configurata con un indirizzo VIP. Il conflitto di indirizzi VIP, poiché lo scheduler e RS si trovano entrambi sullo stesso segmento di rete, causerà disturbi di comunicazione ARP. Poiché viene trasmesso su tutta la LAN, tutti i dispositivi lo ricevono.

Come bloccare la risposta di loopback di lo in modo che risponda solo l'indirizzo IP fisico di questa macchina.

Soluzione: modificare i parametri del kernel:arp_ignora=1

Solo l'indirizzo IP fisico del sistema risponderà alle richieste ARP e l'interfaccia lo loopback non risponderà alle richieste ARP.

2. Quando il messaggio viene restituito, l'indirizzo VIP è ancora presente. Come può il client ricevere la risposta?

Soluzione:arp_announce=2

Il sistema non utilizza l'indirizzo sorgente del pacchetto IP per rispondere alla richiesta ARP, ma invia direttamente l'indirizzo IP dell'interfaccia fisica.

Implementazione della modalità DR

nginx1 RS (ip reale) 192.168.233.20

Codice di errore nginx2

numero di telefono 192.168.233.100

Programmatore 192.168.233.10

Cliente 192.168.233.40

fare un passo
1. Configurazione dello scheduler (test1 192.168.233.10)

yum -y installa ipvsadm* -y

Aggiungi scheda di rete virtuale ens33:0

Modificare i parametri di risposta dello scheduler

vim /etc/sysctl.conf

net.ipv4.ip_forward=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.ens33.send_redirects=0
 

comando di sistema -p

Aggiungi politica

cd /opt

Il comando Il comando ipvsadm -A -t 192.168.233.100:80 -s rr

Il comando Il comando ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.20:80 -g

Il comando Il comando ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.30:80 -g

ipvsadm-save >/etc/sysconfig/ipvsadm

riavvio di ipvsadm

ipvsadm -ln

2. Configurazione RS (nginx1 e nginx2) [deve essere modificata entrambe le volte]

Modificare il contenuto visualizzato delle pagine statiche

vim /usr/local/nginx/html/index.html

riavvio nginx

Aggiungi indirizzo di loopback

cd /etc/sysconfig/script-di-rete/

cp ifcfg-lo ifcfg-lo:0

vim ifcfg-lo:0

Aggiungi l'interfaccia lo:0 come VIP

aggiungi percorso -host 192.168.233.100 dev lo:0

Imposta l'indirizzo IP su 192.168.233.100 e aggiungilo all'interfaccia di loopback come VIP di lvs. Viene inoltrato a RS tramite la modalità routing, che consente al VIP di identificare il server reale.

Modifica la risposta del kernel del real server RS

vim /etc/sysctl.conf

net.ipv4.conf.lo.arp_ignore=1
net.ipv4.conf.lo.arp_announce=2
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

Risultati sperimentali

Modifica l'algoritmo di polling VIP

Modificare il peso nei sondaggi politici

Riassumere

La differenza tra lvs e nginx per il bilanciamento del carico

LVS è un forwarding a quattro livelli, che utilizza IP + porta in modalità kernel e può essere utilizzato solo come proxy a quattro livelli.

proxy a quattro livelli nginx o proxy a sette livelli

Esperimento riassuntivo

lvs (modalità DR)+nginx+tomcat

LVS implementa l'inoltro a quattro livelli + nginx implementa l'inoltro a sette livelli (dinamico). L'accesso all'indirizzo VIP di LVS può ottenere la separazione dinamica e statica.

Diagramma del flusso di dati

Passaggi sperimentali

Sulla base degli esperimenti di cui sopra in modalità DR, si ottiene la separazione dinamica e statica.

1. parte del gatto

1. Crea pagine dinamiche rispettivamente in tomcat1 e tomcat2

<%@ lingua della pagina="java" import="java.util.*" codifica della pagina="UTF-8"%>
<html>
<head>
<title>Pagina di test JSP1</title>
</head>
<body>
&lt;% out.println("Pagina dinamica 1, http://www.test1.com");%&gt;
</body>
</html>

2. Aggiungi siti rispettivamente a tomcat1 e tomcat2

cd conf

vim server.xml

Elimina prima il sito originale

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
    <Context docBase="/usr/local/tomcat/webapps/test" path="" reloadable="true" />

Controlla se la porta è avviata

Visita 192.168.233.40:8080/index.jsp

2. parte nginx

Configura nginx2 e nginx3

cd /usr/local/nginx/conf/

il comando cp nginx.conf nginx.conf.bak.2024.07.08

vim nginx.conf

gatto a monte {
server 192.168.233.40:8080 peso=1;
server 192.168.233.50:8080 peso=1;
}

posizione ~ .*.jsp$ {
proxy_pass http://tomcat;
proxy_set_header HOST $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Inoltrato-Per $proxy_add_x_forwarded_for;
        }

Quindi systemctl riavvia nginx

Configura il proxy nginx1

Diventa un agente a quattro livelli

cd /usr/local/nginx/conf

vim nginx.conf

Quindi systemctl riavvia nginx

Risultati sperimentali

Visita la pagina statica 192.168.100:81

Visita la pagina dinamica 192.168.233.100:82/index.jsp

Tre modalità di lavoro di lvs

NAT DR TUN

Vantaggi: traduzione degli indirizzi, configurazione semplice, WAN dalle migliori prestazioni, possibilità di ottenere l'inoltro di pacchetti di dati su distanze più lunghe

Svantaggi Collo di bottiglia nelle prestazioni Non supporta canali dedicati su segmenti di rete, richiede l'apertura di una VPN (costo in denaro)

Requisiti RS: nessuna restrizione. Le risposte ARP su interfacce non fisiche devono essere disabilitate.

Quantità di RS 10-20 unità 100 unità 100 unità

Domande di un'intervista:

1. Descrivi brevemente le tre modalità e le differenze di lvs

tabella sopra

2. Come risolvere la divisione del cervello in keepalive

Architettura HA a disponibilità elevata

concetto

È un'architettura ad alta disponibilità nel cluster vs, solo per l'elevata disponibilità dello scheduler

Implementare gli scheduler principali e di backup basati su vrp

Pianificatore principale e pianificatore di backup (unità multiple)

Quando lo scheduler principale funziona normalmente, il backup è completamente in uno stato ridondato (standby) e non partecipa al funzionamento del cluster. Solo quando lo scheduler primario fallisce, il server di backup assumerà il lavoro dello scheduler primario. Se lo scheduler principale riprende la sua funzione, lo scheduler principale continuerà a fungere da ingresso al cluster, e quello standby continuerà ad essere in uno stato ridondante, che non dipende necessariamente dalla priorità.

Keepalive si basa sul protocollo vrp per implementare la soluzione ad alta disponibilità lvs

1.Indirizzo multicast

224.0.0.18 comunica in base all'indirizzo multicast e invia messaggi tra i dispositivi primari e secondari.Determina se l'avversario è vivo

2. Determinare le posizioni di primario e secondario in base alla priorità.

3. Failover, se il server primario si guasta, il server di backup continuerà a funzionare.Il Signore si è ripreso ed è in attesa

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 check: responsabile del controllo dello stato e può anche controllare lo stato del real server in background

esperimento keepalive

test1 192.168.233.10 più

test2 192.168.233.50 più

numero di telefono 192.168.233.100

Indirizzo IP del server nginx1

nginx2 192.168.233.30

Cliente 192.168.233.40

Passaggi sperimentali

1. Sia le operazioni primarie che quelle secondarie devono essere eseguite con le stesse modalità.

yum -y installa ipvsadm keepalived

vim /etc/sysctl.conf

net.ipv4.ip_forward=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.ens33.send_redirects=0

comando di sistema -p

ipvsadm -C

Il comando Il comando ipvsadm -A -t 192.168.233.100:80 -s rr

Il comando Il comando ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.20:80 -g

Il comando Il comando ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.30:80 -g

ipvsadm-save &gt;/etc/sysconfig/ipvsadm

riavvio di ipvsadm

ipvsadm -ln

ospite

cd /etc/keepalive

vim keepalived.conf

Preparare

Risultati sperimentali