Hochverfügbarkeit von Servern anhand eines kritischen Dienstes
Aus Winfwiki
1 Titel
| Name des Autors / der Autoren: | Philipp Hungerhoff |
| Titel der Arbeit: | "Hochverfügbarkeit von Servern anhand eines kritischen Dienstes" |
| Hochschule und Studienort: | Fachhochschule für Oekonomie & Management - Düsseldorf |
Inhaltsverzeichnis |
2 Abkürzungsverzeichnis
| Abkürzung | Bedeutung |
|---|---|
| AEC | Availability Environment Classification |
| AMD | Advanced Micro Devices |
| DHCP | Dynamic Host Configuration Protocol |
| DNS | Domain Name System |
| HA | High Availability |
| HRG | Harvard Research Group |
| IEEE | Institute of Electrical and Electronics Engineers |
| IP | Internet Protocol |
| LAN | Local Area Network |
| MAC-Adresse | Media Access Control Adresse |
| MTBF | Mean Time Between Failure |
| MTTR | Mean Time to Repair |
| Netware OES | Netware Open Enterprise Server |
| RAID | redundant array of independent disks |
| RFC | Requests for Comments |
| SAN | Dynamic Host Configuration Protocol |
| SCSI | Small Computer System Interface |
| SPOF | Single Point of Failure |
| VM | Virtuelle Maschine |
| V-LAN | Virtual Local Area Network |
3 Abbildungsverzeichnis
4 Tabellenverzeichnis
| Tabelle Nr. | Quelle | Verweis |
|---|---|---|
| 1 | Availability Environment Classification nach der Harvard Research Group | http://winfwiki.wi-fom.de/index.php?title=Hochverfügbarkeit_von_Servern_anhand_eines_kritischen_Dienstes#Grundlagen |
| 2 | Verfügbarkeitsklassen nach der Harvard Research Group | http://winfwiki.wi-fom.de/index.php?title=Hochverfügbarkeit_von_Servern_anhand_eines_kritischen_Dienstes#Grundlagen |
5 Einleitung
Kaum ein Unternehmen ist in der heutigen Zeit in der Lage, seinen Geschäftsbetrieb ohne die Unterstützung von Computern fortzuführen.
Von einfachen Fileservern über E-Mails bis hin zu komplexen Warenwirtschaftssystemen sind viele Unternehmen stark IT-abhängig. Da diese Abhängigkeit zunehmend durch eine immer stärkere Einbeziehung der EDV wächst, ist es für viele Unternehmen von großer Wichtigkeit, dass eine hohe Verfügbarkeit der EDV-Dienste gewährleistet werden kann. Ein Ausfall von unternehmenskritischen Anwendungen, wie zum Beispiel dem Warenwirtschaftssystem, kann ein Unternehmen in seiner Arbeitsfähigkeit sehr stark beeinträchtigen und mitunter das Unternehmen handlungsunfähig machen. Ein längerer Ausfall würde für das Unternehmen einen hohen wirtschaftlichen Schaden bedeuten.
Neutrale Untersuchungen zeigen, dass die Kosten für eine Stunde IT-Stillstand von etwa 25.000 Euro in der Fertigung über 75.000 im Einzelhandel bis zu mehreren Millionen bei der Verarbeitung von Kreditkartendaten reichen können.[2]
Um eine hohe Verfügbarkeit wichtiger EDV-Dienste zu erreichen, gibt es verschiedene technische Möglichkeiten. Diese Hausarbeit soll zwei Möglichkeiten der Hochverfügbarkeit von Servern beschreiben, dabei speziell den HA-Cluster (High Availability Cluster). Zum besseren Verständnis wird im achten Abschnitt ein praktisches Beispiel angeführt.
Dabei ist in dieser Hausarbeit eine Abgrenzung zur Fehlerresistenz zu sehen, welche eine ständige Verfügbarkeit der Systeme gewähren muss; Hochverfügbarkeit hingegen lässt eine gewisse Ausfallzeit zu. Desweiteren ist zu beachten, dass für eine hoch verfügbare Umgebung nicht nur die Server mit Hilfe einer speziellen Technik abgesichert werden müssen. Dies gilt auch für alle weiteren beteiligten Geräte, wie zum Beispiel die Switche oder Storages. Zudem wird vorausgesetzt, dass in einer hoch verfügbaren Umgebung die Storages - zum Beispiel durch ein RAID-System - intern abgesichert sind, auf welches aber nicht näher eingegangen wird.
6 Grundlagen
Die Hochverfügbarkeit eines Systems bedeutet, dass das System auch im Fehlerfall weiter zur Verfügung steht. Dies ermöglicht eine spezielle Technik, die den menschlichen Eingriff in den meisten Fällen überflüssig macht. Doch ensteht so immer eine kurze Ausfallzeit, bis der Fehler erkannt und behoben ist bzw. ein zweiter Server die Ressource übernimmt. Um eine genauere Bestimmung des Bergriffs der Hochverfügbarkeit zu ermöglichen, hat die Harvard Research Group eine Unterteilung in 6 Kategorien vorgenommen, die Availability Environment Classification (kurz: AEC). Zur Bewertung der verschiedenen Verfügbarkeitsstufen wird die Ausfallzeit (Downtime) pro Jahr herangezogen: [3]
| 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. |
| Tabelle 1 |
Die Hochverfügbarkeit (High Availability) fällt also in die Klasse 2 der Harvard Research Group-Klassifizierung. Wobei die Frage ist, was [..] zur Hauptbetriebszeit minimal unterbrochen werden bedeutet, also von welcher Zeitspanne man hier ausgehen kann.
Um die zugelassene Downtime besser beurteilen zu können, zeigt die nachfolgende Tabelle die Stufen der Verfügbarkeit an. Diese gibt an, wie hoch die prozentuale Verfügbarkeit - gemessen auf ein Jahr - für die entsprechende Kategorie sein muss. Anhand dieser lässt sich dann die maximal tolerierte Ausfallzeit ableiten.
Die Stufen der Verfügbarkeit zeigen die Ausfallzeiten, gemessen in Zeiteinheiten pro Jahr:
[5]
| Verfügbarkeitsklassen | Bezeichnung | Verfügbarkeit in Prozent | tolerierte Downtime pro Jahr |
|---|---|---|---|
| 2 | stabil | 99 | 03,7 Tage |
| 3 | verfügbar | 99,9 | 08,8 Stunden |
| 4 | hoch verfügbar | 99,99 | 52,2 Minuten |
| 5 | Fehler unempfindlich | 99,999 | 05,3 Minuten |
| 6 | Fehler tolerant | 99,9999 | 32,0 Sekunden |
| 7 | Fehler resistent | 99,99999 | 03,0 Sekunden |
| Tabelle 2 |
Auch wenn die Availability Environment Classification die Hochverfügbarkeit als Funktion darf nur innerhalb festgelegter Zeiten oder zur Hauptbetriebszeit minimal unterbrochen werden klassifiziert, so zeigt sich, dass eine 99,99% Verfügbarkeit immer noch eine Ausfallzeit von 52,2 Minuten Donwtime pro Jahr erlaubt. Ein Unternehmen wie zum Beispiel Amazon würde durch eine Ausfallzeit von mehreren Stunden in der Hauptzeit schon einen enormen wirtschaftlichen Schaden erleiden.
Ein anderes Szenario ist ein System mit drei Ausfällen (zu je 20 Minuten) in einem Jahr. Dadurch wäre die Einstufung hoch verfügbar nicht mehr zu halten. Zu dem kommen nicht nur ungeplante Downtimes, sondern auch geplante Downtimes (z.B. für Wartungsarbeiten) vor. Diese müssen zwar nicht zur Hauptarbeitszeit durchgeführt werden, zählen aber trotzdem zur Downtime. So kommt man sehr schnell auf eine Ausfallzeit von mehr als 52 Minuten im Jahr. Doch auch um eine Verfügbarkeit von 99,99% zu ermöglichen ist schon ein gewisser Aufwand nötig (näheres dazu im Kapitel 7:Technologien).
6.1 Definition
Das Institute of Electrical and Electronics Enginers (IEEE) definiert den Begriff Hochverfügbarkeit (Englische: High Availability) folgendermaßen: [6]
- "High Availability (HA for short) refers to the availability of resources in a computer system, in the wake of component failures in the system. [...]" [7]
Sun Microsystems definiert die Hochverfügbarkeit von Servern etwas ausführlicher:
- "Aktiviert die Erkennung einer Dienstunterbrechung und stellt im Falle eines Systemausfalls oder eines Verarbeitungsfehlers Wiederherstellungsmechanismen bereit. Darüber hinaus ermöglicht die Hochverfügbarkeit die Übernahme der Dienste durch ein Sicherungssystem für den Fall eines Ausfalls des Primärsystems. Dies wird auch als HA bezeichnet." [8]
6.2 Anforderungen an ein Hochverfügbarkeitssystem
Die folgenden Anforderungen müssen von einem Hochverfügbarkeitssystem erfüllt werden: [9]
- Verfügbarkeit
- Gibt die Wahrscheinlichkeit an, dass ein System zu einem bestimmten Zeitpunkt unmittelbar funktionsfähig ist. Ein Hochverfügbarkeitssystem sollte zur normalen Arbeitszeit zur Verfügung stehen, dabei ist nach der AEC-Klassifizierung eine minimale Unterbrechung erlaubt Funktion darf [..] zur Hauptbetriebszeit minimal unterbrochen werden. Zudem gibt es bei der Hochverfügbarkeit nur eine Verfügbarkeit von 99,99%.
- Zuverlässigkeit
- Das System muss über einen großen Zeitraum fehlerfrei funktionieren. Für das Hochverfügbarkeitssystem würde dieses nach der Verfügbarkeitsklasse 4 bedeuten, dass das System zu 99,99% verfügbar sein muss. Die Downtime darf demnach nicht mehr als 52,2 Minuten pro Jahr betragen.
- Funktionssicherheit
- Ein Ausfall im Rahmen der Vorgaben darf zu keinen Katastrophen führen. Ein Unternehmen darf durch den Ausfall des Dienstes keinen nennenswerten Schaden davon tragen. Die durch den Ausfall entstandenen Kosten dürfen nicht größer sein als eine höhere Verfügbarkeitsklasse (nötige Hardware, Software, usw.).
- Wartbarkeit
- Gibt an, wie schnell ein ausgefallenes System repariert und wieder zur Verfügung gestellt werden kann. Ein hoch verfügbares System darf durch eine Wartung nicht beeinträchtigt werden. Bei Wartungsarbeiten muss der Dienst von einem anderen System übernommen werden, um den Ausfall zu kompensieren.
Dabei gelten die Anforderungen an ein Hochverfügbarkeitssystem sowohl für Hardware als auch für die Software.
6.3 Kennzahlen
Die folgenden Kennzahlen sind wichtige Kenngrößen zur Bewertung der Systemverfügbarkeit. [10]
-
[11], [12]
- Zuverlässigkeit: Mittlere Uptime des Systems
- Reaktionszeit: Die Zeit, die ein System braucht, bis eine definierte Aktion ausgeführt wird
- Mean Time Between Failure (MTBF): Mittlere ausfallfreie Zeit
- Mean Time to Repair (MTTR): Mittlere Dauer für die Wiederherstellung nach einem Ausfall
- Verfügbarkeitsklassen (siehe Tabelle oben)
- Maximale Dauer eines Ausfalls
7 Technologien
Um den Rahmen der Hausarbeit nicht zu sprengen, werden hier zwei Formen der Hochverfügbarkeit betrachtet und bewertet. Zur Bewertung werden die wesentlichen Stärken und Schwächen noch einmal gesondert hervorgehoben.
7.1 High Available Cluster
Ein Cluster besteht im einfachsten Fall aus zwei Servern (Knoten), die zu einem Verbund, dem Cluster, zusammengefasst werden. Die maximale Anzahl der Knoten ist vom verwendeten Betriebssystem abhängig: Windows Server 2003 unterstützt bis zu 8 Knoten, Linux 8 und Novell Netware Open Enterprise Server (OES) hingegen bis zu 32 Knoten.[13],[14],[15]
Um die Verfügbarkeit der anderen Server zu prüfen, senden die Server Heartbeat-Signale über die gemeinsame LAN- oder eine direkte Netzwerk-Verbindung. Sollte ein Server ausfallen, wird dies durch ein Ausbleiben des Signals von den anderen Servern festgestellt. Die verwalteten Ressourcen werden dann von einem anderen Server übernommen. Diesen Vorgang bezeichnet man als Failover. Durch die Ressourcenübernahme entsteht - je nach Ressource - eine meist kurze Ausfallzeit. Da der Cluster nach Außen wie ein einzelnes System erscheint und demnach über eine IP-Adresse (virtuelle IP oder auch IP-Alias genannt) erreichbar ist, kann nach der Ressourcenübernahme normal weiter gearbeitet werden. Die Anfragen werden direkt an den Server geleitet, der die benötigten Ressourcen verwaltet.[16],[17],[18]
Die Daten befinden sich auf einem gemeinsamen Speicherbereich (Storage). In diesem sind die Speichermedien zu einem RAID-Verbund zusammengefasst, um die Ausfallsicherheit zu erhöhen. Die Anbindung des Storage kann auf viele verschiedene Arten erfolgen. Hier drei gängige Möglichkeiten:[19]
- Direkte Anbindung z.B. über SCSI
- Anbindung über ein Fibre Channel-SAN
- iSCSI ermöglicht den Zugriff über das Netzwerk auf den Speicherbereich, dabei ist der Zugriff auf Blocklevel-Basis möglich.
Um ein Hochverfügbarkeitssystem zu schaffen, muss auch der Storagebereich redundant ausgelegt sein. Selbst durch ein RAID-System kann der Hauptschwachpunkt (SPOF - Single Point of Failure) nicht behoben werden, denn durch den Ausfall des einen vorhandenen RAID-Contollers wäre ein Zugriff auf die Daten nicht mehr möglich. Ist die Funktion eines Systems von der Funktion einer einzelnen Komponente abhängig, bezeichnet man diese Komponente als SPOF. Fällt diese Komponente aus, fällt auch das komplette System aus. Für einen SPOF existiert keine Backup Komponente im System.[20] Natürlich gilt dies auch für alle weiteren beteiligten Geräte oder Verbindungen.
7.1.1 Arten
Je nachdem, welches Betriebssystem man verwendet bzw. welche Ressourcen man hoch verfügbar machen möchte, gibt es unterschiedliche Möglichkeiten, die Knoten in einem Cluster zu organisieren. Dabei kann es vorkommen, dass für verschiedene Ressourcen unterschiedliche Arten genutzt werden können. Es ist zu beachten, dass die einzelnen Arten von den verschiedenen Herstellern unterschiedlich ausgelegt werden. Auch kann man nicht davon ausgehen, dass jeder Hersteller bzw. jede Ressource alle Arten unterstützt. In vielen Fällen haben sich bestimmte Formen bewährt oder aber machen keinen Sinn, so dass auf bestimmte Arten des Clusterings verzichtet werden kann.[21],[22],[23]
7.1.1.1 Aktiv/Passiv
Bei dem Aktiv/Passiv-Clustering befindet sich ein Knoten im Aktiv-Modus, der andere im Passiv-Modus. Der passive Knoten stellt keine Ressourcen bereit. Sollte eine Störung des Aktiv-Knotens festgestellt werden, kommt es zu dem sogenannten Failover. Bei diesem Vorgang werden die Ressourcen von dem Passiv-Knoten übernommen. Der ehemals Passiv-Knoten wechselt nun in den Aktiv-Modus und der Aktiv-Knoten in den Passiv-Modus. Der Administrator hat nun die Möglichkeit, die Störung zu beheben. Danach steht der ausgefallene Knoten wieder bereit, um Ressourcen bei Ausfall des Aktiv-Knotens zu übernehmen. Je nachdem, wie viele Knoten ein Cluser besitzt, kann die Anzahl der Passiv-Knoten variieren.
Bei dieser Art der Ressourcenverteilung kommt es bei einer Störung immer zu einem Ausfall. Dabei hängt die Ausfallzeit von der Ressource ab. [24],[25],[26],[27],[28]
Bei großen Datenbanken kann die Transaktion durchaus 20 Minuten dauern. [29] Allerdings ist diese Form des Clusterings für fast alle Ressourcen möglich.
Bei einem Aktiv/Passiv-Cluster kann man eine Unterteilung in zwei Kategorien vornehmen:[30],[31]
- Cold-Standby-Cluster - Das passive bzw. sekundäre System ist nicht betriebsbereit. Es muss erst hochgefahren/eingeschaltet werden.
- Hot-Standby-Cluster - Das passive System ist bereits betriebsbereit.
Je nachdem, für welche Ressourcen (vom Fileserver bis hin zu großen Datenbanken) man gedenkt ein Aktiv/Passiv-Cluster einzusetzen, kann das Ziel, eine Hochverfügbarkeitsumgebung zu schaffen, durchaus ein Problem werden. Übernahmezeiten von 20 Minuten sind in einer Hochverfügbarkeitsumgebung nach der Harvard Research Group zwar akzeptabel, sollte ein Unternehmen zur Hauptarbeitszeit einen Ausfall von 20 Minuten erleiden, könnte dies trotzdem zu einem enormen wirtschaftlichen Schaden führen.
7.1.1.2 Aktiv/Aktiv
Bei einem Cluster, auf dem ständig alle Ressourcen auf allen Knoten laufen, spricht man von einem Aktiv/Aktiv-Cluster. Sollte ein System ausfallen, übernimmt ein anderes System die Arbeit. Diese Art des Clusters hat den Vorteil, dass hier nur eine geringe bis keine Ausfallzeit auftritt. Lediglich die Übergabe der Besitzrechte für die jeweiligen Ressourcen muss erfolgen. Bei dieser Form des Clusterings ist es auch möglich, die Ressourcen auf beide Systeme zu verteilen. Dabei ist zu beachten, dass die jeweiligen Systeme immer genug Kapazitäten haben müssen, um die Dienste des anderen Knoten mit übernehmen zu können. Möglicherweise müssen hier "größere" Server als beim Aktiv/Passiv-Clustering genutzt werden.[32],[33],[34],[35],[36],[37]
Eine Sonderform hiervon ist die sogenannte Lastenverteilung oder auch Loadbalancing, welche sich auch mit einem HA-Cluster kombinieren lässt. Hierbei wird die Last so verteilt, dass eine optimale Ausnutzung beider Server erfolgt. Da dies nur einen Performance-Vorteil bietet, wird hierauf nicht näher eingegangen.[38],[39]
Der Zugriff auf die Daten lässt sich bei diesem System in zwei Punkte unterteilen:[40]
- Shared Nothing - Jeder Knoten hat exklusiven Zugriff auf die Daten. Diese liegen meist in einem abgetrennten Bereich oder sogar in einem anderen Storage.
- Shared All - Beide Knoten können auf den gleichen Datenbereich zugreifen (z.B. ext. Storage).
Für eine Hochverfügbarkeitsumgebung eignet sich der Aktiv/Aktiv-Cluster sehr gut, da man nur eine sehr kurze bis keine Ausfallzeit hat. Allerdings sollte man dann auch die Möglichkeit des Shared All nutzen. Bei der Option Shared Nothing müssten sich die Systeme ständig synchronisieren, um bei einer Übernahme keine großen und langwierigen Datenabgleiche durchführen zu müssen. Dies würde die Ausfallzeit stark erhöhen, so dass man fast die gleichen Ausfallzeiten eines Aktiv/Passiv-Clusters hätte. Das Aktiv/Aktiv-Clustering hat allerdings den Nachteil, dass eine Implementierung wesentlich schwieriger ist und von vielen Herstellern erst gar nicht unterstützt wird.
7.1.2 Bewertung
Da bereits auf die Stärken und Schwächen der einzelnen Arten des Clusterings eingegangen wurde, hier eine allgemeine Übersicht:
Ein Cluster bietet folgende Vorteile:
- Relativ flexible Architektur - Eine Erweiterung auf mehrere Cluster ist möglich.
- Cluster werden von den gängigsten Systemen (Novell Netware, Linux, Windows, usw.) unterstützt.
- Gute Möglichkeit, Hochverfügbarkeit zu erzielen.
- Server untereinander separiert - Dies erlaubt eine räumliche Trennung der Server.
- Der Cluster erscheint nach außen als ein System - Änderungen fallen den Clients so meistens nicht auf.
Allerdings auch folgende Nachteile:
- Es gibt bei einem Failover immer eine gewisse Ausfallzeit.
- Sollte ein Failover fehlschlagen, ist der ganze Dienst von außen unerreichbar.
- Je komplexer die Systeme (große Datenbanken), desto höher ist die Übernahmezeit und damit die Ausfallzeit.
- Hoher administrativer Aufwand für die Erstellung von Scripten oder bei der Installation von Updates.
7.2 Gespiegelte Server
Im Gegensatz zu den normalen Clusterlösungen, wo bei einem Failover die Server erst die Daten aktualisieren müssen bzw. wo beide Server die Ressource anbieten, wird in diesem Teil eine Hochverfügbarkeitslösung aufgezeigt, bei der die Server ständig synchronisiert werden. Dies hat den Vorteil, dass die Failoverzeiten verkürzt werden. Diese Möglichkeit wird anhand von Marathon everRun HA gezeigt.[41]
7.2.1 Technologie
Die Technologie besteht aus zwei Windows Servern und einer virtuellen Maschine. Dabei handelt es sich hier nicht um eine klassische virtuelle Maschine, lediglich die Systemressourcen werden partitioniert. In der virtuellen Maschine werden beide Server zusammengefasst, sind aber nach außen nur als ein System zu sehen. Allerdings laufen die Anwendungen nicht synchron auf beiden Servern. Sollte es zu einem Ausfall kommen, werden die Anwendungen auf den zweiten Server transferiert, genauer gesagt die virtuelle Maschine. Hierbei handelt es sich wie bei den normalen Clusterlösungen um ein Failover, allerdings sind die Daten schon synchron. Damit haben die Datensätze und die Anwendungen immer den gleichen Zustand.
Ähnlich der Clusterverwaltungssoftware sorgt die Maraton Sofware für die Überwachung und leitet bei Bedarf den Failover ein. In der Abbildung 5 ist der umrahmte Bereich die virtuelle Maschine, die bei einer Störung von dem anderen Server übernommen wird (siehe Abbildung 6). Zudem kümmert sie sich um die komplette Verwaltung des Systems. Die gesammelten Informationen kann der Administrator über die Managementsoftware abfragen und diese ermöglicht auch den direkten Eingriff bei Problemfällen. Die Software läuft auf beiden Systemen und wird permanent synchronisiert. Eine externe Speicherlösung wird ebenso wie eine interne unterstützt. Dabei unterstützt Marathontechnologies auch, dass sich die VM (virtuelle Maschine) auf dem externen Storage befindet.[44],[45],[46],[47],[48],[49]
Für die Synchronisation ist es notwendig, die Server direkt über eine Gigabit Ethernet Strecke direkt zu verbinden. Zudem sollte jeder Server für die Anbindung an das LAN eine zusätzliche Netzwerkkarte haben.
Um die Server auch weiter von einander entfernt aufstellen zu können, bietet die Zusatzsoftware Split-Site die Möglichkeit, die Synchronisation über ein high Speed WAN durchzuführen.[50]
7.2.2 Bewertung
Die Technologie Marathon everRun HA bieten die Vorteile:
- Einfachere Installation und Administration als beim Cluster, da es wie ein "normaler" Server behandelt werden kann.
- Alle Anwendungen, die auf der Windows Server Plattform laufen, können hoch verfügbar gemacht werden .
- Kaum Ausfallzeit, da Daten immer synchronisiert werden
Doch die Nachteile schränken das Produkt stark ein:
- Nur Windows Server (Standard oder Enterprise)
- Drei Windows Lizenzen - Zwei für die Server und eine für die virtuelle Maschine
- Bislang auf zwei Server beschränkt
- Trennung über eine weitere Entfernung nur durch Zusatzsoftware
- Unterstützt bislang nur AMD und Intel Prozessoren
8 Praktisches Beispiel
Zur besseren Erläuterung der Hochverfügbarkeit wird hier ein Beispiel angeführt. Um den administrativen Aufwand zu verringern, setzen viele Unternehmen DHCP-Server ein. Sie dienen der automatischen Vergabe der IP-Adressen. Sollte einem Client keine Adresse zugewiesen werden, kann dieser keine Kommunikation mit anderen Servern durchführen. Diese würde für den Client eine völlige Isolierung bedeuten. Für den Mitarbeiter, der diesen Rechner benutzt, würde dies bedeuten, dass nur lokales Arbeiten möglich wäre.
Ein mittelständisches Unternehmen, in dem ein hoch verfügbarer DHCP-Cluster eingerichtet werden soll, dient als Beispiel. In diesem wird - um die Hochverfügbarkeit des Servers zu gewährleisten - ein Cluster eingesetzt.
Dabei wird ein Szenario von der Ausgangssituation über Anforderungen bis zur Konfiguration und den Funktionstests des Clusters beschrieben.
8.1 Ausgangssituation
In einem mittelständischen Anlagen- und Maschinenbauunternehmen mit ca. 700 Mitarbeitern sind Computer nicht mehr weg zu denken. Alle Konstruktionen werden am PC entworfen und auf Servern gespeichert. Die fertigen Konstruktionen werden dann von den Servern auf die Fertigungsmaschinen geladen und von diesen auf die zu bearbeitenden Teile umgesetzt. Und auch sonst werden die meisten Tätigkeiten am Computer durchgeführt. Ein Ausfall der Computersysteme würde dem Unternehmen einen enormen finanziellen Schaden zufügen. Die IP-Adressvergabe erfolgt in den meisten Bereichen manuell - d.h. der Administrator sucht sich eine freie IP-Adresse aus einer zentralen Tabelle und weist diese dem Gerät zu. Diese Art der Administration bringt eine Reihe von Problemen mit sich:
- Hoher administrativer Aufwand. Jede Änderung der IP-Adressen muss lokal auf den Arbeitsstationen erfolgen.
- Die vergebenen IP-Adressen müssen manuell von den Administratoren in eine zentrale Datei eingepflegt werden.
- Die Zuverlässigkeit der gespeicherten Adressen kann kaum gewährleistet werden, wodurch Fehler entstehen z.B. durch doppelt vergebene IP-Adressen.
- Der Aufwand bei größeren Änderungen ist erheblich.
- Der hohe Administrations- und Verwaltungsaufwand bindet Kapazitäten, die Kosten verursachen.
Aus diesem Grund soll ein hoch verfügbarer DHCP-Server eingerichtet werden, von dem alle Clients ihre IP-Adresse beziehen. Der Grund für die Notwendigkeit eines hoch verfügbaren Servers wurde bereits in der Einleitung dieses Kapitels erläutert.
8.2 Anforderungen
Das zu verwendende System sollte folgende Anforderungen erfüllen:
- Hochverfügbarkeit nach Harvard Research Group
- System muss DHCP-Clustering unterstützen
- V-LAN-Unterstützung
- System bei Bedarf auch für andere Dienste nutzbar -> DNS-Cluster oder ähnliche
- DHCP muss RFC-konform sein, um Kompatibilitätsprobleme zu vermeiden
- Client-unabhängig -> Um Produkt-unabhängig zu bleiben, muss es jedem Client möglich sein, eine IP-Adresse zu beziehen, egal welches System (Windows, Linux, usw.) Verwendung findet
- Es sollte sich möglichst um eine bekannte Plattform handeln, um zusätzliche Kosten durch Schulung der Fachkräfte zu vermeiden
- Einfache und intuitive Administration
- Fernwartung von möglichst vielen verschiedenen Betriebssystemen (z.B. über ein Web-Interface)
8.3 System
Für die Umsetzung des DHCP-Clusters wird das Betriebssystem Novell Netware Open Enterprise gewählt. Diese Auswahl erfolgt aus folgenden Gründen:
- Bietet die Möglichkeiten des Clusterings von DHCP-Diensten (und weitern Diensten wie z.B. DNS)
- Automatische Ressourcenübernahme bei Ausfall => Failover System
- Keine zusätzlichen Kosten für die Möglichkeiten einen Cluster einzusetzen
- Bietet V-LAN Unterstützung
- Unterstützt bis zu 32 Knoten
- Geringe Hardwareanforderungen
- Einbindung in das eDirectory => Kein zusätzlicher Synchronisierungsaufwand für die DHCP-Ressource, da direkte Eingliederung in das eDirectory. Somit kann die Konsistenz der DHCP-Datenbank gewährleistet werden
- Administration über Webinterface => Administration von allen Java unterstützten Systemen
- Erfüllt die gesetzten Anforderungen
8.3.1 Cluster Funktion
Bei Novell Netware OES handelt es sich um eine erweiterte Form des Aktiv/Passiv-Clustering. Zwar läuft eine Ressource immer nur auf einem Knoten, die bei einer Störung von einem anderen Knoten übernommen wird, allerdings werden die Daten immer direkt im eDirecotry gespeichert. Durch diesen Verzeichnisdienst bleiben die Daten immer synchron. Für die DHCP-Ressource bedeutet dies, dass die Datenbank im eDirecotry immer auf dem aktuellen Stand ist. Sobald ein Knoten die Ressource übernimmt, kann dieser ohne großen Synchronisationaufwand die Ressource übernehmen und den Dienst schnell wieder zur Verfügung stellen. Dies ermöglicht eine geringe Ausfallzeit.
Zudem bietet Novell die Möglichkeit, bei mehreren geclusterten Ressourcen diese so zu verteilen, dass beide Server eine gewisse Auslastung haben. Natürlich muss darauf geachtet werden, die Server so auszulasten, dass genug Serverressourcen zur Verfügung stehen, um bei einem Failover andere Ressourcen zu übernehmen.
8.4 Konfiguration
Zum Einsatz kommt ein Novell Netware Open Enterprise Server. Dabei ist die Clusterfunktion direkt enthalten. Der Cluster soll aus zwei Knoten bestehen, wobei eine Erweiterung auf bis zu 32 Knoten jederzeit möglich ist. Um die Funktionstüchtigkeit des Systems sicherzustellen, wird die ganze Konfiguration in einer abgetrennten Testumgebung erprobt. Nach dem erfolgreichen Abschluss findet eine Implementierung in das Echtsystem statt. Dabei unterscheiden sich die hier beschriebenen Konfigurationsschritte nicht voneinander, da beide Systeme identisch aufgesetzt werden.
8.4.1 Testsystem Aufbau
Die Testumgebung besteht aus drei Clients. Auf diesen wird Windows XP Professional installiert, da dies auf fast allen Computern des Unternehmens Verwendung findet. Auf den Servern wird Novell Netware Open Enterprise Server mit folgenden Diensten und Updates installiert:
- Apache - Für die web-basierte Konfiguration
- Tomcat - Java für den Webserver
- DNS/DHCP-Dienste
- iManager 2.5 - Dient zur Konfiguration über die Weboberfläche, basiert auf Java
- Service Pack 5a für OES
Die Server bekommen die Namen S1 und S2 zugewiesen. Eingebunden werden sie in das eDirectory unter dem Baum Bocholt und dem Kontext Olbrich. Die Verbindung erfolgt über einen 100 Mbit/s Switch.
8.4.2 Cluster einrichten
Nachdem Novell Netware OES auf beiden Servern installiert wurde, wird nun der Cluster eingerichtet. Dazu wird in einen der Rechner - nicht Server - die OES CD1 eingelegt. Auf der CD muss die Datei NWDeployNoBrowser.exe ausgeführt werden. In dem sich öffnenden Menü wird der Eintrag „Cluster installieren und Aufrüsten“ unter dem Punkt „Aufgaben nach der Installation“ gewählt. Anschließend wird der „Cluster erstellen“ gewählt. Im weiteren Verlauf wird dem Cluster der Name CL und die IP-Adresse 192.168.0.3 zugewiesen. Dem Clusterverbund werden die Server S1 und S2 hinzugefügt. Es ist möglich, dem Cluster jederzeit weitere Knoten hinzuzufügen. Nach dem Hinzufügen müssen dann die entsprechenden Knoten den einzelnen Ressourcen zugewiesen werden.
8.4.3 Konfigurations-Tools
An dieser Stelle werden zwei mitgelieferte Tools beschrieben. Dabei soll der iManager die Nachfolge der Console One übernehmen. Mit ihm lässt sich der komplette Server steuern. Die DNS/DHCP Management-Konsole ist nur für die Konfiguration des DHCP- bzw. DNS-Servers geeignet. Aufgrund der Baumstruktur eignet sie sich besonders gut für die Konfiguration der DHCP- und DNS-Ressourcen.
8.4.3.1 iManager 2.5
Der iManager ist ein webbasiertes Administrationswerkzeug, welches auf der Java-Technologie aufsetzt und somit Betriebssystem-unabhängig ist. Der iManger eignete sich aufgrund der fehlenden Baumstruktur nur beschränkt für die Konfiguration des DHCP-Servers. Daher wird für diesen Zweck die Management-Konsole genutzt. Lediglich die Clusterkonfiguration wird über den iManager ausgeführt. Die Management-Konsole kann für diesen Zweck nicht verwendet werden, da sie nur die Konfiguration und Administration der DHCP- und DNS-Ressource unterstützt.
Durch folgende Eingabe lässt sich der iManager 2.5 aufrufen: https://IP-Adresse_des_Clusters/nps/iManager.
In dem Loginfenster gibt der zuständige Administrator seinen Namen ein, mit dem er sich am Novell-System anmeldet. Je nachdem, in welchem Kontext der Benutzer sich befindet, muss dieser entsprechend eingetragen werden. In den nächsten Feldern werden das Passwort und der Baum - in diesem Fall „Bocholt“ - eingetragen.
Der Benutzer „admin“ wird bei der Installation des Netware-Betriebssystems angelegt, ähnlich dem Windows-Administrator. Dieser kann sich ohne Kontext einloggen.
8.4.3.2 DNS/DHCP Management-Konsole
Da die Management-Konsole über kein Webinterface angesprochen werden kann, wird diese lokal auf einer Microsoft Windows Workstation installiert. Auf dem Netzlaufwerk des aufgesetzten Netware-Servers führt man unter System -> Public-> DNSDHCP die Setup.exe aus. Die Installation hat auf einem Windows-Rechner zu erfolgen, da das Programm ausschließlich unter diesem Betriebssystem lauffähig ist. Dazu muss der Novell Client installiert sein, weil das Programm eine Anmeldung im eDirectory nicht startet. Die Konsole bietet einen schnellen Überblick über die aktuelle Konfiguration. Zudem lassen sich Ereignisberichte sehr einfach erstellen und auswerten. Aus der Abbildung 8 können die wichtigsten Menüpunkte entnommen werden, welche zur Konfiguration notwendig sind. In der Baumstruktur wird eine grafische Übersicht der hinzugefügten Objekte - z.B. IP-Adressbereiche - angezeigt. Der Button Objekt hinzufügen öffnet ein Fenster, in dem verschiedene Objekttypen ausgewählt werden können z.B. DHCP-Server.
8.4.4 DHCP einrichten
Um den Rahmen der Hausarbeit nicht zu sprengen, werden die einzelnen Konfigurationsschritte nur aufgelistet und kurz erläutert - hier mit der Management-Konsole. Auf eine ausführliche Beschreibung der Konfigurationsschritte wird aus dem besagten Grund verzichtet. Eine ausführliche Dokumentation findet man unter: Novell Netware OES DHCP Dokumentation
- Management-Konsole öffnen
- Serverobjekt erstellen - DHCP-Ressource erstellen und einem Server im eDirectory zum Verwalten zuweisen
- Teilnetz erstellen (siehe Abbildung 9) - Netz festlegen, für das der DHCP-Server zuständig ist
- Teilnetzadressbereich erstellen - Legt den IP-Adresspool fest, welcher der DHCP-Server vergeben kann
- Teilnetzpool erstellen - In diesem Pool werden die Teilnetze zusammengefasst. Dient hauptsächlich der Verwaltung mehrerer Teilnetze
- Art der Adressvergabe für das Teilnetz festlegen
- Zeitlich festgelegte Zuordnung'- Client darf IP nur für kurze Zeit behalten - danach muss die Nutzung verlängert oder erneuert werden
- Permanente Zuordnung - permanente Zuordnung der IP-Adresse (keine Lease Time)
- Manuelle Zuordnung - Anhand der MAC-Adresse wird eine IP-Adresse immer dem selben Client zugeordnet
- Eventuell die Lease Time anpassen - Legt für die Clients die Mietzeit der IP-Adresse fest
- Option „Ping aktivieren“ mit einem Haken versehen - Prüft durch einfaches Pingen, ob IP-Adresse bereits im Netzwerk verwendet wird - vermeidet doppelte IP-Adressen
- Sonstige DHCP-Optionen definieren (siehe Abbildung 10)
- DNS-Server - Legt den DNS-Server fest, der durch den DHCP-Server an die Clients übergeben wird
- Router (Gateway) - Legt den Gateway fest, der an die Clients mit übergeben wird
- Subnetzmaske - Bei einer Abweichung der Standard-Subnetzmaske kann diese hier hinterlegt werden und wird durch den DHCP-Server den Clients übergeben
- Protokollierung konfigurieren - Welche Ereignisse sollen protokolliert werden: Alle Ereignisse, Warnungen oder nur kritische Zustände
- Falls nötig, manuell IP-Adressen hinzufügen - Hier können MAC-Adressen der Clients eingetragen werden, die immer die selbe IP-Adresse zugewiesen bekommen sollen
8.4.5 Clusterressource konfigurieren
Der DHCP-Server soll in einem Cluster betrieben werden, daher muss für den DHCP-Server eine neue Clusterressource angelegt werden. Hierzu wird der iManager, wie im Kapitel iManager beschrieben, aufgerufen. Per Klick auf das Pluszeichen lassen sich die Clusterobjekte erweitern. Unter dem Punkt Clusteroptionen wird der Cluster ausgewählt, auf dem die DHCP-Clusterressource angelegt werden soll. Nach erfolgreichem Laden des Clusters, wird durch einen Klick auf den Punkt Neu unter dem Bereich Cluster-Objekte ein neues Fenster geöffnet. Der Eintrag Ressource wird gewählt. Auf der nächsten Seite wird der Cluster-Ressourcenname angegeben, hier OLB_DHCP_CL. Für einige Ressourcen existieren bereits Schablonen, welche vorkonfigurierte Eigenschaften bereitstellen. Für den DHCP-Server wird die Schablone DHCP verwendet. Diese befindet sich im Bereich des Clusterobjektes. Durch einen Klick auf Weiter erscheint der Punkt Ladeskript. Es wird den Anweisungen entsprechend angepasst:
- CLUSTER DHCP CN=S1.O=olbrich.T=Deutschland
- dhcpsrvr --servaddr=192.168.0.1
- Punkt 1: Ordnet die DHCP-Ressource dem Knoten S1 zu. Bei einem Failover wird automatisch einer der Knoten gewählt, der der Ressource zugewiesen wurde.
- Punkt 2: Startet den DHCP-Dienst und übergibt die Cluster-IP.
Das Entladeskript wird wie folgend angepasst:
- unload dhcpsrvr
- Stoppt den DHCP-Dienst auf dem aktuellen Knoten, um ein "sauberes" Beenden und somit eine Übergabe auf den nächste Knoten zu ermöglichen.
Im Feld Zeitüberschreitung wird die Zeitspanne eingetragen, die zum Ausführen des Skriptes zur Verfügung steht. Wird die Zeitspanne überschritten, wird die Ressource inaktiv.
Die neu erstellte Cluster-Ressource erscheint in der Übersichtsliste. Um die Einstellungen zu überprüfen, wird die erstellte Ressource markiert. Weitere Optionen können über den Eintrag Cluster-Optionen -> Eigenschaften erreicht werden. Die für die Ressource zu verwendenden Knoten müssen dem Feld Bevorzugte Knoten zugeordnet werden, in diesem Fall S1 und S2. Das Fragezeichen bietet eine Übersicht weiterer Informationen.
8.4.6 Funktionstest
In diesem Kapitel soll die Funktionstüchtigkeit der Konfiguration überprüft werden. Dazu wird die korrekte Übernahme von Ressourcen bei einer unterbrochenen Kommunikation der Server getestet. Im zweiten Test wird geprüft, ob der DHCP-Server den Clients IP-Adressen korrekt zuweißt. Folgende Tests werden durchgeführt:
- Clusterfunktionstest - Funktioniert die automatische Ressourcenübernahme im Fehlerfall?
- IP-Adressen beziehen - Bekommen die Clients IP-Adressen vom DHCP-Server zugewiesen?
8.4.6.1 Failover
Um die grundsätzliche Funktionsfähigkeit des Clusters zu prüfen, wird im iManager der Punkt Cluster gewählt. Die Auswahl des Clusters CL.Olbrich unter dem Menüpunkt Cluster-Manager zeigt die Clusterknoten an. Nach der Auswahl der Clusterressource DHCP_CL wird die Option Migrieren gewählt. In dem sich öffnenden Fenster wird die gewählte Ressource auf den anderen Server übertragen. Nach dem erfolgreichen Abschluss dieses Funktionstests wird zur Simulation eines Serverausfalls das Netzwerkkabel des Masterservers (S1) abgezogen. Daraufhin wechselt die Clusterressource automatisch auf den zweiten Server (S2) bzw. Knoten. Durch die erfolgreichen Tests kann die Funktionsfähigkeit des Clusters bestätigt werden.
8.4.6.2 Zuweisung von IP-Adressen
Die Arbeitsstationen der Testumgebung müssen ihre IP-Adressen automatischen beziehen. Dazu wird in den Eigenschaften der jeweiligen Netzwerkkarte der Punkt IP-Adresse automatisch beziehen gewählt. Anschließend wird die Windows-Eingabekonsole (cmd) geöffnet. Nach kurzem Warten wird durch die Eingabe des Befehls ipconfig die IP-Konfiguration abgefragt. Hier wird die vom DHCP-Server zugeordnete IP-Adresse angezeigt. Dieser Test beweist die Funktionsfähigkeit des DHCP-Servers.
Zur Sicherheit wird die Zuweisung ein zweites Mal getestet: Durch den Befehl ipconfig /release wird die IP-Adresse wieder frei gegeben. Der Befehl ipconfig /renew fordert eine IP-Adresse vom DHCP-Server an. Auch dieser Test verläuft bei allen Clients fehlerlos. Zudem wird die korrekte Zuweisung der manuellen IP-Adressen geprüft. Dieser Test ist von Erfolg gekrönt.
Die Funktionstüchtigkeit des DHCP-Servers kann somit bewiesen werden.
8.5 Alternative
Als Alternative zum Cluster bietet sich bei einem DHCP-Server die Möglichkeit, die Ausfallsicherheit mit der 80/20 Regel zu erzielen. Hierbei wird der IP-Pool des DHCP-Servers auf zwei Server verteilt. Dabei verwaltet der primäre Server 80% des Pools, der andere 20%. Allerdings hat dieses System folgende Nachteile:
Da keine Kopplung zwischen den Systemen besteht, können die beiden Server nicht für andere Ressourcen verwendet werden, um diese hoch verfügbar zu machen. Zudem könnte man keinen zusätzlichen Server mit einbinden, um die Verfügbarkeit des DHCP-Dienstes weiter zu erhöhen. Des Weiteren bedeutet eine Erweiterung des IP-Polls, dass beide Server neu konfiguriert werden müssten. Ein längerer Ausfall des primären Servers würde bedeutet, dass nur 20% der IP-Adressen zur Verfügung stünden. Nur durch einen Eingriff des Administrators könnte der sekundäre Server umkonfiguriert werden und die Aufgabe des primären Servers übernehmen. Zwar lassen sich mit bestimmten Betriebssystemen die DHCP-Server so konfigurieren, dass einige dieser Probleme nicht auftreten, dieses bedeutet aber trotzdem einen zusätzlichen Konfigurationsaufwand. Zudem muss sichergestellt sein, dass bei einem Ausfall die Clients sich weiterhin an den richtigen Server wenden, um z.B. die Lease Time zu verlängern. Allerdings kann es dabei zu dem Fehler kommen, dass der Client um eine Verlängerung der IP-Adresse bittet, der Server diese aber gar nicht verwaltet.[51],[52]
Um diese Probleme zu vermeiden, ist ein Cluster - auch administrativ gesehen - die bessere Wahl.
8.6 Bewertung
Ein DHCP-Server auf Basis von Novell Netware OES ermöglicht eine einfach zu implementierende Hochverfügbarkeitsumgebung, welche die Anforderungen der Harvard Research Group erfüllt. Das eDirectory bietet ein ständig synchrones System. Ein weiteres Systeme, das mit dem DHCP-Server zusammenarbeitet, könnte man sehr leicht einbinden. Zum Beispiel wäre es möglich, einen dynamischen DNS-Server mit einzubinden. Dieser könnte die Daten direkt mit Hilfe des eDirectory an den DHCP-Server weitergeben.
Die vielen verschiedenen Tools zum Konfigurieren erschweren das Arbeiten ein wenig. Eine einheitliche Managementkonsole wäre hier von Vorteil. Zwar ist es mit dem iManager schon jetzt möglich, alle Konfigurationen vorzunehmen, diese gestaltet sich allerdings (bislang) noch ein wenig schwierig und unübersichtlich, da die altbewährte Baumstruktur fehlt.
Zwar gibt es Alternativen zum Clustering (z.B. die 80/20 Möglichkeit), allerdings bieten diese weniger Flexibilität und eine geringere Skalierbarkeit. Zudem gestaltet sich die Konfiguration schwieriger als bei Novell Netware OES.
9 Fazit
Es hat sich gezeigt, dass Clustering immer noch die bewährte Strategie ist, wenn es um Hochverfügbarkeit geht. Gerade die hohe Flexibilität und die Skalierbarkeit machen den Cluster immer noch zum Favoriten. Allerdings ist die Konfiguration und Administration in den meisten Fällen sehr komplex, gerade bei großen Datenbanken. Mit zunehmender Größe des Systems steigen natürlich die Anforderungen und die Komplexibilität. Des Weiteren reicht es nicht, nur die eine Clusterlösung zu implementieren, um eine hoch verfügbare Umgebung zu erzielen, alle beteiligten Komponenten, wie das Storage oder auch das Netzwerk müssen redundant ausgelegt sein. Was hilft es, einen Cluster mit 6 Knoten zu haben und nur ein Storage? Sollte es dort zu einem größeren Problem kommen, hilft auch kein RAID-System mehr. Zudem ist wichtig, eine gute Backupstrategie zu verwenden, um Daten im Notfall schnell wieder herstellen zu können und so Ausfallzeiten möglichst klein zu halten.
Die Alternativen zum Cluster, wie zum Beispiel die hier betrachtete Marathon everRun HA bieten zwar bereits gute Ansätze, haben aber noch so große Nachteile, dass sie gerade für große Unternehmen nicht in Frage kommen.
Bei den hier vorgestellten Lösungen kommt es immer zu Ausfällen, wenn eine Ressource von einem anderen System im Fehlerfall übernommen wird. Zudem kann es auch bei der Übernahme (Failover) immer noch zu Fehlern kommen. Gerade für Unternehmen wie Amazon, die auf die Verfügbarkeit zwingend angewiesen sind, empfiehlt es sich, Systeme zu verwenden, die die Verfügbarkeitsklasse 5 oder sogar 6 abdecken. Welches System benötigt wird, muss genau analysiert werden, denn die Kosten des Ausfalls dürfen nie die Kosten einer höheren Verfügbarkeitsklasse übersteigen.
10 Fußnoten
- ↑ Vgl. Manhart (2005)
- ↑ Vgl. Lenz (2005)
- ↑ Vgl. Held (2004), S.27, zitiert nach: http://www.hrgresearch.com/ha/index.html
- ↑ Vgl. Held (2004), S.29
- ↑ Vgl. Held (2004), S.45
- ↑ Vgl. Held (2004), S.29
- ↑ http://www.ieeetcsc.org/high-availability.html
- ↑ http://docs.sun.com/app/docs/doc/819-4626/6n6p0sl52?l=de&a=view#jesgl-aso
- ↑ Vgl. Tanenbaum (2008), S.355
- ↑ Vgl. Held (2004), S.37
- ↑ Vgl. http://de.wikipedia.org/wiki/Hochverf%C3%BCgbarkeit
- ↑ Vgl. Held (2004), S.29
- ↑ http://technet.microsoft.com/de-de/library/cc783804.aspx
- ↑ http://books.google.de/books?id=1PEqrGYcGBgC&pg=PA22&dq=cluster+aktiv+aktiv#PPA22,M1
- ↑ http://www.novell.com/documentation/oes/pdfdoc/cluster_admin_lx/cluster_admin_lx.pdf
- ↑ Vgl. Tierling (2005), S.1114 ff.
- ↑ Vgl. Lenz (2007)
- ↑ http://www.novell.com/documentation/oes/pdfdoc/cluster_admin_lx/cluster_admin_lx.pdf
- ↑ Vgl. Boddenberg (2006), S.90 ff.
- ↑ Filz (2008)
- ↑ http://technet.microsoft.com/de-de/library/bb123612.aspx
- ↑ Vgl.Boddenberg (2006), S.471 ff.
- ↑ http://technet.microsoft.com/de-de/library/bb123612.aspx
- ↑ Vgl. Boddenberg (2006), S.473 f.
- ↑ Vgl. Müller (2005)
- ↑ http://technet.microsoft.com/de-de/library/aa997507(EXCHG.65).aspx
- ↑ http://books.google.de/books?id=H63XyoNlQyEC&pg=PA330&dq=cluster+aktiv+aktiv#PPA299,M1
- ↑ http://books.google.de/books?id=9RJPPV-VuYgC&pg=PT359&dq=cluster+aktiv+aktiv#PPT360,M1
- ↑ Vgl. Held (2004), S.211
- ↑ Vgl. BSI
- ↑ Vgl. Held (2004), S.54 ff.
- ↑ Vgl. Müller (2005)
- ↑ http://technet.microsoft.com/de-de/library/aa997507(EXCHG.65).aspx
- ↑ http://books.google.de/books?id=H63XyoNlQyEC&pg=PA330&dq=cluster+aktiv+aktiv#PPA299,M1
- ↑ http://books.google.de/books?id=9RJPPV-VuYgC&pg=PT359&dq=cluster+aktiv+aktiv#PPT359,M1
- ↑ Vgl. Held (2004), S.211
- ↑ Vgl. Boddenberg (2006), S.476
- ↑ Vgl. Tierling (2005), S.1083 ff.
- ↑ Vgl. Hansen, Neumann (2005), S.843
- ↑ Vgl. Müller (2005)
- ↑ http://www.diventus.de/index.php?option=com_content&view=article&id=32&Itemid=56
- ↑ Vgl. Rohde (2008)
- ↑ Vgl. Rohde (2008)
- ↑ Vgl. Karpf (2007) http://www.computerwoche.de/knowledge_center/datacenter_und_server/1850007/index.html
- ↑ http://www.marathontechnologies.com/documents/marathon_everrunHA.pdf
- ↑ Vgl. Pelzer (2007)
- ↑ Vgl. K. Computerwoche (2006) http://www.computerwoche.de/heftarchiv/2006/23/1214793/
- ↑ http://www.diventus.de/index.php?option=com_content&view=article&id=32&Itemid=56
- ↑ Vgl. Karpf (2007) http://www.searchsecurity.de/themenbereiche/sicherheits-management/business-continuity/articles/93449/index5.html
- ↑ Vgl. Karpf (2007) http://www.searchsecurity.de/themenbereiche/sicherheits-management/business-continuity/articles/93449/index5.html
- ↑ Vgl. Schlüter (2006), 709 ff.
- ↑ Vgl. Joos Lan Line, 2008, Ausgabe 08, S. 44 bis 46
11 Literatur- und Quellenverzeichnis
| Bücher | |
| Boddenberg (2006) | Boddenberg, Ulrich B.: Microsoft-Netzwerke,1.Auflage, Galileo Computing 2006 |
| Hansen, Neumann (2005) | Hansen, Hans Robert; Neumann Gustaf: Wirtschaftsinformatik 2, 9. Auflage, Lucius & Lucius 2005 |
| Held (2005) | Held, Andrea: Oracle 10g Hochverfügbakreit, 1.Auflage, Addison-Wesley 2005 |
| Laudon C., Laudon P., Schoder(2006) | Laudon, Kenneth C.; Laudon, Jane P.; Schoder, Detlef: Wirtschaftsinformatik, 6.Auflage, Pearson Studium 2006 |
| Schlüter (2006) | Schlüter U.: Integrationshandbuch Microsoft-Netzwerke, 3. aktual. und erweiterte Auflage, Galileo Computing 2006 |
| Tanenbaum (2008) | Tanenbaum, Andrew S.: Verteilte Systeme, 2. aktual. Auflage, Pearson Studium 2008 |
| Tierling (2005) | Tierling, Eric: Windows Server 2003 SP1, 2. aktual. Auflage, Addison-Wesley |
| Internet | |
| BSI | Bundesamt für Sicherheit in der Informationstechnik : NM 2.302 Sicherheitsgateways und Hochverfügbarkeit, , http://www.bsi.de/gshb/deutsch/m/m02302.htm (14.02.2009) |
| Filz (2008) | Filz, Florian : Grundlagen der Hochverfügbarkeit, 2008, https://wwwbs.informatik.htw-dresden.de/svortrag/i04/Filz/ (14.02.2009) |
| Karpf (2007) | Karpf, Achim B. C. : Ausfallsicherheit dank Marathon everRun statt Cluster-Lösung, 21.09.2007, http://www.searchsecurity.de/themenbereiche/sicherheits-management/business-continuity/articles/93449/index5.html (14.02.2009) |
| Karpf (2007) | Karpf, Achim B. C. : Es muss nicht immer Cluster sein, 17.04.2007, http://www.netpress.de/uploads/media/IT-Administrator_High-Availability.pdf (14.02.2009) |
| K. Computerwoche (2006) | K., K. Computerwoche 23/2006 : Ein "Ever Run" für das Windows-Backend, 26.05.2006, http://www.computerwoche.de/heftarchiv/2006/23/1214793/ (14.02.2009) |
| Lenz (2005) | Lenz, Ulrich : Jenseits der Cluster, 08.11.2007, 16.05.2006, http://www.networkcomputing.de/jenseits-der-cluster/?no_cache=1 (14.02.2009) |
| Lenz (2007) | Lenz, Ulrich : Fehlertolerante Server unter Linux - Open Source ohne GAU, 25.01.2007, http://www.searchdatacenter.de/index.cfm?pid=4648&pk=66551&print=true&printtype=article# (14.02.2009) |
| Manhart (2005) | Dr.Manhart, Klaus : Networked Computing: Grundlagen und Anwendungen, 16.05.2006, http://www.tecchannel.de/index.cfm?pid=965&pk=439222&p=5 (14.02.2009) |
| Müller (2005) | Müller, Thomas : Management und Sicherheit von IT-Services - Kapitel 4.3 Verfügbarkeit, 05.04.2005, http://www.tu-chemnitz.de/urz/lehre/msis/script05/html/isd/ha.htm (14.02.2009) |
| Pelzer (2007) | Pelzer, Dirk : Fehlertolerante Server von Marathon und Stratus mit leichten Schwächen, 07.12.2007, http://www.computerwoche.de/knowledge_center/datacenter_und_server/1850007/index.html (14.02.2009) |
| Rohde (2008) | Rohde, Reiner : Diventus: Verfügbarkeistlösungen für Microsoft Windows, 29.05.2008, http://www.advantegy.com/pdf/download/EverRun%20RRO%2005%202008_Rohde.pdf (14.02.2009) |
| Zeitschriften |
| Joos, Thomas: Ausfallsicherheit für DHCP-Server unter Windows, in: Lan Line, 2008, Ausgabe 08, S. 44 bis 46 |
