Que faire si la puissance d'un serveur n'est pas suffisante pour traiter toutes les requêtes et que l'éditeur du logiciel ne prévoit pas d'équilibrage de charge ? Il existe de nombreuses options, de l'achat d'un équilibreur de charge à la limitation du nombre de requêtes. Laquelle est correcte doit être déterminée par la situation, en tenant compte des conditions existantes. Dans cet article, nous vous dirons ce que vous pouvez faire si votre budget est limité et que vous disposez d'un serveur gratuit.
Comme système pour lequel il était nécessaire de réduire la charge sur l'un des serveurs, nous avons choisi le DLP (système de prévention des fuites d'informations) d'InfoWatch. Une caractéristique de l'implémentation était le placement de la fonction d'équilibrage sur l'un des serveurs « de combat ».
L'un des problèmes que nous avons rencontrés était l'impossibilité d'utiliser Source NAT (SNAT). Pourquoi cela était nécessaire et comment le problème a été résolu, nous le décrirons plus en détail.
Ainsi, au départ, le schéma logique du système existant ressemblait à ceci :
Le trafic ICAP, SMTP et les événements des ordinateurs des utilisateurs ont été traités sur le serveur Traffic Monitor (TM). Dans le même temps, le serveur de base de données a facilement fait face à la charge après le traitement des événements sur la MT, mais la charge sur la MT elle-même était lourde. Cela ressort clairement de l'apparition d'une file d'attente de messages sur le serveur Device Monitor (DM), ainsi que de la charge du processeur et de la mémoire sur la TM.
À première vue, si nous ajoutons un autre serveur TM à ce schéma, alors ICAP ou DM pourraient y être basculés, mais nous avons décidé de ne pas utiliser cette méthode, car la tolérance aux pannes était réduite.
Description de la solution
Dans le processus de recherche d'une solution adaptée, nous avons opté pour un logiciel distribué gratuitement avec . Car keepalived résout le problème de la création d’un cluster de basculement et peut également gérer l’équilibreur LVS.
Ce que nous voulions réaliser (réduire la charge sur TM et maintenir le niveau actuel de tolérance aux pannes) aurait dû fonctionner selon le schéma suivant :
Lors de la vérification des fonctionnalités, il s'est avéré que l'assemblage RedHat personnalisé installé sur les serveurs ne prend pas en charge SNAT. Dans notre cas, nous avions prévu d'utiliser SNAT pour garantir que les paquets entrants et leurs réponses sont envoyés à partir de la même adresse IP, sinon nous obtiendrions l'image suivante :
C'est inacceptable. Par exemple, un serveur proxy, ayant envoyé des paquets vers une adresse IP virtuelle (VIP), attendra une réponse de VIP, mais dans ce cas elle proviendra d'IP2 pour les sessions envoyées en sauvegarde. Une solution a été trouvée : il a fallu créer une autre table de routage sur la sauvegarde et connecter deux serveurs TM avec un réseau séparé, comme indiqué ci-dessous :
réglages
Nous mettrons en œuvre un schéma de deux serveurs avec les services ICAP, SMTP, TCP 9100 et un équilibreur de charge installé sur l'un d'eux.
Nous disposons de deux serveurs RHEL6, dont les référentiels standards et certains packages ont été supprimés.
Services que nous devons équilibrer :
• ICAP – TCP 1344 ;
• SMTP – TCP 25.
Service de transmission de trafic de DM – TCP 9100.
Tout d’abord, nous devons planifier le réseau.
Adresse IP virtuelle (VIP) :
• IP : 10.20.20.105.
Serveur TM6_1 :
• IP externe : 10.20.20.101 ;
• IP interne : 192.168.1.101.
Serveur TM6_2 :
• IP externe : 10.20.20.102 ;
• IP interne : 192.168.1.102.
Ensuite, nous activons le transfert IP sur deux serveurs TM. Comment faire cela est décrit sur RedHat .
Nous décidons lequel des serveurs dont nous aurons sera le serveur principal et lequel sera celui de secours. Soit le maître TM6_1, la sauvegarde TM6_2.
Lors de la sauvegarde, nous créons une nouvelle table de routage d'équilibreur et des règles de routage :
[root@tm6_2 ~]echo 101 balancer >> /etc/iproute2/rt_tables
[root@tm6_2 ~]ip rule add from 192.168.1.102 table balancer
[root@tm6_2 ~]ip route add default via 192.168.1.101 table balancerLes commandes ci-dessus fonctionnent jusqu'au redémarrage du système. Pour vous assurer que les routes sont conservées après un redémarrage, vous pouvez les saisir dans /etc/rc.d/rc.local, mais mieux via le fichier de paramètres /etc/sysconfig/network-scripts/route-eth1 (remarque : une syntaxe différente est utilisée ici).
Installez keepalived sur les deux serveurs TM. Nous avons utilisé rpmfind.net comme source de distribution :
[root@tm6_1 ~]#yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/keepalived-1.2.13-5.el6_6.x86_64.rpmDans les paramètres keepalived, nous attribuons l'un des serveurs comme maître, l'autre comme sauvegarde. Ensuite, nous définissons VIP et les services pour l'équilibrage de charge. Le fichier de paramètres se trouve généralement ici : /etc/keepalived/keepalived.conf.
Paramètres du serveur TM1
vrrp_sync_group VG1 {
group {
VI_1
}
}
vrrp_instance VI_1 {
state MASTER
interface eth0
lvs_sync_daemon_inteface eth0
virtual_router_id 51
priority 151
advert_int 1
authentication {
auth_type PASS
auth_pass example
}
virtual_ipaddress {
10.20.20.105
}
}
virtual_server 10.20.20.105 1344 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 1344 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 1344
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 1344 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 1344
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 10.20.20.105 25 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 25 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 25
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 25 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 25
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 10.20.20.105 9100 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 9100 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 9100
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 9100 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 9100
nb_get_retry 3
delay_before_retry 3
}
}
}Paramètres du serveur TM2
vrrp_sync_group VG1 {
group {
VI_1
}
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
lvs_sync_daemon_inteface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass example
}
virtual_ipaddress {
10.20.20.105
}
}Nous installons LVS sur le maître, qui équilibrera le trafic. Cela n'a aucun sens d'installer un équilibreur pour le deuxième serveur, puisque nous n'avons que deux serveurs dans la configuration.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmL'équilibreur sera géré par keepalived, que nous avons déjà configuré.
Pour compléter le tableau, ajoutons keepalived au démarrage automatique sur les deux serveurs :
[root@tm6_1 ~]#chkconfig keepalived onConclusion
Vérification des résultats
Exécutons keepalived sur les deux serveurs :
service keepalived startVérifier la disponibilité d'une adresse virtuelle VRRP
Assurons-nous que le VIP est sur master :
Et il n'y a pas de VIP en sauvegarde :
A l'aide de la commande ping, nous vérifierons la disponibilité du VIP :
Vous pouvez maintenant arrêter le maître et réexécuter la commande ping.
Le résultat devrait rester le même, et lors de la sauvegarde nous verrons VIP :
Vérification de l'équilibrage des services
Prenons SMTP par exemple. Lançons simultanément deux connexions vers 10.20.20.105 :
telnet 10.20.20.105 25Sur master, nous devrions voir que les deux connexions sont actives et connectées à des serveurs différents :
[root@tm6_1 ~]#watch ipvsadm –Ln
Ainsi, nous avons implémenté une configuration tolérante aux pannes des services TM en installant un équilibreur sur l'un des serveurs TM. Pour notre système, cela a réduit de moitié la charge sur TM, ce qui a permis de résoudre le problème du manque de mise à l'échelle horizontale à l'aide du système.
Dans la plupart des cas, cette solution est mise en œuvre rapidement et sans coûts supplémentaires, mais il existe parfois un certain nombre de limitations et de difficultés de configuration, par exemple lors de l'équilibrage du trafic UDP.
Source: habr.com