cluster lvs, mode NAT et mode DR, keepalive

Fonction principale : formez plusieurs serveurs back-end en un cluster de serveurs hautement disponible et hautes performances, et distribuez les demandes des clients aux serveurs back-end via des algorithmes d'équilibrage de charge pour obtenir une haute disponibilité et un équilibrage de charge.

Le solde du serveur SLB d'Alibaba est implémenté à l'aide de lvs+keepalive.

Clusterisé et distribué

Comment étendre le système :

Mise à l'échelle verticale : mise à l'échelle vers le haut pour créer des ordinateurs plus performants.Goulot d'étranglement : limitations du propre équipement de l'ordinateur ; goulots d'étranglement en termes de performances du matériel lui-même.

Expansion horizontale : agrandissez vers l'extérieur et ajoutez de l'équipement.Exécutez plusieurs services en parallèle et comptez sur le réseau pour résoudre les problèmes de communication interne, cluster cluster

Cluster : un système unique formé en combinant plusieurs ordinateurs pour résoudre un problème spécifique

Types de clusters : trois types

KG: cluster d'équilibrage de charge, composé de plusieurs hôtes, chaque hôte ne supporte qu'une partie des demandes d'accès

HA : haute disponibilité : lors de la conception du système, certaines mesures sont prises pour garantir qu'en cas de défaillance d'un composant ou d'une partie du système, l'ensemble du système peut toujours fonctionner normalement.Pour maintenir la disponibilité, la fiabilité et la tolérance aux pannes du système

HPC： cluster de calcul haute performance, avec des exigences plus élevées en matière de temps de réponse et de puissance de traitement

Indice de fiabilité du système

Mon BF：Mean Time Between Failure Temps moyen entre les pannes

Temps moyen de réaction：Mean Time Recovery répare le temps moyen de récupération

A=MTBF/(MTBF+MTTR)

L'indice A doit être compris entre 0 et 1. L'indice A est une mesure de la disponibilité du système. 0 signifie que le système est moins disponible, 1 signifie que le système est plus disponible.

L'indicateur A doit être infiniment proche de 1 (98 % à 99 % qualifié ; 90 % à 95 % non qualifié)

Tous sont en heures (8760 heures en 1 an, 365 jours)

Les temps d'arrêt et le temps planifié ne sont pas inclus

Le temps non planifié, c'est-à-dire le temps d'échec, est le temps total écoulé entre l'apparition d'un échec et sa résolution. Le temps imprévu est un indicateur auquel nous devons prêter attention.

Scénarios applicables LVS :

Les petits clusters n'ont pas besoin d'utiliser lvs, utilisez nginx, les grands clusters utilisent lvs

Terminologie dans le cluster LVS

VS : Le nom logique du service lvs du serveur virtuel, qui est l'adresse IP et le port que nous utilisons pour accéder au cluster lvs en externe.

DS : Le serveur principal du cluster lvs du serveur directeur, c'est-à-dire le planificateur (c'est-à-dire le serveur proxy nginx), est le cœur du cluster. Le planificateur est utilisé pour accepter les demandes des clients et les transmettre au back-end. serveur.

RS : le vrai serveur dans le cluster lvs du serveur réel, le serveur back-end, est utilisé pour accepter les requêtes transmises par DS et répondre aux résultats.

CIP : client ip L'adresse du client, c'est-à-dire l'adresse du client qui a initié la demande

VIP : adresse IP virtuelle utilisée par le cluster lvs, adresse IP virtuelle qui fournit un accès externe au cluster

DIP : l'ip du directeur est l'adresse du planificateur dans le cluster, utilisée pour communiquer avec RS

RIP : real ip L'adresse IP du serveur back-end dans le cluster

Comment fonctionne le LV

Mode NAT : le mode est répondu au client par le planificateur (traduction d'adresse)

Mode DR (mode de routage direct) : le serveur réel répond directement au client

Mode TUN : mode tunnel

Modes couramment utilisés : mode NAT et mode DR

Mode NAT

En mode NAT, LVS modifiera l'adresse IP et le port cibles dans le message de demande du client en adresse IP et en port dans LVS, puis transmettra la demande au serveur principal.

Lorsque le résultat de la réponse est renvoyé au client, le message de réponse est traité par lvs et l'adresse IP et le port cibles sont modifiés par l'adresse IP et le port du client.

Principe : Premièrement, lorsque l'équilibreur de charge reçoit le paquet de requête du client, il décide à quel serveur réel (RS) backend envoyer la requête en fonction de l'algorithme de planification.
L'équilibreur de charge modifie ensuite l'adresse IP cible et le port du paquet de requête envoyé par le client vers l'adresse IP (RIP) du serveur réel back-end.
Une fois que le serveur réel a répondu à la demande, il vérifie la route par défaut et envoie le paquet de données de réponse à l'équilibreur de charge. Après avoir reçu le paquet de réponse, l'équilibreur de charge.
Remplacez l'adresse source du paquet par une adresse virtuelle (VIP) et renvoyez-la au client.

Avantages : les serveurs du cluster peuvent utiliser n'importe quel système d'exploitation prenant en charge TCP/IP, à condition que l'équilibreur de charge dispose d'une adresse IP légale.

Inconvénients : évolutivité limitée. Lorsque les nœuds de serveur grandissent trop, puisque toutes les requêtes et réponses doivent passer par l'équilibreur de charge.
Par conséquent, l’équilibreur de charge deviendra le goulot d’étranglement de l’ensemble du système.

Caractérisé par la traduction d'adresse

Traduction d'adresse : réseau interne - réseau externe, l'adresse IP source est traduite SNAT

Réseau externe-réseau interne convertit l'adresse IP de destination DNAT

outils LV

ipvsadmOutils de configuration et de gestion des clusters LVS

-A ajoute un serveur virtuel VIP

-D supprimer l'adresse du serveur virtuel

-s spécifie l'algorithme de planification d'équilibrage de charge

-a ajoute un vrai serveur

-d supprime le vrai serveur

-t spécifie l'adresse VIP et le port

-r spécifie l'adresse et le port de rip

-m Utiliser le mode NAT

-g Utiliser le mode DR

-i Utiliser le mode tunnel

-w définit le poids

-p 60 maintient la connexion pendant 60 s. Définit le temps de maintien de la connexion.

-l vue en liste

-n affichage numérique

algorithme

Sondage rr

Taux de sondage pondéré

Connexion minimale LC

wlc de moindre lien pondéré

expérience

flux de données

nginx 1 RS1 192.168.233.20

nginx2 RS2 192.168.233.30

planificateur test1 ens33 192.168.233.10 ens36 12.0.0.1

client test2 12.0.0.10

étape

1. Configuration du planificateur (test1 192.168.233.10)

yum -y installer ipvsadm* -y

Configurer ens33

systemctl redémarrer le réseau

Configurer ens36

cd /etc/sysconfig/network-scripts/

cp ifcfg-ens33 ifcfg-ens36

vim ifcfg-ens36

systemctl redémarrer le réseau

2. Configuration RS (nginx1 et nginx2)

Configurer nginx1 192.168.233.20 Modifier la passerelle

systemctl redémarrer le réseau

Configurer nginx2 192.168.233.30 Modifier la passerelle

systemctl redémarrer le réseau

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

Modifier le contenu de la page visitée

Vérifiez si l'accès est connecté

3. Traduction d'adresse (test1 192.168.233.10)

iptables -t nat -vnL Vérifier si la table nat a une politique

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

L'adresse de l'appareil 192.168.233.0/24 est convertie en 12.0.0.1

ipvsadm -C efface la politique d'origine

ipvsadm -A -t 12.0.0.1:80 -s rr Spécifiez l'adresse VIP et le port

Ajoutez d'abord le VIP, l'IP et le port du serveur virtuel, puis ajoutez le serveur réel

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

-un ajout d'un vrai serveur

-t spécifie l'adresse VIP

-r spécifie l'adresse et le port du vrai serveur

-m spécifie le mode comme mode nat

ipvsadm -ln vue

ipvsadm-save enregistrer

ipvsadm -D -t 192.168.233.10:80 supprimer la stratégie

ipvsadm -d -r 192.168.233.20 : -t 12.0.0.1:80 supprimer le serveur de nœuds

5. Activer la fonction de routage et de transfert

vim /etc/sysctl.conf

net.ipv4.ip_forward=1

4. Client (test2 12.0.0.10)

Modifier l'adresse IP et la passerelle de test2

Résultats expérimentaux

sondage pondéré

Mode DR

concept

c'est le mode de routage direct

Mode NAT : le planificateur est le plus important de tout le cluster LVS. En mode NAT, il est responsable de la réception des requêtes, du transfert du trafic selon l'algorithme d'équilibrage de charge et de l'envoi des réponses au client.

Mode DR : le planificateur est toujours responsable de la réception des demandes et transmet également le trafic vers RS selon l'algorithme d'équilibrage de charge, et la réponse est directement envoyée au client par RS.

Routage direct : il s'agit d'un mode de transfert de couche 2. La couche 2 transmet les trames de données et les transmet en fonction de l'adresse MAC source et de l'adresse MAC de destination sans modifier l'adresse IP source et l'adresse IP de destination du paquet de données. Transférer en fonction de l'adresse MAC du paquet de données.

En mode DR, LVS conserve également une adresse IP virtuelle et toutes les requêtes sont envoyées à ce VIP. Puisque le transfert de couche 2 est utilisé, lorsque la requête du client atteint le planificateur, un RS est sélectionné en fonction de l'algorithme d'équilibrage de charge et du serveur VIP. est modifié. Le mac de destination devient l'adresse mac de RS. Une fois que RS a traité la requête, il peut directement envoyer la réponse au client en fonction de l'adresse mac source du client dans le message, sans passer par le planificateur.

Principe : Premièrement, lorsque l'équilibreur de charge reçoit le paquet de requête du client, il décide à quel serveur réel (RS) backend envoyer la requête en fonction de l'algorithme de planification.
L'équilibreur de charge modifie ensuite l'adresse MAC de destination du paquet de requête envoyé par le client en l'adresse MAC (R-MAC) du serveur réel backend.
Une fois que le serveur réel a répondu à la demande, il vérifie la route par défaut et envoie le paquet de réponse directement au client sans passer par l'équilibreur de charge.

Avantages : L'équilibreur de charge est uniquement responsable de la distribution des paquets de requêtes aux serveurs de nœuds back-end, tandis que RS envoie les paquets de réponse directement aux utilisateurs.
Par conséquent, la grande quantité de flux de données via l'équilibreur de charge est réduite. L'équilibreur de charge ne constitue plus le goulot d'étranglement du système et peut gérer une énorme quantité de requêtes.

Inconvénients : l'équilibreur de charge et le véritable serveur RS doivent avoir une carte réseau connectée au même segment de réseau physique et doivent être dans le même environnement LAN.

Diagramme de flux de données

question:

1.Conflit d'adresse VIP

Raison : Le planificateur est configuré avec VIP et le RS est également configuré avec une adresse VIP. Un conflit d'adresse VIP, car le planificateur et RS sont tous deux sur le même segment de réseau, entraînera un trouble de la communication ARP. Comme il est diffusé sur l'ensemble du réseau local, tous les appareils le reçoivent.

Comment bloquer la réponse de bouclage de lo afin que seule l'adresse IP physique de cette machine réponde.

Solution : Modifiez les paramètres du noyau :arp_ignore=1

Seule l'adresse IP physique du système répondra aux requêtes ARP, et l'interface de bouclage lo ne répondra pas aux requêtes ARP.

2. Lorsque le message est renvoyé, l'adresse VIP est toujours là. Comment le client peut-il recevoir la réponse ?

Solution:arp_announce=2

Le système n'utilise pas l'adresse source du paquet IP pour répondre à la requête ARP, mais envoie directement l'adresse IP de l'interface physique.

Implémentation du mode DR

nginx1 RS (adresse IP réelle) 192.168.233.20

nginx2 RS 192.168.233.30

VIP 192.168.233.100

Planificateur 192.168.233.10

Client 192.168.233.40

étape

1. Configuration du planificateur (test1 192.168.233.10)

yum -y installer ipvsadm* -y

Ajouter une carte réseau virtuelle ens33:0

Modifier les paramètres de réponse du planificateur

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

sysctl -p

Ajouter une stratégie

cd /option

ipvsadm -A -t 192.168.233.100:80 -s rr

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

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

ipvsadm-save >/etc/sysconfig/ipvsadm

systemctl redémarre ipvsadm

ipvsadm -ln

2. Configuration RS (nginx1 et nginx2) [doit être modifiée les deux fois]

Modifier le contenu d'affichage des pages statiques

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

systemctl redémarre nginx

Ajouter une adresse de bouclage

cd /etc/sysconfig/network-scripts/

cp ifcfg-lo ifcfg-lo:0

vim ifcfg-lo:0

Ajouter l'interface lo:0 en tant que VIP

route ajouter -hôte 192.168.233.100 dev lo:0

Définissez l'adresse IP sur 192.168.233.100 et ajoutez-la à l'interface de bouclage en tant que VIP de lvs. Elle est transmise à RS via le mode de routage, ce qui permet au VIP d'identifier le vrai serveur.

Modifier la réponse du noyau du serveur réel 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

Résultats expérimentaux

Modifier l'algorithme de sondage VIP

Modifier le poids dans les sondages de politique

Résumer

La différence entre lvs et nginx pour l'équilibrage de charge

LVS est un transfert à quatre couches, utilisant le port ip + en mode noyau, et ne peut être utilisé que comme proxy à quatre couches.

Proxy nginx à quatre couches ou proxy à sept couches

Expérience récapitulative

lvs (mode DR)+nginx+tomcat

LVS implémente le transfert à quatre couches + nginx implémente le transfert à sept couches (dynamique). L'accès à l'adresse VIP de LVS peut réaliser une séparation dynamique et statique.

Diagramme de flux de données

Étapes expérimentales

Sur la base des expériences ci-dessus en mode DR, une séparation dynamique et statique est obtenue.

1. partie Tomcat

1. Créez des pages dynamiques dans Tomcat1 et Tomcat2 respectivement

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>
<html>
<head>
<title>Test JSP1 page</title>
</head>
<body>
<% out.println("Page dynamique 1, http://www.test1.com");%>
</body>
</html>

2. Ajoutez des sites à Tomcat1 et Tomcat2 respectivement

cd-conf

serveur vim.xml

Supprimez d'abord le site d'origine

Vérifiez si le port est démarré

Visitez 192.168.233.40:8080/index.jsp

2. Partie nginx

Configurer nginx2 et nginx3

cd /usr/local/nginx/conf/

cp nginx.conf nginx.conf.bak.2024.07.08

fichier fichier vim nginx.conf

Tomcat en amont {
serveur 192.168.233.40:8080 poids=1;
serveur 192.168.233.50:8080 poids=1;
}

emplacement ~ .*.jsp$ {
proxy_pass http://tomcat;
proxy_set_header HÔTE $hôte;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Transféré-Pour $proxy_add_x_forwarded_for;
}

Puis systemctl redémarre nginx

Configurer le proxy nginx1

Soyez un agent à quatre niveaux

cd /usr/local/nginx/conf

fichier fichier vim nginx.conf

Puis systemctl redémarre nginx

Résultats expérimentaux

Visitez la page statique 192.168.100:81

Visitez la page dynamique 192.168.233.100:82/index.jsp

Trois modes de travail de LV

Dr Nat Tun

Avantages : traduction d'adresses, configuration simple, WAN aux meilleures performances, possibilité de transfert de paquets de données sur de plus longues distances

Inconvénients Goulot d'étranglement en termes de performances Ne prend pas en charge les canaux dédiés aux segments inter-réseaux, nécessite l'ouverture d'un VPN (coûteux)

Exigences RS : aucune restriction sur les interfaces non physiques ne doit être désactivée. Le mode tunnel doit être pris en charge.

Quantité d'unités RS 10-20 100 unités 100 unités

Questions d'entretien :

1. Décrivez brièvement les trois modes et différences des LV

tableau ci-dessus

2. Comment résoudre le problème du cerveau divisé dans Keepalive