Zum Inhalt springen

Rechnerverbund

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 11. November 2005 um 12:02 Uhr durch 80.136.221.89 (Diskussion) (→Cluster-Software). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Ein Computercluster, meist einfach Cluster, von engl. cluster = Traube, Bündel, Schwarm, genannt, bezeichnet eine Anzahl von vernetzten Computern, die zur parallelen Abarbeitung von zu einer Aufgabe gehörigen Teilaufgaben zur Verfügung stehen. Im Gegensatz zu Parallelrechnern (ein einzelner Prozess wird auf mehrere Rechner aufgeteilt) findet die Lastverteilung auf der Ebene einzelner Prozesse statt (mindestens ein Prozess wird auf einen Rechner verteilt), die auf einer oder verschiedenen Maschinen des Clusters gestartet werden. Man benötigt also keine parallelisierte Software oder spezielle Betriebssysteme, wohl aber einen Scheduler, der die Teilaufgaben den Einzelrechnern zuweist. Alternativ werden Cluster auch zum Steigern der Verfügbarkeit von Systemen genutzt (sog. failover clustering).

Clusterarten

Cluster bieten sich somit für die Abarbeitung von Batch-Jobs an, bei denen viele voneinander unabhängige Teilrechnungen durchgeführt werden müssen. Eine Menge von Teilaufgaben, die häufig synchronisiert werden müssen oder für sich genommen wenig CPU-Last erzeugen, sind für Cluster weniger geeignet, da die dafür notwendigen Kommunikationszeiten zwischen den Einzelrechnern (Nodes) den Performancegewinn wieder aufzehren.

Ein weiterer Vorteil eines Clusters ist die erhöhte Ausfallsicherheit. Wenn beispielsweise zwei Server an ein RAID-System angeschlossen sind, kann dieses System so konfiguriert werden, dass der Ausfall eines Rechners keinen Einfluss auf die Aufgabe des Clusters hat. Dies ist insbesondere bei Dateiservern von Interesse. Wenn ein Server ausfällt, sind die Daten immer noch erreichbar.

Von hochverfügbaren Systemen spricht man, wenn jede Komponente mehrfach vorhanden ist. Bei Clustern, deren Ziel die Ausfallsicherheit ist, wird zwischen hot-standby und active-active Clustern unterschieden.

Bei hot-standby Clustern wird nur auf einem Clusternode ein bestimmter Dienst ausgeführt. Fällt der primäre Dienstnode aus, übernimmt ein anderer Clusternode den Dienst der ausgefallenen Node. Durch diese Technik muss ein Dienst nicht explizit clusterfähig sein. Die failover-Funktion wird meist durch das Betriebssystem zur Verfügung gestellt (Servicefailover, IP-Übernahme). Die Übernahme von Services kann man z.B. durch Verschieben von IP-Adressen oder Verwenden einer Multicastadresse erreichen.

Bei active-active Clustern hingegen ist auf allen Clusternodes gleichzeitig ein Dienst aktiv. Unterschieden wird hier zwischen den Architekturen shared nothing und shared all.

Typischer Vertreter des active-active Clusters mit shared nothing Architektur ist DB2 mit EEE (sprich "triple i"). Hier beherbergt jeder Clusterknoten eine eigene Datenpartition. Ein Performancegewinn wird durch die Partitionierung der Daten und die damit einhergehende verteilte Verarbeitung erzielt. Ausfallsicherheit wird hiermit nicht gewährleistet.

Anders ist dies beim shared all Cluster. Diese Architektur gewährleistet durch einen konkurrierenden Zugriff auf Shared Storage, dass alle Clusterknoten auf den gesamten Datenbestand zugreifen können. Neben Skalierung und Performancesteigerung wird durch diese Architektur auch eine zusätzliche Ausfallsicherheit erreicht. Fällt ein Node aus, übernehmen die Anderen seine Aufgaben. Meist muss ein Dienst speziell für eine active-active Clusterung programmiert sein. So muss die Anwendung "cluster aware" sein. Eine Anwendung wird als cluster aware bezeichnet, wenn Sie auf spezielle Ereignisse (wie z.B. den Ausfall eines Clusterknotens in einem active-active Cluster) reagiert und diese in geeigneter Weise verarbeitet. Typischer Vertreter der shared all Architektur ist der Oracle Real Application Cluster (kurz: RAC).

In jüngster Zeit reihen sich immer mehr Linux-Cluster in die TOP500 der Superrechner ein.


Bei der Cluster Software der Firma SUN Microsystems, aktuell SUN Cluster 3.1 Release 8/05, ist eine feste Integration in den Solaris Kernel einer der Gründe, um seine heiklen Daten so einem Cluster anzuvertrauen. Es wird immer ein Quorum Device benötigt sowie (mindestens) zwei Interconnects, die meistens mit Gigabit Ethernet über LWL realisiert sind. Alternativ können auch andere Technologien, z.B. SCI (Scalable Coherent Interface) eingesetzt werden. Das Quorum Device ist Teil des Shared Storage, der heute meistens über ein SAN angesprochen wird (Bei dual-node Clustern kann auch gemeinsam genutzter SCSI-Storage implementiert werden). Die RAID LUNs werden auf dem SAN Storage (Hitachi 9970) auf mehrere Ports gemapped, diese werden dann in Solaris als Disk Device gesehen. Der CLuster Framework bietet die Möglichkeit den Datenzugriff auf einen anderen Node umzuschalten (Service Switch). Ein CLuster besteht immer aus definierten Ressourcen, wie dem Cluster Hostnamen. So können Clients zb immer auf den Webserver http://cluster.company.com , obwohl im Huntergrund die Server cluster-node1.company.com und cluster-node2.company.com seine Dienste bereitstellen. Diese Resource muss beim Failover mitgenommen werden, weil sonst wäre die Adresse cluster.company.com nicht erreichbar. Das selbe gilbt f. Datenbanken, DNS, DHCP, SAMBA,NFS Server die von einem zum anderen Node geswitcht werden können, die Daten die v. der Applikation geschrieben werden sind auf beiden Nodes (SAN) verfügbar. Zusätzlich werden Server verwendet die keinen od. nur wenige SPOF´s bieten (Single Point of Failure). So sind zb die Netzteile, Netzwerkanbindung, SAN Anbindung redundant ausgelegt. Das selbe Spiel auf der Netzwerk Seite , wo jeweils ein Kabel zu einem eigene Switch geht. Im SAN werden meist sogar zwei Hardware-RAID Storage Arrays per Software gespiegelt , es könnte ja das Metallgehäuse defekt werden (Jede Box hat aber auch 2 red. Controller+Netzteile). Bei grösseren StorageSystemen wird meist nur eines eingesetzt , weil dieses System in-sich redundant ausgelegt ist (zb StorEdge 9970). Mit dem fest in Solaris integrierten Volume Manager , Solaris Volume Manager (vorher SDS), können die Shared Disks in metasets verwaltet werden. Das selbe gilt für das Solaris build-in IPMP (IP Multi Pathing) , das red. Netz connections verwaltet. Ein typisches SUN Cluster Szenario besteht aus 2 SUN SPARC Servern (zb V440), zwei RAID Arrays (zb StorEdge 3510FC) und zwei Ethernet Switches (zb Cisco 3750).

Siehe auch

Literatur

Cluster-Software

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Rechnerverbund&oldid=10719192“