Reverse-Proxy-Leitfaden

Apache httpd (wie auch die meisten anderen Webserver) ist nicht nur ein „einfacher“ Webserver, der Endbenutzern statische und dynamische Inhalte bereitstellt, sondern kann auch als Reverse-Proxy-Server fungieren, der auch als „Gateway“-Server bezeichnet wird

In solchen Szenarien generiert oder hostet httpd selbst keine Daten, sondern der Inhalt wird von einem oder mehreren Backend-Servern bezogen, die normalerweise keine direkte Verbindung zum externen Netzwerk haben

Wenn httpd eine Anfrage von einem Client erhält, wird die Anfrage selbst an einen dieser Backend-Server weitergeleitet, der dann die Anfrage bearbeitet, den Inhalt generiert und diesen Inhalt dann an httpd zurücksendet, das dann die eigentliche HTTP-Antwort an den Client generiert

Es gibt zahlreiche Gründe für eine solche Implementierung, aber im Allgemeinen sind die typischen Gründe Sicherheit, Hochverfügbarkeit, Lastverteilung und zentralisierte Authentifizierung/Autorisierung

Bei diesen Implementierungen ist es von entscheidender Bedeutung, dass das Layout, das Design und die Architektur der Backend-Infrastruktur (die Server, die die Anfragen tatsächlich bearbeiten) isoliert und von außen geschützt sind
Für den Client ist der Reverse-Proxy-Server die einzige Quelle für alle Inhalte

Reverse Proxy

Verwandte Module Verwandte Anweisungen

Einfaches Reverse-Proxying

Die ProxyPass-Direktive legt die Zuordnung eingehender Anfragen zum Backend-Server (oder einem Server-Cluster, der als Balancer-Gruppe bezeichnet wird) fest

Im einfachsten Beispiel werden alle Anfragen („/“) an ein einzelnes Backend weitergeleitet:

ProxyPass „/“ „http://www.example.com/“

Um sicherzustellen, dass die vom Backend generierten Location:-Header so geändert werden, dass sie auf den Reverse-Proxy verweisen, anstatt auf sich selbst, ist die ProxyPassReverse-Direktive am häufigsten erforderlich:

ProxyPass „/“ „http://www.example.com/“
ProxyPassReverse „/“ „http://www.example.com/“

Nur bestimmte URIs können über einen Proxy weitergeleitet werden, wie in diesem Beispiel gezeigt:

ProxyPass „/images“ „http://www.example.com/“
ProxyPassReverse „/images“ „http://www.example.com/“

Im obigen Beispiel werden alle Anfragen, die mit dem Pfad /images beginnen, an das angegebene Backend weitergeleitet, andernfalls werden sie lokal verarbeitet

Cluster und Balancer

So nützlich das Obige auch ist, es hat immer noch den Nachteil, dass das Proxying dieser Anfragen keinen wirklichen Vorteil bietet, wenn der (einzelne) Backend-Knoten ausfällt oder stark belastet wird

Es muss die Möglichkeit bestehen, eine Gruppe von Backend-Servern zu definieren, die solche Anfragen verarbeiten können, und der Reverse-Proxy muss für den Lastenausgleich und das Failover zwischen diesen Servern sorgen
Diese Gruppe wird manchmal als Cluster bezeichnet, bei Apache httpd wird sie jedoch als Balancer bezeichnet

Ein Balancer wird durch die Nutzung der <Proxy> und BalancerMember-Direktiven definiert, wie in der folgenden Abbildung dargestellt:

<Proxy balancer://myset>
 BalancerMember http://www2.example.com:8080
 BalancerMember http://www3.example.com:8080
 ProxySet lbmethod=bytraffic
</Proxy>

ProxyPass „/images/“ „balancer://myset/“
ProxyPassReverse „/images/“ „balancer://myset/“

Das balancer:// Schema teilt httpd mit, dass wir einen Balancer-Satz mit dem Namen „myset“ erstellen

Es umfasst zwei Backend-Server, die httpd „BalancerMembers“ nennt
In diesem Fall werden alle Anfragen für „/images“ an einen der beiden Backends weitergeleitet
Die „ProxySet“-Anweisung gibt an, dass der Balancer „myset“ einen Lastausgleichsalgorithmus verwendet, der auf der Grundlage von E/A-Bytes ausgleicht

Hinweis

BalancerMembers werden manchmal auch als Worker bezeichnet

Balancer- und BalancerMember-Konfiguration

Sie können zahlreiche Konfigurationsdetails der Balancer und Worker über die verschiedenen in ProxyPassdefinierten Parameter anpassen

Angenommen, wir möchten, dass http://www3.example.com:8080 den dreifachen Datenverkehr mit einem Timeout von 1 Sekunde verarbeitet, würden wir die Konfiguration wie folgt anpassen:

<Proxy balancer://myset>
 BalancerMember http://www2.example.com:8080
 BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
 ProxySet lbmethod=bytraffic
</Proxy>

ProxyPass „/images“ „balancer://myset/“
ProxyPassReverse „/images“ „balancer://myset/“

Failover

Sie können auch verschiedene Failover-Szenarien genau abstimmen und festlegen, auf welche Mitarbeiter und sogar auf welche Balancer in solchen Fällen zugegriffen werden soll

Das folgende Setup implementiert beispielsweise drei Failover-Fälle:# http://spare1.example.com:8080 und http://spare2.example.com:8080 werden nur dann Datenverkehr gesendet, wenn einer oder beide von http://www2.example.com:8080 oder http://www3.example.com:8080 nicht verfügbar sind. (Ein Ersatz wird verwendet, um ein unbrauchbares Mitglied desselben Balancer-Sets zu ersetzen.)

http://hstandby.example.com:8080 wird nur dann Datenverkehr gesendet, wenn alle anderen Mitarbeiter in Balancer-Set 0 nicht verfügbar sind
Wenn alle Mitarbeiter, Ersatzmitarbeiter und der Standby-Mitarbeiter des Lastausgleichssatzes 0 nicht verfügbar sind, werden nur dann die http://bkup1.example.com:8080 und http://bkup2.example.com:8080 Mitarbeiter des Lastausgleichssatzes 1 in die Rotation einbezogen

Somit ist es möglich, einen oder mehrere aktive Ersatzmitarbeiter und aktive Standby-Mitarbeiter für jeden Lastausgleichssatz zu haben

<Proxy balancer://myset>
 BalancerMember http://www2.example.com:8080
 BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
 BalancerMember http://spare1.example.com:8080 status=+R
 BalancerMember http://spare2.example.com:8080 status=+R
 BalancerMember http://hstandby.example.com:8080 status=+H
 BalancerMember http://bkup1.example.com:8080 lbset=1
 BalancerMember http://bkup2.example.com:8080 lbset=1
 ProxySet lbmethod=byrequests
</Proxy>

ProxyPass „/images/“ „balancer://myset/“
ProxyPassReverse „/images/“ „balancer://myset/“

Für die Ausfallsicherung werden Hot Spares als Ersatz für unbrauchbare Worker im selben Lastausgleichssatz verwendet

Ein Worker gilt als unbrauchbar, wenn er ausgelastet, angehalten oder anderweitig in einem Fehler-/Ausfallzustand ist
Hot Standbys werden verwendet, wenn alle Worker und Spares im Lastausgleichssatz nicht verfügbar sind
Lastausgleichssätze (mit ihren jeweiligen Hot Spares und Standbys) werden immer in der Reihenfolge vom niedrigsten bis zum höchsten Wert versucht

Balancer Manager

Eine der einzigartigsten und nützlichsten Funktionen des Reverse-Proxys von Apache httpd ist die eingebettete Anwendung Balancer-Manager.

Ähnlich wie mod_statuszeigt Balancer-Manager die aktuelle Arbeitskonfiguration und den Status der aktivierten Balancer und Worker an, die derzeit verwendet werden
Es werden jedoch nicht nur diese Parameter angezeigt, sondern es ermöglicht auch eine dynamische, laufende und spontane Neukonfiguration fast aller Parameter, einschließlich des Hinzufügens neuer BalancerMembers (Arbeiter) zu einem vorhandenen Balancer

Um diese Funktion zu aktivieren, muss Folgendes zu Ihrer Konfiguration hinzugefügt werden:

<Location „/balancer-manager“>
 SetHandler balancer-manager
 Require host localhost
</Location>

Warnung

Aktivieren Sie den Balancer-Manager erst, wenn Sie Ihren Server gesichert haben

Achten Sie insbesondere darauf, dass der Zugriff auf die URL streng eingeschränkt ist

Wenn auf den Reverse-Proxy-Server unter dieser URL zugegriffen wird (z. B.: http://rproxy.example.com/balancer-manager/, wird eine Seite ähnlich der folgenden angezeigt:

Dieses Formular ermöglicht es dem DevOps-Administrator, verschiedene Parameter anzupassen, Mitarbeiter offline zu schalten, Lastausgleichsmethoden zu ändern und neue Arbeiten hinzuzufügen

Wenn Sie beispielsweise auf den Balancer selbst klicken, wird die folgende Seite angezeigt:

Wenn Sie hingegen auf einen Mitarbeiter klicken, wird diese Seite angezeigt:

Um diese Änderungen beizubehalten, starten Sie den Reverse-Proxy neu und stellen Sie sicher, dass BalancerPersist aktiviert ist

Dynamische Zustandsprüfungen

Bevor httpd eine Anfrage an einen Worker weiterleitet, kann er „testen“, ob dieser Worker verfügbar ist, indem er den „ping“-Parameter für diesen Worker mithilfe von ProxyPass einstellt

Oft ist es sinnvoller, den Zustand der Worker außerhalb des Bandes auf dynamische Weise zu überprüfen
Dies wird in Apache httpd durch das mod_proxy_hcheck-Modul erreicht

BalancerMember-Statusflags

Im Balancer-Manager wird der aktuelle Zustand oder Status eines Arbeiters angezeigt und kann festgelegt/zurückgesetzt werden

Bedeutungen

Flag	String	Beschreibung
	Ok	Arbeiter ist verfügbar
	Init	Arbeiter wurde initialisiert
D	Dis	Arbeiter ist deaktiviert und akzeptiert keine Anfragen; wird automatisch erneut versucht
S	Stop	Arbeiter ist administrativ gestoppt; akzeptiert keine Anfragen und wird nicht automatisch erneut versucht
I	Ign	Der Worker befindet sich im Modus „Fehler ignorieren“ und wird immer als verfügbar betrachtet
R	Spar	Der Worker ist ein Hot Spare Für jeden Worker in einem bestimmten lbset, der nicht verwendbar ist (leer, gestoppt, fehlerhaft usw.), wird ein verwendbarer Hot Spare mit demselben lbset an seiner Stelle verwendet Hot Spares können dazu beitragen, dass eine bestimmte Anzahl von Workers immer für die Verwendung durch einen Balancer verfügbar ist
H	Stby	Der Worker befindet sich im Hot-Standby-Modus und wird nur verwendet, wenn keine anderen geeigneten Worker oder Ersatzteile im Balancer-Set verfügbar sind
E	Err	Der Worker befindet sich in einem Fehlerzustand, in der Regel aufgrund einer fehlgeschlagenen Vorab-Anforderungsprüfung Anforderungen werden nicht an diesen Worker weitergeleitet, aber je nach Einstellung für die erneute Ausführung des Workers wird ein erneuter Versuch unternommen
N	Drn	Der Worker befindet sich im Drain-Modus und akzeptiert nur bestehende Sticky-Sitzungen, die für ihn selbst bestimmt sind, und ignoriert alle anderen Anforderungen
C	HcFl	Der Worker hat die dynamische Zustandsprüfung nicht bestanden und wird erst verwendet, wenn er nachfolgende Zustandsprüfungen besteht

https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html