Was kann ich tun, wenn die Leistung eines Servers nicht ausreicht, um alle Anforderungen zu verarbeiten, und der Softwarehersteller keinen Lastenausgleich vorsieht? Es gibt viele Möglichkeiten - vom Kauf eines Load Balancers bis zur Begrenzung der Anzahl der Anfragen. Welches ist richtig, müssen Sie die Situation unter Berücksichtigung der bestehenden Bedingungen zu betrachten. In diesem Artikel erfahren Sie, was zu tun ist, wenn das Budget begrenzt ist und ein kostenloser Server verfügbar ist.

Als ein System, für das es notwendig war, die Last auf einem der Server zu reduzieren, haben wir InfoWatch DLP (Information Leak Prevention System) gewählt. Ein Merkmal der Implementierung war die Platzierung der Balancer-Funktion auf einem der "Kampf" -Server.

Eines der Probleme, auf die wir gestoßen sind, ist die Unfähigkeit, Source NAT (SNAT) zu verwenden. Wofür es gebraucht wurde und wie das Problem gelöst wurde, werden wir weiter beschreiben.

Das ursprüngliche logische Diagramm des vorhandenen Systems lautete also wie folgt:

ICAP-Datenverkehr, SMTP und Ereignisse von Benutzercomputern wurden auf dem Traffic Monitor-Server verarbeitet. Gleichzeitig konnte der Datenbankserver die Last nach der Verarbeitung von Ereignissen auf dem TM problemlos bewältigen, aber die Last auf dem TM selbst war groß. Dies wurde durch das Auftreten der Nachrichtenwarteschlange auf dem Device Monitor (DM) -Server sowie durch das Laden des Prozessors und des Speichers auf dem TM deutlich.

Wenn wir diesem Schema einen weiteren TM-Server hinzufügen, könnten auf den ersten Blick entweder ICAP oder DM darauf umgestellt werden, aber wir haben uns entschieden, diese Methode nicht zu verwenden, da die Fehlertoleranz verringert wurde.

Lösungsbeschreibung

Auf der Suche nach der richtigen Lösung haben wir uns zusammen mit LVS für die Freeware Keepalived- Software entschieden. Da Keepalived das Problem der Erstellung eines Failover-Clusters löst, kann es auch den LVS-Balancer verwalten.

Was wir erreichen wollten (TM entlasten und die aktuelle Fehlertoleranz beibehalten), sollte nach folgendem Schema funktionieren:

Bei der Überprüfung der Leistung stellte sich heraus, dass die auf den Servern installierte benutzerdefinierte RedHat-Assembly SNAT nicht unterstützt. In unserem Fall wollten wir SNAT verwenden, damit eingehende Pakete und Antworten von derselben IP-Adresse gesendet werden. Andernfalls erhalten wir das folgende Bild:

Das ist inakzeptabel. Beispielsweise wartet ein Proxyserver, der Pakete an eine virtuelle IP-Adresse (VIP) sendet, auf eine Antwort von VIP, in diesem Fall jedoch von IP2 für Sitzungen, die an die Sicherung gesendet werden. Die Lösung wurde gefunden: Es war erforderlich, eine weitere Routing-Tabelle für die Sicherung zu erstellen und die beiden TM-Server mit einem separaten Netzwerk zu verbinden, wie unten gezeigt:

Einstellungen

Wir implementieren ein Schema von zwei Servern mit ICAP-, SMTP-, TCP 9100-Diensten und einem darauf installierten Load Balancer.

Wir haben zwei RHEL6-Server, von denen die Standard-Repositorys und ein Teil der Pakete entfernt wurden.

Dienstleistungen, die wir ausgleichen müssen:

• ICAP - TCP 1344;

• SMTP - TCP 25.

DM-Verkehrsdienst - TCP 9100.

Zuerst müssen wir das Netzwerk planen.

Virtuelle IP-Adresse (VIP):

• IP: 10.20.20.105.

Server TM6_1:

• Externe IP: 10.20.20.101;

• Interne IP: 192.168.1.101.

Server TM6_2:

• Externe IP: 10.20.20.102;

• Interne IP: 192.168.1.102.

Aktivieren Sie dann die IP-Weiterleitung auf den beiden TM-Servern. Wie es bei RedHat gemacht wird, wird hier beschrieben.

Wir entscheiden, welchen der Server wir haben und welchen - das Backup. Sei master TM6_1, backup TM6_2.

Erstellen Sie beim Sichern eine neue Balancer-Routing-Tabelle und -Routing-Regeln:

[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 

Die obigen Befehle funktionieren, bis das System neu gestartet wird. Um die Routen nach dem Neustart beizubehalten , können Sie sie in /etc/rc.d/rc.local eingeben , jedoch besser über die Einstellungsdatei / etc / sysconfig / network-scripts / route-eth1 (Hinweis: Dies verwendet eine andere Syntax).

Installieren Sie keepalived auf beiden TM-Servern. Als Distributionsquelle haben wir rpmfind.net verwendet:

 [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 

In den Keepalived-Einstellungen weisen wir einen der Master-Server zu, den anderen - das Backup. Dann setzen wir VIP und Dienste für den Lastausgleich. Die Einstellungsdatei befindet sich normalerweise hier: /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 } } 

Installation auf Master-LVS, um den Datenverkehr auszugleichen. Für den zweiten Server macht es keinen Sinn, einen Balancer zu installieren, da wir in der Konfiguration nur zwei Server haben.

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

Der Balancer wird von dem Keepalived verwaltet, den wir bereits konfiguriert haben.

Fügen Sie auf beiden Servern keepalived hinzu, um das Bild zu vervollständigen:

 [root@tm6_1 ~]#chkconfig keepalived on 

Fazit

Ergebnisse überprüfen

Führen Sie keepalived auf beiden Servern aus:

 service keepalived start 

Überprüfen Sie die Verfügbarkeit der virtuellen VRRP-Adresse

Stellen Sie sicher, dass sich der VIP auf dem Master befindet:

Und es gibt kein VIP auf dem Backup:

Überprüfen Sie mit dem Befehl ping die Verfügbarkeit von VIP:

Jetzt können Sie den Master ausschalten und den ping Befehl erneut ausführen.

Das Ergebnis sollte gleich bleiben, und beim Backup sehen wir VIP:

Überprüfen Sie Service Balancing

Nehmen Sie zum Beispiel SMTP. Führen Sie gleichzeitig zwei Verbindungen zu 10.20.20.105 aus:

 telnet 10.20.20.105 25 

Auf dem Master sollten wir sehen, dass beide Verbindungen aktiv sind und mit verschiedenen Servern verbunden sind:

 [root@tm6_1 ~]#watch ipvsadm –Ln 

Daher haben wir eine ausfallsichere Konfiguration von TM-Diensten mit der Installation eines Balancers auf einem der TM-Server implementiert. Für unser System reduzierte sich dadurch die Belastung von TM um die Hälfte, was es uns ermöglichte, das Problem der fehlenden horizontalen Skalierung mit Hilfe des Systems zu lösen.

In den meisten Fällen ist diese Lösung schnell und ohne zusätzliche Kosten implementiert, aber manchmal gibt es eine Reihe von Einschränkungen und Schwierigkeiten beim Einrichten, z. B. beim Ausgleich des UDP-Verkehrs.