Ich arbeite an einer Infrastruktur, bei der HTTP-Verkehr über HTTPD-Server zurückgeleitet wird. Wir möchten bei HTTPD bleiben (anstatt beispielsweise Nginx in Betracht zu ziehen), da wir auf dieser Plattform viele virtuelle Hosts konfiguriert haben.
Jetzt möchte ich dem Reverse-Proxy-Teil HA- und Lastausgleichsfunktionen hinzufügen. Wenn ich einen Active-Active-Cluster erstelle, benötige ich eine Lösung wie DNS Round Robin, die ich jedoch nicht als erste Option in Betracht ziehen möchte (weil sie kompliziert zu beschaffen ist).
Wäre es eine gute Lösung, einen HAProxy Active-Passive-Cluster (mit Floating IP) zu konfigurieren, Lasten auszugleichen (im TCP-Modus, Level 4), einen HTTPD Active-Active-Cluster zu verwenden und echtes HTTP(S)-Reverse-Proxying durchzuführen? Auf diese Weise würde ich Folgendes erreichen:
- HA. HAProxy ist fehlertolerant, so dass die httpd's
- Lastverteilung. Httpd ist lastverteilt (aktiv-aktiv). HAProxy ist das nicht (ein einziger Host ist aktiv), aber ich gehe davon aus, dass es bei der Handhabung des Datenverkehrs besser skaliert als httpd, wobei ein Knoten ausreicht
- Da ich den HAProxy-Lastausgleich in TCP verwende, kann ich die gesamte HTTP- und HTTPS-Konfiguration auf der HTTPD-Seite belassen.
Gibt es bei diesem Ansatz Nachteile oder bessere Lösungen?
Antwort1
Sai,
Klingt, als hätten Sie eine sinnvolle Lösung gefunden. Sie beschreiben eine typische HA-Load Balancer-Bereitstellung für einen Anwendungscluster. HAProxy bietet Ihnen viel Flexibilität, wenn und falls Sie sie brauchen, und der TCP-Pass-Through-Modus ist schön und einfach.
Das einzige Problem ist die zusätzliche Komplexität, die mit der zuverlässigen Wartung eines HAProxy-Clusters verbunden ist. Ich nehme an, Sie werden Keepalived verwenden?
Hier bei Loadbalancer.org verwenden wir derzeit Heartbeat (HA-Linux), werden aber in Kürze auf unser eigenes Pulse HA-System umsteigen, das Aktiv/Aktiv über mehrere Load Balancer hinweg unterstützt.