High-Availability Clustering

High-Availability
Clustering
Holger Hennig, HA-Cluster Specialist
HA Cluster
INHALTSVERZEICHNIS
1. ABSTRACT..............................................................................................................................3
2. EINFÜHRUNG .........................................................................................................................4
2.1 GRUNDLAGEN .........................................................................................................................4
2.2 DAS KONZEPT DES HA C LUSTERS .......................................................................................4
2.3 VORTEILE EINER HA C LUSTERLÖSUNG ................................................................................5
3. ARCHITEKTUR.......................................................................................................................6
3.1
3.2
3.3
3.4
ALLGEMEINES ........................................................................................................................6
SHARED ALL PRINZIP ............................................................................................................6
SHARED NOTHING PRINZIP ...................................................................................................7
MIRRORING PRINZIP ..............................................................................................................8
4. BETRIEBSMODI .....................................................................................................................9
4.1
4.2
4.3
4.4
GRUNDLAGEN ........................................................................................................................9
AKTIV – P ASSIV CLUSTERMODELL........................................................................................9
AKTIV – A KTIV CLUSTERMODELL ........................................................................................10
GEMISCHTE CLUSTERMODELLE ..........................................................................................11
5. AUFBAU EINES REDUNDANTEN DIENSTES...............................................................13
5.1 S TRUKTURELLER AUFBAU BEI MEHREREN CLUSTERGRUPPEN ...........................................15
5.2 PLANUNG VON CLUSTERRESSOURCEN...............................................................................16
6. WEBADRESSEN ZUM THEMA HA CLUSTERING .......................................................17
 Dieses Werk ist geistiges Eigentum der transtec AG.
www.transtec.de
Es darf ohne Zustimmung des Autors und der transtec AG weder kopiert noch auszugs weise abgedruckt
oder in einer anderen Form vervielfältigt werden.
Alle in dieser Publikation enthaltenen Informationen wurden mit größter Sorgfalt zusammengestellt.
Dennoch können fehlerhafte Angaben nicht völlig ausgeschlossen werden. Die transtec AG und der Autor
haften nicht für etwaige Fehler und deren Folgen.
Die in der Veröffentlichung verwendeten Soft- und Hardwarebezeichnungen sind häufig eingetragene
Warenzeichen. Sie werden ohne Gewährleistung der freien Verwendbarkeit genutzt. Das Abdrucken von
Waren- und Handelsnamen auf den folgenden Seiten berechtigt nicht zu der Annahme, diese Namen als
frei im Sinne der Markenschutzgesetzgebung zu betrachten.
 transtec AG
Seite 2/17
HA Cluster
1. ABSTRACT
Dieses Whitepaper soll IT Entscheidern und Administratoren einen Überblick über
die aktuelle HA (High Availability) Clustering Technologie verschaffen.
Es wird das Konzept des HA Clustering beschrieben sowie die Anforderungen,
die zum Betrieb eines HA Clusters notwendig sind. Des weiteren wird aufgezeigt,
welche Möglichkeiten existieren, Dienste auf Windows und Linux Plattformen
redundant zu halten.
Auf die Softwareaspekte, die bei der konkreten Installation eines Windows oder Linux
HA Clusters zu berücksichtigen sind, gehen wir in einer getrennten Publikation ein.
 transtec AG
Seite 3/17
HA Cluster
2. EINFÜHRUNG
2.1 Grundlagen
Die Verfügbarkeit von Serverdiensten und Applikationen sind unternehmenskritisch
geworden. Durch Ausfallzeiten entstehen einem Unternehmen Kosten und allzu oft auch
ein Imageschaden, vor dem man sich nur durch entsprechende Maßnahmen schützen
kann. Die Lösung sind Hochverfügbarkeits-Cluster.
Das Ziel eines HA Clusters ist es, die Downtime eines oder mehrerer Dienste möglichst
gering zu halten. Eine Verfügbarkeit von 100% ist nicht zu erhalten, sehr wohl aber
99,999%.
Um einen solchen Wert zu erreichen muss man die Zahl der sogenannten „Single Point
of Failure“ möglichst gering halten. Das beginnt beim redundanten Aufbau der
Serversysteme durch Clusterlösungen, geht über redundante USV-Anlagen bis hin zur
geographischen Trennung der Clusterpaare.
Verfügbarkeit
99%
99,9%
99,99%
99,999%
99,9999%
99,99999%
entsprechende Downtime
3,6 Tage Ausfall/Jahr
8,76 Stunden Ausfall/Jahr
52 Minuten Ausfall/Jahr
5 Minuten Ausfall/Jahr
30 Sekunden Ausfall/Jahr
3 Sekunden Ausfall/Jahr
Tab. 1: Verfügbarkeitsgrad und entsprechende Ausfalldauer
Unter Microsoft Windows und Linux Betriebsystemen steht das HA Clustering Feature
bereits seit geraumer Zeit zur Verfügung. Unter Windows seit NT 4.0 (Wulfpack),
fortgeführt mit dem Windows 2000 Advanced Server und nun dem Windows 2003
Enterprise Server von Microsoft. Unter Linux gibt es sowohl verschiedene Open Source
Projekte als auch kommerzielle Produkte für das HA Clustering, die mehr oder weniger
den gleichen Prinzipien entsprechen.
2.2 Das Konzept des HA Clusters
Ein Cluster besteht aus zwei oder mehreren Computern, die zu einem logischen System
zusammengefasst werden. Das Ziel ist eine bessere Verfügbarkeit, Verwaltbarkeit und
Erweiterbarkeit. Diese Aspekte werden in diesem Whitepaper ausführlich beleuchtet.
Wenn Fehler im Cluster auftreten, können Ressourcen anderer Knoten verwendet
werden. Der Benutzer bekommt in der Regel von dem Fehler nichts mit, auch entfällt
eine neue Verbindung mit seiner Applikation.
 transtec AG
Seite 4/17
HA Cluster
2.3 Vorteile einer HA Clusterlösung
•
Erweiterte Verfügbarkeit: Dienste und Applikationen, die auf dem Cluster laufen,
werden durch die HA Mechanismen redundant ausgelegt, so dass bei einem
Hardware- oder Softwarefehler die Dienste weiter zur Verfügung stehen. Ebenso
sind geplante Wartungen an den Servern durch Dienstmigration (manuelles
Verschieben der Dienste auf den anderen Knoten) einfacher und sicherer
durchzuführen.
•
Erweiterte Skalierbarkeit: unter dem Microsoft Windows Betriebssystem erhält
man mit Windows 2000 Advanced Server oder dem Windows 2003 Enterprise
Server eine erweiterte Unterstützung von bis zu 8 Prozessoren (normalerweise
nur 4) und Support von bis zu 8 GB RAM (normalerweise nur 4 GB). Bei beiden
Windowsversionen wie auch bei Linux, lässt sich die Hardware in einem
Clusterverbund einfacher erweitern. Erweiterungen für die CPU, RAM oder
Storage lassen sich durch eine geplante Downtime ohne Ausfall eines Dienstes
realisieren.
•
Verbessertes Management: die Managementkonsole der Clustersoftware stellt
den Cluster als ganzes dar. Die Ressourcen des gesamten Clusters lassen sich
softwaregeführt konfigurieren. Unter Linux finden auch grafikbasierte
Managementkonsolen (GUIs – Grafisches User Interface) Verwendung, die jedoch
weniger ausgereift sind als die Produkte der Windows Welt. Daher werden unter
Linux meist textbasierte Skripte bzw. globale Konfigurationsdateien verwendet, die
den gleichen Funktionsumfang besitzen wie eine grafische Konsole.
 transtec AG
Seite 5/17
HA Cluster
3. ARCHITEKTUR
3.1 Allgemeines
Für den Aufbau eines HA Clusters stehen drei unterschiedliche Architekturen zur
Auswahl. Sie unterscheiden sich in der Art, wie die einzelnen Knoten auf
Storagebereiche im Clusterverbund zugreifen.
Die Herausforderung besteht darin, nach einem Knotenausfall diejenigen Storagebereiche, die zuvor in Besitz des fehlerhaften Knotens waren, dem überlebenden Knoten
zur Verfügung zu stellen. Hierzu muss mit Shared Storage Lösungen gearbeitet werden,
bei denen alle Knoten die Möglichkeit haben, die gesamten Storagebereiche des
Clusters anzusprechen.
Im folgenden werden die einzelnen Architekturen ausführlicher beschrieben.
3.2 Shared All Prinzip
Beim „Shared All“ Prinzip haben alle Knoten Zugriff auf das gleiche Storagessystem 1. In
diesem Fall besteht die Gefahr, dass beide Knoten in das gleiche Dateisystem schreiben.
Ein solcher Zugriff ist unbedingt zu vermeiden, da dies leicht zu korrupten Daten führen
kann. Daher wird bei Shared All Lösungen ein DLM (Distributed Lock Manager)
verwendet, der den Zugriff der einzelnen Knoten steuert und parallele Zugriffe blockiert.
Cluster Knoten A
Cluster Knoten B
Externe Storageeinheit
SCSI oder Fibre Channel
Abb. 1: HA Cluster mit Shared All Storage
1 In der Regel handelt es sich hierbei um ein externes RAID System, wie beispielsweise das transtec 5016.
 transtec AG
Seite 6/17
HA Cluster
Dieses Prinzip kennt man schon seit längerem aus dem Bereich der VAX VMS Cluster
von Digital, die bereits vor 10 Jahren mit diesem Prinzip sehr stabil arbeiteten.
Aktuell werden nur noch wenige Cluster nach diesem Verfahren eingerichtet. Sowohl
unter Microsoft Windows also auch unter Linux wurde es vom nachfolgend
beschriebenen „Shared Nothing“ Prinzip abgelöst.
3.3 Shared Nothing Prinzip
Das „Shared Nothing“ Prinzip weist beiden Knoten ihre eigenen Storagebereiche zu. Die
Clusterknoten2 haben jedoch die Möglichkeit, die Storagebereiche des anderen Knotens
zusätzlich zu übernehmen. Zu keinem Zeitpunkt ist ein Datenbestand im Besitz von zwei
Knoten gleichzeitig. Dadurch wird ein gemeinsamer Zugriff auf gleiche Datenbestände
ausgeschlossen.
Bei diesem Konzept ist es wichtig sicherzustellen, dass die Kommunikation der Knoten
untereinander einwandfrei arbeitet. Es darf nicht nicht zu einer sogenannten „Split Brain“
Situation kommen, in der beide Knoten versuchen, denselben Storagebereich
anzusprechen. Der Zugriff beider Knoten in einen Storagebereich führt zu einer
Inkonsistenz des Dateisystems und somit zu Datenverlust.
Die gegenseitige Überwachung wird über eine eigene Netzwerkverbindung (Heartbeat)
gewährleistet. Um diesen Fehler sicher zu vermeiden geht man in manchen
Clusterlösungen sogar soweit, den ausgefallenen Knoten über einen Powerswitch
komplett vom Netz zu trennen um einen Crash des Clusters von vorneherein
auszuschließen. Die transtec AG verwendet diese Powerswitch Lösung bei Ihren Linux
Clustern. Bei Microsoft Lösungen wird dieser Fehler durch die Wertigkeit des Quorum
Devices (seperater Bereich auf dem Loggin Informationen abgelegt werden ) geregelt.
Cluster Knoten A
Cluster Knoten B
Datenbereich A
Datenbereich B
Externe Storageeinheit
SCSI oder Fibre Channel
Abb.2: Shared Nothing Prinzip
2
Hierbei kommen meist Dual Xeon Server wie der transtec 2600 zum Einsatz.
 transtec AG
Seite 7/17
HA Cluster
3.4 Mirroring Prinzip
Beim Mirroring Prinzip verfügt jeder Knoten über eigene Storagebereiche, die über eine
dedizierte Netzwerkverbindung gespiegelt werden. Es handelt sich also um eine
Serverbasierte RAID 1 – Lösung.
Sowohl im Microsoft als auch im Linux Bereich existieren hierfür spezielle Lösungen.
Unter Microsoft 2000 Server erlaubt z.B. der Legato Aadvanced Co-Standby Server, zwei
Knoten permanent auf dem gleichen Stand zu halten3. Der in der Enterpriseversion des
Windows 2000 Servers integrierte Clusterdienst verfügt nicht über diese MirrorFunktionalität.
Verwendet man eine Linux Distribution, kann das Linux Paket DRBD zum Einsatz
kommen, das Partitionen über das Netz synchronisiert.
Wie bei RAID 1 üblich müssen die Storagekapazitäten doppelt vorhanden sein.
Cluster Knoten A
Cluster Knoten B
Dedizierter Network Uplink
SCSI oder Fibre Channel
Storageeinheit
SCSI oder Fibre Channel
Storageeinheit
Abb. 3: Mirroring Prinzip 4
3
Die MS Windows 2000 Server Enterprise Version wird hierfür nicht benötigt.
transtec bietet für die Windows 2000 basierende Legato Lösung Produktbundles mit Vorortinstallation und
Konfiguration an.
4
 transtec AG
Seite 8/17
HA Cluster
4. BETRIEBSMODI
4.1 Grundlagen
Bei der Konzeptionierung eines HA Clusters muss zuerst der Betriebsmodus des
Clusters festgelegt werden. HA Cluster Knoten können entweder „Aktiv“ oder „Passiv“
betrieben werden.
•
Aktiver Knoten: der Knoten ist aktiv und bedient Clients mit Ressourcen (z.B. File
Sharing, DNS, Mail, Datenbank)
•
Passiver Knoten: der Knoten ist passiv, arbeitet auf “Standby” und überwacht
aktive Knoten um deren Ressourcen im Fehlerfall zu übernehmen
Daraus resultieren unterschiedliche Clustermodelle, die im folgenden näher beschrieben
werden.
4.2 Aktiv – Passiv Clustermodell
Auf dem „Aktiv-Passiv“ HA-Cluster arbeiten Dienste und Applikationen ausschließlich auf
dem aktiven Clusterknoten. Im Fehlerfall werden sie automatisch auf den passiven
Knoten transferiert. Solange der passive Knoten durch andere Aufgaben nicht belastet
wird, sollte ein Failover ohne Probleme funktionieren .
Eine Voraussetzung für das Betriebsmodell ist die identische Hardwareausstattung der
Knoten.
Cluster Knoten A
Cluster Knoten B
SQL Datenbank
wandert im Fehlerfall zu Knoten B
SCSI oder Fibre Channel
SCSI oder Fibre Channel
Externe Storageeinheit
Abb. 3: Aktiv – Passiv Clustermodell
 transtec AG
Seite 9/17
HA Cluster
4.3
Aktiv – Aktiv Clustermodell
Auf dem „Aktiv-Aktiv“ HA-Cluster arbeiten Dienste und Applikationen auf beiden
Clusterknoten. Im Fehlerfall stellen die Clusterknoten jeweils für den anderen die
Redundanz zur Verfügung. Hierbei ist allerdings der Workload, mit dem die
Clusterknoten betrieben werden, von entscheidender Bedeutung.
In unserem Beispiel in Abb. 4 muss ein Clusterknoten im Fehlerfall die SQL- und die
Maildienste übernehmen. Daher sind die Clusterknoten richtig zu dimensionieren, um für
den Fehlerfall die benötigten Reserven zur Verfügung zu stellen. Empfehlenswert ist eine
gleichmäßige Auslastung beider Knoten im Aktiv-Aktiv Betrieb. Dementsprechend sollte
der Workload je Knoten nicht über 50 % liegen.
Cluster Knoten A
wandert im Fehlerfall zu Knoten B
Cluster Knoten B
SQL Datenbank
Mail Server
wandert im Fehlerfall zu Knoten A
SCSI oder Fibre Channel
SCSI oder Fibre Channel
Externe Storageeinheit
Abb. 4: Aktiv - Aktiv Clustermodell
Sehr oft wird ein „Aktiv-Aktiv“ Cluster auch so verstanden, dass derselbe Dienst auf
beiden Clusterknoten läuft und eine Art „Load Balancing“ der Clientanfragen geschieht.
Dies ist nur sehr eingeschränkt möglich und wird nicht von allen Clustersystemen
unterstützt.
Die Ausnahme bietet Microsoft in den Produkten SQL Server 2000 und Exchange Server
2000/2003, die die Lastverteilung implementiert haben. Der Microsoft SQL Server 2000
erlaubt zum Beispiel die Partitionierung einer Datenbank und das Zuweisen einzelner
Datenbankpartitionen an einen Clusterknoten. Von einem echten Load Balancing kann
aber auch hier nicht gesprochen werden, da auch die Clientanfragen immer nur von
einem Knoten bedient werden (solange sich Anfragen in einer Partition befinden).
Dies gilt ebenso für den Exchange 2000/2003 Server, hier erfolgt die Partitionierung
anhand der Organisationsstruktur.
 transtec AG
Seite 10/17
HA Cluster
Der Aufbau dieses pseudo Load Balanced Aktiv-Aktiv Cluster ist wesentlich aufwändiger
und erfordert detaillierte Microsoft Windows Kenntnisse.
Unter Linux ist diese Art der Aufteilung ebenfalls möglich, es kommt aber stark auf die
Applikation an und ist im Einzelfall zu prüfen.
Die transtec bietet sowohl Aktiv-Passiv also auch Aktiv-Aktiv Lösungen in Ihrem
Produktspektrum an.
4.4 Gemischte Clustermodelle
Zu den Clustermodellen „Aktiv-Passiv“ und „Aktiv-Aktiv“, die man durchaus als
Standardmodelle bezeichnen kann, kommen noch spezielle Modelle hinzu, die von
aktuellen Clusterlösungen ebenfalls unterstützt werden.
Im Beispiel in Abb. 5 arbeiten die Knoten A, B und C als aktive Clusterknoten und stellen
ihre Ressourcen zur Verfügung. Der Knoten D ist als einziger passiv, stellt jedoch für die
anderen drei Clusterknoten den Failover Partner dar. In einem solchen Szenario
kommen die Vorteile eines SAN (Storage Area Network) voll zum tragen, da diese
Lösung über einen Fibre Channel Switch und ein Fibre Channel RAID System leicht
realisiert werden kann.
Eine Lösung auf SCSI Basis ist ebenfalls denkbar, sie erfordert im Vergleich dazu aber
einen höheren technischen Aufwand, da je Clusterverknüpfung ( A-D, B-D, C-D ) eine
eigene Shared Storage Lösung vorgesehen werden muss. Tritt der Fall ein, dass mehr
als ein Knoten ausfällt und der Backupknoten zusätzliche Dienste übernehmen muss,
sind seine Ressourcen in der Regel zu klein. Bei einer professionellen Lösung ist der
Knoten D daher anders zu dimensionieren als die Knoten A bis C.
Das Konzept des gemischten Clusters eignet sich aber auch hervorragend, um manuell
Dienste zu verschieben und danach Wartungsarbeiten oder Hardware Upgrades an den
Hauptservern vorzunehmen.
Server A
Server B
Server D
FC RAIDSystem
Server C
Abb. 5: Gemischter Cluster
 transtec AG
Seite 11/17
HA Cluster
Die gleiche Konstellation kann aber auch ganz anders verwendet werden:
Der Knoten D ist ein Quad Xeon System auf dem aktiv ein Mailserver, eine SQL
Datenbank und der zentrale DNS Server läuft. Es wäre möglich, die Knoten A, B und C
als Single CPU Server auszuführen und jeweils für einen Dienst verantwortlich zu
machen, hier wären die Knoten A, B und C passiv.
Im Fehlerfall könnten die Dienste dann verteilt werden.
•
•
•
 transtec AG
D -> A = Mail Server
D -> B = SQL Server
D -> C = DNS Server
Seite 12/17
HA Cluster
5. AUFBAU EINES REDUNDANTEN D IENSTES
Der schematische Aufbau eines redundanten Dienstes in einem HA-Cluster ist relativ
trivial.
Ein einzelner Dienst (Ressource) ist die kleinste verwaltbare Komponente in einem
Cluster. Bei einer Ressource kann es sich z.B. um eine IP Adresse, einen Netbios
Namen oder eine physikalische Festplatte handeln.
Ressourcen entwickeln untereinander Abhängigkeiten und werden in aller Regel zu
logischen Gruppen zusammengefasst. Als Beispiel werden die Abhängigkeiten eines
redundanten WWW-Dienstes aufgezeigt.
Um einen WWW Server auf einem Cluster oder auch standalone System zu betreiben,
benötigt man eine feste IP Adresse, einen Netzwerknamen unter dem der Server zu
erreichen ist, einen Storagebereich auf dem sich die Daten des WWW-Dienstes befinden
sowie den WWW-Dienst.
WWWDienst
Netzwerkname
Storagebereich
IP Adresse
Abb. 6: Abhängigkeiten eines Dienstes
Im Clustermanagement kann jede Ressource separat Online oder Offline geschalten
werden. In unserem Beispiel kann der WWW-Dienst erst dann Online gehen, wenn die
dazugehörige IP Adresse, der Netzwerkname und der Storagebereich zur Verfügung
stehen.
Somit entwickelt der WWW-Dienst Abhängigkeiten mit diesen drei Ressourcen. Die IP
Adresse und der Storagebereich hingegen entwickeln keine Abhängigkeiten und können
auch alleine Online gehen.
Die Ressourcen, um einen Dienst redundant aufzubauen, werden über die
Clustermanagement Software in logische Gruppen zusammengefasst.
Um den Dienst auf einen anderen Clusterknoten zu verschieben, muss nur die Gruppe
verschoben werden. Die Clustersoftware löst die Abhängigkeiten auf und schält
nacheinander die Ressourcen Offline.
 transtec AG
Seite 13/17
HA Cluster
Reihenfolge der Offline Schaltung des WWW-Dienst:
1. WWW-Dienst
2. Netzwerkname
3. Storagebereich
4. IP Adresse
In umgekehrter Reihenfolge werden die Ressourcen auf dem anderen Clusterknoten
wieder Online geschaltet.
Reihenfolge der Online Schaltung des WWW-Dienst:
1. IP Adresse
2. Netzwerkname
3. Storagebereich
4. WWW-Dienst
Schlägt eine Online Schaltung fehl, so steht der Dienst auch nicht mehr zur Verfügung.
 transtec AG
Seite 14/17
HA Cluster
5.1 Struktureller Aufbau bei mehreren Clustergruppen
In einem HA-Cluster werden die einzelnen zusammengehörenden Ressourcen in
Gruppen verwaltet. Über das Clustermanagement ist dann zu konfigurieren, auf welchem
Knoten die einzelnen Gruppen „aktiv“ laufen. Diese logischen Gruppen werden in einem
Fehlerfall, abhängig von Ihren Ressourcen, auf den überlebenden Knoten verschoben.
Cluster
Gruppe
DHCP
DHCP
Dienst
Netzwerkname
IP Adresse
A
Storage
Bereich A
Gruppe
WWW
WWWDienst
Netzwerkname
IP Adresse
B
Storage
Bereich B
Gruppe
SQL
SQL
Dienst
Netzwerk
Name
IP Adresse
C
Storage
Bereich C
Abb. 7: Struktur der Abhängigkeiten
 transtec AG
Seite 15/17
HA Cluster
5.2 Planung von Clusterressourcen
Aus der schematischen Darstellung in 5.1 geht hervor, dass für jede Clustergruppe eine
IP Adresse, ein Netzwerkname und ein separater Storagebereich zu planen ist.
Die Planung des Storagebereiches bedarf besonderer Aufmerksamkeit. Wird ein
externes RAID-System verwendet, so muss berücksichtig werden, dass für jeden
redundanten Dienst ein eigenes RAID-Set konfiguriert wird, welches dann unabhängig
von anderen Storagebereichen verschoben werden kann.
Es ist im Prinzip auch möglich, mehrere Ressourcen in einer Clustergruppe
zusammenzufassen, welche alle auf denselben Storagebereich zugreifen. Hierbei ist
allerdings zu berücksichtigen, dass beim Failover einer Ressource, die als Abhängigkeit
den Storagebereich inne hat, alle abhängenden Ressourcen verschoben werden
müssen.
Somit ist es nicht möglich, einzelne Dienste zu verschieben oder eine „aktiv-aktiv“
Konfiguration zu erstellen.
 transtec AG
Seite 16/17
HA Cluster
6. W EBADRESSEN ZUM THEMA HA CLUSTERING
Neuerungen beim Clustering mit Windows 2003 Enterprise Server:
http://www.microsoft.com/windowsserver2003/evaluation/overview/technologies/clusterin
g.mspx
HA-Clustering und NLB (Network Load Balancing):
http://www.microsoft.com/windows2000/technologies/clustering/
HA-Clustering unter Linux, mit dem Open Source Paket Failsafe:
http://oss.sgi.com/projects/failsafe/docs/functionality/
Das Linux HA-Projekt:
http://www.linux-ha.org/
Legato Co-Standby Server für Microsoft Windows:
http://portal1.legato.com/products/costandbyserver/
Linux mit GFS (Global File System) für „Shared-All“ Clustering:
http://www.sistina.com/products_gfs.htm
Linux Paket DRBD Netwerk RAID 1 für „Shared-All“ Clustering:
http://www.drbd.org
 transtec AG
Seite 17/17