Wann ist der richtige Zeitpunkt, um Hochverfügbarkeit für Websites einzuführen?

Wann ist der richtige Zeitpunkt, um Hochverfügbarkeit für Websites einzuführen?

Es gibt viele Artikel zu Hochverfügbarkeitsoptionen. Es ist jedoch nicht so offensichtlich, wann der richtige Zeitpunkt für einen Wechsel von einer Einzelserverkonfiguration zu einer Hochverfügbarkeitskonfiguration ist.

Bitte beachten Sie meine Situation:
http://www.postjobfree.com ist eine 24/7-Website mit erheblichem Datenverkehr:
http://www.similarweb.com/website/postjobfree.com

Derzeit führe ich es auf einem einzelnen Server aus: Sowohl IIS 7.0-Webserver als auch SQL Server 2008 werden auf derselben Hardware-Box ausgeführt.

Es gibt gelegentliche (~ eine pro Monat) ~ 5 Minuten Ausfallzeit, die normalerweise durch einen Neustart verursacht wird, der für einige Windows Server-Updates erforderlich ist. Normalerweise sind Ausfallzeiten geplant und treten nachts auf. Trotzdem ist es unangenehm, da Google Bot und einige Benutzer nachts immer noch aktiv sind.

Der aktuelle Website-Umsatz liegt bei ~ 8.000 USD / Monat.

Ich erwäge den Wechsel zur Konfiguration mit zwei Servern (Webfarm mit zwei Webservern und Cluster mit zwei SQL-Servern, die auf zwei Hardwareservern gehostet werden).

Vorteile:
1) Hohe Verfügbarkeit (theoretisch keine Ausfallzeit). Selbst wenn einer der Server ausfällt, würde ein anderer Server übernehmen.
2) Kein Datenverlust: Ohne SQL-Cluster können bei einem Hardwareausfall bis zu einem Tag Daten verloren gehen (wir führen ein tägliches Backup durch).

Nachteile:
1) Mehr Aufwand zum Einrichten und Verwalten einer solchen Konfiguration.
2) Höhere Hostingkosten. Anstelle von ungefähr 600 USD / Monat wären es ungefähr 1200 USD / Monat.

Was wäre Ihre Empfehlung?

Kurze Antwort: Wenn Ausfallzeiten oder das Risiko höher sind als die Kosten für eine hohe Verfügbarkeit.

Es ist grundsätzlich eine wirtschaftliche Entscheidung. Als Beispiel. 8.000 USD / Monat bedeuten, dass ein Ausfall von 2 Stunden 22 USD kostet. Wenn Sie Ihr System so konfigurieren können, dass Sie innerhalb von 2 Stunden von Grund auf eine voll funktionsfähige Site entwickeln können, bringt Ihnen eine hohe Verfügbarkeit nur 22 US-Dollar an Funktionalität.

Anders ausgedrückt: Sie können Geld sparen, es sei denn, Sie haben in einem bestimmten Monat 54 Stunden unvorhergesehene Ausfallzeiten.

Ihre Stakeholder / Geschäftsleute (welche könnten Sie sein!) Müssen sich entscheiden

• akzeptabler Einnahmeverlust
• Folgen Reputationsverlust, Seriosität usw
• akzeptabler Datenverlust (Ziel Wiederherstellungspunkt )
• akzeptable Ausfallzeit ( Recovery Time Objective )

Einnahmeverluste sind leicht zu beziffern: der Rest kann hier leider nicht beantwortet werden ...

Ich denke, die meisten Benutzer können mit geplanten Ausfallzeiten umgehen. Bedenken Sie, dass ebay freitagabends wöchentliche Updates anbietet und Gebote dann manchmal nicht funktionieren. Das Online-Banking meiner (großen australischen) Bank hat wöchentlich stundenweise Ausfälle geplant. Twitter geht die ganze Zeit offline. Heroku / EC2 war vor kurzem tagelang außer Betrieb.

Ich würde es in dieser Perspektive behalten, wenn Sie wirklich nur 5 Minuten pro Monat sprechen, machen Sie einen ziemlich guten Job als Sysadmin.

Sie haben Google bereits als Indizierungsfaktor erwähnt, aber es kann sich auch lohnen, die Auswirkungen der Latenz / Reaktionszeit der Website auf die Suchmaschinenoptimierung zu berücksichtigen. Es ist eine Black Box und das alles, so schwer zu quantifizieren - aber für das, was es wert ist, hält Matt Cutts es für ein One-Per-Center . Ich würde mir mehr Sorgen um den Ruf machen, wie andere gesagt haben.

Denken Sie daran, dass HA ebenso wie Sicherheit kein Produkt, sondern ein Prozess ist.

Beispielsweise führt die Datenbankreplikation nur zu dem Punkt, an dem jeder Spiegel der Datenbank für sich selbst fortgesetzt werden kann. Sie benötigen jedoch auch eine Strategie für die Neusynchronisierung, nachdem ausgefallene Komponenten ersetzt wurden.

Betrachten Sie als Beispiel ein Bestellsystem: Der Kunde gibt eine Bestellung auf, und während der Verarbeitung fällt das physische System aus, mit dem er gesprochen hat, nachdem die Bestellinformationen in seiner lokalen Kopie der Datenbank gespeichert wurden. Ungeduldig drückt der Kunde erneut "submit" und wird zu einem anderen Server geleitet, der die Bestellung annimmt. Wenn Ihre Datenbanken durch einfaches Wiederholen der fehlenden INSERT-Anweisungen auf der anderen Seite erneut synchronisiert werden, wird die Reihenfolge dupliziert, was möglicherweise nicht Ihren Wünschen entspricht.

Wie @Slartibartfast vorschlug, läuft alles auf eine wirtschaftliche Entscheidung hinaus. Ich würde jedoch empfehlen, dass Sie hier auch einige Jahre in der Zukunft planen. Wenn Sie dann eine ordnungsgemäße HA-Einrichtung benötigen, ist jetzt ein guter Zeitpunkt, Ressourcen für die Vorbereitungsarbeiten bereitzustellen.

Während Sie darüber nachdenken, denken Sie darüber nach, eine "Fail-Wal" -Seite einzurichten.

Es gibt viele Möglichkeiten, dies zu tun, aber die aws-Kombination aus route53 und s3 funktioniert auf meinen kleinen Websites gut.

Ich richte die Domain mit Healthchecks so ein, dass DNS bei Fehlern Benutzer an Benutzer auf eine statische HTML-Seite in s3 sendet. Kostet so gut wie nichts.

Nach meiner Erfahrung macht es für die Nutzer einen großen Unterschied, wenn auf Ihrer Website "Es tut mir leid, aber wir arbeiten daran" steht. Ein Twitter-Konto, mit dem Sie sogar mit Benutzern kommunizieren können, ist noch besser.

Dies trägt wesentlich dazu bei, den "Reputationsverlust" zu mildern, der die wichtigsten Auswirkungen eines Ausfalls sein kann.

siehe: https://aws.amazon.com/blogs/aws/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting/ für einen Leitfaden für ihre Einrichtung.

Das soziale Failover von DynDns http://dyn.com/managed-dns/social-failover/ ist ähnlich.

Sie könnten Ihre eigenen und Ihre Integritätsprüfungen durchführen und dann die DNS-Änderungen per Skript ausführen, vorausgesetzt, Ihre DNS-Einträge haben eine niedrige TTL und Sie haben eine Möglichkeit, sie programmgesteuert zu bearbeiten.

Haben Sie darüber nachgedacht, so etwas wie EC2 zu verwenden, mit dem Sie flexibel skalieren und auch Ihre Nachteile zunichte machen können? Es ist letztendlich eine wirtschaftliche Entscheidung, ob sich der Einsatz von EC2 lohnt oder nicht, aber es ist zumindest eine Option, die in Betracht gezogen werden muss.

Um Datenverlust zu vermeiden, sollten Sie sich vor Clustern mit RAID-Konfigurationen befassen. Sie sollten auch eine Failover-IP konfigurieren, mit der Sie im Katastrophenfall von einem Server auf einen anderen wechseln können, ohne auf die DNS-Weitergabe warten zu müssen.