le mie informazioni di contatto
Posta[email protected]
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Sommario
Indice di affidabilità del sistema
1. Configurazione dello scheduler (test1 192.168.233.10)
2. Configurazione RS (nginx1 e nginx2)
3. Traduzione dell'indirizzo (test1 192.168.233.10)
Implementazione della modalità DR
1. Configurazione dello scheduler (test1 192.168.233.10)
2. Configurazione RS (nginx1 e nginx2) [deve essere modificata entrambe le volte]
Architettura HA a disponibilità elevata
Risultati sperimentaliModifica
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
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
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
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
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
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
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
Sondaggio rr
Polling ponderato wrr
Connessione minima lc
collegamento minimo pesato WLC
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
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
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
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
sondaggio ponderato
è 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.
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.
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.
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
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
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
Modifica l'algoritmo di polling VIP
Modificare il peso nei sondaggi politici
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
lvs (modalità DR)+nginx+tomcat
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>
<% out.println("Pagina dinamica 1, http://www.test1.com");%>
</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
Visita la pagina statica 192.168.100:81
Visita la pagina dinamica 192.168.233.100:82/index.jsp
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
È 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
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
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 >/etc/sysconfig/ipvsadm
riavvio di ipvsadm
ipvsadm -ln
cd /etc/keepalive
vim keepalived.conf