Unsere Anwendung erfordert Cookie-basierte Sticky-Sitzungen. Daher möchten wir mit HAproxy den eingehenden Datenverkehr auf eine Farm von IIS-Servern verteilen.HAproxy 1.5.8 Wie konfiguriere ich Cookie-basierte Klebrigkeit?
Wir haben die folgende Konfiguration verwenden, die auf dem Labor (Round-Robin-adaequat und Sitzung beibehalten) scheint zu funktionieren, aber wenn fehlschlägt in producion mit mehr als 3k gleichzeitigem Benutzer angewandt:
Frontend Front_http
bind :80
mode http
default_backend backend_http
stats enable
capture cookie ASP.NET_SessionId len 32
maxconn 10000
Frontend Front_https
mode http
default_backend backend_https
bind *:443 ssl crt /etc/haproxy/cert.pem
capture cookie ASP.NET_SessionId len 32
maxconn 10000
Backend backend_http
balance roundrobin
option forwardfor
stick-table type ip size 20k expire 5m
appsession ASP.NET_SessionId len 64 timeout 5m request-learn prefix
server Server_1 192.168.10.81:80 cookie Server_1
server Server_2 192.168.10.81:80 cookie Server_2
server Server_3 192.168.10.81:80 cookie Server_3
Backend backend_https
balance roundrobin
option forwardfor
stick-table type ip size 20k expire 5m
appsession ASP.NET_SessionId len 64 timeout 5m request-learn prefix
server Server_1 192.168.10.81:80 cookie Server_1 ssl verify none
server Server_2 192.168.10.81:80 cookie Server_2 ssl verify none
server Server_3 192.168.10.81:80 cookie Server_3 ssl verify none
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
Von der HAProxy 1.5.8 Dokumentation I Cookies in Ihrem Browser Klebrigkeit verstehen wird mit dem Befehl "appsession" erreicht, aber ich verstehe nicht, die Rolle andere Befehle spielen, wie „Capture-Cookie "oder" stick-table ", sind sie überhaupt notwendig bei der Verwendung von Appsession? Kann jemand mir helfen, zu verstehen, wie sie arbeiten, und beraten, wenn Sie etwas falsch mit unserer Konfiguration feststellen.
Vielen Dank für Ihre vollständige Erklärung. Mit "nicht arbeiten" meinte ich Langsamkeit und schließlich Clients, die HTTP-Fehler 504 und 500 erhielten. Wir überwachten das Ausbalancieren neu initiierter Sitzungen und es sah sogar so aus, aber zu einem bestimmten Zeitpunkt schien einer der IIS viel mehr Sitzungen als die anderen zu haben und hörte auf zu antworten, und wurde später von einem anderen IIS gefolgt. Ich muss jedoch sagen, dass unsere Plattform in Azure ist und wir später erfuhren, dass es einen schweren Ausfall in Azure gab, der sich wahrscheinlich auf die IIS auswirkte. Vielleicht ging es also nicht um den HAproxy. –
Ich überprüfe jedoch meine Konfiguration, da einige Dinge im Hinblick auf Ihre Erklärungen seltsam aussehen. Ich bleibe bei einer der Methoden, die Sie vorschlagen, um Stickyness zu erreichen, und teste es erst wieder, wenn Azure-Probleme wirklich gelöst sind. Da dies in Azure implementiert ist, gibt es auch Netzwerkbeschränkungen, die eine Implementierung der Hochverfügbarkeitstopologie unmöglich machen. –
504 bedeutet, dass der Server zu langsam war, um zu antworten. 'Timeout Server' ist hier der Schlüssel. 500 werden von Ihrem Anwendungsserver generiert, HAProxy kann sie nicht beheben :) – Baptiste