100% Verfügbarkeit für eine Webanwendung


312

Wir haben heute eine interessante "Anforderung" von einem Kunden erhalten.

Sie wollen 100% Uptime mit Off-Site - Failover auf einer Web - Anwendung. Aus Sicht unserer Webanwendung ist dies kein Problem. Es wurde entwickelt, um eine Skalierung auf mehrere Datenbankserver usw. zu ermöglichen.

Aufgrund eines Netzwerkproblems kann ich jedoch nicht herausfinden, wie es funktioniert.

Kurz gesagt, die Anwendung befindet sich auf Servern im Netzwerk des Clients. Der Zugriff erfolgt sowohl durch interne als auch externe Personen. Sie möchten, dass wir eine Kopie des Systems außerhalb des Standorts aufbewahren, die im Falle eines schwerwiegenden Ausfalls in ihren Räumlichkeiten sofort abgeholt und übernommen wird.

Jetzt wissen wir, dass es für interne Personen (Brieftauben?) Absolut keine Möglichkeit gibt, eine Lösung zu finden, aber sie möchten, dass die externen Benutzer dies nicht einmal bemerken.

Ehrlich gesagt habe ich keine Ahnung, wie das möglich sein könnte. Wenn sie die Internetverbindung verlieren, müssten wir anscheinend eine DNS-Änderung vornehmen, um den Datenverkehr an die externen Computer weiterzuleiten ... Das braucht natürlich Zeit.

Ideen?

AKTUALISIEREN

Ich hatte heute ein Gespräch mit dem Kunden und er hat das Problem geklärt.

Sie hielten sich an die 100% -Zahl und sagten, dass die Anwendung auch im Falle einer Überschwemmung aktiv bleiben sollte. Diese Anforderung tritt jedoch nur dann in Kraft, wenn wir sie für sie hosten. Sie sagten, sie würden die Verfügbarkeitsanforderungen erfüllen, wenn die Anwendung vollständig auf ihren Servern läuft. Sie können meine Antwort erraten.


49
Unterschätzen Sie nicht die enormen Ausfallzeiten, die durch Hacking verursacht werden. Schauen Sie sich Sony und das PlayStation-Netzwerk an. Sie können garantieren, dass sie die gleiche 100% Verfügbarkeitsidee und das Geld / die Hardware hatten, um sie zu sichern. Machen Sie dem Kunden klar, dass eine 100% ige Verfügbarkeit eine undurchführbare Erwartung ist. Selbst Google-Techniker würden zögern, "100% ige Verfügbarkeit" zu murmeln. Ein Tipp ist übrigens, die Verwendung von dynamischem DNS zu untersuchen. Sie werden nur 60 Sekunden zwischengespeichert. Dies sollte Betriebssystem- und lokale DNS-Server einschließen.
Silverfire

182
Ich würde persönlich von diesem Kunden so schnell wie möglich RUN . Ich vermute, dass dies nicht die letzte verrückte Idee sein wird, die sie haben könnten (aus technologischer Sicht).
GregD

137
Ich wünschte, ich könnte Ihren Klienten ablehnen.
Joeqwerty

81
Wenn Sie 100% Verfügbarkeit herausfinden, lassen Sie es mich wissen. Ich werde ein Geschäft damit gründen und es an Google verkaufen. Es ist unmöglich, 100% zu garantieren. Sogar Unternehmen wie Microsoft, Amazon oder Google werden nicht so hoch steigen, weil sie wissen, dass es unmöglich ist. Das Beste, das ich je gesehen habe, ist 99,999% und selbst das ist eine Strecke (5 Minuten pro Jahr). Das Beste, was Sie wahrscheinlich tun können, ist 99,99% zuverlässig.
Matt

39
Überlegen Sie sich einfach einen wahnsinnig hohen Preis, um ihren wahnsinnigen Wunsch zu erfüllen. Das wird sie wahrscheinlich wieder zur Besinnung bringen. Entweder als, oder es wird sie davonschicken, jemanden zu suchen, der bereit ist, sie anzulügen.
Nate CK

Antworten:


368

Hier ist das handliche Diagramm von Wikipedia über das Streben nach Neunen:

Bildbeschreibung hier eingeben

Interessanterweise erreichten nur drei der 20 besten Websites 2007 die mythischen 5 Neun oder 99,999% Betriebszeit. Dies waren Yahoo, AOL und Comcast. In den ersten vier Monaten des Jahres 2008 kamen einige der beliebtesten sozialen Netzwerke dem nicht einmal nahe.

Aus dem Diagramm sollte ersichtlich sein, wie lächerlich das Streben nach 100% Betriebszeit ist ...


62
Pingdom überprüft auch nicht jede Sekunde. Darüber hinaus hatten diejenigen, die fünf Neunen erreichten, wahrscheinlich noch lokalisierte Störungen, die Pingdom möglicherweise nicht entdeckt hatte, oder Störungen, die einige Dienste nicht verfügbar machten, während sie noch auf Pings reagierten.
Ceejayoz

8
Was an und für sich die fünf Neuner zweifelhaft macht ...
GregD

5
Genau. Und sie haben Milliarden Dollar, mit denen sie arbeiten können!
Ceejayoz

43
Tut mir leid, dass ich den Chat stören musste, aber die Frage des OP lautete, wie man das Ziel einer 100% igen Verfügbarkeit auf technischer Ebene erreichen kann, und zwar nicht konzeptionell und die Umwelt. Können wir ihm dabei helfen?
David d C e Freitas

5
Zum OP: Ich habe SLAs gesehen, die eine Verfügbarkeit außerhalb der normalen Wartung garantieren. Die normale Wartung ist natürlich eine geplante monatliche Ausfallzeit für Updates, Patches usw., die normalerweise an dem Tag ausgeführt wird, an dem der Monat am wenigsten zu tun hat (normalerweise mitten in der Nacht). Sie müssen eine Art von Metriken für ihr Geschäft in Bezug auf das Geschäft haben. Sie könnten ihnen nur in diesen Zeiten eine bessere Betriebszeit (4 Neunen) bieten .
GregD

186

Bitten Sie sie, 100% zu definieren und festzulegen, wie es in welchem ​​Zeitraum gemessen werden soll. Sie bedeuten wahrscheinlich so nahe an 100%, wie sie sich leisten können. Gib ihnen die Kosten.

Ausarbeiten. Ich war über die Jahre mit Kunden in Gesprächen mit vermeintlich lächerlichen Anforderungen. In allen Fällen verwendeten sie tatsächlich nur eine nicht genau genug gesprochene Sprache.

Sehr oft rahmen sie Dinge auf absolut erscheinende Weise ein - wie 100% - aber tatsächlich sind sie nach eingehender Untersuchung angemessen genug, um die Kosten-Nutzen-Analysen durchzuführen, die erforderlich sind, wenn Kalkulationen zur Risikominderung vorgelegt werden. Die Frage, wie die Verfügbarkeit gemessen werden soll, ist von entscheidender Bedeutung. Wenn sie das nicht wissen, sind Sie in der Lage, ihnen vorzuschlagen, dass dies zuerst definiert werden muss.

Ich würde den Kunden bitten, zu definieren, was in Bezug auf geschäftliche Auswirkungen / Kosten passieren würde, wenn die Website unter den folgenden Umständen ausfallen würde:

  • In ihren geschäftigsten Stunden für x Stunden
  • In den am wenigsten beschäftigten Stunden für x Stunden

Und auch, wie sie das messen werden.

Auf diese Weise können Sie mit ihnen zusammenarbeiten, um den richtigen Wert für "100%" zu ermitteln. Ich vermute, dass sie durch diese Art von Fragen die Prioritäten ihrer anderen Anforderungen besser bestimmen können. Beispielsweise möchten sie möglicherweise bestimmte SLA-Stufen bezahlen und andere Funktionen in Frage stellen, um dies zu erreichen.


21
Einverstanden. Sie bedeuten möglicherweise nur eine "sehr hohe" Betriebszeit (obere 90er Jahre?) Mit einer ziemlich soliden Failover-Strategie. Wenn nicht, dann würde eine Erklärung der damit verbundenen Kosten hoffentlich überzeugen ...
Martin Dow

32
+1, wenn Sie nicht zu Schlussfolgerungen springen und stattdessen den Kunden bitten, zu erklären, was er vorhat.
Sleske

4
Ich stimme der Aussage zu, dass keine Schlussfolgerungen gezogen werden dürfen ... Wenn der Kunde eine 100% ige Verfügbarkeit (abzüglich geplanter Wartungsarbeiten) meint, ist dies möglicherweise eher eine vernünftige Anforderung.
Tim Reddy

1
In Bezug auf die geschäftlichen Auswirkungen kennen und verstehen wir deren Geschäft tatsächlich vollständig und die Kosten für den Ausfall der Website sind nicht finanziell. Mehr in der Art der Einheimischen, die mit Heugabeln, möglichen Hinweisen usw. auftauchen;) Stellen Sie sich vor, 40.000 Menschen tauchen schreiend vor Ihrer Haustür auf. Das wollen sie mit Leidenschaft vermeiden.
NotMe

7
@ChrisLively Umso mehr Grund, ein ausgereiftes Risikoverständnis zu haben. Das vorherrschende Paradigma für die Sicherheitstechnik ist die probabilistische Risikobewertung . Es gibt Systeme, die Tausende von Menschen töten (nicht nur ärgern) könnten, und sie haben immer noch eine niedrige, hoffentlich gut verstandene, aber nicht Null-Ausfallwahrscheinlichkeit.
Poolie

140

Ihre Kunden sind verrückt. Eine 100% ige Verfügbarkeit ist unmöglich, egal wie viel Geld Sie dafür ausgeben. Schlicht und einfach - unmöglich. Schauen Sie sich Google, Amazon usw. an. Sie haben fast unendlich viel Geld für ihre Infrastruktur und schaffen es dennoch, Ausfallzeiten zu haben. Sie müssen ihnen diese Nachricht übermitteln, und wenn sie weiterhin darauf bestehen, dass sie angemessene Forderungen stellen. Wenn sie nicht erkennen, dass eine gewisse Ausfallzeit unvermeidlich ist, lassen Sie sie los.

Das heißt, Sie scheinen die Mechanik der Skalierung / Verteilung der Anwendung selbst zu haben. Der Netzwerkteil muss redundante Uplinks zu verschiedenen ISPs beinhalten, eine ASN- und IP-Zuweisung erhalten und in BGP und realer Routing-Ausrüstung tiefgreifend sein, damit der IP-Adressraum bei Bedarf zwischen ISPs verschoben werden kann.

Dies ist ganz offensichtlich eine sehr knappe Antwort. Sie haben noch keine Erfahrung mit Anwendungen, die diese Verfügbarkeit erfordern. Sie müssen also einen Fachmann hinzuziehen, wenn Sie die mythische Verfügbarkeit von 100% erreichen möchten.


7
Einverstanden. Total. Verrückt.
Jdw

2
früher haben sie ??
Sirex,

2
@ Sirex Unter Bezugnahme auf das kürzlich durchgeführte Experiment @ CERN, bei dem festgestellt wurde, dass Neutrinos schneller als Licht wandern. Die Ergebnisse müssen jedoch noch von unabhängigen Wissenschaftlern bestätigt werden.
TC1

9
@ TC1 Ich wette, Sie erhalten 200 US-Dollar , die nicht ausgehen.
dpatchery

4
@ErikA Eine Anforderung von 100% Betriebszeit weist auf Unkenntnis der technischen Merkmale von Systemen hin. Das ist in Ordnung, denn der Kunde macht alles, was er tut. Ihre Aufgabe ist es, IT-Systeme zu entwickeln. Schwierige Kunden wie diese können Albträume sein, aber sie können auch Ihre besten Kunden werden.
Duffbeer703

54

Nun, das ist definitiv interessant. Ich bin mir nicht sicher, ob ich mich vertraglich zur 100% igen Verfügbarkeit verpflichten möchte, aber wenn ich müsste, würde es meiner Meinung nach ungefähr so ​​aussehen:

Beginnen Sie mit der öffentlichen IP auf einem Load Balancer, der vollständig aus dem Netzwerk entfernt ist, und erstellen Sie mindestens zwei davon, damit ein Failover auf das andere durchgeführt werden kann. Ein Programm wie Heatbeart kann beim automatischen Failover dieser Programme helfen.

Lack ist in erster Linie als Caching-Lösung bekannt, führt aber auch einen angemessenen Lastenausgleich durch. Vielleicht wäre das eine gute Wahl, um den Lastausgleich zu erledigen. Es kann so eingerichtet werden, dass 1 bis n Backends optional in Direktoren gruppiert sind, die den Lastenausgleich entweder zufällig oder im Round-Robin-Modus durchführen. Lack kann intelligent genug gemacht werden, um den Zustand jedes Backends zu überprüfen und ungesunde Backends aus der Schleife zu entfernen, bis er wieder online ist. Die Backends müssen sich nicht im selben Netzwerk befinden.

Ich bin heutzutage ein bisschen verliebt in die Elastic IPs in Amazon EC2, daher würde ich wahrscheinlich meine Load Balancer in EC2 in verschiedenen Regionen oder zumindest in verschiedenen Verfügbarkeitszonen in derselben Region bauen. Das würde Ihnen die Möglichkeit geben, manuell (Gott bewahre) einen neuen Load Balancer hochzufahren, wenn Sie die vorhandene A-Record-IP in die neue Box verschieben müssten.

Varnish kann SSL jedoch nicht kündigen. Wenn dies ein Problem ist, sollten Sie sich stattdessen etwas wie Nginx ansehen.

Sie könnten die meisten Ihrer Backends in Ihrem Client-Netzwerk und eines oder mehrere außerhalb ihres Netzwerks haben. Ich glaube, aber ich bin mir nicht hundertprozentig sicher, dass Sie die Backends priorisieren können, damit die Maschinen Ihrer Kunden Priorität erhalten, bis sie alle nicht mehr fehlerfrei sind.

Hier würde ich anfangen, wenn ich diese Aufgabe hätte und sie auf meinem Weg zweifellos verfeinern würde.

Wie @ErikA feststellt, ist es jedoch das Internet, und es wird immer Teile des Netzwerks geben, die außerhalb Ihrer Kontrolle liegen. Sie sollten sicherstellen, dass Ihr Legal Sie nur mit Dingen in Verbindung bringt, die unter Ihrer Kontrolle stehen.


2
Eine Weile dachte ich über Amazon und MS für eine Cloud-Bereitstellung nach, aber beide hatten in den letzten Monaten große Ausfälle. SSL ist kritisch.
NotMe

3
Wenn Sie Amazon verwenden möchten, möchten Sie Ihre Computer auf jeden Fall auf die 5 Verfügbarkeitszonen verteilen. Es ist ziemlich unwahrscheinlich, dass alle ihre Zonen gleichzeitig ausgehen.
Jdw

11
+1 für die tatsächliche Beantwortung der Hauptfrage des OP.
Phil

Sie werden immer einen Punkt des Ausfalls haben, jdw, solange es eine nicht verteilte Sache in der Kette gibt (in Ihrem Fall Herzschlag, es sei denn, Sie haben natürlich mehrere Instanzen davon, die auf entfernten Maschinen laufen, die sich alle gegenseitig überwachen, sowie Ihre Server, die einer von ihnen aufgrund von Netzwerkproblemen entlang des Routings sehen kann oder nicht). Das bringt uns zu "Ausfallzeiten". Möglicherweise sind die Server in Betrieb und für den Client immer noch nicht verfügbar, ohne dass Heartbeat dies bemerkt, wenn der Fehler nicht im Routing-Pfad enthalten ist.
30.

Einverstanden. Wie JEDER ANDERE darauf hingewiesen hat, gibt es keine 100% ige Verfügbarkeit. Alles, was Sie tun können, ist zu versuchen, und was ich beschrieben habe, ist, wie ich anfangen würde, es zu versuchen.
Jdw

30

Kein Problem - allerdings leicht überarbeiteter Vertragstext:

... garantieren eine Verfügbarkeit von 100% (auf null Dezimalstellen gerundet).


2
+1 für die Feststellung, dass 100% nicht 100,0% oder 100.000% usw. ist. Die Nachkommastellen sind wichtig, sie geben die Genauigkeit an;)
Danubian Sailor

4
Gemäß einigen Konventionen hat "100%" nur eine signifikante Zahl, sodass alle Zahlen zwischen einer Hälfte und einer auf "100%" gerundet würden. 50% würden auf 100% gerundet.
Thomas Levine

1
Abhängig vom Standard für das Zählen werden einige sagen, dass 50% zwei meeningfull Zahlen haben, wobei 100% drei meeningful Zahlen haben. 50,5 und 100 sind daher genauso präzise. Andere zählen die Nachkommastellen. Dann sind 50,5 und 100,4 genauso genau. Wenn nichts anderes angegeben ist, würde ich davon ausgehen, dass 100% 99,5% und mehr sind. 100,0% sind 99,95% und mehr usw.
Tillebeck

26

Wenn Facebook und Amazon es nicht können, dann können Sie es nicht. So einfach ist das.


17
er könnte schlauer sein als alle ihre Leute zusammen, wer weiß: p
Matt

3
100% Betriebszeit muss nicht so buchstäblich sein - es bedeutet: 100% verfügbar während der Zeit, die benötigt wird. Zum Beispiel sollten Bankensysteme immer verfügbar sein, und sie funktionieren recht gut. Nur weil sie einmal im Jahr für eine Sekunde zur Wartung ausfallen, bedeutet dies nicht, dass sie ihr 100% iges Verfügbarkeitsziel nicht erreicht haben.
David d C e Freitas

13
@ DavidFreitas - Ich denke, in Verträgen ist es normalerweise ziemlich wörtlich ...
UpTheCreek

2
@Matt, nur weil Facebook / Amazon es nicht kann, bedeutet nicht, dass eine kleinere Site es nicht kann. Viele große Websites haben viel schwerer zu bewältigende Probleme als kleinere Websites.
Xorlev

1
Sie haben also keine 100% ige Verfügbarkeit, da einige Clients Fehler aufwiesen. Außerdem ist DNS kein sofortiger Wechsel, da Sie ISPs haben, die kurze TTLs ignorieren
Mike

25

Hinzufügen der Antwort von oconnore von Hacker News

Ich verstehe nicht, worum es geht. Der Kunde möchte, dass Sie sich auf eine Katastrophe einstellen, und sie sind nicht mathematisch orientiert. Daher klingt es vernünftig, nach einer Wahrscheinlichkeit von 100% zu fragen. Der Ingenieur erinnerte sich, wie es Ingenieure gerne tun würden, an seinen ersten Tag von prob & stat 101, ohne zu bedenken, dass der Kunde dies möglicherweise nicht tat. Wenn sie das sagen, denken sie nicht an nuklearen Winter, sondern daran, dass Fred seinen Kaffee auf den Büroserver wirft, eine Festplatte abstürzt oder ein ISP ausfällt. Darüber hinaus können Sie dies erreichen. Mit geografisch getrennten, unabhängigen, selbstüberwachenden Servern haben Sie im Grunde keine Ausfallzeiten. Bei 3 Servern, die mit einer unabhängigen Zuverlässigkeit (1) und 9 mit guten Failover-Modi arbeiten, liegt die erwartete Ausfallzeit unter einer Sekunde pro Jahr (2). Auch wenn dies alles auf einmal passiert, Sie befinden sich immer noch innerhalb einer angemessenen SLA für Webverbindungen und daher ist die Ausfallzeit praktisch nicht vorhanden. Der Kunde muss sich immer noch mit Doomsday-Szenarien auseinandersetzen, aber Godzilla schloss aus, er wird einen Service haben, der "immer" verfügbar ist.

(1) Ein Server in LA ist einigermaßen unabhängig vom Server in Boston, aber ich verstehe, dass es eine Kreuzung mit Atomkrieg, chinesischen Hackern, die das Stromnetz zum Absturz bringen usw. gibt diese.

(2) DNS-Failover kann einige Sekunden dauern. Sie befinden sich immer noch in einem Szenario, in dem der Client eine Anforderung einmal im Jahr wiederholen muss, was wiederum innerhalb eines angemessenen SLA liegt und normalerweise nicht mit "Ausfallzeit" gleichgesetzt wird. Bei einer Anwendung, die bei einem Ausfall automatisch zu einem verfügbaren Knoten umgeleitet wird, kann dies unbemerkt bleiben.


6
Das Problem ist, dass sie es in Vertrag sagen. Das bedeutet, dass die Site im Falle einer Katastrophe, die länger als zehn Sekunden dauert, über Backups wieder online geschaltet werden kann.
Shadur

@ Shadur: Wenn sie es wirklich wollen, dann müssen Sie sie wirklich aufladen. Verteilen Sie die Server geografisch weit und breit, hoffentlich kommt es nicht überall zu Katastrophen.
Jungle Hunter

3
Ich habe eine Website gesehen, die 100% Verfügbarkeitsgarantie oder Geld zurück bietet. Der Trick war, dass sie eine Bootsladung geladen und in Monate aufgeteilt haben. Einige Monate bleiben also unbezahlt und Sie planen alles, was dazugehört, und decken den Verlust mit den Monaten ab, die in Ordnung sind.
Jldugger

17

Sie werden nach etwas Unmöglichem gefragt.

Sehen Sie sich die anderen Antworten hier an, setzen Sie sich mit Ihrem Kunden zusammen und erklären Sie , warum dies unmöglich ist.

Wenn sie immer noch auf 100% Verfügbarkeit bestehen, informieren Sie sie höflich darüber, dass dies nicht möglich ist, und lehnen Sie den Vertrag ab. Sie werden ihre Nachfrage niemals befriedigen, und wenn der Vertrag nicht vollständig zum Erliegen kommt, werden Sie mit Strafen belegt.


2
100% muss definiert werden, dh 100% sind verfügbar, es sei denn, Sie führen Wartungsarbeiten oder Upgrades durch. Diese Zeit ist auf wenige Stunden pro Monat beschränkt. Es hängt alles davon ab, was der Zweck und die Verwendung der Web-App in diesem Fall ist ...
David d C e Freitas

1
und definieren Sie "Ausfallzeiten". Ich kann nicht einmal theoretisch garantieren, dass sie von ihren Büros in Fairbanks aus auf einen Server in Omaha zugreifen können, es sei denn, Sie kontrollieren das gesamte Netzwerk dazwischen (obwohl Sie versichern könnten, dass der Server in Betrieb ist).
30.

Die Definitionen sind, meiner Meinung nach, irrelevant, wenn sie nach "100% Verfügbarkeit" fragen: Selbst wenn Sie eine geplante Wartung aushandeln und N + N-Redundanz einbauen, wenn ein kleiner Fehler einen außerplanmäßigen Neustart oder Service-Blink verursacht, haben Sie Ihr SLA durchgebrannt. ENDGÜLTIG relevant, wenn Sie ein SLA mit 3, 4 oder 5 Neunen aushandeln.
Voretaq7

Kommt aber auf die Bedingungen der SLA an, oder? Wenn Sie 100.000 US-Dollar pro Monat erhalten und jede Minute Ausfallzeit mit einer 1.000-Dollar-Strafe verbunden ist, kann dies durchaus machbar sein (wenn Sie andere Verträge zur Amortisierung der Kosten für Sysadmins vor Ort rund um die Uhr abgeschlossen haben).
Michael Borgwardt

@MichaelBorgwardt es gibt definitiv Möglichkeiten, es von einem reinen Zahlenstandpunkt aus "zum Laufen zu bringen", aber ich würde es immer noch ablehnen, weil die Gefahr einer schlechten PR besteht und kann ihre SLA nicht einhalten! '). Persönlich hätte ich lieber 10 kleinere, vernünftigere Kunden, die mir 10.000 US-Dollar im Monat zahlen :-)
voretaq7

13

Der Preis ist dementsprechend und im Vertrag wird festgelegt, dass Ausfallzeiten nach dem SLA zum von ihnen gezahlten Satz erstattet werden.

Der ISP bei meinem letzten Job hat das getan. Wir hatten die Wahl zwischen einem "normalen" DSL-Anschluss mit einer Verfügbarkeit von 99,9% für 40 US-Dollar pro Monat oder einem gebundenen T1-Trio mit einer Verfügbarkeit von 99,99% für 1100 US-Dollar pro Monat. Es gab häufige Ausfälle von mehr als 10 Stunden pro Monat, wodurch die Verfügbarkeit deutlich unter den 40 USD pro Monat für DSL lag. Wir erhielten jedoch nur eine Rückerstattung von ungefähr 15 USD, da dies der Stundensatz * für Stunden war. Sie machten sich wie Banditen aus dem Geschäft.

Wenn Sie 450.000 US-Dollar pro Monat für eine 100-prozentige Verfügbarkeit abrechnen und nur 99,999 Prozent erreichen, müssen Sie diese 324 US-Dollar erstatten. Ich bin bereit zu wetten, dass die Infrastrukturkosten bei 99,999% in der Nähe von 45.000 USD pro Monat liegen, vorausgesetzt, es handelt sich um vollständig verteilte Colos, mehrere Tier-1-Uplinks, Fancypants-Hardware usw.


3
Wenn Sie jemanden sehen, der 100% Verfügbarkeit verspricht, dann ist dies genau das, was er tut. Es gibt einen Unterschied zwischen 100% Verfügbarkeit und der Lieferung. Es ist eine gute Idee, dies dem Kunden zu erklären, wenn er versucht, Ihnen die SLA eines Mitbewerbers zu zitieren.
Sjbotha

10

Wenn Fachleute fragen, ob eine Verfügbarkeit von 99,999 Prozent jemals eine praktikable oder finanziell realisierbare Möglichkeit ist , dann ist eine Verfügbarkeit von 99,9999 Prozent noch weniger möglich oder praktisch. Geschweige denn 100%.

Sie werden das 100% -Verfügbarkeitsziel für einen längeren Zeitraum nicht erreichen. Sie können eine Woche oder ein Jahr damit durchkommen, aber dann passiert etwas und Sie werden zur Verantwortung gezogen. Der Ausfall kann von einem beschädigten Ruf (Sie haben versprochen, dass Sie nicht geliefert haben) bis hin zum Konkurs von Vertragsstrafen reichen.


10

Es gibt zwei Arten von Personen, die nach einer 100% igen Verfügbarkeit fragen:

  1. Menschen ohne jegliche Kenntnisse über Computer, Computersysteme oder das Internet. *
  2. Diejenigen, die sich absichtlich einen Arsch machen, entweder um Ihre Fähigkeit zu testen, Nein zu sagen (Google "der Orangensaft-Test") oder um eine Art Vertrags-SLA-Hebel zu erlangen, um Sie später nicht mehr zu bezahlen.

Mein Rat, unter beiden Kliententypen schon oft zu leiden, ist, diesen Klienten nicht anzunehmen. Lassen Sie sie jemanden verrückt machen.

* Dieselbe Person ist möglicherweise nicht in Verlegenheit, wenn sie nach schneller als Licht Reisen, Perpetual Motion, Cold Fusion usw. fragt.


2
+1 für den Orangensaft-Test .. Ich mag und wusste nicht darüber :)
Oliver M Grech

8

Ich würde mit dem Kunden kommunizieren, um herauszufinden, was genau 100% Verfügbarkeit bedeutet. Es ist möglich, dass sie nicht wirklich einen Unterschied zwischen 99% Betriebszeit und 100% Betriebszeit sehen. Für die meisten Leute (dh nicht für Serveradministratoren) sind diese beiden Nummern gleich.


6

100% Betriebszeit?

Folgendes benötigen Sie:

Mehrere (und redundante) DNS-Server, die auf mehrere Standorte auf der ganzen Welt verweisen, mit korrekten SLAs für jeden ISP.

Stellen Sie sicher, dass die DNS-Server ordnungsgemäß eingerichtet sind und TTL effektiv erkannt wird.


1
Ja, DNS ist ein guter Anfang - z. B. nslookup google.comgibt 6 verschiedene IP-Adressen zur Redundanz zurück, falls einige von ihnen nicht funktionieren. Besuchen Sie auch RobTex.com, eine großartige Website, um sich die Konfigurationen bestimmter Domains anzusehen,
David d C e Freitas,

6

Das ist einfach. Das Amazon EC2 SLA besagt eindeutig:

"Annual Uptime Percentage" (Jährlicher Betriebszeitprozentsatz) wird berechnet, indem von 100% der Prozentsatz der 5-Minuten-Perioden während des Service-Jahres abgezogen wird, in dem sich Amazon EC2 im Status "Region nicht verfügbar" befand.

http://aws.amazon.com/ec2-sla/

Definieren Sie "Betriebszeit" einfach so, dass sie sich auf das gesamte Servicebündel bezieht, das Sie tatsächlich zu 100% in Betrieb halten können, und Sie sollten keine Probleme haben.

Es ist auch erwähnenswert, dass der gesamte Sinn eines SLA darin besteht, zu definieren, welche Verpflichtungen Sie haben und was passiert, wenn Sie diese nicht erfüllen können. Es ist egal, ob der Kunde 3 Neunen oder 5 Neunen oder eine Million Neunen verlangt - die Frage ist, was sie bekommen, wenn / wenn Sie nicht liefern können. Die offensichtliche Antwort besteht darin, eine Werbebuchung mit einer Verfügbarkeit von 100% zu dem fünffachen Preis bereitzustellen, den Sie berechnen möchten. Wenn Sie dieses Ziel verfehlen, erhalten sie eine vierfache Rückerstattung. Sie könnten punkten!


5

DNS-Änderungen nehmen nur Zeit in Anspruch, wenn sie so konfiguriert sind, dass sie Zeit in Anspruch nehmen. Sie können die TTL für einen Datensatz auf eine Sekunde festlegen. Sie müssen nur sicherstellen, dass Sie rechtzeitig auf DNS-Abfragen antworten und dass die DNS-Server diese Abfragen verarbeiten können.

Genau so funktioniert GTM in F5 Big IP - die DNS-TTL ist standardmäßig auf 30 Sekunden eingestellt, und wenn ein Mitglied des Clusters übernehmen muss, wird der DNS aktualisiert und die neue IP wird fast sofort übernommen. Maximal 30 Sekunden Ausfall, aber das ist der Randfall, der Durchschnitt wäre 15 Sekunden.


10
Ich habe die Erfahrung gemacht, dass einige DNS-Server eine TTL ignorieren, die sie (trotz RFC) für unangenehm niedrig halten. Alles, was weniger als 5 Minuten dauert, wird im globalen Maßstab etwas unzuverlässig.
Jdw

13
@Paul, die Realität zu ignorieren, ist keine akzeptable Praxis, egal wie sehr es alle verärgert.
MDMarra

5
Ich bin mit jdw dabei. Ich habe zahlreiche DNS-Server gesehen, die TTL vollständig ignoriert haben, sogar eine 1-Stunden-Einstellung und standardmäßig etwa 24 Stunden oder so.
NotMe

6
@Paul - Das OP hat nicht die Kontrolle über die DNS-Resolver aller ISPs auf dem Planeten. Ergo, sie haben nicht die Wahl zu sagen "Wenn Sie unsere Website nutzen wollen, verwenden Sie Comcast / Roadrunner / wen auch immer nicht als Ihren ISP, da sie unsere TTL-Einstellungen ignorieren". Es ist etwas, das einfach außerhalb ihrer Kontrolle liegt und daher zu zerbrechlich ist, um als Lösung für dieses Problem angesehen zu werden. Die Lösung muss eine Möglichkeit beinhalten, die IPs intern zu erzwingen, ohne auf andere Teile des Netzwerks angewiesen zu sein, die möglicherweise nicht kooperativ sind.
Jdw

3
Das ist so, als hätte man keine USV, weil der Strom einfach funktionieren sollte. Es ist keine vorausschauende Art, ein System zu entwerfen. Wenn Sie wissen, dass es aus irgendeinem Grund einen fragilen Teil des Systems gibt, sollten Sie versuchen, dies zu berücksichtigen.
Jdw

5

Sie wissen, dass das unmöglich ist.

Zweifellos ist der Kunde darauf ausgerichtet, "100%" zu sehen. Das Beste, was Sie tun können, ist, 100% zu versprechen, mit Ausnahme von [allen vernünftigen Gründen, die nicht Ihre Schuld sind].


Zweifellos möchte der Kunde keine Lösung. Sie wollen einen Niedergang. Sie können also sagen, sie haben es zumindest versucht.
mbx

Vielleicht. Sie gehen von einem hohen Maß an Anhaltspunkten aus.
Marcin

4

Obwohl ich bezweifle, dass 100% möglich sind, möchten Sie vielleicht Azure (oder etwas mit einem ähnlichen SLA) als eine Möglichkeit in Betracht ziehen. Was geht ab:

Ihre Server sind virtuelle Maschinen. Wenn auf einem Server jemals ein Hardwareproblem auftritt, wird Ihre virtuelle Maschine auf eine neue Maschine verschoben. Der Load Balancer kümmert sich um die Umleitung, sodass der Kunde keine Ausfallzeiten sehen sollte (obwohl ich nicht sicher bin, wie sich Ihr Sitzungsstatus auswirken würde).

Trotz dieses Failovers grenzt der Unterschied zwischen 99,999 und 100 an Wahnsinn.

Sie müssen die volle Kontrolle über die folgenden Faktoren haben.
- Menschliche Faktoren, sowohl interne als auch externe, sowohl Bosheit als auch Impotenz. Ein Beispiel hierfür ist, dass jemand etwas in den Produktionscode pusht, wodurch ein Server heruntergefahren wird. Schlimmer noch, was ist mit Sabotage?
- Geschäftsprobleme. Was ist, wenn Ihr Provider nicht mehr im Geschäft ist oder vergisst, seine Stromrechnungen zu bezahlen, oder einfach beschließt, die Unterstützung Ihrer Infrastruktur ohne ausreichende Warnung einzustellen?
- Natur. Was ist, wenn nicht verwandte Tornados gleichzeitig genug Rechenzentren treffen, um die Backup-Kapazität zu überfordern?
- Eine völlig fehlerfreie Umgebung. Sind Sie sicher, dass es keinen Edge-Case mit einer Drittanbieter- oder Kernsystemsteuerung gibt, der sich nicht manifestiert hat, dies aber in Zukunft noch tun könnte?
- Selbst wenn Sie die volle Kontrolle über die oben genannten Faktoren haben, sind Sie sicher, dass die Software / Person, die dies überwacht, Sie nicht mit falschen Negativen belastet, wenn Sie prüfen, ob Ihr System in Betrieb ist?


2
Sowohl Azure als auch EC2 hatten kürzlich fast vollständige und vollständige Ausfälle. Ich glaube, Azure wurde kürzlich einfach aufgrund eines schlechten Konfigurationseintrags auf einem DNS-Server heruntergefahren. Wie auch immer, danke für die Infos.
NotMe

Und wenn Ihr Load Balancer (der den Switch ausführt) unbemerkt ausfällt (sein Monitor könnte auch unbemerkt und unbegrenzt ausfallen), wenn der Knoten ausfällt, sind Sie immer noch angeschraubt.
30.

1
Ich denke, Sie meinten "Inkompetenz". Impotenz sollte keinen großen Einfluss auf die Fähigkeit der IT-Mitarbeiter haben, ihre Arbeit zu erledigen.
mfinni

4

Ehrlich gesagt ist 100% völlig verrückt, ohne dass ein Hacking-Angriff ins Wanken gerät. Am besten tun Sie das, was Google und Amazon tun, indem Sie über eine geoverteilte Hosting-Lösung verfügen, bei der Ihre Site und Ihre Datenbank auf mehreren Servern an mehreren geografischen Standorten repliziert werden. Dies wird alles andere als eine große Katastrophe garantieren, wie zum Beispiel, dass das Internet-Backbone auf eine Region (die von Zeit zu Zeit vorkommt) oder etwas nahezu Apokalyptisches zerschnitten wird.

Ich würde eine Klausel für genau solche Fälle (DDOS, Internet-Backbone-Kürzung, apokalyptischer Terroranschlag oder großer Krieg usw.) einfügen.

Ansonsten werfen Sie einen Blick auf Amazon S3- oder Rackspace-Cloud-Services. Im Wesentlichen bietet das Cloud-Setup nicht nur Redundanz an jedem Standort, sondern auch Skalierbarkeit und Geoverteilung des Datenverkehrs sowie die Möglichkeit, fehlgeschlagene Geobereiche umzuleiten. Nach meinem Verständnis kostet die Geodistribution jedoch mehr Geld.


3

Ich wollte der Party "Es kann (theoretisch) getan werden" nur eine weitere Stimme hinzufügen .

Ich würde keinen Vertrag abschließen, in dem dies angegeben ist, egal wie viel sie für mich bezahlt haben, aber als Forschungsproblem hat es einige ziemlich interessante Lösungen. Ich kenne mich nicht gut mit Netzwerken aus, um die einzelnen Schritte zu erläutern, aber ich stelle mir vor, dass eine Kombination aus netzwerkbezogenen Konfigurationen + Failover der Elektro- / Hardware-Verkabelung + Software-Failover möglicherweise in einigen Konfigurationen oder anderen Abläufen tatsächlich zum Erfolg führen würde.

Es gibt fast immer irgendwo in einer Konfiguration eine einzelne Fehlerstelle. Wenn Sie jedoch hart genug arbeiten, können Sie diese Fehlerstelle so verschieben, dass sie "live" repariert werden kann (dh der DNS-Stamm geht aus, aber die Werte werden weiterhin zwischengespeichert) überall sonst, so dass Sie Zeit haben, es zu beheben).

Nochmals, nicht zu sagen, dass es machbar ist. Mir hat einfach nicht gefallen, wie keine einzige Antwort die Tatsache angesprochen hat, dass es kein "Ausweg" ist.


3

Überdenken Sie Ihre Methode zur Messung der Verfügbarkeit und arbeiten Sie dann mit Ihrem Kunden zusammen, um aussagekräftige Ziele festzulegen .

Wenn Sie eine große Website betreiben, ist die Verfügbarkeit überhaupt nicht sinnvoll. Wenn Sie 10 Minuten lang Anfragen stellen, wenn Ihre Kunden sie am meisten benötigen (Verkehrsspitze), kann dies für das Unternehmen schädlicher sein als ein stundenlanger Ausfall um 3 Uhr morgens an einem Sonntag.

Manchmal messen große Web-Unternehmen die Verfügbarkeit oder Zuverlässigkeit anhand der folgenden Metriken:

  1. Prozentsatz der erfolgreich beantworteten Abfragen ohne serverseitigen Fehler (HTTP 500s).
  2. Prozentsatz der Anfragen, die unterhalb einer bestimmten Zielwartezeit beantwortet werden .
  3. Abgebrochene Abfragen sollten mit Ihren Statistiken abgeglichen werden (siehe unten).

Die Verfügbarkeit sollte nicht mit Probesonden gemessen werden. Dies kann eine externe Entität wie Pingdom und Pingability melden. Verlassen Sie sich nicht nur darauf. Wenn Sie es richtig machen möchten, sollte jede einzelne Abfrage zählen . Messen Sie Ihre Verfügbarkeit anhand Ihres tatsächlichen, wahrgenommenen Erfolgs.

Am effizientesten ist es, Protokolle oder Statistiken von Ihrem Load-Balancer zu erfassen und die Verfügbarkeit anhand der oben genannten Metriken zu berechnen.

Der Prozentsatz der gelöschten Anfragen sollte auch für Ihre Statistiken gelten. Es kann im selben Bucket wie serverseitige Fehler abgerechnet werden. Wenn es Probleme mit dem Netzwerk oder mit einer anderen Infrastruktur wie DNS oder den Load Balancern gibt, können Sie mithilfe einfacher Berechnungen abschätzen, wie viele Abfragen Sie verloren haben . Wenn Sie für diesen Wochentag X-Abfragen erwartet haben, aber X-1000 erhalten haben, haben Sie wahrscheinlich 1000 Abfragen gelöscht. Zeichnen Sie Ihren Datenverkehr in Diagramme mit Abfragen pro Minute (oder Sekunde). Wenn Lücken auftreten, haben Sie Abfragen gelöscht. Verwenden Sie die Basisgeometrie , um die Fläche dieser Lücken zu messen. Auf diese Weise erhalten Sie die Gesamtzahl der abgelegten Abfragen.

Besprechen Sie diese Methode mit Ihrem Kunden und erläutern Sie deren Vorteile. Stellen Sie eine Basislinie ein, indem Sie deren aktuelle Verfügbarkeit messen. Ihnen wird klar, dass 100% ein unmögliches Ziel ist.

Anschließend können Sie einen Vertrag unterzeichnen, der auf Verbesserungen an der Baseline basiert. Angenommen, sie sind derzeit zu 95% verfügbar, könnten Sie versprechen, die Situation um das Zehnfache zu verbessern, indem Sie 98,5% erreichen.

Hinweis: Diese Art der Verfügbarkeitsmessung hat Nachteile. Erstens ist das Sammeln von Protokollen, das Verarbeiten und Generieren der Berichte möglicherweise nicht trivial, es sei denn, Sie verwenden dafür vorhandene Tools. Zweitens können Anwendungsfehler Ihre Verfügbarkeit beeinträchtigen. Wenn die Qualität der Anwendung niedrig ist, treten mehr Fehler auf. Die Lösung hierfür besteht darin, nur die vom Load Balancer erstellten 500er zu berücksichtigen, anstatt die aus der Anwendung stammenden.

Auf diese Weise werden die Dinge vielleicht etwas kompliziert, aber es geht noch einen Schritt weiter, als nur die Verfügbarkeit Ihres Servers zu messen .


3

Während einige Leute hier bemerkten, dass 100% verrückt oder unmöglich sind , verpassten sie irgendwie den wahren Punkt. Sie argumentierten, dass der Grund dafür die Tatsache ist, dass selbst die besten Unternehmen / Dienstleistungen dies nicht erreichen können.

Nun, es ist viel einfacher als das. Es ist mathematisch unmöglich .

Alles hat eine Wahrscheinlichkeit. An allen Orten, an denen Sie Ihre Server aufbewahren, kann es zu einem gleichzeitigen Erdbeben kommen, das alle zerstört. Zugegeben, es ist eine lächerlich kleine Wahrscheinlichkeit, aber nicht 0. Alle Ihre Internetanbieter könnten einem gleichzeitigen Terror- / Cyberangriff ausgesetzt sein. Wiederum nicht sehr wahrscheinlich, aber auch nicht Null. Was auch immer Sie bereitstellen, Sie können ein Szenario mit einer Wahrscheinlichkeit ungleich Null erhalten, das den gesamten Service beeinträchtigt. Aus diesem Grund kann Ihre Betriebszeit auch nicht 100% betragen.


Eigentlich würde ich verrückt oder unmöglich sein und es als dumm bezeichnen. Nichts, was Menschen wissen, ist 100%.
Vierfach

2

Lesen Sie ein Buch über die Qualitätskontrolle in der Fertigung anhand statistischer Stichproben. Eine allgemeine Diskussion in diesem Buch, deren Konzepten jeder Manager in einem allgemeinen Statistikkurs im College ausgesetzt gewesen wäre, diktiert die Kosten, die von einer Exzession von tausend auf eine von zehntausend auf eine von einer Million auf eine zu gehen 1 in einer Milliarde steigt exponentiell. Im Wesentlichen würde die Fähigkeit, eine 100% ige Verfügbarkeit zu erreichen, eine nahezu unbegrenzte Menge an Geld kosten, ähnlich wie die Menge an Kraftstoff, die erforderlich ist, um ein Objekt auf Lichtgeschwindigkeit zu bringen.

Aus Performance-Engineering-Sicht würde ich die Forderung als nicht prüfbar und unvernünftig ablehnen, dass dieser Ausdruck eher ein Wunsch als eine wahre Forderung ist. Angesichts der Anwendungsabhängigkeiten, die außerhalb von Anwendungen für Netzwerke, Namensauflösung, Routing, Fehler, die von zugrunde liegenden Architekturkomponenten oder Entwicklungstools stammen, besteht, ist es praktisch unmöglich, dass jemand eine 100% ige Verfügbarkeit garantiert.


1

Ich glaube nicht, dass der Kunde tatsächlich eine Verfügbarkeit von 100% oder sogar 99,999% wünscht. Wenn Sie sich ansehen, was sie beschreiben, sprechen sie davon, dort anzuhalten, wo sie aufgehört haben, wenn ein Meteor sein Rechenzentrum vor Ort verlässt.

Wenn die Anforderung ist, dass externe Personen es nicht einmal bemerken, wie drastisch muss das sein? Würde es akzeptabel sein, eine Ajax-Anfrage erneut zu starten und dem Endbenutzer 30 Sekunden lang einen Spinner anzuzeigen?

Das sind die Dinge, die den Kunden interessieren. Wenn der Kunde tatsächlich an präzise SLAs dachte, wusste er genug, um dies als 99,99 oder 99,999 auszudrücken.


Wenn der Kunde denkt, dass er eine "100% ige Verfügbarkeit" haben möchte und dies dann in der vertraglichen Vereinbarung endet, werden Sie möglicherweise festgehalten, wenn dies vor Gericht erfolgt. Reden Sie es am besten aus und helfen Sie dem Kunden zu verstehen, was er wirklich will, anstatt davon auszugehen, dass Sie wissen, was er denkt.
Chris S

Oh, ich bin damit einverstanden, dass dies geklärt werden muss, bevor ein Vertrag zustande kommt. Ich sage nur, dass dies angegangen werden muss, da der Kunde nicht mitteilt, was er eigentlich will, im Gegensatz zum Kunden, der um etwas Lächerliches bittet.
Kevin Peterson

1

meine 2 Cent. Ich war für eine sehr beliebte Website eines Fortune-5-Unternehmens verantwortlich, das Anzeigen für den Super Bowl herausbrachte. Ich musste mich mit riesigen Verkehrsspitzen auseinandersetzen und die Art und Weise, wie ich das löste, war, einen Dienst wie Akamai zu nutzen. Ich arbeite nicht für Akamai, aber ich fand ihren Service sehr gut. Sie haben ein eigenes, intelligenteres DNS-System, das weiß, dass ein bestimmter Knoten / Host entweder stark ausgelastet oder ausgefallen ist und den Datenverkehr entsprechend weiterleiten kann.

Das Schöne an ihrem Service war, dass ich eigentlich nichts sehr Kompliziertes tun musste, um Inhalte auf Servern in meinem eigenen Rechenzentrum in ihr Rechenzentrum zu replizieren. Außerdem haben sie, wie ich weiß, Apache-HTTP-Server intensiv genutzt.

Obwohl die Verfügbarkeit nicht 100% beträgt, können Sie solche Optionen in Betracht ziehen, um Inhalte auf der ganzen Welt zu verbreiten. Nach meinem Verständnis war Akamai auch in der Lage, den Datenverkehr zu lokalisieren, was bedeutet, dass ich mich in Michigan befand, Inhalte von einem Michigan / Chicago-Server bezogen habe und wenn ich mich in Kalifornien befand, angeblich Inhalte von einem Server mit Sitz in Kalifornien.


-1 weil dies eine praktische Antwort ist, aber überhaupt nicht nützlich. Alle Fragen auf dieser Website könnten von "jemand anderem beauftragen" beantwortet werden, aber aus diesem Grund sind wir nicht hier.
Yves Junqueira

Ich bin anderer Ansicht. "Überhaupt nicht nützlich?" Es war mit Sicherheit nützlich für mich und entgegen Ihrer Bemerkung, dass Sie jemand anderen damit beauftragen sollten, sollte der Typ mit Ihrer Überlegung sein eigenes Glasfaserkabel ausgraben und seine eigenen Schalter entwerfen, anstatt sie auch zu kaufen? Meinst du das ernst, Yves? Sie klingen wie jemand, der nicht viel Zeit im IT-Bereich verbracht hat.
Kilo

0

Statt eines externen Failovers müssen Sie die Anwendung nur an zwei Standorten gleichzeitig ausführen, intern und extern. Und synchronisieren Sie die beiden Datenbanken ... Wenn die internen Daten ausfallen, können die internen Personen weiterhin arbeiten und externe Personen können die Anwendung weiterhin verwenden. Wenn internal wieder online ist, synchronisieren Sie die Änderungen. Sie können zwei DNS-Einträge für einen Domainnamen oder sogar einen Netzwerkrouter mit Round-Robin haben.


0

Bei extern gehosteten Websites ist das Hosting Ihrer Website in der App Engine von Google und die Verwendung des Datenspeichers mit hoher Replikation (High Replication Datastore, HRD) das automatische Replizieren Ihrer Daten in mindestens drei Rechenzentren in Echtzeit. Ebenso werden die App Engine-Front-End-Server automatisch für Sie skaliert / repliziert.

Trotz aller Ressourcen von Google und der weltweit fortschrittlichsten Plattform beträgt die SLA- Verfügbarkeitsgarantie für App Engine nur "99,95% der Zeit in einem Kalendermonat".


0

Einfach und direkt: Anycast

http://en.wikipedia.org/wiki/Anycast

Dies ist, was Cloudflare, Google und jedes andere große Unternehmen verwendet, um redundante, latenzarme, kontinentalübergreifende Failover- / Balancing-Vorgänge durchzuführen.

Beachten Sie aber auch, dass es unmöglich ist, eine 100% ige Verfügbarkeit zu erreichen, und dass die Kosten für einen Anstieg von 99,999% auf 99,9999% VIEL höher sind.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.