Kapitel 3 Sun Cluster-Architektur

Mithilfe der Sun Cluster-Architektur können Systemgruppen als ein einziges, großes System bereitgestellt, verwaltet und angezeigt werden.

Dieses Kapitel enthält die folgenden Abschnitte:

• Sun Cluster-Hardwareumgebung

• Sun Cluster-Softwareumgebung

• Skalierbare Datendienste

• Multihost-Plattenspeicher

• Cluster-Interconnect

• IPMP-Gruppen

Sun Cluster-Hardwareumgebung

Ein Cluster setzt sich aus den folgenden Hardwarekomponenten zusammen:

• Cluster-Knoten mit lokalen, nicht gemeinsam genutzten Platten bilden die Hauptcomputerplattform des Clusters.

• Über Multihost-Speicher werden Platten bereitgestellt, die von den Knoten gemeinsam genutzt werden.

• Wechselmedien wie Bänder und CD-ROM sind als globale Geräte konfiguriert.

• Cluster-Interconnect ist der Kommunikationskanal zwischen den Knoten.

• Öffentliche Netzwerkschnittstellen aktivieren die Netzwerkschnittstellen, die von den Client-Systemen für den Zugriff auf Datendienste im Cluster verwendet werden.

Abbildung 3–1 zeigt, wie die Hardwarekomponenten zusammenarbeiten.

Abbildung 3–1 Sun Cluster-Hardwarekomponenten

Sun Cluster-Softwareumgebung

Auf einem Knoten, der als Cluster-Mitglied eingesetzt werden soll, muss folgende Software installiert sein:

• Solaris-Software

• Sun Cluster-Software

• Datendienstanwendung

• Datenträgerverwaltung (Solaris^TM Volume Manager oder VERITAS Volume Manager)

  Davon ausgenommen ist eine Konfiguration, die vorinstallierte Datenträgerverwaltung verwendet. Für eine solche Konfiguration ist möglicherweise kein Software-Datenträger-Manager erforderlich.

Abbildung 3–2 zeigt auf höchster Ebene die Softwarekomponenten, die gemeinsam die Sun Cluster-Softwareumgebung bilden.

Abbildung 3–2 Sun Cluster-Softwarearchitektur

Cluster-Mitgliedschaftsüberwachung (Cluster Membership Monitor, CMM)

Alle Knoten müssen eine konsistente Einigung hinsichtlich der Cluster-Mitgliedschaft erzielen, um die Daten vor Beschädigung zu schützen. Der CMM koordiniert gegebenenfalls eine Cluster-Rekonfiguration der Cluster-Dienste infolge eines Fehlers.

Der CMM erhält Informationen über die Konnektivität mit anderen Knoten aus der Cluster-Transportschicht. Der CMM verwendet während einer Rekonfiguration den Cluster-Interconnect zum Austauschen von Statusinformationen.

Nach dem Erkennen einer Änderung bei der Cluster-Mitgliedschaft führt der CMM eine synchronisierte Konfiguration des Clusters aus. Bei dieser Konfiguration können Cluster-Ressourcen auf Grundlage der neuen Mitgliedschaft im Cluster neu verteilt werden.

Der CMM wird vollständig im Kernel ausgeführt.

Cluster-Konfigurations-Repository (Cluster Configuration Repository, CCR)

Das CCR stellt mithilfe des CMM sicher, dass ein Cluster nur mit einem festgelegten Quorum läuft. Das CCR ist dafür zuständig, die Datenkonsistenz im ganzen Cluster zu überprüfen, eine ggf. erforderliche Wiederherstellung durchzuführen und Aktualisierungen für die Daten bereitzustellen.

Cluster-Dateisysteme

Ein Cluster-Dateisystem ist ein Proxy zwischen den folgenden Komponenten:

• Dem Kernel auf einem Knoten und dem zugrunde liegenden Dateisystem.

• Dem Datenträger-Manager, der auf einem Knoten mit realer Verbindung mit der Platte bzw. den Platten ausgeführt wird.

Cluster-Dateisysteme hängen von globalen Geräten (Platten, Bänder, CD-ROMs) ab. Der Zugriff auf globale Geräte ist von einem beliebigen Knoten im Cluster über den gleichen Dateinamen möglich, zum Beispiel /dev/global/. Für den Knoten ist keine reale Verbindung mit dem Speichergerät erforderlich. Sie können ein globales Gerät genauso verwenden wie ein normales Gerät, das heißt, Sie könen mit den Befehlen newfs oder mkfs Dateisysteme darauf erstellen.

Das Cluster-Dateisystem hat folgende Merkmale:

• Die Speicherorte für den Dateizugriff sind transparent. Ein Prozess kann eine Datei an einem beliebigen Speicherort im System öffnen. Zudem können die Prozesse die Datei auf allen Knoten mithilfe desselben Pfadnamens suchen.

  ---

  Hinweis –

  Wenn das Cluster-Dateisystem Dateien liest, wird die Zugriffszeit für diese Dateien nicht aktualisiert.

  ---

• Mit Kohärenzprotokollen wird die UNIX-Dateizugriffssemantik auch dann bewahrt, wenn mehrere Knoten gleichzeitig auf die Datei zugreifen.

• Umfasssendes Caching wird zusammen mit Bulk-E/A-Bewegungen ohne Zwischenspeicherung (Zero-Copy) eingesetzt, um Dateidaten effizient zu verschieben.

• Das Cluster-Dateisystem stellt mit den fcntl(2)-Schnittstellen eine hoch verfügbare kooperative Dateisperrfunktion zur Verfügung. Anwendungen, die auf mehreren Cluster-Knoten ausgeführt werden, können den Datenzugriff synchronisieren, indem sie die kooperative Dateisperrung auf eine Cluster-Dateisystemdatei anwenden. Dateisperren werden sofort von allen den Cluster verlassenden Knoten und von allen gesperrten und fehlgeschlagenen Anwendungen aufgehoben.

• Kontinuierlicher Datenzugriff ist auch bei Ausfällen gesichert. Anwendungen sind von den Ausfällen nicht betroffen, solange noch ein Pfad zu den Platten funktionsfähig ist. Diese Garantie gilt für den Plattenzugriff im raw-Modus und für alle Dateisystemvorgänge.

• Cluster-Dateisysteme sind vom zugrunde liegenden Dateisystem und von der Datenträgerverwaltung unabhängig. Cluster-Dateisysteme machen jedes unterstützte, auf den Platten vorhandene Dateisystem global.

Skalierbare Datendienste

Das wichtigste Ziel eines Cluster-Netzwerks besteht darin, Skalierbarkeit für Datendienste zu ermöglichen. Skalierbarkeit bedeutet, dass ein Datendienst trotz steigender Belastung eine konstante Antwortzeit beibehalten kann, weil dem Cluster neue Knoten hinzugefügt und neue Serverinstanzen ausgeführt werden. Ein gutes Beispiel für einen Scalable-Datendienst ist ein Webdienst. In der Regel besteht ein Scalable-Datendienst aus mehreren Instanzen, von denen jede auf unterschiedlichen Cluster-Knoten ausgeführt wird. Insgesamt verhalten sich diese Instanzen für einen Remote-Client wie ein einziger Dienst und führen die Funktionen dieses Dienstes aus. Bei einem Scalable-Webdienst mit mehreren httpd-Dämonen, die auf unterschiedlichen Knoten ausgeführt werden, kann jeder beliebige Dämon zum Bedienen einer Client-Anforderung eingesetzt werden. Welcher Dämon die Anforderung bedient, hängt vom Lastausgleichsverfahren ab. Die Antwort an den Client kommt scheinbar vom Dienst und nicht vom konkreten Dämon, der die Anforderung bedient hat, so dass der Eindruck eines einzigen Dienstes gewahrt wird.

Die nachstehende Abbildung zeigt eine Scalable-Dienst-Architektur.

Abbildung 3–3 Scalable-Datendienst-Architektur

Die Knoten, welche die globale Schnittstelle nicht hosten (Proxy-Knoten), hosten die gemeinsam genutzte Adresse auf ihren Schleifenschnittstellen. Die an der globalen Schnittstelle eintreffenden Pakete werden anhand konfigurierbarer Lastausgleichsverfahren auf andere Cluster-Knoten verteilt. Die möglichen Lastausgleichsverfahren werden im Folgenden beschrieben.

Lastausgleichsverfahren

Der Lastausgleich verbessert die Leistung der Scalable-Dienste sowohl bei der Antwortzeit als auch beim Durchsatz.

Es gibt zwei Klassen von Scalable-Datendiensten: reine Dienste und Sticky-Dienste. Ein reiner Dienst ist ein Dienst, bei dem jede Instanz Client-Anforderungen beantworten kann. Bei einem Sticky-Dienst sorgt der Cluster für den Lastausgleich bei Anforderungen an den Knoten. Diese Anforderungen werden nicht an andere Instanzen umgeleitet.

Ein reiner Dienst verwendet ein gewichtetes Lastausgleichsverfahren. Bei diesem Lastausgleichsverfahren werden Client-Anforderungen standardmäßig gleichmäßig auf die Serverinstanzen im Cluster verteilt. Wenn zum Beispiel bei einem Drei-Knoten-Cluster jedem Knoten die Gewichtung 1 zugewiesen ist, bedient jeder Knoten ein Drittel der Anforderungen eines beliebigen Clients für diesen Dienst. Gewichtungen können jederzeit über die scrgadm(1M)-Befehlsschnittstelle bzw. über die GUI von SunPlex-Manager geändert werden.

Es gibt zwei Typen von Sticky-Diensten: Normal-Sticky und Platzhalter-Sticky. Mit Sticky-Diensten können Sitzungen auf Anwendungsebene gleichzeitig über mehrere TCP-Verbindungen ausgeführt werden, um den Zustandsspeicher (Anwendungssitzungszustand) gemeinsam zu nutzen.

Mit normalen Sticky-Diensten kann ein Client den Zustand zwischen mehreren gleichzeitigen TCP-Verbindungen teilen. Ein Client wird als “Sticky” in Bezug auf die Serverinstanz bezeichnet, die einen einzigen Port abhört. Der Client hat die Sicherheit, dass alle seine Anforderungen an dieselbe Serverinstanz gehen. Voraussetzung hierfür ist, dass die Instanz aktiv und zugänglich bleibt und das Lastausgleichsverfahren nicht geändert wird, solange der Dienst online ist.

Platzhalter-Sticky-Dienste verwenden dynamisch zugewiesene Port-Nummern, erwarten jedoch trotzdem, dass die Client-Anforderungen an denselben Knoten geleitet werden. Der Client ist in Bezug auf dieselbe IP-Adresse “Sticky-Platzhalter” bei den Ports.

Multihost-Plattenspeicher

Die Sun Cluster-Software macht Platten mithilfe des Multihost-Plattenspeichers hoch verfügbar. Dieser Plattenspeicher kann an mehrere Knoten gleichzeitig angeschlossen werden. Mithilfe von Datenträgerverwaltungs-Software können diese Platten in einem gemeinsam genutzten Speicher mit einem Cluster-Knoten als Master angeordnet werden. Daraufhin werden die Platten so konfiguriert, dass sie bei Ausfällen auf einen anderen Knoten verschoben werden. Die Verwendung von Multihost-Platten für Sun Cluster-Systeme bietet zahlreiche Vorteile, unter anderem die folgenden:

• Globaler Zugriff auf Dateisysteme

• Mehrere Zugriffspfade auf Dateisysteme und Daten

• Toleranz einzelner Knotenausfälle

Cluster-Interconnect

Alle Knoten müssen mit dem Cluster-Interconnect über mindestens zwei redundante, real unabhängige Netzwerke oder Pfade verbunden sein, um einen Single Point of Failure (Ausfallpunkt) zu vermeiden. Für Redundanz sind zwei Interconnects erforderlich. Es können jedoch bis zu sechs verwendet werden, um den Datenverkehr zu verteilen, Engpässe zu vermeiden und Redundanz und Skalierbarkeit zu verbessern. Der Sun Cluster-Interconnect verwendet Fast Ethernet, Gigabit-Ethernet, InfiniBand, Sun Fire Link oder Scalable Coherent Interface (SCI, IEEE 1596-1992) und ermöglicht so hoch leistungsfähige Cluster-private Kommunikation.

In Cluster-Umgebungen sind Hochgeschwindigkeits-Interconnects und -Protokolle mit geringer Verzögerung für die Kommunikation zwischen den Knoten entscheidend. SCI-Interconnect in Sun Cluster-Systemen bietet verbesserte Leistung im Vergleich zu üblichen Netzwerk-Schnittstellenkarten (Network Inferface Cards, NICs). Sun Cluster verwendet die RSM^TM-Schnittstelle (Remote Shared Memory) für die Kommunikation zwischen den Knoten über ein Sun Fire Link-Netzwerk. RSM ist eine Sun-Schnittstelle zur Meldungsübertragung, die bei Remote-Speichervorgängen sehr effizient ist.

Der RSMRDT-Treiber (RSM Reliable Datagram Transport) umfasst einen Treiber, der auf der RSM-API basiert und eine Bibliothek, die die RSMRDT-API-Schnittstelle exportiert. Dieser Treiber verbessert die Leistung der Oracle Parallel Server/Real Application-Cluster. Darüber hinaus verbessert er die Lastausgleichs- und Hochverfügbarkeits-Funktionen (HA) durch direkte Bereitstellung im Treiber und somit transparente Verfügbarkeit für die Clients.

Der Cluster-Interconnect besteht aus folgenden Hardwarekomponenten:

• Adapter – Die Netzwerk-Schnittstellenkarten, die sich in jedem Cluster-Knoten befinden. Ein Netzwerkadapter mit mehreren Schnittstellen kann zu einem Single Point of Failure werden, wenn der ganze Adapter ausfällt.

• Verbindungspunkte – Die Schalter, die sich außerhalb des Cluster-Knotens befinden. Verbindungspunkte übernehmen Pass-Through- und Umschaltfunktionen, damit Sie mehr als zwei Knoten zusammenschließen können. In einem Zwei-Knoten-Cluster benötigen Sie keine Verbindungspunkte, weil die Knoten mit redundanten realen Kabeln direkt miteinander verbunden werden können. Diese redundanten Kabel werden auf jedem Knoten mit redundanten Adaptern verbunden. Für Konfigurationen mit mehr als zwei Knoten sind Verbindungspunkte erforderlich.

• Kabel – Die realen Verbindungen, entweder zwischen zwei Netzwerkadaptern oder zwischen einem Adapter und einem Verbindungspunkt.

Abbildung 3–4 zeigt, wie die drei Komponenten miteinander verbunden sind.

Abbildung 3–4 Cluster-Interconnect

IPMP-Gruppen

Öffentliche Netzwerkadapter sind als IPMP-Gruppen (Multipathing-Gruppen) organisiert. Jede Multipathing-Gruppe hat mindestens einen öffentlichen Netzwerkadapter. Jeder Adapter in einer Multipathing-Gruppe kann aktiv sein oder Sie können Standby-Schnittstellen konfigurieren, die bis zum Auftreten eines Failovers inaktiv bleiben.

Multipathing-Gruppen bilden die Grundlage für logische Hostnamen und gemeinsam genutzte Adressen. Dieselbe Multipathing-Gruppe kann auf einem Knoten eine beliebige Anzahl logischer Hostnamen oder gemeinsam genutzter Adressen hosten. Multipathing kann erstellt werden, um die Konnektivität von Cluster-Knoten mit dem öffentlichen Netzwerk zu überwachen.

Weitere Informationen zu logischen Hostnamen und gemeinsam genutzten Adressen finden Sie im Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Öffentliche Netzwerkschnittstellen

Die Verbindung der Clients mit dem Cluster erfolgt über die öffentlichen Netzwerkschnittstellen. Jede Netzwerkadapterkarte kann an ein oder mehrere öffentliche Netzwerke angeschlossen sein, je nachdem, ob die Karte mehrere Hardwareschnittstellen hat. Sie können Knoten mit mehreren öffentlichen Netzwerk-Schnittstellenkarten einrichten, die so konfiguriert sind, dass mehrere Karten aktiv sind und dadurch gegenseitig als Failover-Sicherung dienen. Wenn einer der Adapter ausfällt, wird die Solaris-IP-Multipathing-Software für Sun Cluster aufgerufen, um für die fehlerhafte Schnittstelle ein Failover zu einem anderen Adapter in der Gruppe auszuführen.