Hochverfügbarkeit und Ausfallsicherheit (Webserver)

= 1. Allgemein =

Damit z.B. ein Webserver und somit der Webauftritt den bestmöglichen Ausfallsicherheit und Scutz hat, ist es von Vorteil sämtliche Dienste und Anwendungen in einem Cluster auf mehreren Servern redundant bereitzustellen. Sollte es zu einem Ausfall kommen, wird dieser automatisch vom System erkannt und innerhalb von Sekunden behoben. Gleichzeitig werden die Dienste automatisch von einem anderen Server im Cluster übernommen. Um dies zu bewerkstelligen wird auch auf Web-Hoster, also externe bzw. sogar verteilte Systeme zurückgegriffen. Bezogen auf gesamte IT-Infrastrukturen bedeutet dies, dass sowohl Netzwerkdienste als auch Ressourcen( Server, Software) für die Nutzenden praktisch jederzeit erreichbar und uneingeschränkt nutzbar sind. Dies gilt unabhängig von geplanten Wartungsarbeiten und möglichen Störungen.

Die Definintion von Hochverfügbarkeit seitens der IEEE **) lautet : “High Availability (HA for short) refers to the availability of resources in a computer system, in the wake of component failures in the system.”  

**) Institute of Electrical and Electronics Engineers

1.1. Definition Hochverfügbarkeit

Hochverfügbarkeit (High Availability, kurz HA) bezieht sich auf die Verfügbarkeit von Ressourcen in einem Computersystem nach dem Ausfall von Komponenten im System. Dies kann auf unterschiedliche Weise erreicht werden, wobei das gesamte Spektrum von Lösungen, die kundenspezifische und redundante Hardware verwenden, um die Verfügbarkeit zu gewährleisten, bis hin zu Lösungen reicht, die Softwarelösungen unter Verwendung von Standard-Hardwarekomponenten anbieten. Die erstgenannten Lösungen bieten ein höheres Maß an Verfügbarkeit, sind aber deutlich teurer als die letztgenannten. Dies hat dazu geführt, dass die letztere Klasse immer beliebter wird, da fast alle Hersteller von Computersystemen verschiedene HA-Produkte anbieten. In der Regel überleben diese Produkte einzelne Fehlerpunkte im System,

1.1.1 Abgrenzung

Nachstehend eine Auflistung und Kurzbestreibung verwandter Terminologien aus sicht der IEEE [15]

Kontinuierliche Verfügbarkeit:

Dies bedeutet, dass der Dienst ohne Unterbrechung und ohne zeitliche Unterbrechung zur Verfügung steht. Dies stellt einen idealen Zustand dar und wird im Allgemeinen verwendet, um ein hohes Verfügbarkeitsniveau zu bezeichnen, bei dem nur eine sehr geringe Menge an Ausfallzeiten zulässig ist. Hochverfügbarkeit bedeutet nicht ständige Erreichbarkeit.

Fehlertoleranz:

Dies ist ein Mittel, um ein sehr hohes Maß an Verfügbarkeit zu erreichen. Ein fehlertolerantes System ist in der Lage, den Betrieb trotz eines Hardware- oder Softwarefehlers fortzusetzen, und zeichnet sich durch Redundanz in der Hardware aus, einschließlich CPU, Speicher und I/0-Subsysteme. Hohe Verfügbarkeit ist nicht gleichbedeutend mit Fehlertoleranz.

Single Point of Failure (SPOF):

Eine Hardware- oder Softwarekomponente, deren Ausfall den Verlust des Dienstes zur Folge hat; solche Komponenten sind nicht durch redundante Komponenten abgesichert.

Ausfallsicherung (fail over):

Wenn eine Komponente in einem HA-System ausfällt und dies zu einem Dienstverlust führt, wird der Dienst durch das HA-System auf einer anderen Komponente im System gestartet. Diese Übertragung eines Dienstes nach einem Ausfall im System wird als Failover bezeichnet.

1.1.2 Ungeplante Betriebsunterbrechungen

Ungeplante Betriebsunterbrecungen  können nach folgenden Ursachen klassifiziert werden:

a) Benutzerfehler: Sind wahrscheinlich die häufigste Ursache ungeplanter Betriebsunterbrechungen. Vorgehensweisen werden nicht ordnungsgemäß eingehalten, Warnungen werden missachtet, möglicherweise fehlt es an der richtigen Ausbildung, oder es gibt ganz einfach Kommunikationsprobleme

    und Missverständnisse zwischen Benutzergruppen. Dies alles kann zu ungeplanten Betriebsunterbrechungen führen, die Auswirkungen auf den Geschäftsbetrieb haben.
b) Softwareprobleme: Komplexe Anwendungs-, Betriebssystem-, Middleware- oder Datenbankabläufe können zu ungeplanten Betriebsunterbrechungen führen. Jeder Geschäftsbetrieb ist anders strukturiert, und Interaktionsprobleme zwischen verschiedenen Softwarekomponenten können Probleme

    verursachen.
c) Hardwarefehler:Mechanische Einheiten fallen irgendwann aus. Elektrische Bauteile sind Umgebungseinflüssen wie Hitze, Feuchtigkeit und elektrostatischer Entladung ausgesetzt, was zum vorzeitigen Ausfall führen kann. Kabel können beschädigt und Verbindungen getrennt werden.
d) Umgebungsbedingte Einflüsse: Stromausfälle, Netzausfälle und Klimatisierung können dazu führen, dass ein einzelnes System ausfällt. Es können redundante Messungen durchgeführt werden, um einige dieser Einflüsse zu 

    verringern, aber die Möglichkeiten sind begrenzt.

1.2 Berechnungen

Als Verfügbarkeit wird jenee Wahrscheinlichkeit bezeichnet, wo das System bzw, die geramte IT-Infrastruktur  innerhalb eines spezifizierten Zeitraums (hoch)verfügbar ist. Als Verfügbarkeit gilt das Verhältnis aus ungeplanten/fehlerbedingter Ausfallzeit und gesamter Produktionszeit eines Systems

Als Berechnung dafür kann folgende Formel heran gezogen werden:

                   

          [99]

Ein IT-System oder eine System-Komponente gilt ab 99,9 %  bzw. nach AEC-2 als „hochverfügbar“ (siehe Pkt. 1.2.1).

1.2.1 Klassifikation

Die HRG, also die Harvard research Grout  teilt Hochverfügbarkeit in ihrer Availability Environment Classification (AEC) 0-5 in 6 Klassen [14] ein:

HRG-Klasse	Bezeichnung	Erklärung
AEC-0	Conventional	Funktion kann unterbrochen werden, Datenintegrität ist nicht essentiell.
AEC-1	Highly Reliable	Funktion kann unterbrochen werden, Datenintegrität muss jedoch gewährleistet sein.
AEC-2	High Availability	Funktion darf nur innerhalb festgelegter Zeiten oder zur Hauptbetriebszeit minimal unterbrochen werden.
AEC-3	Fault Resilient	Funktion muss innerhalb festgelegter Zeiten oder während der Hauptbetriebszeit ununterbrochen aufrechterhalten werden.
AEC-4	Fault Tolerant	Funktion muss ununterbrochen aufrechterhalten werden, 24*7-Betrieb (24 Stunden, 7 Tage die Woche) muss gewährleistet sein.
AEC-5	Disaster Tolerant	Funktion muss unter allen Umständen verfügbar sein.

In der Praxis werden SLA 's, also die Vereinbarung, zwischen einem Dienstleistungsunternehmen und einem Kunden getroffen, in der alle zu erbringenden Dienstleistungen sowie die Kunden- und Kommunikationserwartungen und Erfolgskennzahlen, also die Verfügbarkeit in % festgelegt sind.

1.3 Skalierung versus Verfügbarkeit

=== 1.3.1 Vertikale Skalierung ===

Das bedeutet man vergrößert z.B. die Rechenleistung bzw. fügt Ressourcen hinzu, ohne die Verfügbarkeit oder Betriebszeit zu erhöhen.  Angenommen, es mögen mehr Benutzer, mehr Datenverkehr und mehr Last für die Webanwendung zur Verfügung gestellt werden. D.h. es könnten auch alle Daten von einem einzelnen kleinen Server auf einen größeren Server mit mehr Arbeitsspeicher, mehr CPUs und schnellerem Speicherplatz kopiert werden.  Hinsichtlich virtueller Server diesen anhalten, ihm mehr Ressourcen zuweisen und ihn wieder starten.  Läuft der Server in der Cloud einfach den Instance-Typ zu einem mit mehr Ressourcen ändern. Dies nennt man vertikale Skalierung oder Skalierung nach oben. 

=== 1.3.2 Horizontale Skalierung ===

Eine andere Möglichkeit der Skalierung besteht darin, weitere Server hinzuzufügen, die manchmal auch als Knoten bezeichnet werden.  Dies wird als horizontale Skalierung oder Skalierung nach außen bezeichnet. Für eine horizontale Skalierung müssen im Vorfeld ein wenig Arbeit geleistet werden um ein entsprechendes Design zu entwickeln.  Wenn z.B.  von einem Webserver auf zwei Webserver umstiegen wird muss eine Möglichkeit gefunden werden, um den Datenverkehr an den zusätzlichen Knoten zu leiten und die Last vorzugsweise auf die beiden Server zu verteilen, detto  einen dritten oder vierten Server.  Da nun mehrere Server zur Verfügung stehen, welche die dieselbe Funktion erfüllen, und einer von ihnen ausfällt, ist der Dienst im schlimmsten Fall beeinträchtigt.

=== 1.3.3 High Availability ===

Die Hochverfügbarkeit bezieht sich ja auf die Fähigkeit eines Systems, einen unterbrechungsfreien Betrieb und Zugriff zu gewährleisten und Hauptmerkmale sind Minimierung von Ausfallzeiten, Redundanz zur Bewältigung von Hardwareausfällen sowie Mechanismen zur Fehlertoleranz.

In Bezug auf einen Webserver bedeutet dies, ein hochverfügbarer Webdienst stellt durch Load Balancing und redundante Server sicher, dass diser auch bei Serverausfällen erreichbar bleibt. Kleinere Websites, die auf einfachen Strukturen aufbauen und keine ausufernde Seitenzahl aufweisen kommen ohne Datenbank aus, aber sobald es ein Content Management System(CMS) oder Learn Management System(LMS) handelt ist einDatenbankmanagementsystem(DBMS) involviert. Auch dieses benötigt einen hohen Durchsatz bezogen auf das Daten- oder Transaktionsvolumen, welches das System innerhalb eines bestimmten Zeitraums verarbeiten kann. Die Effizienz der Datenübertragung durch das System, wird durch optimierte Datenverarbeitung, minimierte Latenzzeit bei der Datenübertragung.und effiziente Nutzung der Systemressourcen sichergestellt.

Zusammenfassend bedeutet das:

• Bei der Hochverfügbarkeit liegt der Schwerpunkt auf der Minimierung von Ausfallzeiten und der Gewährleistung der ständigen Erreichbarkeit.
• Hohe Skalierbarkeit bezieht sich auf die Fähigkeit eines Systems, eine erhöhte Last durch zusätzliche Ressourcen zu bewältigen.
• Hoher Durchsatz misst die Effizienz der Datenübertragung durch ein System

==== 1.3.3.1 Hochverfügbarkeit von Daten ====

Die Hochverfügbarkeit von Daten wird durch eine Datensicherung gewährleistet, die eine strukturierte,regelmäßige Sicherung der Daten im Regelbetrieb und eine mögliche Wiederherstellung der Daten nach eingetretenem Verlust (z. B. nach einem Web-Serverausfall) vorsieht.

Zur gesamtheitlichen Betrachtung der Datensicherung im Sinne einer Hochverfügbarkeit müssen folgende Schritte berücksichtigt werden: [21]

• die Datensicherungs- und Wiederherstellungsstrategie muss konzipiert und definiert werden,
• für deren Umsetzung ein entsprechender operativer Prozess entwickelt, dokumentiert und gelebt werden,
• die Technologie zur Datensicherung spezifiziert, ausgewählt, beschafft und betriebsbereit sein
• die zuständigen Mitarbeiter die erforderliche Expertise hinsichtlich der Technologie haben, fachlich fortgebildet werden und Kenntnis über den Datensicherungs bzw. Wiederherstellungsprozess besitzen.

2. Implementierung von Hochverfügbarkeitslösungen und Failover-Strategien

Der primäre Mechanismus zur Aufrechterhaltung einer hohen Systemverfügbarkeit wird als Failover bezeichnet. Bei diesem Ansatz wird ein ausgefallenes Primärsystem durch ein Backup-System ersetzt, d. h. die Verarbeitung wird auf das Backup-System verlagert. Viele HA-Konfigurationen bieten auch Mechanismen für Disaster Recovery, d. h. die Wiederherstellung der Systemverfügbarkeit, wenn die Failover-Mechanismen nicht in der Lage waren, das System verfügbar zu halten.

Wenn jedoch keine Failover-Strategie vorhanden ist, kann ein Ausfall zu erheblichen Ausfallzeiten führen, je nach Ursache des Ausfalls und Ihrer Fähigkeit, diesen zu isolieren und zu beheben. Für viele Anwendungen, die nicht geschäftskritisch sind, kann dieses Risiko akzeptabel sein.

2.1. Hochverfügbarkeit und Failover

Hochverfügbarkeit und Failover sind entscheidende Konzepte für Unternehmen, die darauf angewiesen sind, dass die Softwaresysteme unterbrechungsfrei und zuverlässig laufen.

Hochverfügbarkeit ist der  kontinuierlichen Betrieb eines Systems mit minimalsten Ausfallzeiten, selbst bei unerwarteten Ereignissen oder Ausfällen.

Failover ist der Wechsels zu einem Backup-System, wenn das Primärsystem aufgrund eines Fehlers, einer Wartung oder eines anderen Ereignisses, das eine Unterbrechung verursacht hat, nicht verfügbar ist.

2.2. Failover-Cluster

Ein gängiger Ansatz zur Erreichung von HA ist der Failover-Cluster, bei dem das primäre Produktionssystem durch ein (in der Regel identisches) Standby-System mit gemeinsamem Speicher und einer Cluster-IP-Adresse, die dem aktiven Mitglied folgt, ergänzt wird. Im Falle eines Ausfalls des Produktionssystems übernimmt das Standby-System die Arbeitslast der Produktion und übernimmt die Programme und Dienste, die zuvor auf dem ausgefallenen Primärsystem liefen. Damit der Failover automatisiert und ohne Eingriff eines Administrators erfolgen kann, ist der Einsatz einer Cluster-Manager-Software oder eines Loadbalancers erforderlich. Weiterer Vorteil eines Failover-Clusters ist die Möglichkeit, ein System zu Wartungszwecken bewusst außer Betrieb nehmen zu können. Der Standby-Server muss für die Dauer der Wiederherstellung des ausgefallenen Primärsystems in der Lage sein, die normale Produktionsauslastung zu bewältigen. Optional kann der Standby-Server zum Primärserver werden, wobei der ausgefallene Primärserver zum Standby-Server wird, sobald er wiederhergestellt ist.

2.3. Cluster mit zwei Knoten

Um die HA-Cluster-Technologie einsetzen zu können, muss die Anwendung folgende Voraussetzungen erfüllen:[21]

Es muss eine relativ einfache Möglichkeit geben, die Anwendung zu starten, zu stoppen, den Stopp zu erzwingen und den Status der Anwendung zu überprüfen

Die Anwendung muss in der Lage sein, gemeinsam genutzte Speicher wie NAS/SAN zu nutzen.

Die Anwendung muss so viel wie möglich von ihrem Zustand auf einem permanenten gemeinsamen Speicher speichern

Es muss möglich sein, die Anwendung auf einem anderen Knoten mit dem letzten Zustand vor dem Ausfall neu zu starten, indem der gespeicherte Zustand aus dem gemeinsamen Speicher verwendet wird.

Die Anwendung darf im Falle eines Absturzes keine Daten beschädigen oder vom gespeicherten Zustand neu starten.

Anmerkung: iv u. v sind nicht immer leicht zu realisieren

Hochverfügbarkeits-Cluster (HA-Cluster), auch als Failover-Cluster bekannt, sind Gruppen von Computern, die Serveranwendungen unterstützen, die mit einem Minimum an Nichtverfügbarkeit zuverlässig genutzt werden können.  Das Prinzip besteht darin, redundante Computer in Gruppen oder Clustern zusammenzufassen, die einen kontinuierlichen Service bieten. Wenn es kein Clustering gibt und ein Server, auf dem eine bestimmte Anwendung läuft, abstürzt, ist die Anwendung nicht verfügbar, bis der abgestürzte Server repariert ist. HA-Clustering beseitigt diese Situation, indem Hardware-/Softwarefehler erkannt werden und die Anwendung sofort auf einem anderen System neu gestartet wird, ohne dass ein administrativer Eingriff erforderlich ist. Als Teil dieses Prozesses kann die Clustering-Software den Knoten konfigurieren, bevor die Anwendung auf ihm gestartet wird. HA-Cluster werden häufig für kritische Datenbanken verwendet.

HA-Cluster-Implementierungen versuchen, Redundanz in einen Cluster einzubauen, um einzelne Ausfallpunkte zu eliminieren, einschließlich mehrerer Netzwerkverbindungen und Datenspeicherung, die redundant über Storage Area Networks (SAN) erfolgt. HA-Cluster verwenden eine private Heartbeatverbindung (so nennt man  eine Netzwerkverbindung zwischen zwei (oder mehr) Rechnern in einem Cluster,)die zur Überwachung der Gesundheit und des Status jedes Knotens im Cluster verwendet wird.

.

Cluster-Konfigurationen können in folgende Kategorien eingeteilt werden:[21]

• Aktiv/aktiv

  Der für den ausgefallenen Knoten bestimmte Datenverkehr wird entweder an einen vorhandenen Knoten weitergeleitet oder die Last auf die verbleibenden Knoten verteilt. Dies ist normalerweise nur möglich, wenn die Knoten eine homogene Softwarekonfiguration verwenden.

• Aktiv/passiv

  Stellt eine vollständig redundante Instanz jedes Knotens bereit, die nur dann online geschaltet wird, wenn der zugehörige primäre Knoten ausfällt Diese Konfiguration erfordert normalerweise die meiste zusätzliche Hardware.

• N+1

  Stellt einen einzelnen zusätzlichen Knoten bereit, der online geschaltet wird, um die Rolle des ausgefallenen Knotens zu übernehmen. Im Fall einer heterogenen Softwarekonfiguration auf jedem primären Knoten muss der zusätzliche Knoten universell in der Lage sein, alle Rollen der primären Knoten zu übernehmen, für die er verantwortlich ist. Dies bezieht sich normalerweise auf Cluster, auf denen mehrere Dienste gleichzeitig ausgeführt werden; im Fall eines einzelnen Dienstes degeneriert dies zu aktiv/passiv.

• N+M

  In Fällen, in denen ein einzelner Cluster viele Dienste verwaltet, bietet ein einziger dedizierter Failover-Knoten möglicherweise nicht genügend Redundanz. In solchen Fällen sind mehr als ein (M) Standby-Server enthalten und verfügbar. Die Anzahl der Standby-Server ist ein Kompromiss zwischen Kosten und Zuverlässigkeitsanforderungen.

• N-zu-1

  Ermöglicht, dass der Failover-Standby-Knoten vorübergehend zum aktiven Knoten wird, bis der ursprüngliche Knoten wiederhergestellt oder wieder online gebracht werden kann. An diesem Punkt muss ein Failover der Dienste oder Instanzen auf ihn durchgeführt werden, um die Hochverfügbarkeit wiederherzustellen.

• N-zu-N –

  Eine Kombination aus Aktiv/Aktiv- und N+M-Clustern. N-zu-N-Cluster verteilen die Dienste, Instanzen oder Verbindungen des ausgefallenen Knotens auf die verbleibenden aktiven Knoten. Dadurch entfällt (wie bei Aktiv/Aktiv) die Notwendigkeit eines Standby-Knotens, allerdings entsteht auf allen aktiven Knoten ein Bedarf an zusätzlicher Kapazität.

= 3. Überwachung und Automatisierung zur schnellen Wiederherstellung von Diensten =

Überwachungs- und Protokollierungsfunktionen zur Erkennung von und Reaktion auf Sicherheitsvorfälle sein unerlässlich. Die Echtzeitüberwachung von Verkehrsmustern, Serverprotokollen und Sicherheitsereignissen ermöglicht eine schnelle Identifizierung verdächtiger Aktivitäten. Die Analyse von Protokolldaten hilft bei der Untersuchung von Vorfällen, der Forensik und bei proaktiven Sicherheitsmaßnahme.

Wichtig ist der Aufbau und Verwaltung eines robusten Disaster-Recovery-Systems (DR), das Verfügbarkeit und Leistung innerhalb der gewünschten Durchlaufzeiten bietet. Die Automatisierung der wichtigsten DR-Prozesse - einschließlich Replikation, Workflows und Failover-reduziert Betriebsrisiken drastisch und erhöht die Effizienz, während erweiterte Dashboards und die rechtzeitige Verfügbarkeit sensibler Daten helfen, das Recovery Point (RPO) und die Wiederherstellungszeit (RTO) zu verbessern.

== 3.1. Monitoring ==

Monitoring von z.B. Servern und Diensten sind in einer modernen IT-Infrastruktur unerlässlich. Modernes Netzwerkmanagement ist der Prozess der Verwaltung und des Managements von Computernetzwerken . Bereitgestellte Diensten, Fehleranalyse, Leistungsmanagement sowie Aufrechterhaltung der Servicequalität sind die Aufgaben . Netzwerkadmin bedienen sich dafür einer Netzwerkmanagementsoftware, um diese Aufgaben zu bewerkstelligen.

Mit dieser Funktion kann die Netzwerkverwaltungssoftware das Netzwerk auf Probleme überwachen und Verbesserungsvorschläge machen. Die Software kann die Geräte regelmäßig abfragen oder sich selbst registrieren, um Warnmeldungen von Netzwerkgeräten zu erhalten. Ein Mechanismus, mit dem Netzwerkgeräte freiwillig Informationen über sich selbst weitergeben, ist das Senden eines SNMP-Trap [19]**).Die Überwachung deckt Fehler im Netz auf, z. B. ausgefallene oder falsch konfigurierte Knoten, Leistungsengpässe, böswillige Akteure, Eindringlinge usw.

**) Simple Network Management Protocol zum Sammeln und Organisieren von Informationen über verwaltete Geräte in IP-Netzwerken und zum Ändern dieser Informationen, um das Geräteverhalten(Dienste) zu ändern.

Networkmanagement u. Monitoringsysteme:

• Zabbix
• Nagios
• PRTG
• Icinga
• uvm.

=== 3.2.1 Recovery Point Objective ===

Recovery Point Objective (RPO) ist der maximal akzeptable Datenverlust nach einem ungeplanten Datenverlustvorfall, ausgedrückt als Zeitdauer. Dies wird im Allgemeinen als der Zeitpunkt vor dem Ereignis angesehen, zu dem Daten erfolgreich wiederhergestellt werden können – also die Zeit, die seit der letzten zuverlässigen Sicherung vergangen ist.

=== 3.2.2 Recovery Time Objective ===

Recovery Time Objective (RTO) ist die maximal akzeptable Zeitspanne für die Wiederherstellung eines Netzwerks oder einer Anwendung und die Wiedererlangung des Datenzugriffs nach einer ungeplanten Unterbrechung. Umsatzeinbußen und das Ausmaß, in dem ein unterbrochener Prozess die Geschäftskontinuität beeinträchtigt, können sich beide auf das RTO auswirken.

=== 3.2.3  Recovery as a Service ===

Recovery as a Service ( RaaS ), [1] seltener auch Disaster Recovery as a Service ( DRaaS ) genannt, ist eine Möglichkeit , Anwendungen und Dienste via Cloud-Computing zu schützen. Dabei unterscheidet sich RaaS von Cloud-basierten Backup-Diensten, indem es Daten schützt und bei Bedarf Standby-Rechenkapazität bereitstellt, um eine schnellere Wiederherstellung von Diensten und Anwendungen zu ermöglichen.   Je nach Art des Geschäfts und des betreffenden Prozesses oder Systems kann dieser Zeitraum stark variieren.

=== 3.2.4 Online-Backup ===

Cloud-Backup, auch Online-Backup oder Remote-Backup genannt , ist eine Strategie zum Senden einer Kopie einer physischen oder virtuellen Datei oder Datenbank an einen sekundären, externen Standort zur Sicherung im Falle eines Geräteausfalls.

=== 3.2.5. Planung – Automatisiertes Recovery ===

Hinsichtlich einer Automatisierung für ein Back-up und Disaster Recovery, sind Voraussetzungen und Strategien zu treffen. Die Sicherungsintervalle sind u. a. abhängig von der Risikobewertung eines Datenverlustes. Eine Beschreibung des Wiederanlaufs sollte vorhanden sein, die neben anderen Anforderungen eine regelmäßige Datensicherung und Auslagerung an einen sicheren Ort beinhaltet, alle relevanten Daten umfasst sowie Verfahren für reguläre und protokollierte Tests enthält.[20]

== 3.2 Recovery ==

Die Recovery befasst sich mit dem Wiederherstellen von Daten nach aufgetretenen schweren Fehlern. Diese Fehler lassen sich grob in zwei Klassen einteilen, in Hardware- und Softwarefehler.

Hardware Fehler: Stromausfall, Wackelkontakte, Festplattenausfall, Arbeitsspeicherausfall, Netzausfall, Brand sowie Feuer und Löschwasser.

Software Fehler: Fehler z.B. in der Datenbanksoftware, im Betriebssystem, im Anwendungsprogramm, in der Übertragungssoftware Eine gewisse Vorsorge wird ein Datenbankadministrator dadurch treffen, dass er die Hard- und Software auch nach dem Gesichtspunkt der Zuverlässigkeit auswählt. Dies minimiert die Ausfallrate, ganz verhindert wird sie dadurch jedoch nicht. Die grundsätzliche Forderung im Fehlerfall ist, dass keine Daten verlorengehen, dass eine Rekonstruktion aller Daten also immer möglich ist, und dass dabei die Datenbank-Integrität und -Konsistenz erhalten bleibt.

Prinzipiell wird daher ein Administrator mehrstufig vorgehen: Er wird mindestens einmal pro Woche eine Komplettsicherung und täglich eine Differenzsicherung des Datenbestandes vornehmen. Weiter werden alle Änderungen in der Datenbank protokolliert. Dieses „elektronische Logbuch“ heißt Logdatei oder Logfile.

== 3.3 Verteilte Systeme(Datenbanken) ==

Der Hauptgrund für die Verteilung liegt in der schnellen Verfügbarkeit. Daten ausschließlich zentral zu halten, kann bei extrem vielen Zugriffen schnell zum Engpass werden. Weltweit operierende Unternehmen sind ebenfalls dezentral aufgebaut. Es existieren meist mehrere Fabriken, Werke oder Zweigstellen. Aber auch bei kleineren Firmen gibt es Unternehmensbereiche, Abteilungen oder zumindest verschiedene Projekte. Daraus folgt direkt, dass bereits die anfallenden Daten verteilt sind. Es ist quasi ein Schritt zurück, diese verteilten Daten zentral zusammenzufassen. Und wir fragen uns, ob dies im Zeitalter der Vernetzung überhaupt noch notwendig ist. Ein wichtiger Vorteil dezentraler Datenhaltung liegt darin, dass häufig lokal zugegriffen wird.

Ein weiterer Vorteil der Verteilung von Daten liegt in der Ausfallsicherheit. Setzen wir voraus, dass das verteilte System keinen zentralen Server besitzt, so wird der Ausfall eines beliebigen Rechners das Netz nicht vollständig lahmlegen. Im Gegenteil, bis auf die Daten des einen Rechners bleiben alle weiteren zugreifbar. Damit wird eine hohe Ausfallsicherheit garantiert. Hier liegt andererseits die Achillesferse zentraler Systeme. Der Ausfall des zentralen Datenbankservers legt das gesamte System lahm. Ein weiterer Vorteil liegt in der optimalen Verteilung auf hunderte von Systemen. So können tausende parallele Abfragen auf verschiedene Rechner und Datenbanken gelenkt werden. Die Antwortzeiten bleiben niedrig.

Wird in diesen Systemen auch viel geändert, so ist es äußerst schwer, die über alle Systeme verteilten Daten konsistent zu halten. Dieser enorm hohe Kommunikationsaufwand führt dazu, dass sich die Vor- und Nachteile letztendlich gegenseitig aufheben. [19]

3.4 Wiederherstellung im Notfall

Um Hochverfügbarkeit sicher zu stellen ist ein Disaster Recovery-Plan auch notwenig. Dieser bezieht sich auf einen strukturierten, dokumentierten Ansatz mit Anweisungen zur Reaktion auf ungeplante Vorfälle.

• Virtualisiertes DRP: Mit der Virtualisierung kann DR auf effiziente und unkomplizierte Weise implementiert werden. In einer virtualisierten Umgebung können sofort neue Instanzen von virtuellen Maschinen (VMs) erstellt und die Wiederherstellung von Anwendungen mit hoher Verfügbarkeit bereitstellen. Darüber hinaus erleichtert es das Testen. Der Plan muss Validierungsfunktionen enthalten, um sicherzustellen, dass Anwendungen im DR-Modus schneller ausgeführt werden und innerhalb von RTO und RPO zum normalen Betrieb zurückkehren können.
• Netzwerk-DRP: Die Erstellung eines Plans zur Wiederherstellung eines Netzwerks wird durch die zunehmende Komplexität des Netzwerks kompliziert. Ergo ist es wichtig, das Wiederherstellungsverfahren Schritt für Schritt detailliert zu beschreiben, es korrekt zu testen und es auf dem neuesten Stand zu halten. Unter einem Netzwerk-DRP sind Daten netzwerkspezifisch. Zum Beispiel in Bezug auf Leistung und Netzwerk.
• Cloud DRP: Ein Cloud basierter Ansatz kann von der Dateisicherung/Datensicherung bis zum vollständigen Replikationsprozess reichen. Cloud DRP ist zeit-, raum- und kosteneffizient. Die Wartung erfordert jedoch Geschicklichkeit und ordnungsgemäße Verwaltung. Der Administrator muss den Standort des physischen und des virtuellen Servers kennen. Außerdem muss der Plan auch Sicherheitsprobleme hinsichtlich der Cloud berücksichtigen.
• DRP für Rechenzentren: Dieser Plan konzentriert sich auf die Rechenzentrumsanlage und deren Infrastruktur. Ein Schlüsselelement in dieser DRP ist eine Bewertung des operationellen Risikos, da dies die erforderlichen Schlüsselkomponenten wie Gebäudestandort, Sicherheit, Büroräume sowie Stromversorgungssysteme und Schutz analysiert. Es muss sich auch mit einem breiteren Spektrum möglicher Szenarien befassen.

   [23]

4 Tools

Administratoren bedienen sich mehrerer Möglichkeiten um eine rasche Wiederherstellung von Diensten und Geräten zu ermöglichen. Eine Möglichkeit sind zugekaufte Tools, welche die sämtliche Komponenten komplexer Umgebungen koordinieren und ordnungsgemäß herunterfahren können. In dessen Konfiguration sind alle Systeme (Virtualisierungshosts, SAN-Systeme etc.) hinterlegt, die in der grafischen Benutzeroberfläche zu Ausführungsplänen kombiniert werden können.

Eine weitere Möglichkeit ist selbst entwickelte Skripts und Applikationen.