Mein Verständnis aus der NGINX Plus-Dokumentation ist, dass deren Lastverteilung um ausgefallene oder überlastete Server herumgeleitet wird und dass die Sitzungspersistenz versucht, denselben Server für eine bestimmte Sitzung beizubehalten. Es scheint, als könnten sich die beiden gegenseitig ausschließen, wenn ein Server mitten in einer Sitzung ausfällt. Gibt es einen Hinweis auf den Serverausfall, sodass wir wissen, dass es durch die Umstellung auf einen anderen Server (der möglicherweise nicht an den Änderungen während der Sitzung beteiligt ist) zu Datenverlusten kommen könnte, oder erfolgt die Umstellung stillschweigend?
Dies gilt speziell für die TCP/UDP-Kommunikation, nicht für HTTP.
Antwort1
Es scheint, als würden sich die beiden gegenseitig ausschließen
Ja. Das ist kein spezifisches Problem von nginx. Die bei weitem beste Lösung besteht darin, Ihre Sitzungsdaten zu replizieren bzw. hochverfügbar zu machen – aber das lässt sich nicht so einfach in einen bestehenden Dienst integrieren, der nicht gut geplant wurde.
Was soll nginx tun, wenn der Server, der eine Sitzung implementiert, ausfällt? Failover auf einen anderen Server? Failover auf einen bestimmten Server? Sind Ihre Server paarweise? Etwas anderes? Stoppen Sie die Sitzung – da sie sich in einem unbestimmten Zustand befindet … Es gibt so viele Möglichkeiten.
Was die Meldung von Fehlern betrifft, so besteht dies aus zwei Teilen. Einer ist die Überwachung – jemand muss informiert werden, dass etwas kaputt ist/repariert werden muss. Dies ist nicht die Aufgabe von Nginx. Damit muss sich Ihr Überwachungsstapel befassen. Der zweite Teil besteht darin, den Client darüber zu informieren, dass etwas nicht funktioniert hat. Nginx weiß nicht, dass es den Bestand wieder in die Regale legen/die DNS-Änderung erneut anwenden sollte. Dies ist die Aufgabe des von Ihnen ausgeführten Protokolls und der Anwendung. Obwohl es zeitliche Probleme gibt, verwenden die meisten Netzwerkprotokolle einen Austausch kurzer Anforderungs-/Antwortnachrichten, um den Serverstatus beim Client sichtbar zu machen. Bei (den meisten) Datenbanken ist dies mit einer expliziten „COMMIT“-Nachricht vom Client sehr gut definiert. Aber überlegen Sie, was passiert, wenn der Client „COMMIT“ sagt und keine Antwort erhält?
Dies gilt speziell für die TCP/UDP-Kommunikation, nicht für HTTP.
Wie @PersionGulf würde ich die Verwendung von HAProxy für nicht-HTTP-Lastausgleich / HA von TCP über nginx empfehlen. Als ich das letzte Mal nachgesehen habe, konnte es kein UDP.
Es zeigt nicht an, wie es im Fehlerfall funktioniert
Es ist nicht schwer, das zu testen.