|
|
| (51 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| == Reverse-Proxy-Leitfaden ==
| | #WEITERLEITUNG [[Apache/HTTP/Reverse proxy]] |
| 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
| |
| | |
| Eine typische Implementierung ist unten dargestellt:
| |
| * [https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html#related Reverse Proxy]
| |
| * [https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html#simple Einfaches Reverse-Proxying]
| |
| * [https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html#cluster Cluster und Balancer]
| |
| * [https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html#config Balancer- und BalancerMember-Konfiguration]
| |
| * [https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html#failover Failover]
| |
| * [https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html#manager Balancer Manager]
| |
| * [https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html#health-check Dynamische Zustandsprüfungen]
| |
| * [https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html#status BalancerMember-Statusflags]
| |
| | |
| === Siehe auch ===
| |
| * [https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html#comments_section Kommentare]
| |
| | |
| == 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:
| |
| | |
| ProxyPass „/“ „http://www.example.com/“
| |
| | |
| 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:
| |
| | |
| 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 <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:
| |
| | |
| <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 <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:
| |
| | |
| <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:# <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
| |
| | |
| <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 [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:
| |
| | |
| <Location „/balancer-manager“>
| |
| SetHandler balancer-manager
| |
| Require host localhost
| |
| </Location>
| |
| | |
| === 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
| |
| * B.: <tt>http://rproxy.example.com/balancer-manager/</tt>, 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 [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
| |
| * Die Bedeutungen dieser Status sind wie folgt:
| |
| | |
| Flag String Beschreibung
| |
| | |
| ''Ok ''Arbeiter ist verfügbar
| |
| | |
| ''Init ''Arbeiter wurde initialisiert
| |
| | |
| <tt>D </tt>''Dis ''Arbeiter ist deaktiviert und akzeptiert keine Anfragen; wird automatisch erneut versucht
| |
| | |
| <tt>S </tt>''Stop ''Arbeiter ist administrativ gestoppt; akzeptiert keine Anfragen und wird nicht automatisch erneut versucht
| |
| | |
| <tt>I </tt>''Ign ''Der Worker befindet sich im Modus „Fehler ignorieren“ und wird immer als verfügbar betrachtet
| |
| | |
| <tt>R </tt>''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
| |
| | |
| <tt>H </tt>''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
| |
| | |
| <tt>E </tt>''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 <tt>erneute Ausführung</tt> des Workers wird ein erneuter Versuch unternommen
| |
| | |
| <tt>N </tt>''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
| |
| | |
| <tt>C </tt>''HcFl ''Der Worker hat die dynamische Zustandsprüfung nicht bestanden und wird erst verwendet, wenn er nachfolgende Zustandsprüfungen besteht
| |