Tutorial zur Tomcat-Konfiguration für Nginx/Httpd-Lastausgleich

Im vorherigen Blog haben wir über die Verwendung von Nginx und httpd gesprochen, um den Back-End-Tomcat-Dienst für die Rückwärtsgenerierung zu konfigurieren. Eine Übersicht finden Sie unter https://www.jb51.net/article/191277.htm. Heute sprechen wir über die Verwendung von Nginx und httpd, um den Tomcat-Cluster für den Lastenausgleich zu konfigurieren, und die Punkte, die beachtet werden müssen. Die vorherige Demonstration und Konfiguration wurde alle mit einem einzelnen Tomcat konfiguriert und verwendet. In der Produktion kann ein einzelner Tomcat jedoch keinen groß angelegten Zugriff unterstützen. Derzeit müssen wir in Betracht ziehen, mehrere Tomcats zu clustern, um externe Dienste bereitzustellen. Wenn mehrere Tomcats geclustert werden, um externe Dienste bereitzustellen, muss ein Scheduler vorhanden sein, um Clientanforderungen zu planen. Zu den häufig verwendeten Schedulern gehören nginx, httpd, haproxy, lvs usw. Es gibt keinen wesentlichen Unterschied zwischen der Verwendung dieser Scheduler zum Konfigurieren von Tomcat zum Lastenausgleich und anderen Webservern zum Lastenausgleich. Wir können Tomcat einfach als Webserver konfigurieren.

1. Umweltvorbereitung

Führen Sie Docker aus, um zwei Tomcat-Container als Back-End-Tomcat-Server zu starten und ordnen Sie die Webverzeichnisse der beiden Tomcat-Container unter Verwendung von Speichervolumes den Verzeichnissen /tomcat/doc/tomcat1 bzw. tomcat1 zu.

Tipp: Oben laufen zwei Tomcat-Container, nämlich tct1 und tc2, und wir ordnen /usr/local/tomcat/webapps/myapp /tomcat/doc/tomcat1 und tomcat2 des Hostcomputers zu. Auf diese Weise können wir das Webskript direkt in dieses Verzeichnis auf dem Hostcomputer einfügen, um die Webseite auf dem Standard-virtuellen Host von Tomcat bereitzustellen.

Bearbeiten Sie den Inhalt der Homepage-Datei beider Container

Tipp: Oben finden Sie eine Test-Homepage für Tomcat1 bzw. Tomcat2.

Setzen Sie nun tomcat1 und tomcat2 separat ein, um zu sehen, ob auf die entsprechende Homepage zugegriffen werden kann

Tipp: Sie können sehen, dass sowohl tomcat1 als auch tomcat2 zugänglich sind, also ist die Tomcat-Backend-Umgebung bereit. Als Nächstes konfigurieren wir nginx, um die Last auszugleichen.

2. Konfigurieren Sie Nginx für den Lastenausgleich von Tomcat

Tipp: Die obige Konfiguration dient dazu, die beiden Tomcat-Container in der Gruppe tcsevs zusammenzuführen und dann über den Reverse-Proxy / auf diese Gruppe zuzugreifen. Diese Konfiguration ist standardmäßig auf Polling ausgelegt.

Überprüfung: Greifen Sie auf dem Hostcomputer auf Port 80 zu, um zu prüfen, ob Sie auf die von den beiden Backend-Tomcat-Containern bereitgestellten Homepages zugreifen können.

Überprüfen Sie das Syntaxformat der Nginx-Konfigurationsdatei und starten Sie Nginx

Greifen Sie auf Port 80 des Hostcomputers zu, um zu prüfen, ob Sie auf die vom Backend-Tomcat bereitgestellte Seite zugreifen können.

Tipp: Sie können sehen, dass über Port 80 des Hostcomputers normal auf den Tomcat-Backend-Server zugegriffen werden kann, und Sie können auch die Wirkung der standardmäßigen Polling-Planung sehen; hier gibt es jedoch ein Problem. Wenn derselbe Benutzer auf Port 80 des Hostcomputers zugreift, ist die Sitzungs-ID des Antwortergebnisses unterschiedlich, was bedeutet, dass nginx die Statusinformationen des Benutzers nicht verfolgt. Der Grund dafür ist, dass HTTP-Anfragen zustandslos sind. Damit der Dienst die Statusinformationen des Benutzers aufzeichnen kann, können wir basierend auf der Quell-IP auf nginx planen. Was bedeutet das? Für dieselbe Quell-IP-Adresse plant nginx die Anfrage für denselben Backend-Server, sodass die Statusinformationen des Zugriffs desselben Benutzers immer für denselben Backend-Server geplant werden;

Nginx verwaltet die Sitzung basierend auf der Quell-IP

Tipp: ip_hash und hash $remote_addr stehen beide für das Hashen der Quell-IP-Adresse und führen dann eine Modulo-Operation mit dem Ergebnis und der Gesamtgewichtung durch. Die Anfrage wird an den Knoten weitergeleitet, bei dem das Ergebnis anfällt. Was bedeutet das? Wie oben gezeigt gibt es zwei Backend-Server und ihre Gewichtungen sind beide 1, also ist die Summe ihrer Gewichtungen 2. ip_hash und hash $remote_addr sollen eine Hashing-Operation mit den ersten drei Segmenten der IP-Adresse des Clients durchführen und dann eine Modulo-Operation mit dem erhaltenen Wert und der Summe der Gewichtungen. Offensichtlich ist das Ergebnis des Modulo-Backends entweder 0 oder 1. Wenn das Ergebnis nach der Modulo-Operation 1 ist, leitet nginx die Anfrage basierend auf der internen Entsprechung an tomcatB oder tomcatA weiter.

Test: Starten Sie niginx neu und greifen Sie auf Port 80 des Hostcomputers zu, um zu sehen, ob alle Anfragen an denselben Backend-Server weitergeleitet werden.

TIPP: Der Zugriff auf Port 80 der Host -Maschine ist jedoch nicht mehr befragt, aber wenn wir auf Port 80 von 127.0.1 zugreifen, wird er auf Tomcatb geschickt. X wird in der gleichen LAN wie nginxserver die Anfrage an den Backend -Server in derselben LAN entsenden. Der gleiche Backend -Server.

httpd führt den Lastenausgleich für Tomcat durch

Wenn Sie httpd als Lastenausgleich verwenden, müssen Sie bestätigen, ob httpd proxy_http_module, proxy_module und proxy_balancer_module aktiviert hat. Wenn Sie ajp verwenden müssen, müssen Sie auch bestätigen, ob das Modul proxy_ajp_module aktiviert ist, sowie die drei Module des Planungsalgorithmus, lbmethod_bybusyness_module, lbmethod_byrequests_module und lbmethod_bytraffic_module. Für den Planungsalgorithmus können Sie jedes der oben genannten Module aktivieren, und dasselbe gilt für http oder ajp. Aktivieren Sie sie, wenn Sie sie benötigen, und es macht nichts, wenn Sie sie nicht verwenden.

Tipp: Sie können sehen, dass alle Module, die wir verwenden müssen, aktiviert sind;

Konfigurieren Sie httpd, um den Backend-Tomcat zu laden

: : : : : : : : : : : : : : :

Stoppen Sie nginx, überprüfen Sie die Syntax der httpd-Konfigurationsdatei und starten Sie httpd, wenn kein Problem vorliegt

Greifen Sie auf den von httpd bereitgestellten Dienst zu, um zu prüfen, ob Sie auf die Backend-Tomcat-Seite zugreifen können

Tipp: Sie sehen, dass Polling genauso erreicht werden kann wie der Zugriff von nginx.

httpd verwendet Cookies, um die Sitzungsbindung zum Backend-Tomcat zu gewährleisten

: : : : : : : : : : : : : : :

Test: Überprüfen Sie die Syntax der Konfigurationsdatei von httpd. Wenn kein Problem vorliegt, starten Sie httpd neu und greifen Sie dann auf httpd zu, um zu sehen, welche Änderungen auftreten.

Simulieren Sie mit curl den ersten Zugriff auf den httpd-Server und prüfen Sie, ob sich im Antwortheader Änderungen ergeben haben.

Tipp: Sie können sehen, dass beim Zugriff auf den httpd-Server im Antwortheader ein zusätzlicher Set-Cookie-Header vorhanden ist und der Wert dieses Headers der SCHLÜSSEL und der Wert sind, die wir zuvor in der Konfigurationsdatei konfiguriert haben. Der Set-Cookie-Header wird hauptsächlich verwendet, wenn der Browser die nächste Anforderung stellt. Er überträgt den Wert des Set-Cookie-Headers mit dem Cookie-Header, um auf den Server zuzugreifen, sodass der Server analysieren kann, welcher Client die Anforderung gesendet hat, und wie der nachfolgende Server entsprechend dem Wert des Cookies in der Clientanforderungsnachricht geplant werden soll.

Greifen Sie über einen Browser auf die Website zu und prüfen Sie, ob der Client bei nachfolgenden Anfragen den Set-Cookie-Wert des ersten Besuchs verwendet, um den Server anzufordern.

Tipp: Sie können sehen, dass der Server beim ersten Besuch des Browsers einen Set-Cookie-Header im Antwortheader hinzufügt. Der Wert dieses Headers ist ROUTEID, also der Wert der Route in der aktuellen Antwort an unseren Backend-Server.

Tipp: Sie können sehen, dass der Client die Werte des zuvor festgelegten Cookies im Anforderungsheader-Cookie überträgt. Wenn httpd zu diesem Zeitpunkt die Clientanforderung empfängt, kann es anhand des durch die festgelegte Stickysession angegebenen Schlüssels bestimmen, an welchen Backend-Server die entsprechende Anforderung zur Antwort gesendet werden soll. Auf diese Weise wird der Client bei jedem Zugriff auf den Server anhand des Werts des Cookie-Headers informiert, an welchen Backend-Server die entsprechende Anforderung gesendet werden soll, solange das Cookie des Clients unverändert bleibt.

Verwenden Sie curl, um die Clientanforderung zum Übertragen von Cookies für den Zugriff auf den Server zu simulieren

Tipp: Sie können sehen, dass, wenn wir curl verwenden, um den Clientzugriff zum Übertragen von Cookies zu imitieren, der Set-Cookie-Header nicht im Antwortheader an uns gesendet wird (Set-Cookie bezieht sich hier auf den Header, der sich auf unsere Servereinstellungen bezieht) und wir Cookies mit unterschiedlichen ROUTEIDs übertragen, werden wir je nach dem Wert der von uns übertragenen ROUTEID zur Antwort an unterschiedliche Backend-Server weitergeleitet. Die Konfigurationsmethode zur Verwendung von ajp für den httpd-Lastausgleichsproxy-Backend-Tomcat ist dieselbe wie die Konfigurationsmethode von http. Der einzige Unterschied besteht darin, dass das http-Protokoll des Backend-Servers in ajp geändert wird und der Port des Backend-Tomcat in den vom ajp-Protokoll abgehörten Port geändert wird. Standardmäßig hört das Tomcat-ajp-Protokoll auf Port 8009 ab.

Konfigurieren der Seite „HTTPD-Backend-Verwaltungsschnittstelle“

Tipp: Die obige Konfiguration bedeutet, dass die httpd-Verwaltungsseite gestartet und an die URI /manager-page gebunden wird. Für die URI /manager-page wird kein Proxy ausgeführt, und die RUI kann nur dem Host mit der IP-Adresse 192.168.0.232 den Zugriff erlauben. Andere Hosts, einschließlich des Servers selbst, haben keine Berechtigung.

Überprüfung: Verwenden Sie einen anderen Host als 192.168.0.232, um auf 192.168.0.22/Manager-Seite zuzugreifen und zu sehen, ob darauf zugegriffen werden kann.

Tipp: Sie können sehen, dass bei Verwendung von 192.168.0.22 für den Zugriff die Eingabeaufforderung 403 „Keine Berechtigung“ angezeigt wird.

Verwenden Sie für den Zugriff 192.168.0.232 und prüfen Sie, ob Sie auf die Verwaltungsseite zugreifen können.

Tipp: Sie können auf die httpd-Verwaltungsseite normalerweise über einen Browser unter 192.168.0.232 zugreifen.

Ändern Sie das Gewicht von Tomcat1 dynamisch

Tipp: Da diese Seite die Eigenschaften des Backend-Servers dynamisch ändern kann, sind in der Regel Zugriffsbeschränkungen erforderlich.

Dies ist das Ende dieses Artikels über die Tomcat-Konfiguration für den Nginx/Httpd-Lastausgleich. Weitere relevante Inhalte zur Tomcat-Konfiguration für den Nginx/Httpd-Lastausgleich finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!