replizierte Server mit hoher Verfügbarkeit, Tomcat-Sitzung verloren. Firefox und Chrome 60 segs als TTL und nicht respektieren DNS definiert TTL

Question

Ich habe 4-Server für einen HTTP-Dienst definiert auf meinem DNS-Server:

app.speednetwork.in.  IN  A  63.142.255.107 
app.speednetwork.in.  IN  A  37.247.116.68 
app.speednetwork.in.  IN  A  104.251.215.162 
app.speednetwork.in.  IN  A  192.121.166.40 

für sie alle den DNS-Server eine TTL angeben (Zeit zu leben) von mehr als 10 Stunden:

$ttl 38400 

speednetwork.in. In SOA plugandplay.click. info.plugandplay.click. (38400)

Firefox TTL ignorieren und eine neue DNS-Abfrage nach jeweils 60 Sekunden machen, wie auf über gesehen: config -> network.dnsCacheExpiration 60 und weiter über: Vernetzung -> DNS. Chrome zeigen hier chrome: // net-internals/# einen korrekten gecached dns Eintrag dns, mit mehr als 10 Stunden, bis Expired:

apis.google.com IPV4 216.58.210.174 2016-04-12 11:07:07.618 [Expired] 
app.speednetwork.in IPV4 192.121.166.40 2016-04-12 21:45:36.592 

aber diesen Eintrag ignorieren und jede Minute requery die dns als https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/655ZTdxTftA diskutiert und gesehen auf chrome: // net-internals/# events

Die Schlussfolgerung und das Problem: jede Minute beide Browser Abfrage dns wieder, erhalten eine neue IP von den 4 auf DNS konfiguriert, gehen Sie für eine neue IP/Server und LOST THE TOMCAT-SITZUNG.

Als Config jeder Benutzer Browser nicht möglich ist, meine Frage ist:

1) Es gibt einige andere DNS-Konfiguration, die ich für eine hohe Verfügbarkeit verwenden kann?

2) Gibt es einen HTTP-Header, mit dem ich die Browser anweisen kann, den gleichen IP/Server für den Tag zu verwenden?

Answer 1

Der DNS-TTL-Wert ist die maximale Zeit, die die Informationen zwischengespeichert werden können. Es gibt weder eine Mindestzeit noch eine Anforderung zum Zwischenspeichern. Das Browserverhalten, das Sie beschreiben, liegt vollständig innerhalb der DNS-Spezifikationen und die Browser machen nichts falsch. Wenn Ihre Serverlösung davon abhängt, dass sich die Clients für eine bestimmte Zeit an eine DNS-Suche erinnern, müssen Sie sie neu gestalten. Wie Sie bereits festgestellt haben, funktioniert es nicht.

Der Aufbau eines Load-Balancing-Clusters von Tomcat-Servern ist heutzutage keine Seltenheit, und Sie können problemlos selbst eine Lösung googlen.

Answer 2

Keep-Alive-Header kann den Trick machen. Bei Verwendung eines großen Werts von 65 Sekunden verwenden Browser die HTTP-Verbindung während der gesamten Sitzung erneut und versuchen keine neue DNS-Abfrage. Dies gilt in meiner App, wo jede Minute eine Huckepack-XMLHttpRequest-Verbindung zum Server besteht. Vielleicht benötigen Sie einen größeren Wert. Apache Standard ist 5 Sekunden.

On direkt über tomcat:

response.setHeader ("Keep-Alive", "timeout = 65");

auf Apache mit (und mod_ajp) vor tomcat:

nano /etc/apache2/apache2.conf:

 MaxKeepAliveRequests 0 
     KeepAliveTimeout 65 

Aber dies war keine Gesamtlösung.Nach dem Trennen der http-Verbindung ist geschlossen, oder unter mehreren gleichzeitig Server-Petitionen, jeder ist offen über mehrere Server, so dass Ergebnisse nicht unter der gleichen Server-Sitzung sind. Schließlich löse ich diese implementierende CORS (cross-domain), einen Server zu reparieren (app1, app2, etc.) und gehen Sie so lange, bis dieser Server fehlschlägt. CORS-Header auf Server und Client lassen Sie mich Daten austauschen, egal, dass die ersten Dateien Download von App war. (IE eine andere Domäne).