Globale Frage zur Einrichtung der Hochverfügbarkeit

Ich besitze und betreibe visualwebsiteoptimizer.com /. Die App bietet ein Code-Snippet, das meine Kunden in ihre Websites einfügen, um bestimmte Metriken zu verfolgen. Da es sich bei dem Code-Snippet um externes JavaScript handelt (oben im Site-Code), kontaktiert der Browser eines Besuchers unseren App-Server, bevor eine Kunden-Website angezeigt wird. Falls unser App-Server ausfällt, versucht der Browser weiterhin, die Verbindung herzustellen, bevor das Zeitlimit überschritten wird (normalerweise 60 Sekunden). Wie Sie sich vorstellen können, können wir es uns nicht leisten, unseren App-Server in irgendeinem Szenario herunterzufahren, da dies die Erfahrung nicht nur unserer Website-Besucher, sondern auch der Website-Besucher unserer Kunden negativ beeinflusst!

Wir verwenden derzeit einen DNS-Failover-Mechanismus mit einem Sicherungsserver in einem anderen Rechenzentrum (tatsächlich auf einem anderen Kontinent). Das heißt, wir überwachen unseren App-Server von drei verschiedenen Standorten aus. Sobald festgestellt wird, dass er nicht verfügbar ist, ändern wir einen Datensatz so, dass er auf die IP des Sicherungsservers verweist. Dies funktioniert für die meisten Browser einwandfrei (da unsere TTL 2 Minuten beträgt), aber der IE speichert den DNS 30 Minuten lang im Cache, was ein Deal Killer sein könnte. Sehen Sie sich diesen letzten Beitrag von uns an: visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/

Welche Art von Setup können wir verwenden, um ein fast sofortiges Failover sicherzustellen, falls das App-Rechenzentrum einen größeren Ausfall erleidet? Ich habe hier www.tenereillo.com/GSLBPageOfShame.htm gelesen, dass es eine Lösung ist, mehrere A-Datensätze zu haben, aber wir können uns (noch) keine Sitzungssynchronisation leisten. Eine andere Strategie, die wir untersuchen, besteht darin, zwei A-Datensätze zu haben, von denen einer auf den App-Server und der zweite auf einen Reverse-Proxy (der sich in einem anderen Rechenzentrum befindet) verweist, der in den Haupt-App-Server aufgelöst wird, wenn dieser aktiv ist, und in den Backup-Server, wenn er aktiv ist. Halten Sie diese Strategie für angemessen?

Um sicherzugehen, dass wir Prioritäten setzen, können wir es uns leisten, unsere eigene Website oder App auf dem neuesten Stand zu halten, aber wir können nicht zulassen, dass die Website unserer Kunden aufgrund unserer Ausfallzeiten langsamer wird. Falls unsere App-Server nicht verfügbar sind, beabsichtigen wir nicht, mit der Standardantwort der Anwendung zu antworten. Selbst eine leere Antwort wird ausreichen. Wir brauchen nur, dass der Browser diese HTTP-Verbindung herstellt (und sonst nichts).

Referenz: Ich habe diesen Thread gelesen, der nützlich war

Ihre Situation ist unserer ziemlich ähnlich. Wir wollen geteilte Rechenzentren und ein Failover vom Typ Netzwerkschicht.

Wenn Sie das Budget dafür haben, möchten Sie zwei Rechenzentren, mehrere IP-Transits zu jedem, ein Paar Edge-Router, die BGP-Sitzungen mit Ihren Transitanbietern durchführen und Ihre IP-Adressen im globalen Internet bewerben.

Dies ist der einzige Weg, um ein echtes Failover durchzuführen. Wenn die Router feststellen, dass die Route zu Ihren Servern nicht mehr gültig ist (was Sie auf verschiedene Arten tun können), stellen sie die Werbung für diese Route ein und der Datenverkehr wird zur anderen Site geleitet.

Das Problem ist, dass für ein Paar Edge-Router zunächst relativ hohe Kosten anfallen, um diese Einrichtung zu erhalten.
Dann müssen Sie das Netzwerk einrichten, das dahinter steht, und Sie möchten möglicherweise eine Art Layer2-Konnektivität zwischen Ihren Standorten als Punkt-zu-Punkt-Verbindung in Betracht ziehen, damit Sie eingehenden Datenverkehr an ein Rechenzentrum weiterleiten können. im Falle eines teilweisen Ausfalls Ihres primären Standorts direkt an den anderen.

Best Practice für BGP Multihomed / Multi-Location und Bester Weg zur Verbesserung der Belastbarkeit? sind Fragen, die ich zu ähnlichen Themen gestellt habe.

Die GSLB-Seite der Schande wirft einige wichtige Punkte auf, weshalb ich persönlich niemals bereitwillig eine GSLB wählen würde, um das BGP-Routing zu erledigen.

Sie sollten sich auch die anderen Fehlerquellen in Ihrem Netzwerk ansehen. Stellen Sie sicher, dass alle Server über 2 Netzwerkkarten (verbunden mit 2 separaten Switches) und 2 Netzteile verfügen und dass Ihr Dienst aus mehreren Backend-Servern als redundanten Paaren oder Clustern mit Lastenausgleich besteht.

Grundsätzlich ist DNS "Lastausgleich" über mehrere A-Einträge nur "Lastverteilung", da der DNS-Server keine Vorstellung davon hat, wie viel Last auf jedem Server ist. Das ist billig (kostenlos).

Ein GSLB-Dienst hat ein Konzept darüber, wie ausgelastet die Server sind und wie sie verfügbar sind, und bietet eine größere Fehlerresistenz, ist jedoch immer noch von den Problemen im Zusammenhang mit DNS-Caching und Pegging geplagt. Das ist weniger billig, aber etwas besser.

Ein BGP-geroutetes Netzwerk, das von einer soliden Infrastruktur unterstützt wird, ist meiner Meinung nach der einzige Weg, um wirklich eine gute Verfügbarkeit zu gewährleisten. Sie könnten etwas Geld sparen, indem Sie Routenserver anstelle von Cisco / Juniper / etc-Routern verwenden. Letztendlich müssen Sie diese Server jedoch sehr sorgfältig verwalten. Dies ist keineswegs eine billige Option oder etwas, das leichtfertig unternommen werden muss, aber es ist eine sehr lohnende Lösung und bringt Sie als Anbieter und nicht nur als Verbraucher ins Internet.

OK, das wurde vor einiger Zeit gefragt, aber ich sehe es jetzt zum ersten Mal.

Das Code-Snippet ist externes JavaScript (oben im Site-Code). Bevor eine Kunden-Website angezeigt wird, kontaktiert der Browser eines Besuchers unseren App-Server.

Du solltest:

1. Platzieren Sie Ihre Javascript-Datei in einem guten, professionellen Content Delivery Network, dh kaufen Sie hochverfügbare HTTP (S) -Dienste für Javascript von jemandem, der bereits über dieses Fachwissen verfügt.
2. Programmieren Sie Ihr Javascript so, dass ein guter Fallback-Status vorliegt. Wenn Ihr App-Server nicht schnell reagiert, sieht der Endbenutzer eine normale, unveränderte Seite.

Alles andere zu tun ist wirklich unverantwortlich. Ich gehe davon aus, dass Sie dies bereits eingerichtet haben.

Sie sollten nicht Ihren Dienst auf BGP Basis Tricks Routing , es sei denn , Sie haben oder das Know-how erhalten , dies zu tun. Komplexe BGP-Routing-Szenarien sind entschieden nicht trivial zu implementieren. Tun Sie dies nicht selbst, wenn Sie nicht über die domänenspezifischen Kenntnisse verfügen.

Ihre Frage selbst ist etwas verwirrt. Die Analyse, wie ein hochverfügbarer Dienst erstellt wird, beginnt mit den Anwendungsdaten , da dies Ihr "Status" ist. Die zustandslosen Teile sind leicht hoch verfügbar zu machen, die zustandsreichen Teile nicht. Anstatt sich auf Ihre Server und DNS zu konzentrieren, sollten Sie sich ansehen, wo Ihre Anwendung den Status beibehält . Beginnen Sie, indem Sie dort optimieren und möglicherweise nach Algorithmus-Ratschlägen zum Stapelüberlauf fragen. Könnten Sie einen Begriff von Transaktionen und Smart Server-Wiederholungsversuchen in Ihrer Javascript-Datei fx implementieren?

Tatsächlich könnte das, was Sie möchten, aktualisiert werden, um Ihre Split-Test-Aktivitäten zu unterstützen, wenn Sie Geodns und DNS-Failover kombinieren.

Wenn Sie Gruppe A an IP 1 und Gruppe B an IP 2 senden, können Sie Ihre Testgruppen trennen, selbst wenn sie sich auf demselben Server befinden. Gruppe A und Gruppe B stammen aus verschiedenen geografischen Regionen. Um fair zu sein, drehen Sie am nächsten Tag / in der nächsten Woche / im nächsten Monat die Gruppen um, um sicherzustellen, dass Sie geografische Unterschiede berücksichtigen. Nur um in Ihrer Methodik streng zu sein.

Der Geodns / Failover-DNS-Dienst unter http://edgedirector.com kann dies tun

Offenlegung: Ich bin mit dem obigen Link verbunden, bin hier gestolpert und habe einen Artikel über die Anwendung dummer DNS-Tricks auf Split-Tests recherchiert.