Kapitel 2 Schlüsselkonzepte für Sun Cluster

In diesem Kapitel werden die Schlüsselkonzepte für die Hardware- und Softwarekomponenten des Sun Cluster-Systems erläutert, mit denen Sie vor der Arbeit mit Sun Cluster-Systemen vertraut sein sollten.

Dieses Kapitel enthält die folgenden Abschnitte:

• Cluster-Knoten

• Cluster-Interconnect

• Cluster-Mitgliedschaft

• Cluster-Konfigurations-Repository

• Fehler-Monitore

• Quorum-Geräte

• Geräte

• Datendienste

Cluster-Knoten

Ein Cluster-Knoten ist ein Rechner, auf dem sowohl die Solaris-Software als auch die Sun Cluster-Software ausgeführt wird. Mit der Sun Cluster-Software können Sie zwei bis acht Knoten in einen Cluster einbinden.

Cluster-Knoten sind im Allgemeinen an mindestens eine Platte angeschlossen. Nicht an Platten angeschlossene Knoten verwenden das Cluster-Dateisystem zum Zugriff auf die Multihostplatten. Knoten in Konfigurationen paralleler Datenbanken teilen den Zugriff auf einige oder alle Platten.

Jeder Knoten im Cluster nimmt wahr, wenn ein anderer Knoten dem Cluster beitritt oder diesen verlässt. Daneben nimmt jeder Knoten sowohl die lokalen Ressourcen als auch die Ressourcen auf den anderen Cluster-Knoten wahr.

Knoten innerhalb desselben Clusters sollten eine vergleichbare Verarbeitungs-, Speicher- und E/A-Kapazität aufweisen, so dass ein Failover ohne nennenswerten Leistungsabfall möglich ist. Da Failover vorkommen können, muss jeder Knoten für den Fall eines Knotenversagens über ausreichende Kapazität zur Erfüllung der Dienstebenenvereinbarungen (Service Level Agreements, SLA) verfügen.

Cluster-Interconnect

Der Cluster-Interconnect ist die reale Konfiguration der Geräte, die für die Übertragung von Cluster-privaten Kommunikationen und Datendienstkommunikationen zwischen Cluster-Knoten eingesetzt werden.

Über redundante Interconnects wird der Betrieb auf funktionsfähigen Interconnects aufrechterhalten, während die Systemverwalter Fehler isolieren und die Kommunikation wieder herstellen. Die Sun Cluster-Software erkennt und repariert Fehler und startet die Kommunikation automatisch über einen reparierten Interconnect neu.

Weitere Informationen finden Sie im Abschnitt Cluster-Interconnect.

Cluster-Mitgliedschaft

Der Cluster-Mitglieder-Monitor (CMM) ist ein verteilter Satz von Agenten, die Nachrichten über den Cluster-Interconnect austauschen, um folgende Aufgaben auszuführen:

• Erzwingen einer konsistenten Mitgliederansicht auf allen Knoten (Quorum)

• Steuern einer synchronisierten Rekonfiguration als Reaktion auf Mitgliedschaftsänderungen

• Abwickeln der Cluster-Partitionierung

• Sicherstellen von vollständiger Konnektivität zwischen allen Cluster-Mitgliedern, indem fehlerhafte Knoten bis zu deren Reparatur aus dem Cluster ausgeschlossen werden

Die Hauptfunktion des CMM besteht im Festlegen der Cluster-Mitgliedschaft. Hierfür ist eine Cluster-weite Einigung über den Knotensatz, der zum jeweiligen Zeitpunkt am Cluster teilnimmt, erforderlich. Der CMM stellt wichtige Cluster-Statusänderungen auf den Knoten fest, wie zum Beinspiel den Kommunikationsverlust zwischen einem oder mehreren Knoten. Der CMM nutzt das Transport-Kernel-Modul zum Generieren von Heartbeats über das Transportmedium an andere Knoten im Cluster. Wenn der CMM innerhalb einer definierten Zeitüberschreitungsperiode keinen Heartbeat eines Knoten feststellt, wird davon ausgegangen, dass der Knoten ausgefallen ist, und der CMM startet eine Cluster-Rekonfiguration, um die Cluster-Mitgliedschaft neu zu verhandeln.

Der CMM führt folgende Aufgaben aus, um die Cluster-Mitgliedschaft festzulegen und die Datenintegrität sicherzustellen:

• Festhalten von Änderungen bei der Cluster-Mitgliedschaft, zum Beispiel ein Knoten, der dem Cluster beitritt oder diesen verlässt.

• Sicherstellen, dass ein fehlerhafter Knoten den Cluster verlässt.

• Sicherstellen, dass ein fehlerhafter Knoten bis zu seiner Reparatur inaktiv bleibt.

• Verhindern, dass der Cluster sich selbst in Knoten-Teilsätze partitioniert.

Weitere Informationen darüber, wie sich der Cluster vor der Partitionierung in mehrere getrennte Cluster schützt, finden Sie unter Datenintegrität.

Cluster-Konfigurations-Repository

Das Cluster-Konfigurations-Repository (CCR) ist eine private, Cluster-weite, verteilte Datenbank zur Speicherung von Informationen über Konfiguration und Zustand des Clusters. Um eine Beschädigung der Konfigurationsdaten zu vermeiden, muss jedem Knoten der aktuelle Zustand der Cluster-Ressourcen bekannt sein. Das CCR stellt sicher, dass alle Knoten ein konsistentes Bild des Clusters haben. Das CCR wird aktualisiert, wenn Fehler- bzw. Wiederherstellungssituationen auftreten bzw. wenn sich der allgemeine Status des Clusters ändert.

Die CCR-Strukturen enthalten folgende Informationstypen:

• Cluster- und Knotennamen

• Cluster-Transportkonfiguration

• Namen der Solaris Volume Manager-Plattensätze bzw. VERITAS-Plattengruppen

• Eine Liste der Knoten, die die einzelnen Plattengruppen unterstützen können

• Betriebsparameterwerte für Datendienste

• Pfade zu Datendienst-Rückmeldemethoden

• DID-Gerätekonfiguration

• Aktueller Cluster-Status

Fehler-Monitore

Das Sun Cluster-System macht alle Komponenten auf dem ”Pfad” zwischen Benutzern und Daten hoch verfügbar, indem die Anwendungen selbst, das Dateisystem und die Netzwerkschnittstellen überwacht werden.

Die Sun Cluster-Software stellt ein Knotenversagen rasch fest und erstellt einen äquivalenten Server für die Ressourcen auf dem ausgefallenen Knoten. Die Sun Cluster-Software stellt sicher, dass die vom Knotenversagen nicht betroffenen Ressourcen während der Wiederherstellungsphase konstant verfügbar bleiben und dass die Ressourcen des ausgefallenen Knotens unmittelbar nach ihrer Wiederherstellung wieder verfügbar werden.

Datendienstüberwachung

Jeder Sun Cluster-Datendienst stellt einen Fehler-Monitor zur Verfügung, der regelmäßig den Datendienst auf einwandfreies Funktionieren prüft. Ein Fehler-Monitor überprüft, ob der Anwendungsdämon bzw. die -dämone laufen und die Clients bedient werden. Je nach den von den Testsignalen zurückgegebenen Informationen können vordefinierte Aktionen, wie ein Neustart des Dämons oder ein Failover, eingeleitet werden.

Plattenpfadüberwachung

Die Sun Cluster-Software unterstützt Plattenpfadüberwachung (Disk-Path Monitoring, DPM). DPM verbessert insgesamt die Zuverlässigkeit von Failover- bzw. Switchover-Vorgängen, indem das Versagen eines sekundären Plattenpfads gemeldet wird. Eine der beiden folgenden Methoden kann zur Plattenpfadüberwachung verwendet werden. Die erste Methode wird mit dem scdpm-Befehl zur Verfügung gestellt. Mit diesem Befehl können Sie die Plattenpfade im Cluster überwachen, die Überwachung aufheben oder deren Status anzeigen. Weitere Informationen zu Befehlszeilenoptionen finden Sie unter scdpm(1M).

Die zweite Methode zur Überwachung von Plattenpfaden im Cluster wird von der grafischen Benutzeroberfläche (Grafical User Interface, GUI) von SunPlex-Manager zur Verfügung gestellt. SunPlex-Manager bietet eine topologische Ansicht der überwachten Plattenpfade. Die Ansicht wird alle 10 Minuten aktualisiert, um Informationen zur Anzahl der fehlgeschlagenen Pings zu liefern.

IP-Multipath-Monitoring

Jeder Cluster-Knoten hat seine eigene IP network multipathing-Konfiguration, die sich von der auf anderen Cluster-Knoten unterscheiden kann. IP network multipathing überwacht die folgenden Netzwerk-Kommunikationsfehler:

• Der Übertragungs- und Empfangspfad des Netzwerkadapters überträgt keine Pakete mehr.

• Die Verbindung des Netzwerkadapters mit der Verknüpfung ist zusammengebrochen.

• Der Port des Schalters überträgt bzw. empfängt keine Pakete.

• Die reale Schnittstelle in einer Gruppe ist beim Booten des Systems nicht vorhanden.

Quorum-Geräte

Ein Quorum-Gerät ist eine Platte, die von zwei oder mehr Knoten gemeinsam genutzt wird und Stimmen abgibt. Die Stimmen dienen der Feststellung des Quorums für den Betrieb des Clusters. Der Cluster kann nur arbeiten, wenn ein Quorum von Stimmen verfügbar ist. Das Quorum-Gerät wird verwendet, wenn ein Cluster in separate Knotensätze partitioniert wird, um festzulegen, welcher Knotensatz den neuen Cluster bildet.

Sowohl Cluster-Knoten als auch Quorum-Geräte geben eine Stimme für das Quorum ab. Standardmäßig erhalten Cluster-Knoten eine Stimmenanzahl von Eins für das Quorum, sobald sie booten und Cluster-Mitglieder werden. Knoten können eine Stimmenanzahl von Null haben, wenn der Knoten gerade installiert wird oder wenn ein Verwalter den Knoten in Wartungszustand versetzt hat.

Quorum-Geräte erhalten eine Stimmenanzahl für das Quorum, die sich nach der Anzahl von Knotenverbindungen mit dem Gerät richtet. Wenn ein Quorum-Gerät konfiguriert wird, erhält es eine maximale Stimmenanzahl von N-1, wobei N der Anzahl der mit dem Quorum-Gerät verbundenen Stimmen entspricht. Ein Quorum-Gerät, das zum Beispiel mit zwei Knoten mit einer Stimmenanzahl von nicht Null verbunden ist, hat einen Quorum-Zählwert von Eins (Zwei minus Eins).

Datenintegrität

Das Sun Cluster-System versucht, Datenbeschädigung zu verhindern und Datenintegrität sicherzustellen. Da Cluster-Knoten Daten und Ressourcen gemeinsam nutzen, darf ein Cluster nie in gleichzeitig aktive, getrennte Partitionen unterteilt werden. Der CMM stellt sicher, dass jeweils nur ein Cluster in Betrieb ist.

Zwei Arten von Problemen können aufgrund der Partitionierung von Clustern auftreten: Split Brain und Amnesie. Zum Split Brain kommt es, wenn der Cluster-Interconnect zwischen den Knoten verloren geht und der Cluster in Teil-Cluster zerfällt, die sich jeweils als die einzige Partition wahrnehmen. Ein Teil-Cluster, der keine weiteren Teil-Cluster wahrnimmt, kann Konflikte bei gemeinsam genutzten Ressourcen verursachen, wie zum Beispiel duplizierte Netzwerkadressen und Datenbeschädigung.

Amnesie tritt ein, wenn alle Knoten den Cluster in gestaffelten Gruppen verlassen. Beispiel: Ein Cluster hat zwei Knoten, A und B. Wenn A ausfällt, werden die Konfigurationsdaten im CCR nur auf Knoten B, nicht aber auf Knoten A aktualisiert. Wenn später Knoten B ausfällt, wird Knoten A neu gestartet und mit alten CCR-Inhalten ausgeführt. Dieser Zustand wird als Amnesie bezeichnet und kann dazu führen, dass ein Cluster mit veralteten Konfigurationsinformationen läuft.

Split Brain und Amnesie können vermieden werden, indem jeder Knoten eine Stimme erhält und eine Stimmenmehrzahl für den Betrieb eines Clusters vorgeschrieben wird. Eine Partition mit der Mehrheit der Stimmen hat ein Quorum und wird für den Betrieb aktiviert. Dieser Mechanismus der Stimmenmehrzahl funktioniert gut, wenn ein Cluster über mehr als zwei Knoten verfügt. In einem Zwei-Knoten-Cluster ist zwei eine Mehrheit. Wenn ein solcher Cluster in Partitionen zerfällt, sorgt eine externe Stimme für ein Quorum bei einer der Partitionen. Diese externe Stimme wird von einem Quorum-Gerät beigesteuert. Ein Quorum-Gerät kann jede beliebige Platte sein, die von den beiden Knoten gemeinsam genutzt wird.

In Tabelle 2–1 wird beschrieben, wie die Sun Cluster-Software das Quorum zur Vermeidung von Split Brain und Amnesie einsetzt.

Tabelle 2–1 Cluster-Quorum und Split Brain- und Amnesie-Probleme

Partitionstyp	Quorum-Lösung
Split Brain	Ermöglicht nur der Partition (Teil-Cluster) mit Stimmenmehrzahl die Ausführung als Cluster. Nur eine Partition mit einer solchen Mehrheit ist möglich. Nachdem ein Knoten den Kampf um das Quorum verloren hat, gerät er in Panik.
Amnesie	Stellt sicher, dass beim Booten eines Clusters mindestens ein Knoten zum Cluster gehört, der Mitglied der letzten Cluster-Mitgliedschaft war (und somit über die neuesten Konfigurationsdaten verfügt).

Fehlerschutz

Ein wichtiges Thema bei Clustern ist ein Fehler, der zur Partitionierung des Clusters führt (als Split Brain bezeichnet). In diesem Fall können nicht mehr alle Knoten miteinander kommunizieren, so dass einzelne Knoten oder Knoten-Teilsätze ggf. versuchen, Einzel- oder Untermengen-Cluster zu bilden. Jede Untermenge oder Partition kann davon “überzeugt” sein, alleinigen Zugriff auf die Multihost-Platten und die Eigentümerschaft zu haben. Wenn mehrere Knoten versuchen, auf die Platten zu schreiben, kann dies zu Datenbeschädigung führen.

Der Fehlerschutz schränkt den Knotenzugriff auf die Multihostplatten ein, indem der Zugriff auf die Platten verhindert wird. Wenn ein Knoten den Cluster verlässt (aufgrund eines Ausfalls oder Partitionierung), wird mit dem Fehlerschutz sichergestellt, dass der Knoten keinen Zugriff mehr auf die Platte hat. Nur aktuelle Mitgliederknoten haben Zugriff auf die Platten. Das sichert die Datenintegrität.

Das Sun Cluster-System verwendet SCSI-Plattenreservierungen zur Implementierung des Fehlerschutzes. Mit den SCSI-Reservierungen werden die Multihostplatten vor den ausgefallenen Knoten “geschützt” und der Zugriff auf diese Platten wird verhindert.

Wenn ein Cluster-Mitglied erkennt, dass ein anderer Knoten nicht mehr über den Cluster-Interconnect kommuniziert, leitet es ein Fehlerschutzverfahren ein, um den ausgefallenen Knoten am Zugriff auf die gemeinsam genutzten Platten zu hindern. Wenn dieser Fehlerschutz eintritt, gerät der geschützte Knoten in Panik, und eine Meldung zum “Reservierungskonflikt” wird auf seiner Konsole angezeigt.

Failfast-Mechanismus für Fehlerschutz

Der Failfast-Mechanismus versetzt einen fehlerhaften Knoten in Panik, hindert ihn aber nicht an einem Neustart. Anschließend kann der Knoten neu booten und versuchen, wieder dem Cluster beizutreten.

Wenn ein Knoten die Konnektivität mit anderen Knoten im Cluster verliert und nicht zu einer Partition gehört, die ein Quorum erzielen kann, wird er erzwungenermaßen von einem anderen Knoten aus dem Cluster entfernt. Ein anderer Knoten, der Teil der Partition ist, die ein Quorum erzielen kann, belegt die gemeinsam genutzten Platten mit Reservierungen. Der Knoten ohne Quorum gerät dann infolge des Failfast-Mechanismus in Panik.

Geräte

Das globale Dateisystem macht alle Dateien im Cluster auf allen Knoten gleichermaßen verfügbar und sichtbar. Auf die gleiche Art und Weise macht die Sun Cluster-Software alle Geräte eines Clusters Cluster-weit verfügbar und sichtbar. Das heißt, dass das E/A-Teilsystem Zugriff auf ein beliebiges Gerät im Cluster von jedem Knoten aus ermöglicht, unabhängig davon, wo das Gerät real angeschlossen ist. Dieser Zugriff wird als globaler Gerätezugriff bezeichnet.

Globale Geräte

Sun Cluster-Systeme verwenden globale Geräte, um Cluster-weiten, hoch verfügbaren Zugriff auf alle Geräte im Cluster von jedem Knoten aus zu ermöglichen. Wenn ein Knoten ausfällt, während er Zugriff auf ein globales Gerät gewährt, schaltet die Sun Cluster-Software normalerweise zu einem anderen Pfad zu dem Gerät um und leitet den Zugriff auf diesen Pfad um. Diese Umleitung lässt sich mit globalen Geräten problemlos ausführen, weil pfadunabhängig immer der gleiche Gerätename verwendet wird. Der Zugriff auf ein Remote-Gerät erfolgt auf die gleiche Weise wie auf ein gleichnamiges lokales Gerät. Auch die API für den Zugriff auf ein globales Gerät auf dem Cluster ist die gleiche wie diejenige, die für den lokalen Zugriff auf ein Gerät verwendet wird.

Zu den globalen Geräten bei Sun Cluster gehören Platten, CD-ROMs und Bänder. Platten sind jedoch die einzigen unterstützten globalen Multiport-Geräte. Diese eingeschränkte Unterstützung bedeutet, dass CD-ROM- und Bandgeräte derzeit keine hoch verfügbaren Geräte sind. Die lokalen Platten auf jedem Server sind ebenfalls keine Multiport-Geräte und deswegen nicht hoch verfügbar.

Der Cluster weist jeder Platte, jedem CD-ROM-Laufwerk und jedem Bandgerät im Cluster eine einmalige ID zu. Diese Zuweisung ermöglicht einen konsistenten Zugriff auf jedes Gerät von jedem Cluster-Knoten aus.

Geräte-ID

Die Sun Cluster-Software verwaltet globale Geräte über einen so genannten Geräte-ID-Treiber (DID-Treiber). Der Treiber weist jedem Gerät im Cluster, darunter Multihost-Platten, Bandlaufwerken und CD-ROMs, automatisch einmalige IDs zu.

Der DID-Treiber ist fester Bestandteil der Zugriffsfunktion auf globale Geräte des Clusters. Der DID-Treiber sendet ein Testsignal an alle Knoten des Clusters und erstellt eine Liste der einmaligen Plattengeräte. Er weist auch jedem Gerät eine einmalige Geräteklassen- und Gerätenummer zu, die über alle Cluster-Knoten hinweg konsistent ist. Der Zugriff auf die globalen Geräte erfolgt über die einmalige, vom DID-Treiber zugewiesene DID, nicht über die üblichen Solaris-DIDs.

Damit wird sichergestellt, dass alle Anwendungen, die auf Platten zugreifen, wie zum Beispiel Solaris Volume Manager oder Sun Java System Directory Server, Cluster-weit einen konsistenten Pfad verwenden. Diese Konsistenz ist besonders für Multihost-Platten wichtig, da die lokalen Geräteklassen- und Gerätenummern für die einzelnen Geräte von Knoten zu Knoten unterschiedlich sein können. Die Nummern können auch die Solaris-Konventionen zur Gerätebenennung ändern.

Lokale Geräte

Die Sun Cluster-Software verwaltet auch lokale Geräte. Auf solche Geräte kann nur auf einem Knoten zugegriffen werden, der einen Dienst ausführt und real an den Cluster angeschlossen ist. Lokale Geräte erbringen möglicherweise bessere Leistung als globale Geräte, da sie keine Zustandsinformationen auf mehreren Knoten gleichzeitig replizieren müssen. Wenn die Gerätedomäne versagt, entfällt auch der Zugriff auf das Gerät, wenn es nicht von mehreren Knoten gemeinsam genutzt werden kann.

Plattengerätegruppen

Durch Plattengerätegruppen werden Datenträger-Manager-Plattengruppen “global”, da hierdurch den zugrunde liegenden Platten Multipath- und Multihost-Unterstützung zur Verfügung gestellt wird. Jeder mit den Multihostplatten real verbundene Cluster-Knoten stellt einen Pfad zur Plattengerätegruppe zur Verfügung.

Im Sun Cluster-System können Multihostplatten von der Sun Cluster-Software gesteuert werden, wenn sie als Plattengerätegruppen registriert werden. Durch die Registrierung erhält das Sun Cluster-System Informationen darüber, welche Knoten über Pfade zu welchen Datenträger-Manager-Plattengruppen verfügen. Die Sun Cluster-Software erstellt eine im raw-Modus betriebene Plattengerätegruppe für jedes Plattengerät und Bandlaufwerk im Cluster. Diese Cluster-Gerätegruppen bleiben so lange im Zustand “Offline”, bis auf sie als globale Geräte zugegriffen wird. Dies geschieht entweder durch Einhängen eines globalen Dateisystems oder durch Zugriff auf eine raw-Datenbankdatei.

Datendienste

Ein Datendienst besteht aus einer Kombination aus Software- und Konfigurationsdateien, mit deren Hilfe eine Anwendung ohne Änderung in einer Sun Cluster-Konfiguration ausgeführt werden kann. Wenn eine Sun Cluster-Konfiguration ausgeführt wird, läuft eine Anwendung als Ressource unter der Steuerung von Resourcengruppen-Manager (RGM). Mit einem Datendienst kann eine Anwendung wie Sun Java System Web Server oder eine Oracle-Datenbank für die Ausführung auf einem Cluster anstelle eines einzelnen Servers konfiguriert werden.

Die Datendienstsoftware implementiert Sun Cluster-Verwaltungsmethoden, die folgende Vorgänge an der Anwendung ausführen:

• Starten der Anwendung

• Stoppen der Anwendung

• Überwachen der Fehler in der Anwendung und Wiederherstellen nach Fehlern

Die Konfigurationsdateien eines Datendienstes definieren die Eigenschaften der Ressource, die eine Anwendung für RGM darstellt.

RGM steuert die Anordnung der Failover- und Scalable-Datendienste im Cluster. RGM ist für das Starten und Stoppen der Datendienste auf ausgewählten Cluster-Knoten zuständig, als Reaktion auf Änderungen bei der Cluster-Mitgliedschaft. RGM aktiviert Datendienstanwendungen für die Nutzung des Cluster-Frameworks.

RGM steuert Datendienste als Ressourcen. Diese Implementierungen werden entweder von Sun bereitgestellt oder von einem Entwickler erstellt. Der Entwickler kann eine generische Datendienstvorlage, die Datendienst-Entwicklungsbibliotheks-API (DSDL-API) oder die Ressourcenverwaltungs-API (RMAPI) nutzen. Der Cluster-Verwalter erstellt und verwaltet Ressourcen in Containern, die als Ressourcengruppen bezeichnet werden. Durch RGM- oder Verwalteraktionen werden Ressourcen und Ressourcengruppen in den Zustand “Online” bzw. “Offline” versetzt.

Ressourcentypen

Ein Ressourcentyp ist eine Sammlung von Eigenschaften, die eine Anwendung für den Cluster beschreiben. Diese Sammlung enthält Informationen darüber, wie die Anwendung auf den Cluster-Knoten gestartet, gestoppt und überwacht wird. Ein Ressourcentyp enthält auch anwendungsspezifische Eigenschaften, die für die Verwendung der Anwendung im Cluster definiert werden müssen. Sun Cluster-Datendienste verfügen über mehrere vordefinierte Ressourcentypen. Sun Cluster HA für Oracle ist zum Beispiel der Ressourcentyp SUNW.oracle-server und Sun Cluster HA für Apache der Ressourcentyp SUNW.apache.

Ressourcen

Eine Ressource ist eine Instanz eines Ressourcentyps, der Cluster-weit definiert ist. Der Ressourcentyp ermöglicht die Installation mehrerer Instanzen einer Anwendung im Cluster. Nach Initialisieren einer Ressource weist RGM den anwendungsspezifischen Eigenschaften Werte zu, und die Ressource übernimmt alle auf Ressourcentypebene vorhandenen Eigenschaften.

Datendienste verwenden mehrere Typen von Ressourcen. Anwendungen wie Apache Web Server oder Sun Java System Web Server verwenden Netzwerkadressen (logische Hostnamen und gemeinsam genutzte Adressen), von denen die Anwendungen abhängen. Anwendung und Netzwerkressourcen bilden eine grundlegende Einheit, die vom RGM verwaltet wird.

Ressourcengruppen

Von RGM verwaltete Ressourcen werden in Ressourcengruppen abgelegt, um als eine Einheit verwaltet werden zu können. Eine Ressourcengruppe ist ein Satz verwandter oder voneinander abhängiger Ressourcen. Eine Ressource, die vom Ressourcentyp SUNW.LogicalHostname abgeleitet wurde, kann zum Beispiel in derselben Ressourcengruppe wie eine Ressource des Oracle-Datenbank-Ressourcentyps abgelegt werden. Eine Ressourcengruppe migriert als Einheit, wenn ein Failover oder ein Switchover für die Ressourcengruppe eingeleitet wird.

Datendiensttypen

Mithilfe von Datendiensten können Anwendungen hoch verfügbar gemacht werden. Scalable-Dienste tragen zur Vermeidung signifikanter Anwendungsausfälle nach einzelnen Fehlern in einem Cluster bei.

Datendienste müssen als einer der folgenden Datendiensttypen konfiguriert werden:

• Failover-Datendienst

• Scalable-Datendienst

• Paralleler Datendienst

Failover-Datendienste

Failover ist der Vorgang, bei dem der Cluster automatisch einen Dienst von einem ausgefallenen Primärknoten auf einen dafür vorgesehenen redundanten Sekundärknoten verschiebt. Failover-Anwendungen weisen folgende Merkmale auf:

• Sie können auf einem einzigen Cluster-Knoten ausgeführt werden.

• Keine Cluster-Unterstützung

• Vom Cluster-Framework für hohe Verfügbarkeit abhängig

Wenn der Fehler-Monitor einen Fehler erkennt, versucht er entweder, die Instanz auf demselben Knoten erneut zu starten oder die Instanz auf einem anderen Knoten zu starten (Failover), je nachdem, wie der Datendienst konfiguriert wurde. Failover-Dienste verwenden eine Failover-Ressourcengruppe, die Ressourcen für Anwendungsinstanzen und Netzwerkressourcen enthält (logische Hostnamen). Logische Hostnamen sind IP-Adressen, die auf einem Knoten als aktiv konfiguriert werden können. Später werden sie auf dem Originalknoten automatisch als inaktiv und auf einem anderen Knoten als aktiv konfiguriert.

Der Client nimmt möglicherweise eine kurze Unterbrechung im Dienst wahr und muss ggf. die Verbindung neu herstellen, nachdem das Failover abgeschlossen ist. Er nimmt jedoch den Wechsel des realen Servers, der den Dienst zur Verfügung stellt, nicht wahr.

Scalable-Datendienste

Der Scalable-Datendienst ermöglicht die auf mehreren Knoten gleichzeitige Ausführung der Anwendungsinstanzen. Scalable-Dienste verwenden zwei Ressourcengruppen. Die Scalable-Ressourcengruppe enthält die Anwendungsressourcen, während die Failover-Ressourcengruppe die Netzwerkressourcen (gemeinsam genutzte Adressen) enthält, von denen der Scalable-Dienst abhängt. Die Scalable-Ressourcengruppe kann auf mehreren Knoten online sein, so dass mehrere Instanzen dieses Dienstes gleichzeitig ausgeführt werden können. Die Failover-Ressourcengruppe, welche die gemeinsam genutzten Adressen hostet, ist jeweils nur auf einem Knoten online. Alle Knoten, die einen Scalable-Dienst hosten, verwenden dieselbe gemeinsam genutzte Adresse, um den Dienst zu hosten.

Der Cluster erhält die Dienstanforderungen über eine einzige Netzwerkschnittstelle (die globale Schnittstelle). Diese Anforderungen werden auf Grundlage mehrerer vordefinierter Algorithmen, die in den Lastausgleichsverfahren festgelegt sind, an die Knoten verteilt. Der Cluster kann die Dienstlast mithilfe des Lastausgleichsverfahrens zwischen mehreren Knoten ausgleichen.

Parallele Anwendungen

Sun Cluster-Systeme stellen eine Umgebung zur Verfügung, in der parallele Datenbanken für die gemeinsame, parallele Ausführung von Anwendungen auf allen Cluster-Knoten verwendet werden. Sun Cluster Support für Oracle Parallel Server/Real Application Clusters ist ein Satz Pakete, deren Installation die Ausführung von Oracle Parallel Server/Real Application Clusters auf Sun Cluster-Knoten ermöglicht. Dieser Datendienst ermöglicht auch Sun Cluster Support für Oracle Parallel Server/Real Application Clusters für die Verwaltung mit Sun Cluster-Befehlen.

Eine parallele Anwendung wurde für das Ausführen in einer Cluster-Umgebung eingerichtet, so dass die Anwendung von zwei oder mehr Knoten gleichzeitig unterstützt werden kann. In einer Oracle Parallel Server/Real Application Clusters-Umgebung arbeiten mehrere Oracle-Instanzen zusammen, um Zugriff auf dieselbe, gemeinsam genutzte Datenbank zu gewähren. Die Oracle-Clients können jede beliebige dieser Instanzen für den Datenbankzugriff verwenden. Wenn also eine oder mehrere Instanzen ausfallen, können die Clients Verbindungen mit einer der noch laufenden Instanzen herstellen und weiterhin auf die Datenbank zugreifen.