Hohe Verfügbarkeit

Hohe Verfügbarkeit (HA) ist ein Merkmal eines Systems, das normalerweise ein vereinbartes Maß an operativer Leistung gewährleisten soll Betriebszeitfür einen höheren als normalen Zeitraum.

Die Modernisierung hat zu einer erhöhten Abhängigkeit von diesen Systemen geführt. Beispielsweise erfordern Krankenhäuser und Rechenzentren eine hohe Verfügbarkeit ihrer Systeme, um routinemäßige tägliche Aktivitäten durchzuführen. Verfügbarkeit Bezieht sich auf die Fähigkeit der Benutzergemeinschaft, einen Dienst oder Gut zu erhalten, auf das System zuzugreifen, ob neue Arbeiten eingereicht, vorhandene Arbeiten vorhanden oder die Ergebnisse früherer Arbeiten sammelt. Wenn ein Benutzer nicht auf das System zugreifen kann, ist dies - aus Sicht des Benutzers - nicht verfügbar.[1] Im Allgemeinen der Begriff Ausfallzeit wird verwendet, um sich auf Perioden zu beziehen, in denen ein System nicht verfügbar ist.

Prinzipien

Es gibt drei Prinzipien von Systemdesign in Zuverlässigkeitstechnik Dies kann dazu beitragen, eine hohe Verfügbarkeit zu erreichen.

  1. Beseitigung von Einzelpunkte des Versagens. Dies bedeutet, dass Redundanz in das System hinzugefügt oder aufgebaut wird, sodass ein Ausfall einer Komponente keinen Fehler des gesamten Systems bedeutet.
  2. Zuverlässige Crossover. Im redundante SystemeDer Crossover -Punkt selbst wird tendenziell zu einem einzelnen Ausfallpunkt. Zuverlässige Systeme müssen zuverlässige Crossover vorsehen.
  3. Erkennung von Fehlern, sobald sie auftreten. Wenn die beiden oben genannten Prinzipien beobachtet werden, wird ein Benutzer möglicherweise nie einen Fehler erkennen - aber die Wartungsaktivität muss.

Geplante und außerplanmäßige Ausfallzeiten

Es kann zwischen geplanten und außerplanmäßigen Ausfallzeiten unterschieden werden. Typischerweise, Geplante Ausfallzeiten ist ein Ergebnis von Wartung Dies ist störend für den Systembetrieb und kann normalerweise nicht mit einem derzeit installierten Systemdesign vermieden werden. Geplante Ausfallzeitveranstaltungen können Patches zu enthalten Systemsoftware das erfordert a Neustart oder Systemkonfigurationsänderungen, die nur auf einen Neustart wirken. Im Allgemeinen ist die geplante Ausfallzeit in der Regel das Ergebnis eines logischen, von Managements initiierten Ereignisses. Außerplante Ausfallzeitveranstaltungen ergeben sich in der Regel aus einem physischen Ereignis, wie z. B. einer Hardware oder einer Softwarefehler oder einer Umweltanomalie. Beispiele für außerplanmäßige Ausfallzeitereignisse sind Stromausfälle, fehlgeschlagen Zentralprozessor oder RAM Komponenten (oder möglicherweise andere fehlgeschlagene Hardwarekomponenten), ein übertemperaturbezogenes Herunterfahren, logisch oder physikalisch abgetrennte Netzwerkverbindungen, Sicherheitsverletzungen oder verschiedene Verstöße Anwendung, Middleware, und Betriebssystem Fehler.

Wenn Benutzer vor geplanten Verschwindigkeiten gewarnt werden können, ist die Unterscheidung nützlich. Wenn die Anforderung jedoch eine echte hohe Verfügbarkeit gilt, ist Ausfallzeiten, unabhängig davon, ob sie geplant ist oder nicht.

Viele Computing -Sites schließen geplante Ausfallzeiten von Verfügbarkeitsberechnungen aus, vorausgesetzt, es hat wenig oder gar keinen Einfluss auf die Computer -Benutzergemeinschaft. Auf diese Weise können sie behaupten, phänomenal hohe Verfügbarkeit zu haben, was die Illusion von geben könnte kontinuierliche Verfügbarkeit. Systeme, die eine wirklich kontinuierliche Verfügbarkeit aufweisen, sind vergleichsweise selten und teurer. der Punkt des Versagens Ermöglichen Sie Online -Hardware, Netzwerk, Betriebssystem, Middleware und Anwendungs ​​-Upgrades, Patches und Austausch. Für bestimmte Systeme spielt die geplante Ausfallzeit keine Rolle, beispielsweise Systemausfallzeiten in einem Bürogebäude, nachdem alle für die Nacht nach Hause gegangen sind.

Prozentuale Berechnung

Die Verfügbarkeit wird normalerweise als Prozentsatz der Verfügbarkeit in einem bestimmten Jahr ausgedrückt. Die folgende Tabelle zeigt die Ausfallzeit, die für einen bestimmten Prozentsatz der Verfügbarkeit zulässig ist, da das System für den kontinuierlichen Betrieb erforderlich ist. Service Level Agreements Beziehen Sie sich häufig auf monatliche Ausfallzeiten oder Verfügbarkeit, um Servicegutschriften so zu berechnen, dass sie monatliche Abrechnungszyklen entsprechen. Die folgende Tabelle zeigt die Übersetzung von einem bestimmten Verfügbarkeitsprozentsatz auf die entsprechende Zeitspanne, in der ein System nicht verfügbar wäre.

Verfügbarkeit% Ausfallzeit pro Jahr[Anmerkung 1] Ausfallzeit pro Quartal Ausfallzeit pro Monat Ausfallzeit pro Woche Ausfallzeit pro Tag (24 Stunden)
90% ("ein neun") 36,53 Tage 9.13 Tage 73,05 Stunden 16,80 Stunden 2,40 Stunden
95% ("eineinhalb Nines") 18,26 Tage 4,56 Tage 36,53 Stunden 8.40 Stunden 1,20 Stunden
97% ("Ein- und drei Viertel Nines") 10,96 Tage 2,74 Tage 21,92 Stunden 5,04 Stunden 43,20 Minuten
98% ("Ein- und sieben Acht -Nines") 7,31 Tage 43,86 Stunden 14,61 Stunden 3,36 Stunden 28,80 Minuten
99% ("zwei Neunen") 3,65 Tage 21,9 Stunden 7.31 Stunden 1,68 Stunden 14,40 Minuten
99,5% ("zweieinhalb Ninen") 1,83 Tage 10.98 Stunden 3,65 Stunden 50,40 Minuten 7,20 Minuten
99,8% ("Zwei und sieben Achtel -Ninen") 17,53 Stunden 4,38 Stunden 87,66 Minuten 20,16 Minuten 2,88 Minuten
99,9% ("drei Neunen") 8,77 Stunden 2.19 Stunden 43,83 Minuten 10.08 Minuten 1,44 Minuten
99,95% ("dreieinhalb Ninen") 4,38 Stunden 65,7 Minuten 21,92 Minuten 5,04 Minuten 43,20 Sekunden
99,99% ("vier Neunen") 52,60 Minuten 13.15 Minuten 4,38 Minuten 1,01 Minuten 8,64 Sekunden
99,995% ("viereinhalb Ninen") 26.30 Minuten 6,57 Minuten 2.19 Minuten 30,24 Sekunden 4,32 Sekunden
99,999% ("fünf Neunen") 5.26 Minuten 1,31 Minuten 26.30 Sekunden 6,05 Sekunden 864.00 Millisekunden
99,9999% ("sechs Neunen") 31,56 Sekunden 7,89 Sekunden 2,63 Sekunden 604.80 Millisekunden 86,40 Millisekunden
99,99999% ("sieben Neunen") 3.16 Sekunden 0,79 Sekunden 262.98 Millisekunden 60,48 Millisekunden 8,64 Millisekunden
99,999999% ("acht Neuner") 315.58 Millisekunden 78,89 Millisekunden 26.30 Millisekunden 6,05 Millisekunden 864.00 Mikrosekunden
99,9999999% ("Neun Neuns") 31.56 Millisekunden 7,89 Millisekunden 2,63 Millisekunden 604.80 Mikrosekunden 86,40 Mikrosekunden

Betriebszeit und Verfügbarkeit kann synonym verwendet werden, solange die besprochenen Elemente konsistent gehalten werden. Das heißt, ein System kann abgelaufen sein, aber seine Dienste sind nicht verfügbar, wie im Fall von a Netzwerkausfall. Dies kann auch als ein System angesehen werden, an dem sie bearbeitet werden können. Die Dienste sind jedoch nicht aus einer funktionalen Perspektive (im Gegensatz zur Perspektive des Software -Dienstes/-prozesses). Die Perspektive ist hier wichtig - unabhängig davon, ob das besprochene Element die Serverhardware, das Server -Betriebssystem, der funktionale Dienst, der Software -Service/der Prozess ... usw. ist. Halten Sie die Perspektive während einer Diskussion konsistent, dann können Fahrt und Verfügbarkeit synonym verwendet werden.

"Nines"

Prozentsatz einer bestimmten Größenordnung werden manchmal von der bezeichnet Anzahl der Neune oder "Klasse von Ninen" in den Ziffern. Zum Beispiel Strom, der ohne Unterbrechungen geliefert wird (Stromausfälle, Brownouts oder Anstände) 99,999% der Fälle hätten 5 Neun -Zuverlässigkeit oder Klasse fünf.[2] Insbesondere wird der Begriff in Verbindung mit verwendet Mainframes[3][4] oder Enterprise Computing, oft als Teil von a Service-Level-Vereinbarung.

In ähnlicher Weise haben Prozentsätze, die mit 5 enden, herkömmliche Namen, traditionell die Anzahl der Neunen, dann "fünf", also sind 99,95% "drei neun fünf", abgekürzt 3N5.[5][6] Dies wird beiläufig als "dreieinhalb Ninen" bezeichnet,[7] Dies ist jedoch falsch: Ein 5 ist nur ein Faktor von 2, während ein 9 ein Faktor von 10 ist, also ist A 5 0,3 Neun (per unterhalb der Formel: ):[Anmerkung 2] 99,95% Die Verfügbarkeit beträgt 3,3 Neun, nicht 3,5 neun.[8] Einfacher ist, dass die Verfügbarkeit von 99,9% bis zu 99,95% die Verfügbarkeit von 2 (0,1% bis 0,05% Nichtverfügbarkeit) beträgt. doppelt so viel.[Notiz 3]

Eine Formulierung der Klasse von 9s Basierend auf einem System eines Systems Nichtverfügbarkeit wäre

(vgl. Boden- und Deckenfunktionen).

A Ähnliche Messung wird manchmal verwendet, um die Reinheit von Substanzen zu beschreiben.

Im Allgemeinen wird die Anzahl der Ninen bei der Modellierung und Messung der Verfügbarkeit nicht oft von einem Netzwerkingenieur verwendet, da es schwierig ist, in der Formel angewendet zu werden. Öfter die Nichtverfügbarkeit als ausgedrückt als Wahrscheinlichkeit (wie 0,00001) oder a Ausfallzeit pro Jahr wird zitiert. Die Verfügbarkeit als eine Reihe von Neunen ist häufig in festgelegt Marketing Unterlagen. Die Verwendung der "Nines" wurde in Frage gestellt, da sie nicht angemessen widerspiegelt, dass die Auswirkungen der Nichtverfügbarkeit mit seiner Zeit des Auftretens variieren.[9] Für große Mengen von 9S ist der Index der "Nichtverfügbarkeit" (Maß für die Ausfallzeit und nicht für Betriebszeit) einfacher zu handhaben. Aus diesem Grund wird beispielsweise eine "Nichtverfügbarkeit" anstelle von Verfügbarkeitsmetrik in Festplatten- oder Datenverbindung verwendet Bit -Fehlerraten.

Manchmal wird der humorvolle Begriff "Neun Fives" (55,5555555%) verwendet, um sich mit "fünf Neunen" (99,999%) zu kontrastieren.[10][11][12] Dies ist zwar kein tatsächliches Ziel, sondern ein sarkastischer Hinweis darauf, kein vernünftiges Ziel zu erreichen.

Messung und Interpretation

Die Verfügbarkeitsmessung unterliegt einem gewissen Grad an Interpretation. Ein System, das seit 365 Tagen in einem Nicht-LEAP-Jahr in den Schatten gestellt wurde, könnte durch einen Netzwerkfehler in den Schatten gestellt worden sein, der während eines Spitzennutzungszeitraums 9 Stunden dauerte. Die Benutzergemeinschaft wird das System als nicht verfügbar sehen, während der Systemadministrator 100% beansprucht wird Betriebszeit. Angesichts der tatsächlichen Definition der Verfügbarkeit wird das System jedoch ungefähr 99,9% oder drei Neunen (8751 Stunden verfügbarer Zeit von 8760 Stunden pro Jahr) verfügbar sein. Außerdem werden Systeme, die Leistungsprobleme haben, häufig als teilweise oder völlig nicht verfügbar von Benutzern angesehen, selbst wenn die Systeme weiter funktionieren. In ähnlicher Weise kann die Nichtverfügbarkeit ausgewählter Anwendungsfunktionen von Administratoren unbemerkt bleiben, aber für Benutzer verheerend - eine echte Verfügbarkeitsmaßnahme ist ganzheitlich.

Die Verfügbarkeit muss gemessen werden, um festzustellen, idealerweise mit umfassenden Überwachungstools ("Instrumentierung"), die selbst hoch verfügbar sind. Wenn es an Instrumenten mangelt, werden Systeme, die die Verarbeitung von Transaktionen im Laufe des Tages und der Nacht, wie z. fordern.

Eine alternative Metrik ist Zwischenzeit zwischen Fehlern (MTBF).

Eng verwandte Konzepte

Wiederherstellungszeit (oder geschätzte Reparaturzeit (ETR), auch bekannt als Erholungszeitziel (RTO) ist eng mit der Verfügbarkeit verbunden, dh die Gesamtzeit, die für einen geplanten Ausfall erforderlich ist, oder die Zeit, die erforderlich ist, um sich vollständig von einem ungeplanten Ausfall zu erholen. Eine weitere Metrik ist Zwischenzeit bis zur Genesung (MTTR). Die Wiederherstellungszeit könnte mit bestimmten Systemdesigns und -fehlern unendlich sein, d. H. Die vollständige Genesung ist unmöglich. Ein solches Beispiel ist ein Feuer oder eine Flut, die ein Rechenzentrum und seine Systeme zerstört, wenn es keine Sekundär gibt Notfallwiederherstellung Rechenzentrum.

Ein anderes verwandtes Konzept ist Datenverfügbarkeit, das ist der Grad, in dem Datenbanken und andere Informationsspeichersysteme zeichnen und melden Systemtransaktionen treu und melden. Informationsmanagement konzentriert sich häufig separat auf Datenverfügbarkeit oder Wiederherstellungspunktziel, um akzeptable (oder tatsächliche) zu bestimmen Datenverlust mit verschiedenen Fehlerereignissen. Einige Benutzer können Anwendungsdienstunterbrechungen tolerieren, können jedoch den Datenverlust nicht tolerieren.

A Service -Level -Vereinbarung ("SLA") Formalisiert die Verfügbarkeitsziele und -anforderungen einer Organisation.

Militärkontrollsysteme

Hohe Verfügbarkeit ist eine der Hauptanforderungen der Kontroll systeme in unbemannte Fahrzeuge und Autonome Seeschiffe. Wenn das Steuerungssystem nicht verfügbar ist, das Bodenkampffahrzeug (GCV) oder ASW Continuous Trail Unbemannte Schiff (Actuv) wäre verloren.

System-Design

Das Hinzufügen von mehr Komponenten zu einem Gesamtsystemdesign kann die Bemühungen untergraben, um eine hohe Verfügbarkeit zu erreichen, weil Komplexe Systeme haben von Natur aus mehr potenzielle Fehlerpunkte und sind schwieriger zu umsetzen. Während einige Analysten die Theorie vorstellen würden, dass die am besten verfügbaren Systeme an einer einfachen Architektur einhalten (ein einzelnes, hochwertiges, mehrzweckiges physikalisches System mit umfassender interner Hardware-Redundanz), leidet diese Architektur unter der Anforderung, dass das gesamte System sein muss zum Patchen und Betriebssystem -Upgrades gesenkt. Fortgeschrittene Systemdesigns ermöglichen es, die Systeme ohne Kompromisse bei der Verfügbarkeit von Dienstleistungen zu patchieren und aktualisieren (siehe Lastverteilung und Failover).

Eine hohe Verfügbarkeit erfordert weniger menschliche Eingriffe, um den Betrieb in komplexen Systemen wiederherzustellen. Der Grund dafür ist, dass die häufigste Ursache für Ausfälle menschlicher Fehler ist.[13]

Redundanz wird verwendet, um Systeme mit hohen Verfügbarkeitsniveaus zu erstellen (z. B. Flugzeugflugcomputer). In diesem Fall ist es erforderlich, ein hohes Maß an Ausfalldetektierbarkeit und die Vermeidung gemeinsamer Ursachenfehler zu haben. Zwei Arten von Redundanz sind passive Redundanz und aktive Redundanz.

Passive Redundanz wird verwendet, um eine hohe Verfügbarkeit zu erzielen, indem genügend überschüssige Kapazitäten in das Design aufgenommen werden, um einen Leistungsrückgang zu berücksichtigen. Das einfachste Beispiel ist ein Boot mit zwei separaten Motoren, die zwei getrennte Propeller fahren. Das Boot setzt sich trotz des Scheiterns eines einzelnen Motors oder eines Propellers in Richtung seines Ziels fort. Ein komplexeres Beispiel sind mehrere redundante Stromerzeugungsanlagen in einem großen System, das einbezieht Elektrisches Stromübertragung. Eine Fehlfunktion einzelner Komponenten wird nicht als Fehler angesehen, es sei denn, der resultierende Leistungsrückgang überschreitet die Spezifikationsgrenzen für das gesamte System.

Aktive Redundanz wird in komplexen Systemen verwendet, um eine hohe Verfügbarkeit ohne Leistungsrückgang zu erreichen. Mehrere Elemente derselben Art werden in ein Design aufgenommen, das eine Methode zum Erkennen von Fehler und automatisch neu konfigurieren, um das System mithilfe eines Abstimmungsschemas zu umgehen. Dies wird mit komplexen Computersystemen verwendet, die verknüpft sind. Internet Routing wird von frühen Arbeiten von Birman und Joseph in diesem Bereich abgeleitet.[14] Aktive Redundanz kann komplexere Fehlermodi in ein System einführen, wie z. B. eine kontinuierliche Systemrekonfiguration aufgrund fehlerhafter Abstimmungslogik.

Zero -Ausfallsystemdesign bedeutet, dass Modellierung und Simulation angezeigt werden Zwischenzeit zwischen Fehlern überschreitet den Zeitraum zwischen den Zeitraum zwischen erheblich geplante Wartung, Aktualisierung Ereignisse oder Systemlebensdauer. Zero -Ausfallzeit beinhaltet eine massive Redundanz, die für einige Flugzeugtypen und für die meisten Arten von benötigt wird Kommunikationssatelliten. Global Positioning System ist ein Beispiel für ein Nullausfallsystem.

Fehler Instrumentierung Kann in Systemen mit begrenzter Redundanz verwendet werden, um eine hohe Verfügbarkeit zu erreichen. Wartungsaktionen treten in kurzen Zeiträumen der Ausfallzeit erst auf, nachdem ein Fehlerindikator aktiviert ist. Das Versagen ist nur signifikant, wenn dies während a auftritt missionkritisch Zeitraum.

Modellierung und Simulation wird verwendet, um die theoretische Zuverlässigkeit für große Systeme zu bewerten. Das Ergebnis dieser Art von Modell wird verwendet, um verschiedene Designoptionen zu bewerten. Ein Modell des gesamten Systems wird erstellt und das Modell wird durch Entfernen von Komponenten betont. Redundanzsimulation umfasst die N-X-Kriterien. N repräsentiert die Gesamtzahl der Komponenten im System. x ist die Anzahl der Komponenten, die zur Spannung des Systems verwendet werden. N-1 bedeutet, dass das Modell durch Bewertung der Leistung mit allen möglichen Kombinationen betont wird, in denen eine Komponente fehlerhaft ist. N-2 bedeutet, dass das Modell durch Bewertung der Leistung mit allen möglichen Kombinationen betont wird, bei denen zwei Komponenten gleichzeitig fehlerhaft sind.

Gründe für Nichtverfügbarkeit

Eine Umfrage unter Experten der akademischen Verfügbarkeit im Jahr 2010 belegte die Gründe für die Nichtverfügbarkeit von Unternehmenssystemen. Alle Gründe beziehen sich auf Best Practice nicht folgen In jedem der folgenden Bereiche (in der Reihenfolge von Bedeutung):[15]

  1. Überwachung der relevanten Komponenten
  2. Anforderungen und Beschaffung
  3. Operationen
  4. Vermeidung von Netzwerkfehlern
  5. Vermeidung interner Anwendungsfehler
  6. Vermeidung von externen Diensten, die scheitern
  7. Physische Umgebung
  8. Netzwerkreduktion
  9. Technische Lösung des Backups
  10. Prozesslösung von Backup
  11. Physischer Standort
  12. Infrastrukturablehre
  13. Aufbewahrungsarchitektur Redundanz

Ein Buch über die Faktoren selbst wurde 2003 veröffentlicht.[16]

Kosten der Nichtverfügbarkeit

In einem Bericht von 1998 von IBM Global ServicesEs wurde geschätzt, dass nicht verfügbare Systeme im Jahr 1996 im Jahr 1996 kürzlich amerikanische Unternehmen kosteten.[17]

Siehe auch

Anmerkungen

  1. ^ Verwendung von 365,25 Tagen pro Jahr. Für die Konsistenz werden alle Zeiten auf zwei Dezimalstellen gerundet.
  2. ^ Sehen Mathematische Zufälle in Bezug auf Basis 2 Einzelheiten zu dieser Näherung.
  3. ^ "Doppelt so viel" auf einer logarithmischen Skala, was bedeutet zwei Faktoren von 2:

Verweise

  1. ^ Floyd Piedad, Michael Hawkins (2001). Hohe Verfügbarkeit: Design, Techniken und Prozesse. Prentice Hall. ISBN 9780130962881.
  2. ^ Vorlesungsnotizen M. Nesterenko, Kent State University
  3. ^ Einführung in den neuen Mainframe: Großes kommerzielles Computing Kapitel 5 Verfügbarkeit IBM (2006)
  4. ^ IBM Zenterprise EC12 Business Value Video bei youtube.com
  5. ^ Edelmetalle, Band 4. Pergamon Press. 1981. p.Seite 262. ISBN 9780080253695.
  6. ^ PVD für die Mikroelektronik: Sputterversicherung zum Semiconductor Manufacturing. 1998. p.387.
  7. ^ Murphy, Niall Richard; Beyer, Betsy; Petoff, Jennifer; Jones, Chris (2016). Site Zuverlässigkeitstechnik: Wie Google Produktionssysteme ausführt. p.38.
  8. ^ Josh DePrez (23. April 2016). "Nines of Nines". Archiviert von das Original am 4. September 2016. Abgerufen 31. Mai, 2016.
  9. ^ Evan L. Marcus, Der Mythos der Neunen
  10. ^ Newman, David; Snyder, Joel; Thayer, Rodney (24. Juni 2012). "Weinen Wolf: Fehlalarme verbergen Angriffe". Netzwerkwelt. Vol. 19, nein. 25. p. 60. Abgerufen 15. März, 2019. Dies führt zu Unfällen und Betriebszahlen näher an neun Fünfen als zu fünf Neunen.
  11. ^ Metcalfe, Bob (2. April 2001). "Nach 35 Jahren Technologie -Kreuzzüge reitet Bob Metcalfe in den Sonnenuntergang.". Itworld. Abgerufen 15. März, 2019. und fünf Neunen (nicht neun Fünfe) Zuverlässigkeit
  12. ^ Pilgrim, Jim (20. Oktober 2010). "Auf Wiedersehen fünf 9s". Clearfield, Inc. Abgerufen 15. März, 2019. Aber es scheint mir, dass wir uns in Netzwerkzuverlässigkeit anstelle von 5-9 näher an 9-5s (55,5555555%) nähern
  13. ^ "Top -sieben Überlegungen zum Konfigurationsmanagement für virtuelle und Cloud -Infrastrukturen". Gärtner. 27. Oktober 2010. Abgerufen 13. Oktober, 2013.[Dead Link]
  14. ^ RFC 992
  15. ^ Ulrik Franke, Pontus Johnson, Johan König, Liv Marcks von Würtemberg: Verfügbarkeit von IT-Systemen für Unternehmen-ein fachmännisches Bayes'sche Modell, Proc. Viertes internationales Workshop zur Softwarequalität und -wartbarkeit (WSQM 2010), Madrid, [1] Archiviert 4. August 2012 bei Archive.Today
  16. ^ Marcus, Evan; Stern, Hal (2003). Blaupausen für hohe Verfügbarkeit (Zweite Ausgabe). Indianapolis, IN: John Wiley & Sons. ISBN 0-471-43026-9.
  17. ^ IBM Global Services, Verbesserung der Systemverfügbarkeit, IBM Global Services, 1998, [2]

Externe Links