Que dois-je faire si la puissance d'un serveur n'est pas suffisante pour traiter toutes les demandes et que le fabricant 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 demandes. Laquelle est correcte, vous devez examiner la situation en tenant compte des conditions existantes. Dans cet article, nous vous dirons ce qui peut être fait si le budget est limité et qu'un serveur gratuit est disponible.

En tant que système pour lequel il était nécessaire de réduire la charge sur l'un des serveurs, nous avons choisi InfoWatch DLP (Information Leak Prevention System). 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 est l'impossibilité d'utiliser Source NAT (SNAT). Pour ce qui était nécessaire et comment le problème a été résolu, nous décrirons plus loin.

Ainsi, le schéma logique initial du système existant était le suivant:

Le trafic ICAP, SMTP, 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 géré la charge après le traitement des événements sur la MT, mais la charge sur la TM elle-même était importante. Cela était évident par l'occurrence de la file d'attente de messages sur le serveur Device Monitor (DM), ainsi que par le chargement du processeur et de la mémoire sur la TM.

À première vue, si nous ajoutons un autre serveur TM à ce schéma, ICAP ou DM pourrait y être basculé, 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 de la bonne solution, nous avons opté pour le logiciel freeware keepalived avec LVS . Étant donné que keepalived résout le problème de la création d'un cluster de basculement, il peut également gérer l'équilibreur LVS.

Ce que nous voulions en venir (réduire la charge sur TM et maintenir le niveau actuel de tolérance aux pannes) devrait fonctionner selon le schéma suivant:

Lors de la vérification des performances, 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 que les paquets entrants et leurs réponses soient envoyés à partir de la même adresse IP, sinon nous obtiendrions l'image suivante:

C'est inacceptable. Par exemple, un serveur proxy, envoyant des paquets à une adresse IP virtuelle (VIP), attendra une réponse de VIP, mais dans ce cas, elle proviendra d'IP2 pour les sessions envoyées à la sauvegarde. La solution a été trouvée: il était nécessaire de créer une autre table de routage lors de la sauvegarde et de connecter les deux serveurs TM à un réseau distinct, comme illustré ci-dessous:

Paramètres

Nous implémentons 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 avons deux serveurs RHEL6, dont les référentiels standard et une partie des packages ont été supprimés.

Services que nous devons équilibrer:

• ICAP - TCP 1344;

• SMTP - TCP 25.

Service de trafic DM - TCP 9100.

Nous devons d'abord 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.

Activez ensuite le transfert IP sur les deux serveurs TM. Comment le faire sur RedHat est décrit ici .

Nous décidons lequel des serveurs nous aurons le principal et lequel - la sauvegarde. Laissez le maître être TM6_1, la sauvegarde être TM6_2.

Lors de la sauvegarde, créez une nouvelle table de routage d'équilibrage 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 balancer 

Les commandes ci-dessus fonctionnent jusqu'à ce que le système redémarre. Pour conserver les routes après le 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: cela utilise une syntaxe différente).

Installez keepalived sur les deux serveurs TM. En tant que source de distribution, nous avons utilisé rpmfind.net:

 [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.rpm 

Dans les paramètres de conservation, nous attribuons l'un des serveurs maîtres, l'autre - la sauvegarde. Ensuite, nous définissons VIP et des services pour l'équilibrage de charge. Le fichier de paramètres se trouve généralement ici: /etc/keepalived/keepalived.conf .

 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 } } } 

 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 } } 

Installez sur le LVS maître, ce qui équilibrera le trafic. Pour le deuxième serveur, cela n'a aucun sens d'installer un équilibreur, car dans la configuration, nous n'avons que deux serveurs.

 [root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpm 

L'équilibreur sera géré par le keepalived que nous avons déjà configuré.

Pour compléter l'image, ajoutez keepalived à l'exécution automatique sur les deux serveurs:

 [root@tm6_1 ~]#chkconfig keepalived on 

Conclusion

Vérification des résultats

Exécutez keepalived sur les deux serveurs:

 service keepalived start 

Vérifier la disponibilité de l'adresse virtuelle VRRP

Assurez-vous que le VIP est maître:

Et il n'y a pas de VIP sur la sauvegarde:

À l'aide de la commande ping, vérifiez la disponibilité de VIP:

Vous pouvez maintenant désactiver master et réexécuter la commande ping .

Le résultat devrait rester le même, et lors de la sauvegarde, nous verrons VIP:

Vérifier l'équilibrage des services

Prenez SMTP, par exemple. Exécutez deux connexions à 10.20.20.105 en même temps:

 telnet 10.20.20.105 25 

Sur le maître, nous devons voir que les deux connexions sont actives et connectées à différents serveurs:

 [root@tm6_1 ~]#watch ipvsadm –Ln 

Ainsi, nous avons implémenté une configuration de sécurité des services TM avec l'installation d'un équilibreur sur l'un des serveurs TM. Pour notre système, cela a réduit de moitié la charge sur TM, ce qui nous a permis de résoudre le problème du manque de mise à l'échelle horizontale au moyen du système.

Dans la plupart des cas, cette solution est mise en œuvre rapidement et sans frais 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.