La tâche consistait à implémenter une solution à tolérance de pannes pour deux serveurs Web et, si possible, à implémenter l'équilibrage de charge entre les serveurs Web, car parfois une base de données ne pouvait pas répondre à toutes les demandes. Il n'a pas été possible d'acheter un équipement spécial, dans le cadre duquel le schéma suivant a été inventé. L'idée n'est peut-être pas originale, mais sur Internet je n'ai rien trouvé de tel. Notre topologie est la suivante:
Il existe un routeur Cisco qui amène les serveurs Web sur Internet. Deux serveurs Web sur Centos 7 avec nginx. Les adresses IP du premier et du deuxième serveur Web sont respectivement 192.168.20.176/24 et 192.168.20.177/24. Pour mettre en œuvre le plan, les serveurs Web doivent définir la même adresse IP secondaire. Il peut s'agir de n'importe quelle adresse IP privée qui n'est pas utilisée sur votre réseau. J'ai sélectionné 192.168.120.175 et l'ai enregistré avec l'adresse IP secondaire de l'interface eth0 principale des serveurs Web. Sur Centos, cela se fait en créant le fichier eth0: 0 dans le répertoire / etc / sysconfig / network-scripts /. Contenu du fichier:
TYPE="Ethernet" DEVICE=eth0:0 BOOTPROTO="static" IPADDR=192.168.120.175 NETMASK=255.255.255.255 ONBOOT="yes"
Il est important de noter que le masque 255.255.255.255 est utilisé et cela évite tout conflit IP, car les serveurs Web ne l'utiliseront pas pour générer du trafic. Pour ainsi dire, nous aurons des interfaces Loopback sur les serveurs web.
Après cela, le routeur peut implémenter l'équilibrage de charge à l'aide d'un routage statique. Cette technologie est implémentée à l'aide d'IP Cef sur les routeurs Cisco. Lien
ici . D'autres fournisseurs peuvent avoir certaines nuances.
Dans Cisco, la distribution des threads peut se faire de deux manières:
- Par destination (par défaut). Nous avons besoin de cette option. Tous les paquets d'un flux seront envoyés à l'un des deux serveurs. Le principe de fonctionnement est que le hachage est calculé par les adresses IP source et de destination, et en fonction de ce hachage, le premier itinéraire (serveur) ou le second est sélectionné. Ensuite, nous modifierons légèrement ce comportement.
- Par paquet. Cette option ne nous convient pas, car l'équilibrage se fera sur les packages. En gros, le premier paquet sur la première route, le deuxième paquet sur la seconde.
Nous prescrivons deux itinéraires à l'aide des commandes:
ip route 192.168.120.175 255.255.255.255 GigabitEthernet0/0 192.168.20.176 ip route 192.168.120.175 255.255.255.255 GigabitEthernet0/0 192.168.20.177
Ainsi, les deux itinéraires seront installés dans la table de routage et la répartition des charges sera effectuée le long d'eux:
Nous vérifions également si la méthode d'équilibrage est correctement sélectionnée:
L'adresse IP source changera et l'adresse IP de destination sera toujours laissée seule. Cela peut affecter l'uniformité d'équilibrage, compte tenu du NAT. Pour l'optimisation, vous pouvez considérer le port source, qui sera différent de manière aléatoire, selon la session client. Pour ce faire, utilisez la commande suivante:
ip cef load-sharing algorithm include-ports source
Vous devez également configurer le NAT statique pour rediriger les requêtes Web vers l'adresse 192.168.120.175:
ip nat inside source static tcp 192.168.120.175 80 interface GigabitEthernet0/1 80
Qu'obtenons-nous? Les demandes des utilisateurs d'Internet iront à notre routeur, qui les répartira entre nos serveurs par flux, en fonction du port source dans TCP. Lorsque vous ouvrez une nouvelle session, le client peut accéder au nouveau serveur.
Que se passe-t-il si l'un des serveurs tombe en panne? L'itinéraire qui a conduit à ce serveur sera supprimé de la table de routage. Pour optimiser ce processus, vous pouvez utiliser IP SLA. Surveillez l'état des serveurs en exécutant une commande ping toutes les 10 secondes:
ip sla 10 icmp-echo 192.168.20.176 frequency 10 ip sla schedule 10 life forever start-time now ip sla 20 icmp-echo 192.168.20.177 frequency 10 ip sla schedule 20 life forever start-time now
Ensuite, ajoutez la surveillance aux itinéraires appropriés:
ip route 192.168.120.175 255.255.255.255 GigabitEthernet0/0 192.168.20.176 track 10 ip route 192.168.120.175 255.255.255.255 GigabitEthernet0/0 192.168.20.177 track 20
IP SLA sur les routeurs Cisco permet également la surveillance par des requêtes HTTP GET, ce qui aidera à déterminer la panne du serveur Web non seulement par son absence dans le réseau, mais aussi lorsque le service Web est en panne.
Ainsi, pour construire un tel schéma ne nécessite pas d'équipement supplémentaire et aucun logiciel pour les serveurs Web. Tout ce dont vous avez besoin est un routeur capable d'équilibrer le trafic.