Zum Inhalt springen

Reverse-Proxy-Leitfaden: Unterschied zwischen den Versionen

Aus Foxwiki
Die 5 zuletzt angesehenen Seiten:  Verinice/Installation » Reverse-Proxy-Leitfaden
Keine Bearbeitungszusammenfassung
Weiterleitung nach Apache/HTTP/Reverse proxy erstellt
 
(34 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== Reverse-Proxy-Leitfaden ==
#WEITERLEITUNG [[Apache/HTTP/Reverse proxy]]
[[Datei:Reverse-Proxy.png|mini|Eine typische Implementierung]]
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
 
* [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html mod_proxy]
* [https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html mod_proxy_balancer]
* [https://httpd.apache.org/docs/2.4/mod/mod_proxy_hcheck.html mod_proxy_hcheck]
 
* [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass ProxyPass]
* [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#balancermember BalancerMember]
 
== Einfaches Reverse-Proxying ==
Die [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass ProxyPass]-Direktive legt die Zuordnung eingehender Anfragen zum Backend-Server (oder einem Server-Cluster, der als <tt>Balancer</tt>-Gruppe bezeichnet wird) fest
 
Im einfachsten Beispiel werden alle Anfragen (<tt>„/“</tt>) an ein einzelnes Backend weitergeleitet:
<syntaxhighlight lang="apache" highlight="0" line>
ProxyPass „/“ „http://www.example.com/“
</syntaxhighlight>
 
Um sicherzustellen, dass die vom Backend generierten <tt>Location:</tt>-Header so geändert werden, dass sie auf den Reverse-Proxy verweisen, anstatt auf sich selbst, ist die [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypassreverse ProxyPassReverse]-Direktive am häufigsten erforderlich:
<syntaxhighlight lang="apache" highlight="0" line>
ProxyPass „/“ „http://www.example.com/“
ProxyPassReverse „/“ „http://www.example.com/“
</syntaxhighlight>
 
Nur bestimmte URIs können über einen Proxy weitergeleitet werden, wie in diesem Beispiel gezeigt:
<syntaxhighlight lang="apache" highlight="0" line>
ProxyPass „/images“ „http://www.example.com/“
ProxyPassReverse „/images“ „http://www.example.com/“
</syntaxhighlight>
 
Im obigen Beispiel werden alle Anfragen, die mit dem Pfad <tt>/images</tt> 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 [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxy <Proxy>] und [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#balancermember BalancerMember]-Direktiven definiert, wie in der folgenden Abbildung dargestellt:
 
<syntaxhighlight lang="apache" highlight="0" line>
<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/“
</syntaxhighlight>
 
Das <tt>balancer://</tt> 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 <tt>„/images“</tt> an ''einen der'' beiden Backends weitergeleitet
* Die [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxyset „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 [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass ProxyPass]definierten Parameter anpassen
* Angenommen, wir möchten, dass <tt>http://www3.example.com:8080</tt> den dreifachen Datenverkehr mit einem Timeout von 1 Sekunde verarbeitet, würden wir die Konfiguration wie folgt anpassen:
 
<syntaxhighlight lang="apache" highlight="0" line>
<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/“
</syntaxhighlight>
 
== 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:# <tt>http://spare1.example.com:8080</tt> und <tt>http://spare2.example.com:8080</tt> werden nur dann Datenverkehr gesendet, wenn einer oder beide von <tt>http://www2.example.com:8080</tt> oder <tt>http://www3.example.com:8080</tt> nicht verfügbar sind. (Ein Ersatz wird verwendet, um ein unbrauchbares Mitglied desselben Balancer-Sets zu ersetzen.)
# <tt>http://hstandby.example.com:8080</tt> wird nur dann Datenverkehr gesendet, wenn alle anderen Mitarbeiter in Balancer-Set <tt>0</tt> nicht verfügbar sind
# Wenn alle Mitarbeiter, Ersatzmitarbeiter und der Standby-Mitarbeiter des Lastausgleichssatzes <tt>0</tt> nicht verfügbar sind, werden nur dann die <tt>http://bkup1.example.com:8080</tt> und <tt>http://bkup2.example.com:8080</tt> Mitarbeiter des Lastausgleichssatzes <tt>1</tt> in die Rotation einbezogen
 
Somit ist es möglich, einen oder mehrere aktive Ersatzmitarbeiter und aktive Standby-Mitarbeiter für jeden Lastausgleichssatz zu haben
<syntaxhighlight lang="apache" highlight="0" line>
<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/“
</syntaxhighlight>
 
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 [https://httpd.apache.org/docs/2.4/mod/mod_status.html mod_status]zeigt ''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:
<syntaxhighlight lang="apache" highlight="0" line>
<Location „/balancer-manager“>
SetHandler balancer-manager
Require host localhost
</Location>
</syntaxhighlight>
 
; Warnung
Aktivieren Sie den ''Balancer-Manager'' erst, wenn Sie [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#access 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.&nbsp;B.: <tt>http://rproxy.example.com/balancer-manager/</tt>, wird eine Seite ähnlich der folgenden angezeigt:
[[Datei:Balancer-manager.png|mini]]
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:
[[Datei:BalancerManagerWorker.png|mini]]
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 [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#balancerpersist 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 <tt>„ping</tt>“-Parameter für diesen Worker mithilfe von [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass 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 [https://httpd.apache.org/docs/2.4/mod/mod_proxy_hcheck.html 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
{|class="wikitable options"
! 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
 
[[Kategorie:Apache/HTTP/Proxy]]

Aktuelle Version vom 31. März 2025, 23:17 Uhr

Weiterleitung nach: