Kapitel 3 Schlüsselkonzepte für Systemverwalter und Anwendungsentwickler

In diesem Kapitel werden die Schlüsselkonzepte im Zusammenhang mit den Softwarekomponenten eines Sun Cluster-Systems beschrieben. Zu den behandelten Themen gehören:

• Verwaltungsschnittstellen

• Cluster-Zeit

• Hoch verfügbares Framework

• Globale Geräte

• Plattengerätegruppen

• Globaler Namensraum

• Cluster-Dateisysteme

• Plattenpfadüberwachung

• Quorum und Quorum-Geräte

• Datendienste

• Verwenden des Cluster-Interconnect für den Datendienstverkehr

• Ressourcen, Ressourcengruppen und Ressourcentypen

• Datendienst-Projektkonfiguration

• Öffentliche Netzwerkadapter und Internet Protocol (IP) Network Multipathing

• SPARC: Unterstützung der dynamischen Rekonfiguration

Diese Informationen richten sich in erster Linie an Systemverwalter und Anwendungsentwickler, die mit der Sun Cluster-API und dem SDK arbeiten. Cluster-Systemverwalter können diese Informationen als Vorbereitung für das Installieren, Konfigurieren und Verwalten von Cluster-Software nutzen. Anwendungsentwickler können die Informationen nutzen, um die Cluster-Umgebung zu verstehen, in der sie arbeiten.

Verwaltungsschnittstellen

Sie können auswählen, wie Sie das Sun Cluster-System von unterschiedlichen Benutzeroberflachen aus installieren, konfigurieren und verwalten möchten. Sie können Systemverwaltungsaufgaben entweder über die grafische Benutzeroberfläche (Graphical User Interface, GUI) von SunPlex-Manager oder über die dokumentierte Befehlszeilenschnittstelle ausführen. Im obersten Bereich der Befehlszeilenschnittstelle befinden sich mehrere Dienstprogramme wie scinstall und scsetup, um bestimmte Installations- und Konfigurationsaufgaben zu vereinfachen. Zum Sun Cluster-System gehört auch ein Modul, das als Teil von Sun Management Center läuft und eine GUI für bestimmte Cluster-Aufgaben zur Verfügung stellt. Dieses Modul ist nur für SPARC-basierte Cluster verfügbar. Unter Verwaltungstools in Sun Cluster Handbuch Systemverwaltung für Solaris OS finden Sie vollständige Beschreibungen der Verwaltungsschnittstellen.

Cluster-Zeit

Die Zeit muss zwischen allen Knoten eines Clusters synchronisiert sein. Ob die Zeitsynchronisierung der Cluster-Knoten mit einer externen Zeitquelle erfolgt, hat für den Cluster-Betrieb keine Bedeutung. Das Sun Cluster-System verwendet das NTP-Protokoll (Network Time Protocol) zum Synchronisieren der Uhren zwischen den Knoten.

Im Allgemeinen verursacht eine Änderung der Systemuhr um eine Sekundenfraktion keine Probleme. Wenn Sie jedoch date(1), rdate(1M) oder xntpdate(1M) (interactiv oder innerhalb von cron-Skripten) auf einem aktiven Cluster ausführen, können Sie eine weit über einer Sekundenfraktion liegende Zeitänderung erzwingen, um die Systemuhr mit der Zeitquelle zu synchronisieren. Diese erzwungene Änderung kann zu Problemen bei den Zeitmarken für Dateiänderungen oder beim NTP-Dienst führen.

Wenn Sie das Solaris-Betriebssystem auf jedem Cluster-Knoten installieren, können Sie die Standardeinstellung für Zeit und Datum für den Knoten ändern. Im Allgemeinen können Sie die werkseitigen Standardeinstellungen akzeptieren.

Wenn Sie die Sun Cluster-Software mit scinstall(1M) installieren, wird in einem Prozessschritt auch das NTP für den Cluster konfiguriert. Sun Cluster-Software stellt eine Vorlagendatei zur Verfügung, ntp.cluster (siehe /etc/inet/ntp.cluster auf einem installierten Clusterknoten), die eine Peer-Beziehung zwischen allen Cluster-Knoten erstellt. Ein Knoten wird als "bevorzugter" Knoten festgelegt. Die Knoten werden über ihre privaten Hostnamen identifiziert und die Zeitsynchronisierung erfolgt über den Cluster-Interconnect. Anweisungen zur Konfiguration des Clusters über NTP erhalten Sie in Kapitel 2, Installieren und Konfigurieren der Sun Cluster-Software in Sun Cluster Handbuch Softwareinstallation für Solaris OS.

Alternativ können Sie einen oder mehrere NTP-Server außerhalb des Clusters einrichten und die ntp.conf-Datei ändern, um diese Konfiguration wiederzugeben.

Im Normalbetrieb sollten Sie die Cluster-Zeit niemals anpassen müssen. Wenn die Zeit bei der Installation des Solaris-Betriebssystems jedoch nicht richtig eingestellt wurde und Sie sie ändern möchten, finden Sie das erforderliche Verfahren in Kapitel 7, Verwalten des Clusters in Sun Cluster Handbuch Systemverwaltung für Solaris OS.

Hoch verfügbares Framework

Das Sun Cluster-System macht alle Komponenten auf dem "Pfad" zwischen Benutzern und Daten hoch verfügbar, einschließlich der Netzwerkschnittstellen, der Anwendungen selbst, des Dateisystems und der Multihostgeräte. Im Allgemeinen ist eine Cluster-Komponente hoch verfügbar, wenn sie trotz eines einzelnen Fehlers (Software oder Hardware) im System in Betrieb bleibt.

Die nachstehende Tabelle zeigt die Arten von Sun Cluster -Komponentenfehlern (bei Hardware und Software) und die entsprechende Form der Wiederherstellung, die in das hoch verfügbare Framework integriert ist

Das Hochverfügbarkeits-Framework der Sun Cluster -Software erkennt einen Knotenfehler schnell und erstellt einen neuen, gleichwertigen Server für die Framework-Ressourcen auf einem anderen Knoten im Cluster. Zu keiner Zeit sind alle Framework-Ressourcen nicht verfügbar. Framework-Ressourcen, die von einem abgestürzten Knoten nicht betroffen sind, sind während der Wiederherstellung voll verfügbar. Darüber hinaus sind die Framework-Ressourcen des ausgefallenen Knotens wieder verfügbar, sobald sie wiederhergestellt sind. Eine wiederhergestellte Framework-Ressource muss nicht warten, bis die Wiederherstellung aller anderen Framework-Ressourcen abgeschlossen ist.

Die meisten hoch verfügbaren Framework-Ressourcen werden für die Anwendungen (Datendienste), die sie verwenden, transparent wiederhergestellt. Die Semantik des Framework-Ressourcenzugriffs bleibt bei einem Knotenfehler vollständig erhalten. Die Anwendungen können einfach nicht erkennen, dass der Framework-Ressourcenserver auf einen anderen Knoten verschoben wurde. Der Ausfall eines einzelnen Knotens ist für die Programme auf verbleibenden Knoten vollständig transparent, indem die zu dem Knoten gehörenden Dateien, Geräte und Plattendatenträger verwendet werden. Diese Transparenz besteht, sofern ein alternativer Hardwarepfad zu den Platten von einem anderen Knoten aus vorhanden ist. Ein Beispiel ist die Verwendung von Multihostgeräten mit Ports für mehrere Knoten.

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 (Anwendungen) 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 einer synchronisierten Konfiguration können Cluster-Ressourcen auf Grundlage der neuen Mitgliedschaft im Cluster neu verteilt werden.

Im Unterschied zu früheren Sun Cluster Softwareversionen wird der CMM vollständig im Kernel ausgeführt.

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

Failfast-Mechanismus

Wenn der CMM ein kritisches Knoten-Problem erkennt, fordert er das Cluster-Framework auf, den Knoten zwangsweise herunterzufahren (Panik) und aus der Cluster-Mitgliedschaft zu entfernen. Der Mechanismus für diesen Vorgang wird als Failfast bezeichnet. Ein Failfast bewirkt das Herunterfahren eines Knotens auf zwei Arten.

• Wenn ein Knoten den Cluster verlässt und dann versucht, einen neuen Cluster ohne Quorum zu starten, wird er vom Zugriff auf die gemeinsam genutzten Platten "geschützt". Weitere Details zur Verwendung von Failfast finden Sie unter Informationen zum Fehlerschutz .

• Wenn einer oder mehr Cluster-spezifische Dämonen ausfallen (clexecd, rpc.pmfd, rgmd oder rpc.ed) wird der Fehler vom CMM erkannt und der Knoten gerät in Panik.

Wenn der Ausfall eines Cluster-Dämons einen Knoten in Panik versetzt, wird in der Konsole für diesen Knoten eine Meldung angezeigt, die in etwa folgendermaßen aussieht.

panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 35 seconds ago.
409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0)
%l0-7: 1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0

Nach der Panik kann der Knoten neu booten und versuchen, dem Cluster wieder beizutreten. Alternativ kann der Knoten in Clustern aus SPARC-basierten Systemen an der OpenBoot^TM PROM (OBP)-Eingabeaufforderung bleiben. Die nächste Aktion des Knotens wird durch die Einstellung des auto-boot?-Parameters festgelegt. Sie können auto-boot? mit eeprom(1M) an der OpenBoot PROM ok-Eingabeaufforderung einstellen.

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

Das CCR verwendet für Aktualisierungen einen Zwei-Phasen-Commit-Algorithmus: Eine Aktualisierung muss auf allen Cluster-Mitgliedern erfolgreich abgeschlossen werden, sonst wird die Aktualisierung zurückgenommen. Das CCR verwendet den Cluster-Interconnect für die Umsetzung der verteilten Aktualisierungen.

Das CCR besteht zwar aus Textdateien, aber Sie dürfen die CCR-Dateien unter keinen Umständen manuell bearbeiten. Jede Datei enthält einen Prüfsummeneintrag, um die Konsistenz zwischen den Knoten zu sichern. Eine manuell Aktualisierung der CCR-Dateien kann dazu führen, dass ein Knoten oder der ganze Cluster nicht mehr funktioniert.

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.

Globale Geräte

Das Sun Cluster-System verwendet Globale Geräte, um einen cluster-weiten, hoch verfügbaren Zugriff auf alle Geräte innerhalb eines Clusters von jedem Knoten aus zur Verfügung zu stellen. Wenn ein Knoten ausfällt, während er Zugriff auf ein globales Gerät gewährt, erkennt die Sun Cluster-Software normalerweise einen anderen Pfad zu dem Gerät und leitet den Zugriff auf diesen Pfad um. Zu den globalen Geräten bei Sun Cluster gehören Platten, CD-ROMs und Bänder. Die einzigen globalen Multiport-Geräte, die von der Sun Cluster-Software unterstützt werden, sind jedoch Platten. Das 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 automatisch eine einmalige ID zu. Diese Zuweisung ermöglicht einen konsistenten Zugriff auf jedes Gerät von jedem Cluster-Knoten aus. Der Namensraum globaler Geräte ist im Verzeichnis /dev/global enthalten. Weitere Informationen finden Sie unter Globaler Namensraum .

Globale Multiport-Geräte stellen mehrere Pfade zu einem Gerät zur Verfügung. Da Multihostplatten zu einer Plattengerätegruppe gehören, die von mehreren Knoten gehostet wird, werden sie hoch verfügbar gemacht.

Geräte-IDs und DID-Pseudotreiber

Die Sun Cluster-Software verwaltet globale Geräte über einen so genannten Geräte-ID-Pseudotreiber (DID-Pseudotreiber). Dieser Treiber wird verwendet, um automatisch jedem Gerät im Cluster einschließlich Multihostplatten, Bandlaufwerken und CD-ROM-Laufwerken eine einmalige ID zuzuweisen.

Der DID-Pseudotreiber ist fester Bestandteil der Zugriffsfunktion auf globale Geräte des Clusters. Der DID-Treiber testet alle Knoten des Clusters, erstellt eine Liste von einmaligen Plattengeräten und weist jeder Platte eine einmalige Geräteklassen- und Gerätenummer zu, die auf allen Knoten des Clusters konsistent ist. Der Zugriff auf globale Geräte erfolgt mithilfe der einmaligen, vom DID-Treiber zugewiesenen Geräte-ID anstelle der herkömmlichen Solaris-Geräte-IDs wie c0t0d0 für eine Platte.

Dieser Ansatz stellt sicher, dass jede auf Platten zugreifende Anwendung (wie Datenträger-Manager oder Anwendungen, die im raw-Modus betriebene Geräte verwenden) im ganzen Cluster einen konsistenten Pfad verwenden. Diese Konsistenz ist besonders bei Multihostplatten wichtig, weil die lokale Geräteklassen- und Gerätenummern für jedes Gerät von Knoten zu Knoten unterschiedlich sein kann und sich damit auch die Solaris-Konventionen zur Gerätebenennung ändern. Node 1 kann eine Multihostplatte zum Beispiel als c1t2d0 identifizieren, während Node 2 dieselbe Platte vollkommen anders, nämlich als c3t2d0 , identifiziert. Der DID-Treiber weist einen globalen Namen zu, wie d10, den der Knoten stattdessen verwendet, und gibt jedem Knoten eine konsistente Zuordnung zur Multihostplatte.

Sie aktualisieren und verwalten die Geräte-IDs mithilfe von scdidadm(1M) und scgdevs(1M). Weitere Informationen entnehmen Sie bitte den folgenden Man Pages:

• scdidadm(1M)

• scgdevs(1M)

Plattengerätegruppen

Im Sun Cluster-System müssen alle Multihostgeräte von der Sun Cluster-Software gesteuert werden. Sie erstellen zunächst die Plattengruppen des Datenträger-Managers – entweder Solaris Volume Manager-Plattensätze oder VERITAS Volume Manager-Plattengruppen (nur in SPARC-basierten Clustern verfügbar) – auf den Multihost-Platten. Dann registrieren Sie die Datenträger-Manager-Plattengruppen als Plattengerätegruppen. Eine Plattengerätegruppe ist ein globaler Gerätetyp. Zudem erstellt die Sun Cluster-Software automatisch eine im raw-Modus betriebene Plattengerätegruppe für jedes Platten- und Bandgerät im Cluster. Diese Cluster-Gerätegruppen bleiben jedoch im Offline-Zustand, bis Sie darauf als globale Geräte zugreifen.

Die Registrierung liefert dem Sun Cluster-System Informationen zu den Pfaden zwischen Knoten und Datenträger-Manager-Plattengruppen. An diesem Punkt werden Datenträger-Manager-Plattengruppen innerhalb des Clusters global zugänglich. Wenn mehrere Knoten in eine Plattengerätegruppe schreiben können (die Gruppe unterstützen können), werden die in dieser Plattengerätegruppe gespeicherten Daten hoch verfügbar. Die hoch verfügbare Plattengerätegruppe kann zum Hosten von Cluster-Dateisystemen verwendet werden.

Plattengerätegruppen sind von Ressourcengruppen unabhängig. Ein Knoten kann eine Ressourcengruppe (die eine Gruppe von Datendienstprozessen darstellt) unterstützen, während ein anderer die Plattengruppen unterstützen kann, auf welche die Datendienste zugreifen. Das optimale Vorgehen besteht aber darin, die Plattengerätegruppe zur Speicherung bestimmter Anwendungsdaten und die Ressourcengruppe mit den Anwendungsressourcen (Anwendungsdämon) auf demselben Knoten zu speichern. Weitere Informationen über die Zuordnung zwischen Ressourcengruppen und Plattengerätegruppen finden Sie unter Relationship Between Resource Groups and Disk Device Groups in Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Wenn ein Knoten eine Plattengerätegruppe verwendet, wird die Datenträger-Manager-Plattengruppe "global", weil sie Multipathing für die zugehörigen Platten unterstützt. Jeder mit den Multihostplatten real verbundene Cluster-Knoten stellt einen Pfad zur Plattengerätegruppe zur Verfügung.

Plattengerätegruppen-Failover

Auf alle Plattengerätegruppen in einem Gehäuse kann über einen alternativen Pfad zugegriffen werden, wenn der derzeitige Knoten-Master der Gerätegruppe ausfällt, weil ein Plattengehäuse an mehrere Knoten angeschlossen ist. Der Ausfall des Knotens, der als Gerätegruppen-Master fungiert, beeinträchtigt den Zugriff auf die Gerätegruppe nur während der Zeitspanne, die zur Ausführung der Wiederherstellungs- und Konsistenzprüfung erforderlich ist. Während dieser Zeit werden alle Anforderungen (für die Anwendung transparent) gesperrt, bis das System die Gerätegruppe verfügbar macht.

Abbildung 3–1 Plattengerätegruppe vor und nach Failover

Multiport-Plattengerätegruppen

In diesem Abschnitt werden Plattengruppeneigenschaften beschrieben, mit denen Sie Leistung und Verfügbarkeit in einer Multiport-Plattenkonfiguration ausgleichen können. Die Sun Cluster-Software stellt Ihnen zwei Eigenschaften zur Verfügung, mit denen Sie eine Multiport-Plattenkonfiguration konfigurieren können: preferenced und numsecondaries. Mit der preferenced-Eigenschaft können Sie die Reihenfolge steuern, in der die Knoten versuchen, die Steuerung im Fall eines Failover zu übernehmen. Mit der numsecondaries-Eigenschaft legen Sie eine gewünschte Anzahl von Sekundärknoten für eine Gerätegruppe fest.

Ein hoch verfügbarer Dienst gilt als ausgefallen, wenn der Primärknoten ausfällt und kein Sekundärknoten die Rolle des Primärknotens übernehmen kann. Wenn ein Dienst-Failover erfolgt und die preferenced-Eigenschaft auf true eingestellt ist, folgen die Knoten bei der Auswahl eines Sekundärknotens der Reihenfolge in der Knotenliste. Die mit der preferenced-Eigenschaft eingerichtete Knotenliste definiert die Reihenfolge, in der die Knoten versuchen, die Steuerung als Primärknoten oder den Übergang von Spare-Knoten zu Sekundärknoten zu übernehmen. Sie können den Vorrang eines Gerätedienstes mit dem Dienstprogramm scsetup(1M) dynamisch ändern. Der Vorrang der abhängigen Dienste, zum Beispiel eines globalen Dateisystems, stimmt exakt mit dem Vorrang des Gerätedienstes überein.

Im Normalbetrieb führt der Primärknoten Checkpoint-Vorgänge für Sekundärknoten durch. In einer Multiport-Plattenkonfiguration führt das Durchführen des Checkpoint-Vorgangs an jedem Sekundärknoten zu einer Leistungsverminderung des Clusters und zu Speicherüberlastung. Die Spare-Knoten-Unterstützung wurde implementiert, um die Checkpoint-bedingte Leistungsminderung und Speicherüberlastung zu minimieren. Standardmäßig weist Ihre Plattengerätegruppe einen Primär- und einen Sekundärknoten auf. Die restlichen verfügbaren Anbieterknoten werden Spare-Knoten. Bei einem Failover wird der Sekundärknoten zum Primärknoten, und der Knoten mit der höchsten Priorität in der Knotenliste wird zum Sekundärknoten.

Die gewünschte Anzahl von Sekundärknoten kann auf jede beliebige Ganzzahl zwischen 1 und der Anzahl der betriebsbereiten Anbieterknoten in der Gerätegruppe, die keine Primärknoten sind, gesetzt werden.

Wenn Sie Solaris Volume Manager verwenden, müssen Sie zuerst die Plattengerätegruppe erstellen, bevor Sie die Eigenschaft numsecondaries auf einen anderen Wert als den Standardwert einstellen können.

Die standardmäßig eingestellte gewünschte Anzahl von Sekundärknoten für Gerätedienste ist Eins. Die tatsächliche Anzahl der vom Replikat-Framework verwalteten Sekundäranbieter entspricht der gewünschten Anzahl, es sei denn, die Anzahl der betriebsbereiten Anbieter, die keine Primärknoten sind, ist kleiner als die gewünschte Anzahl. Sie müssen die numsecondaries-Eigenschaft ändern und die Knotenliste erneut überprüfen, wenn Sie Knoten zur Konfiguration hinzufügen oder daraus entfernen. Die Verwaltung der Knotenliste und der gewünschten Anzahl von Sekundärknoten verhindert Konflikte zwischen der konfigurierten und der tatsächlichen, vom Framework erlaubten Anzahl von Sekundärknoten.

• (Solaris Volume Manager) Sie verwalten das Hinzufügen oder Entfernen von Knoten aus Ihrer Konfiguration mit dem metaset(1M)-Befehl für Solaris Volume Manager-Gerätegruppen in Verbindung mit den Einstellungen für die Eigenschaften preferenced und numsecondaries.

• (Veritas Volume Manager) Sie verwalten das Hinzufügen oder Entfernen von Knoten aus Ihrer Konfiguration mit dem scconf(1M)-Befehl für VxVM-Plattengerätegruppen in Verbindung mit den Einstellungen für die Eigenschaften preferenced und numsecondaries.

• Verfahrenstechnische Informationen über das Ändern der Plattengerätegruppen-Eigenschaften finden Sie unter Überblick über das Verwalten von Cluster-Dateisystemen in Sun Cluster Handbuch Systemverwaltung für Solaris OS.

Globaler Namensraum

Der Sun Cluster-Softwaremechanismus zur Aktivierung globaler Geräte ist der globale Namensraum. Der globale Namensraum beinhaltet die /dev/global/-Hierarchie sowie die Datenträger-Manager-Namensräume. Der globale Namensraum gibt sowohl Multihostplatten als auch lokale Platten wieder (und jedes andere Cluster-Gerät wie CD-Rom-Laufwerke und Bänder) und stellt mehrere Failover-Pfade für die Multihostplatten zur Verfügung. Jeder real an die Multihostplatten angeschlossene Knoten stellt für alle Knoten im Cluster einen Pfad zum Speicher zur Verfügung.

In der Regel befinden sich die Namensräume des Datenträger-Managers für Solaris Volume Manager in den Verzeichnissen /dev/md/Plattensatz/dsk (und rdsk). Die Namensräume des Datenträger-Managers für Veritas VxVM befinden sich in den Verzeichnissen /dev/vx/dsk/disk-group und /dev/vx/rdsk/disk-group. Diese Namensräume bestehen aus Verzeichnissen für jeden Solaris Volume Manager-Plattensatz bzw. jede VxVM-Plattengruppe auf dem ganzen Cluster. Jedes dieser Verzeichnisse enthält einen Geräteknoten für jedes Metagerät oder jeden Datenträger in diesem Plattensatz bzw. in dieser Plattengruppe.

Im Sun Cluster -System wird jeder Geräteknoten im lokalen Datenträger-Manager-Namensraum durch eine symbolische Verknüpfung mit einem Geräteknoten im Dateisystem /global/.devices/node@ nodeID ersetzt, wobei nodeID als Ganzzahl für den Knoten im Cluster steht. Die Sun Cluster-Software zeigt die Datenträger-Manager-Geräte auch weiterhin als symbolische Verknüpfungen an ihren Standard-Speicherorten an. Sowohl der globale Namensraum als auch der Datenträger-Manager-Namensraum sind auf jedem Cluster-Knoten verfügbar.

Der globale Namensraum bietet unter anderem folgende Vorteile:

• Jeder Knoten bleibt ziemlich unabhängig, und es gibt nur geringfügige Änderungen im Geräteverwaltungsmodell.

• Geräte können selektiv global gemacht werden.

• Verknüpfungsgeneratoren von Drittherstellern arbeiten weiterhin.

• Nach Vergabe eines lokalen Gerätenamens erfolgt eine einfache Zuordnung, um den entsprechenden globalen Namen zu erhalten.

Beispiel für lokale und globale Namensräume

Die nachstehende Tabelle zeigt die Zuordnungen zwischen lokalen und globalen Namensräumen für eine Multihostplatte, c0t0d0s0.

Der globale Namensraum wird automatisch bei der Installation erzeugt und bei jedem Neubooten der Rekonfiguration aktualisiert. Sie können den globalen Namensraum auch durch Ausführen des scgdevs(1M)-Befehls generieren.

Cluster-Dateisysteme

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. Die Prozesse können 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.

• Umfassendes 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 ein Cluster-Dateisystem 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.

Sie können ein Dateisystem mit mount -g global oder mit mount lokal auf einem globalen Gerät einhängen.

Programme können auf die Dateien in einem Cluster-Dateisystem von jedem Knoten im Cluster aus und mit demselben Dateinamen zugreifen (z. B. /global/foo).

Ein Cluster-Dateisystem wird auf allen Cluster-Mitgliedern eingehängt. Sie können ein Cluster-Dateisystem nicht auf einer Untermenge von Cluster-Mitgliedern einhängen.

Ein Cluster-Dateisystem ist kein anderer Typ von Dateisystem. Die Clients überprüfen das zugrunde liegende Dateisystem (z. B. UFS).

Verwenden von Cluster-Dateisystemen

Im Sun Cluster-System sind alle Multihostplatten in Plattengerätegruppen eingebunden. Hierbei kann es sich um Solaris Volume Manager-Plattensätze, VxVM-Plattengruppen oder Platten handeln, die nicht von einem softwarebasierten Datenträger-Manager gesteuert werden.

Damit ein Cluster-Dateisystem hoch verfügbar ist, muss der zugrunde liegende Plattenspeicher mit mehreren Knoten verbunden sein. Deswegen ist ein lokales Dateisystem (ein auf der lokalen Platte eines Knotens gespeichertes Dateisystem), das zu einem Cluster-Dateisystem gemacht wird, nicht hoch verfügbar.

Sie können Cluster-Dateisysteme genauso wie andere Dateisysteme einhängen:

• Manuell — Verwenden Sie den Befehl mount mit den Einhängeoptionen -g oder -o global, um das Cluster-Dateisystem von der Befehlszeile aus einzuhängen. Beispiel:

  SPARC: # mount -g /dev/global/dsk/d0s0 /global/oracle/data

• Automatisch— Erstellen Sie einen Eintrag in der Datei /etc/vfstab mit einer global-Einhängeoption, um das Cluster-Dateisystem beim Booten einzuhängen Dann können Sie im /global-Verzeichnis auf allen Knoten einen Einhängepunkt erstellen. Das /global-Verzeichnis ist ein empfohlener Speicherplatz, keine Anforderung. Hier eine Beispielzeile für ein Cluster-Dateisystem aus einer /etc/vfstab-Datei:

  SPARC: /dev/md/oracle/dsk/d1 /dev/md/oracle/rdsk/d1 /global/oracle/data ufs 2 yes global,logging

Solange die Sun Cluster-Software kein Benennungsverfahren für Cluster-Dateisysteme vorschreibt, können Sie die Verwaltung durch das Erstellen eines Einhängepunktes für alle Cluster-Dateisysteme unter demselben Verzeichnis vereinfachen, wie /global/disk-device-group. Weitere Informationen erhalten Sie in der Sun Cluster 3.1 9/04 Software Collection for Solaris OS (SPARC Platform Edition) und im Sun Cluster Handbuch Systemverwaltung für Solaris OS.

HAStoragePlus Ressourcentyp

Der HAStoragePlus-Ressourcentyp ist darauf ausgelegt, nicht globale Dateisystemkonfigurationen wie UFS und VxFS hoch verfügbar zu machen. Mit HAStoragePlus integrieren Sie das lokale Dateisystem in die Sun Cluster-Umgebung und machen das Dateisystem hoch verfügbar. HAStoragePlus stellt zusätzliche Dateisystemfunktionen wie Prüfen, Einhängen und erzwungenes Aushängen zur Verfügung, mit denen Sun Cluster bei lokalen Dateisystemen ein Failover durchführen kann. Zum Ausführen eines Failover-Vorgangs muss sich das lokale Dateisystem auf globalen Plattengruppen mit aktivierten Affinitäts-Switchover befinden.

Unter Enabling Highly Available Local File Systems in Sun Cluster Data Services Planning and Administration Guide for Solaris OS finden Sie Informationen zum Konfigurieren des HAStoragePlus-Ressourcentyps.

HAStoragePlus kann auch zum Synchronisieren beim Start von Ressourcen und Plattengerätegruppen, von denen die Ressourcen abhängen, eingesetzt werden. Weitere Informationen finden Sie unter Ressourcen, Ressourcengruppen und Ressourcentypen .

Syncdir-Einhängeoption

Die syncdir-Einhängeoption kann für auf UFS basierende Cluster-Dateisysteme verwendet werden. Sie erzielen jedoch eine wesentlich bessere Leistung, wenn Sie syncdir nicht angeben. Bei Angabe von syncdir sind die Einträge garantiert POSIX-konform. Wenn syncdir nicht angegeben wird, verhält sich das System wie ein NFS-Dateisystem. So kann es beispielsweise ohne syncdir vorkommen, dass Sie fehlende Speicherkapazität zum Beispiel erst beim Schließen der Datei feststellen. Mit syncdir (und POSIX-Verhalten) wäre das Fehlen von Speicherplatz während des Schreibvorgangs erkannt worden. Es treten allerdings nur selten Probleme auf, wenn Sie syncdir nicht angeben.

Wenn Sie einen SPARC-basierten Cluster verwenden, hat VxFS keine Einhängeoption, die der Einhängeoption syncdir für UFS entspricht. Das VxFS-Verhalten entspricht dem UFS-Verhalten, wenn die syncdir-Einhängeoption nicht angegeben wurde.

Häufig gestellte Fragen zu globalen Geräten und Cluster-Dateisystemen finden Sie unter FAQs zu Dateisystemen .

Plattenpfadüberwachung

Die derzeitige Version der Sun Cluster-Software unterstützt die Plattenpfadüberwachung (DPM). Dieser Abschnitt liefert konzeptionelle Informationen zu DPM, zum DPM-Dämon und zu den Verwaltungstools für die Plattenpfadüberwachung. Verfahrenstechnische Informationen zur Überwachung, zum Aufheben der Überwachung und zum Prüfen des Plattenpfadstatus finden Sie im Sun Cluster Handbuch Systemverwaltung für Solaris OS.

DPM wird auf Knoten mit Versionen vor Sun Cluster 3.1 10/03 nicht unterstützt. Verwenden Sie während einer Aufrüstung keine DPM-Befehle. Nach der Aufrüstung müssen alle Knoten online sein, um die DPM-Befehle verwenden zu können.

DPM - Überblick

DPM verbessert die gesamte Zuverlässigkeit der Failover- und Switchover-Vorgänge durch die Überwachung der Verfügbarkeit des Plattenpfades für den Sekundärknoten. Mit dem scdpm-Befehl überprüfen Sie die Verfügbarkeit des von einer Ressource verwendeten Plattenpfades, bevor die Ressource umgeschaltet wird. Mit dem vom scdpm-Befehl zur Verfügung gestellten Optionen können Sie die Plattenpfade zu einem einzelnen oder zu allen Knoten im Cluster überwachen. Weitere Informationen zu Befehlszeilenoptionen finden Sie in der Online-Dokumentation scdpm(1M).

Die DPM-Komponenten werden aus dem SUNWscu-Paket installiert. Das SUNWscu-Paket wird im Rahmen der Sun Cluster-Standardinstallation installiert. Details zur Installationsoberfläche finden Sie in der Online-Dokumentation scinstall(1M). In der nachstehenden Tabelle wird der Standardspeicherort für die Installation der DPM-Komponenten beschrieben.

Ein Multithread-DPM-Dämon wird auf jedem Knoten ausgeführt. Der DPM-Dämon (scdpmd) wird durch ein rc.d-Skript gestartet, wenn ein Knoten bootet. Wenn ein Problem auftritt, wird der Dämon von pmfd verwaltet und startet automatisch neu. In der folgenden Liste wird die Arbeitsweise von scdpmd beim ersten Start beschrieben.

Beim Start wird der Status für jeden Plattenpfad auf UNKNOWN initialisiert.

1. Der DPM-Dämon sammelt Plattenpfad- und Knotennameninformationen aus der vorherigen Statusdatei oder aus der CCR-Datenbank. Weitere Informationen zum CCR finden Sie unter Cluster-Konfigurations-Repository (Cluster Configuration Repository, CCR) . Nach dem Start eines DPM-Dämons können Sie den Dämon zwingen, die Liste der überwachten Platten aus einer angegebenen Datei zu lesen.

2. Der DPM-Dämon initialisiert die Kommunikationsschnittstelle, um Anforderungen von Komponenten zu beantworten, die außerhalb des Dämons liegen, wie die Befehlszeilenschnittstelle.

3. Der DPM-Dämon pingt jeden Plattenpfad der überwachten Liste alle 10 Minuten mit dem Befehl scsi_inquiry an. Die Einträge werden gesperrt, um die Kommunikationsschnittstelle daran zu hindern, auf einen Eintrag zuzugreifen, der gerade geändert wird.

4. Der DPM-Dämon benachrichtigt das Sun Cluster-Ereignis-Framework und protokolliert den neuen Pfadstatus über den UNIX syslogd(1M)-Mechanismus.

Alle mit dem Dämon zusammenhängenden Fehler werden von pmfd (1M) aufgezeichnet. Alle API-Funktionen geben 0 für erfolgreich und -1 für einen Fehler zurück.

Der DPM-Dämon überwacht die Verfügbarkeit des logischen Pfades, der über Multipath-Treiber wie Sun StorEdge Traffic Manager, HDLM und PowerPath sichtbar ist. Die jeweiligen realen Pfade, die von diesen Treibern verwaltet werden, werden nicht überwacht, weil der Multipath-Treiber einzelne Ausfälle vor dem DPM-Dämon verbirgt.

Überwachen von Plattenpfaden

In diesem Abschnitt werden zwei Methoden zur Überwachung von Plattenpfaden in Ihrem Cluster beschrieben. 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. Dieser Befehl dient auch dem Drucken der Liste von ausgefallenen Platten und der Überwachung der Plattenpfade aus einer Datei.

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 gibt Ihnen einen topologischen Überblick über die überwachten Plattenpfade im Cluster. Die Ansicht wird alle 10 Minuten aktualisiert, um Informationen zur Anzahl der fehlgeschlagenen Pings zu liefern. Zur Verwaltung der Plattenpfade verwenden Sie die Informationen der GUI von SunPlex-Manager zusammen mit dem scdpm(1M)-Befehl. Informationen über SunPlex-Manager finden Sie in Kapitel 10, Verwaltung von Sun Cluster mithilfe der grafischen Benutzeroberflächen in Sun Cluster Handbuch Systemverwaltung für Solaris OS.

Verwenden des scdpm-Befehls zur Plattenpfadüberwachung

Der scdpm(1M)-Befehl stellt DMP-Verwaltungsbefehle zur Verfügung, mit denen Sie folgende Aufgaben ausführen können:

• Überwachen eines neuen Plattenpfades,

• Aufheben der Überwachung eines Plattenpfades,

• Neues Lesen der Konfigurationsdaten aus der CCR-Datenbank,

• Lesen der Platten, die überwacht werden sollen oder deren Überwachung aufgehoben werden soll, von einer angegebenen Datei aus,

• Berichten des Status eines Plattenpfades oder aller Plattenpfade im Cluster,

• Drucken aller Plattenpfade, auf die von einem Knoten aus zugegriffen werden kann.

Geben Sie den scdpm(1M)-Befehl mit dem Plattenpfad-Argument von einem beliebigen aktiven Knoten aus, um DPM-Verwaltungsaufgaben auf dem Cluster auszuführen. Das Plattenpfad-Argument besteht immer aus einem Knotennamen und einem Plattennamen. Der Knotenname ist nicht erforderlich und wird standardmäßig auf all gesetzt, wenn kein Knotenname angegeben wurde. In der nachstehenden Tabelle werden die Benennungskonventionen für den Plattenpfad beschrieben.

Die Verwendung des globalen Plattenpfadnamens wird dringend empfohlen, weil der globale Plattenpfadname auf dem ganzen Cluster konsistent ist. Der UNIX-Plattenpfadname ist nicht auf dem ganzen Cluster konsistent. Der UNIX-Plattenpfad für eine Platte kann von einem Cluster-Knoten zum anderen unterschiedlich sein. Der Plattenpfad kann auf einem Knoten c1t0d0 und auf einem anderen Knoten c2t0d0 sein. Verwenden Sie bei UNIX-Plattenpfadnamen den Befehl scdidadm -L, um die UNIX-Plattenpfadnamen den globalen Plattenpfadnamen zuzuordnen, bevor Sie DPM-Befehle ausgeben. Weitere Informationen finden Sie in der Online-Dokumentation scdidadm(1M).

Verwenden von SunPlex-Manager zur Plattenpfadüberwachung

Mit SunPlex-Manager können Sie folgende grundlegende DPM-Verwaltungsaufgaben durchführen:

• Überwachen eines Plattenpfades,

• Aufheben der Überwachung eines Plattenpfades,

• Anzeigen des Status aller Plattenpfade im Cluster

Verfahrenstechnische Informationen zur Plattenpfadverwaltung mit SunPlex-Manager finden Sie in der Online-Hilfe zu SunPlex-Manager.

Quorum und Quorum-Geräte

Dieses Kapitel umfasst die folgenden Themen:

• Informationen zur Quorum-Stimmenanzahl

• Informationen zum Fehlerschutz

• Informationen zu Quorum-Konfigurationen

• Erfüllen der Anforderungen für Quorum-Geräte

• Einhalten von Empfehlungen für Quorum-Geräte

• Empfohlene Quorum-Konfigurationen

• Untypische Quorum-Konfigurationen

• Unzulässige Quorum-Konfigurationen

Eine Liste der Geräte, die von der Sun Cluster-Software als Quorum-Geräte unterstützt werden, erhalten Sie bei Ihrem Sun-Dienstanbieter.

Da Cluster-Knoten Daten und Ressourcen gemeinsam nutzen, darf ein Cluster nie in getrennte Partitionen aufgeteilt werden, die zur gleichen Zeit aktiv sind. Mehrere aktive Partitionen können zur Beschädigung von Daten führen. Durch den Cluster-Mitglied-Monitor (CMM) und den Quorum-Algorithmus wird gewährleistet, dass immer höchstens eine Instanz desselben Clusters in Betrieb ist, auch wenn der Cluster-Interconnect partitioniert ist.

Eine Einführung in Quorum und CMM finden Sie unter Cluster-Mitgliedschaft in Sun Cluster Überblick für das Betriebssystem Solaris.

Bei Cluster-Partitionen ergeben sich zwei Arten von Problemen:

• Split Brain

• Amnesie

Split Brain tritt auf, wenn der Cluster-Interconnect zwischen Knoten verloren geht und der Cluster partitioniert wird. Jede Partition "glaubt", dass sie die einzige Partition ist, da der Knoten in der einen Partition nicht mit dem Knoten in der anderen Partition kommunizieren kann.

Zur Amnesie kommt es, wenn der Cluster nach dem Herunterfahren mit Cluster-Konfigurationsdaten neu startet, die älter als die Daten zum Zeitpunkt des Herunterfahrens sind. Dieses Problem kann auftreten, wenn Sie den Cluster an einem Knoten starten, der nicht Teil der letzten funktionierenden Cluster-Partition war.

Die Sun Cluster-Software vermeidet das Autreten von Split Brain und Amnesie durch folgende Vorgänge:

• Zuweisung einer Stimme für jeden einzelnen Knoten

• Festlegung einer Stimmenmehrheit für einen betriebsbereiten Cluster

Eine Partition mit der Mehrheit der Stimmen erhält ein Quorum und erhält die Erlaubnis zum Arbeiten. Dieser auf einer Stimmenmehrheit basierende Mechanismus vermeidet Split Brain und Amnesie für den Fall, dass mehr als zwei Knoten in einem Cluster konfiguriert wurden. Das Zählen der Knotenstimmen allein reicht jedoch nicht aus, wenn mehr als zwei Knoten in einem Cluster konfiguriert wurden. In einem Zwei-Knoten-Cluster ist zwei eine Mehrheit. Wenn ein solcher Zwei-Knoten-Cluster partitioniert wird, benötigen beide Partitionen jeweils eine externe Stimme, um ein Quorum zu erhalten. Diese externe Stimme wird von einem Quorum-Gerät beigesteuert.

Informationen zur Quorum-Stimmenanzahl

Verwenden Sie den Befehl scstat -q, um folgende Informationen festzulegen:

• Gesamte konfigurierte Stimmen

• Aktuell vorhandene Stimmen

• Für Quorum erforderliche Stimmen

Weitere Informationen zu diesem Befehl finden Sie unter scstat(1M).

Beide Knoten und Quorum-Geräte steuern Stimmen für den Cluster bei, um ein Quorum zu bilden.

Ein Knoten steuert je nach Status eine unterschiedliche Stimmenanzahl bei:

• Ein Knoten hat eine Stimmenanzahl von eins, wenn er gestartet wird und ein Cluster-Mitglied wird.

• Ein Knoten verfügt über null Stimmen, wenn er installiert wird.

• Wenn ein Systemadministrator einen Knoten in den Wartungszustand versetzt, hat der Knoten eine Stimmenanzahl von null.

Die von Quorum-Geräten beigesteuerten Stimmen basieren auf der Anzahl der Stimmen, die mit dem Gerät verbunden sind. Wenn Sie ein Quorum-Gerät konfigurieren, weist die Sun Cluster-Software dem Quorum-Gerät eine Stimmenanzahl von N-1 zu. Hierbei ist N die Anzahl der mit dem Quorum-Gerät verbundenen Stimmen. 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).

Ein Quorum-Gerät steuert Stimmen bei, wenn eine der beiden folgenden Bedingungen erfüllt ist:

• Bei mindestens einem der Knoten, an die das Quorum-Gerät derzeit angeschlossen ist, handelt es sich um ein Cluster-Mitglied.

• Mindestens einer der Knoten, an die das Quorum-Gerät derzeit angeschlossen ist, wird gerade gestartet und der entsprechende Knoten war ein Mitglied der Cluster-Partition, die zuletzt Eigentümer des Quorum-Geräts war.

Quorum-Geräte werden während der Cluster-Installation oder zu einem späteren Zeitpunkt mithilfe der in Kapitel 5, Verwalten des Quorums in Sun Cluster Handbuch Systemverwaltung für Solaris OS beschriebenen Verfahren konfiguriert.

Informationen zum 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, sodass 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 Multihostgeräte und die Eigentümerschaft zu haben. Wenn mehrere Knoten versuchen, auf die Platten zu schreiben, können Datenfehler auftreten.

Der Fehlerschutz schränkt den Knotenzugriff auf die Multihostgeräte ein, indem der Zugriff auf die Platten real 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.

Plattengerätedienste stellen Failover-Funktionen für Dienste zur Verfügung, die Multihostgeräte verwenden. Wenn ein Cluster-Mitglied, das zurzeit als Primärknoten (Eigentümer) der Plattengerätegruppe dient, ausfällt oder nicht mehr erreichbar ist, wird ein neuer Primärknoten ausgewählt. Der neue Primärknoten ermöglicht den weiteren Zugriff auf die Plattengerätegruppe nach einer geringfügigen Unterbrechung. Während dieses Vorgangs muss der alte Primärknoten den Zugriff auf die Geräte freigeben, bevor der neue Primärknoten gestartet werden kann. Wenn ein Mitglied jedoch aus dem Cluster ausscheidet und nicht mehr erreichbar ist, kann der Cluster diesen Knoten nicht zur Freigabe der Geräte auffordern, für die er als Primärknoten fungierte. Sie brauchen also ein Mittel, mit dessen Hilfe die funktionsfähigen Mitglieder die Steuerung und den Zugriff auf die globalen Geräte der ausgefallenen Mitglieder übernehmen können.

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

SCSI-2-Plattenreservierungen unterstützen eine Reservierungsform, die entweder allen mit der Platte verbundenen Knoten den Zugriff gestattet (wenn keine Reservierung vorliegt) oder den Zugriff auf einen einzelnen Knoten beschränkt (der Knoten, der die Reservierung aufweist).

Wenn ein Cluster-Mitglied erkennt, dass ein anderer Knoten nicht mehr über den Cluster-Interconnect kommuniziert, leitet er ein Fehlerschutzverfahren ein, um den anderen 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.

Die Entdeckung, dass ein Knoten nicht länger Mitglied des Clusters ist, bewirkt eine SCSI-Reservierung auf allen Platten, die von diesem und anderen Knoten gemeinsam genutzt werden. Der geschützte Knoten ist sich möglicherweise nicht "bewusst", dass er geschützt wird, und wenn er versucht, auf eine der gemeinsam genutzten Platten zuzugreifen, entdeckt er die Reservierung und gerät in Panik.

Failfast-Mechanismus für den Fehlerschutz

Der Mechanismus, durch den das Cluster-Framework sicherstellt, dass ein ausgefallener Knoten nicht neu booten und auf gemeinsam genutzten Speicher schreiben kann, wird als Failfast bezeichnet.

Knoten, die Cluster-Mitglieder sind, aktivieren kontinuierlich ein spezifisches ioctl, MHIOCENFAILFAST, für die Platten, auf die sie zugreifen. Hierzu gehören auch die Quorum-Platten. Dieses ioctl ist eine Direktive für den Plattentreiber. Das ioctl gibt einem Knoten die Möglichkeit, selbst in Panik zu geraten, wenn er durch eine Reservierung eines anderen Knotens nicht auf die Platte zugreifen kann.

Das ioctl MHIOCENFAILFAST veranlasst den Treiber, die Fehlerrückgabe jedes Lese- und Schreibvorgangs, den ein Knoten an die Platte ausgibt, auf den Fehlercode Reservation_Conflict zu überprüfen. Das ioctl gibt im Hintergrund regelmäßig einen Testvorgang an die Platte aus, um sie auf die Meldung Reservation_Conflict zu überprüfen. Sowohl der Vordergrund- als auch der Hintergrund-Flussaufzeichnungspfad geraten in Panik, wenn Reservation_Conflict zurückgegeben wird.

Bei SCSI-2-Platten sind die Reservierungen nicht dauerhaft – sie werden beim erneuten Booten von Knoten gelöscht. Bei SCSI-3-Platten mit PGR (Persistent Group Reservation) werden die Reservierungsinformationen auf der Platte gespeichert und bleiben auch nach dem Booten von Knoten erhalten. Der Failfast-Mechanismus funktioniert stets auf dieselbe Weise, ob Sie nun SCSI-2- oder SCSI-3-Platten verwenden.

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. Wenn der Knoten, der über kein Quorum verfügt, versucht, auf die gemeinsam genutzten Platten zuzugreifen, wird ein Reservierungskonflikt gemeldet und der Knoten gerät, bewirkt durch den Failfast-Mechanismus, in Panik.

Nach der Panik kann der Knoten neu booten und versuchen, dem Cluster wieder beizutreten oder in Clustern aus SPARC-basierten Systemen an der OpenBoot^TM PROM (OBP)-Eingabeaufforderung bleiben. Welche Aktion eingeleitet wird, bestimmt die Einstellung des auto-boot?-Parameters. Sie können den Parameter auto-boot? mit eeprom(1M) an der OpenBoot PROM-Eingabeaufforderung ok in einem SPARC-basierten Cluster einstellen. Alternativ dazu können Sie diesen Parameter auch mit dem SCSI-Dienstprogramm einstellen, das Sie nach dem Booten des BIOS in einem x86-basierten Cluster ausführen können.

Informationen zu Quorum-Konfigurationen

Die folgende Liste enthält Informationen zu Quorum-Konfigurationen:

• Quorum-Geräte können Benutzerdaten enthalten.

• In einer N+1-Konfiguration, in der N Quorum-Geräte mit einem der 1 bis N Knoten und dem N+1-Knoten verbunden sind, überlebt der Cluster den Ausfall aller 1 bis N Knoten oder eines der N/2-Knoten. Bei dieser Verfügbarkeit wird vorausgesetzt, dass das Quorum-Gerät ordnungsgemäß funktioniert.

• In einer N-Knotenkonfiguration, in der ein einzelnes Quorum-Gerät mit allen Knoten verbunden ist, kann der Cluster den Ausfall aller N-1Knoten überleben. Bei dieser Verfügbarkeit wird vorausgesetzt, dass das Quorum-Gerät ordnungsgemäß funktioniert.

• In einer N-Knoten-Konfiguration, bei der ein einzelnes Quorum-Gerät mit allen Knoten verbunden wird, kann der Cluster den Ausfall des Quorum-Geräts überleben, sofern alle Cluster-Knoten verfügbar sind.

Beispiele für Quorum-Konfigurationen, die Sie besser vermeiden sollten, finden Sie unter Unzulässige Quorum-Konfigurationen . Beispiele für empfohlene Quorum-Konfigurationen finden Sie unter Empfohlene Quorum-Konfigurationen .

Erfüllen der Anforderungen für Quorum-Geräte

Sie müssen folgende Anforderungen erfüllen. Wenn Sie diese Anforderungen missachten, kann die Verfügbarkeit Ihres Clusters beeinträchtigt werden.

• Stellen Sie sicher, dass die Sun Cluster-Software Ihr Gerät als Quorum-Gerät unterstützt.

  ---

  Hinweis –

  Eine Liste der Geräte, die von der Sun Cluster-Software als Quorum-Geräte unterstützt werden, erhalten Sie bei Ihrem Sun-Dienstanbieter.

  ---

  Die Sun Cluster-Software unterstützt zwei Arten von Quorum-Geräten:

  • Gemeinsam genutzte Multihost-Platten, die SCSI-3-PGR-Reservierungen unterstützen

  • Gemeinsam genutzte Dual-Host-Platten, die SCSI-2-Reservierungen unterstützen

• In einer Konfiguration mit zwei Knoten müssen Sie mindestens ein Quorum-Gerät konfigurieren, um sicherzustellen, dass ein einzelner Knoten weiterbesteht, wenn der andere Knoten ausfällt. Informationen hierzu finden Sie in Abbildung 3–2.

Beispiele für Quorum-Konfigurationen, die Sie besser vermeiden sollten, finden Sie unter Unzulässige Quorum-Konfigurationen . Beispiele für empfohlene Quorum-Konfigurationen finden Sie unter Empfohlene Quorum-Konfigurationen .

Einhalten von Empfehlungen für Quorum-Geräte

Ermitteln Sie mithilfe der folgenden Informationen, welche Quorum-Konfiguration am besten für Ihre Topologie geeignet ist:

• Verfügen Sie über ein Gerät, das an alle Knoten des Clusters angeschlossen werden kann?

  • Falls ja, konfigurieren Sie dieses Gerät als Ihr Quorum-Gerät. Es ist nicht nötig, dass Sie ein weiteres Quorum-Gerät konfigurieren, da Ihre Konfiguration bereits optimal ist.

    ---

    Achtung –

    Wenn Sie diese Anforderung ignorieren und ein weiteres Quorum-Gerät konfigurieren, wird die Verfügbarkeit des Clusters durch das zusätzliche Quorum-Gerät verringert.

    ---

  • Falls nicht, konfigurieren Sie Ihr Gerät bzw. Ihre Geräte mit zwei Anschlüssen.

• Stellen Sie sicher, dass die Gesamtanzahl der Stimmen, die von Quorum-Geräten bereitgestellt werden, grundsätzlich geringer ist als die Gesamtanzahl der von Knoten bereitgestellten Stimmen. Ist dies nicht der Fall, können die Knoten keinen Cluster bilden, wenn alle Platten verfügbar sind – auch wenn sämtliche Knoten funktionsfähig sind.

  ---

  Hinweis –

  In bestimmten Umgebungen sollten Sie die allgemeine Cluster-Verfügbarkeit reduzieren, um sie Ihren Bedürfnissen anzupassen. Ignorieren Sie in diesen Fällen die genannte Empfehlung. Wenn diese Empfehlung jedoch nicht wahrgenommen wird, wird die Verfügbarkeit insgesamt beeinträchtigt. Die unter Untypische Quorum-Konfigurationen beschriebene Konfiguration beispielsweise ist weniger verfügbar: Die Quorum-Stimmen übersteigen hier die Knotenstimmen. Der Cluster ist so konfiguriert, dass der gesamte Cluster ausfällt, wenn der Zugriff auf den von Nodes A und Node B gemeinsam genutzten Speicher verloren geht.

  ---

  Unter Untypische Quorum-Konfigurationen finden Sie eine Ausnahme für diese Empfehlung.

• Geben Sie ein Quorum-Gerät für sämtliche Knotenpaare an, die auf ein gemeinsam genutztes Speichergerät zugreifen. Diese Quorum-Konfiguration beschleunigt den Fehlerschutzvorgang. Informationen hierzu finden Sie unter Quorum in Konfigurationen mit mehr als zwei Knoten .

• Im Allgemeinen steigt die Cluster-Verfügbarkeit, falls durch das Hinzufügen eines Quorum-Geräts die Gesamtanzahl der Cluster-Stimmen gerade wird.

• Quorum-Geräte verlangsamen die Neukonfiguration nach dem Beitritt eines Knotens bzw. dem Ausfall eines Knotens geringfügig. Fügen Sie aus diesem Grund nicht mehr Quorum-Geräte als erforderlich hinzu.

Beispiele für Quorum-Konfigurationen, die Sie besser vermeiden sollten, finden Sie unter Unzulässige Quorum-Konfigurationen . Beispiele für empfohlene Quorum-Konfigurationen finden Sie unter Empfohlene Quorum-Konfigurationen .

Empfohlene Quorum-Konfigurationen

Dieser Abschnitt enthält Beispiele für empfohlene Quorum-Konfigurationen. Beispiele für Quorum-Konfigurationen, die besser vermieden werden sollten, finden Sie unter Unzulässige Quorum-Konfigurationen .

Quorum in Zwei-Knoten-Konfigurationen

Zwei Quorum-Stimmen sind erforderlich, damit ein Zwei-Knoten-Cluster gebildet werden kann. Diese beiden Stimmen können von den beiden Cluster-Knoten oder von einem Knoten und einem Quorum-Gerät stammen.

Abbildung 3–2 Zwei-Knoten-Konfiguration

Quorum in Konfigurationen mit mehr als zwei Knoten

Cluster mit mehr als zwei Knoten können auch ohne ein Quorum-Gerät konfiguriert werden. In diesem Fall können Sie den Cluster nicht ohne eine Knotenmehrheit im Cluster starten.

Untypische Quorum-Konfigurationen

In Abbildung 3–3 wird vorausgesetzt, dass auf Node A und Node B sehr wichtige Anwendungen (beispielsweise Oracle-Datenbanken) ausgeführt werden. Wenn Node A und Node B nicht verfügbar sind und nicht auf gemeinsam genutzte Daten zugreifen können, sollten Sie den gesamten Cluster herunterfahren. Anderenfalls ist diese Konfiguration nicht optimal, da sie keine Hochverfügbarkeit bietet.

Informationen zu Empfehlungen, für die diese Ausnahme gilt, finden Sie unter Einhalten von Empfehlungen für Quorum-Geräte .

Abbildung 3–3 Untypische Konfiguration

Unzulässige Quorum-Konfigurationen

Dieser Abschnitt enthält Beispiele für Quorum-Konfigurationen, die Sie vermeiden sollten. Beispiele für empfohlene Quorum-Konfigurationen finden Sie unter Empfohlene Quorum-Konfigurationen .

Datendienste

Der Begriff Datendienst beschreibt eine Anwendung wie Sun Java System Web Server oder Oracle, die eher zur Ausführung auf einem Cluster als auf einem Einzelserver konfiguriert wurde. Ein Datendienst besteht aus einer Anwendung, spezialisierten Sun Cluster-Konfigurationsdateien und Sun Cluster -Verwaltungsmethoden, mit denen die nachfolgenden Anwendungsaktionen gesteuert werden.

• Beginn

• Anhalten

• Überwachen und Ergreifen von Korrekturmaßnahmen

Informationen zu Datendienst-Typen finden Sie unter Datendienste in Sun Cluster Überblick für das Betriebssystem Solaris.

In Abbildung 3–4 cwird eine Anwendung, die auf einem einzigen Anwendungsserver ausgeführt wird (Einzelservermodell) mit derselben Anwendung auf einem Cluster (Cluster-Servermodell) verglichen. Der einzige Unterschied zwischen den beiden Konfigurationen besteht darin, dass die Cluster-Anwendung ggf. schneller ausgeführt wird und eine bessere Hochverfügbarkeit zeigt.

Abbildung 3–4 Standardkonfiguration versus Client/Server-Konfiguration als Cluster

Beim Einzelservermodell konfigurieren Sie die Anwendung für den Zugriff auf den Server über eine bestimmte öffentliche Netzwerkschnittstelle (einen Hostnamen). Der Hostname ist diesem realen Server zugeordnet.

Beim geclusterten Servermodell ist die öffentliche Netzwerkschnittstelle ein logischer Hostname oder eine gemeinsam genutzte Adresse. Der Begriff Netzwerkressourcen bezeichnet sowohl die logischen Hostnamen als auch die gemeinsam genutzten Adressen.

Für bestimmte Datendienste müssen Sie entweder logische Hostnamen oder gemeinsam genutzte Adressen als Netzwerkschnittstellen angeben. Logische Hostnamen und gemeinsam genutzte Adressen sind nicht austauschbar. Für andere Datendienste können Sie wahlweise logische Hostnamen oder gemeinsam genutzte Adressen angeben. Details zum jeweils erforderlichen Schnittstellentyp finden Sie in den Angaben zur Installation und Konfiguration für den jeweiligen Datendienst.

Eine Netzwerkressource ist keinem spezifischen realen Server zugeordnet. Netzwerkressourcen können zwischen den realen Servern migrieren.

Eine Netzwerkressource ist zunächst einem einzigen Knoten zugeordnet, dem Primärknoten. Wenn der Primärknoten ausfällt, werden Netzwerkressource und Anwendungsressource mit einem Failover-Vorgang auf einen anderen Cluster-Knoten (einen Sekundärknoten) umgeleitet. Wenn die Netzwerkressource ein Failover durchführt, wird die Anwendungsressource nach einer kurzen Verzögerung auf dem Sekundärknoten weiter ausgeführt.

In Abbildung 3–5 wird das Einzelservermodell mit dem geclusterten Servermodell verglichen. Beachten Sie, dass eine Netzwerkressource (in diesem Beispiel ein logischer Hostname) in einem geclusterten Servermodell zwischen mindestens zwei Cluster-Knoten wechseln kann. Die Anwendung ist zur Verwendung dieses logischen Hostnamens anstelle eines Hostnamens konfiguriert, der einem bestimmten Server zugeordnet ist.

Abbildung 3–5 Festgelegter Hostname versus logischer Hostname

gemeinsam genutzte Adresse ist zunächst ebenfalls einem einzigen Knoten zugeordnet. Dieser Knoten wird als globaler Schnittstellenknoten (GIF-Knoten) bezeichnet. Eine gemeinsam genutzte Adresse (die so genannte globale Schnittstelle) wird als einzige Netzwerkschnittstelle zum Cluster eingesetzt.

Der Unterschied zwischen dem Modell logischer Hostname und dem Modell Scalable-Dienst besteht darin, dass beim letztgenannten auf jedem Knoten die gemeinsam genutzte Adresse auf der Schleifenschnittstelle ebenfalls aktiv konfiguriert ist. Dank dieser Konfiguration können mehrere Instanzen eines Datendienstes auf mehreren Knoten gleichzeitig aktiv sein. Der Begriff "Scalable-Dienst" bedeutet, dass Sie die CPU-Leistung für die Anwendung durch Hinzufügen zusätzlicher Cluster-Knoten erhöhen können und die Leistung verbessert wird.

Wenn der globale Schnittstellenknoten ausfällt, kann die gemeinsam genutzte Adresse auf einem anderen Knoten gestartet werden, auf dem ebenfalls eine Instanz der Anwendung ausgeführt wird (wobei dieser andere Knoten zum globalen Schnittstellenknoten wird). Oder die gemeinsam genutzte Adresse wird mit einem Failover auf einen anderen Cluster-Knoten verschoben, auf dem die Anwendung zuvor nicht ausgeführt wurde.

In Abbildung 3–6 wird die Einzelserverkonfiguration mit der Cluster-Konfiguration mit Scalable-Diensten verglichen. Beachten Sie, dass die gemeinsam genutzte Adresse in der Scalable-Dienst-Konfiguration auf allen Knoten vorhanden ist. Ähnlich wie bei der Verwendung eines logischen Hostnamens für Failover-Datendienste wird die Anwendung zur Verwendung dieser gemeinsam genutzten Adresse anstelle eines einem bestimmten Server zugeordneten Hostnamens konfiguriert.

Abbildung 3–6 Festgelegter Hostname versus gemeinsam genutzte Adresse

Datendienstmethoden

Die Sun Cluster-Software stellt eine Reihe von Dienstverwaltungsmethoden zur Verfügung. Diese Methoden werden vom Ressourcengruppen-Manager (RGM) gesteuert und eingesetzt, um die Anwendung auf den Cluster-Knoten zu starten, anzuhalten und zu überwachen. Mit diesen Methoden, der Cluster-Framework-Software und den Multihostgeräten können die Anwendungen als Failover- oder Scalable-Datendienste verwendet werden.

Der RGM verwaltet auch Ressourcen im Cluster einschließlich der Anwendungsinstanzen und Netzwerkressourcen (logische Hostnamen und gemeinsam genutzte Adressen).

Zusätzlich zu den Methoden der Sun Cluster-Software stellt das Sun Cluster-System auch eine API und verschiedene Datendienst-Entwicklungstools zur Verfügung. Mit diesen Tools können Anwendungsprogrammierer die Datendienstmethoden entwickeln, die sie zum Ausführen anderer Anwendungen als hoch verfügbare Datendienste mit der Sun Cluster-Software benötigen.

Failover-Datendienste

Wenn der Knoten ausfällt, auf dem der Datendienst ausgeführt wird (der Primärknoten), migriert der Dienst ohne Benutzereingriff auf einen anderen funktionsfähigen Knoten. 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 dekonfiguriert und auf einem anderen Knoten konfiguriert.

Für Failover-Datendienste werden die Anwendungsinstanzen nur auf einem einzigen Knoten ausgeführt. 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). Das Ergebnis hängt davon ab, wie der Datendienst konfiguriert wurde.

Skalierbare Datendienste

Der Scalable-Datendienst kann aktive Instanzen auf mehreren Knoten ausführen. Scalable-Dienste verwenden die beiden folgenden Ressourcengruppen:

• Eine Scalable-Ressourcengruppe enthält die Anwendungsressourcen.

• Eine Failover-Ressourcengruppe enthält die Netzwerkressourcen ( gemeinsam genutzte Adressen), 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.

Dienstanforderungen erreichen den Cluster ü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. Mehrere globale Schnittstellen können auf anderen Knoten vorhanden sein, die weitere, gemeinsam genutzte Adressen hosten.

Bei Scalable-Diensten werden die Anwendungsinstanzen auf mehreren Knoten gleichzeitig ausgeführt. Wenn der Knoten mit der globalen Schnittstelle ausfällt, wird die globale Schnittstelle auf einen anderen Knoten verschoben. Wenn eine Anwendungsinstanz bei der Ausführung fehlschlägt, versucht die Instanz, auf demselben Knoten neu zu starten.

Wenn eine Anwendungsinstanz nicht auf demselben Knoten neu gestartet werden kann und ein anderer, nicht verwendeter Knoten für die Ausführung des Dienstes konfiguriert ist, wird der Dienst im Rahmen eines Failover-Vorgangs auf den nicht verwendeten Knoten verschoben. Andernfalls wird der Dienst weiter auf den restlichen Knoten ausgeführt und führt möglicherweise zu einer Reduzierung des Dienstdurchsatzes.

Der TCP-Zustand für jede Anwendungsinstanz bleibt auf dem Knoten mit der Instanz, nicht auf dem Knoten mit der globalen Schnittstelle. Deswegen hat ein Ausfall des Knotens mit der globalen Schnittstelle keine Auswirkung auf die Verbindung.

Abbildung 3–7 zeigt ein Beispiel für eine Failover- und eine Scalabe-Ressourcengruppe und die Abhängigkeiten, die zwischen den beiden für Scalable-Dienste bestehen. Dieses Beispiel enthält drei Ressourcengruppen. Die Failover-Ressourcengruppe enthält Anwendungsressourcen für hoch verfügbare DNS und Netzwerkressourcen, die sowohl vom hoch verfügbaren DNS als auch vom hoch verfügbaren Apache Web Server genutzt werden (nur in SPARC-basierten Clustern verwendet). Die Scalable-Ressourcengruppen enthalten nur Anwendungsinstanzen des Apache Web Servers. Beachten Sie, dass Ressourcengruppenabhängigkeiten zwischen den Scalable- und den Failover-Ressourcengruppen (durchgezogene Linien) bestehen. Außerdem hängen alle Apache-Anwendungsressourcen von der Netzwerkressource schost-2 ab, die eine gemeinsam genutzte Adresse ist (gestrichelte Linien).

Abbildung 3–7 SPARC: Beispiel für Failover- und Scalable-Ressourcengruppen

Lastausgleichsverfahren

Der Lastausgleich verbessert die Leistung der Scalable-Dienste sowohl bei der Antwortzeit als auch beim Durchsatz. Es gibt zwei Klassen von Scalable-Datendiensten.

• Rein

• Sticky

Bei einem reinen Dienst, kann jede Instanz Client-Anforderungen beantworten. Bei einem Sticky-Dienst kann ein Client Anforderungen an dieselbe Instanz senden. 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. Angenommen, jeder Knoten in einem Drei-Knoten-Cluster hat eine Gewichtung von 1. Jeder Knoten bedient 1/3 der Anforderungen aller beliebigen Clients im Auftrag des Dienstes. Gewichtungen können jederzeit vom Verwalter über die scrgadm(1M)-Befehlsschnittstelle oder über die SunPlex-Manager-GUI geändert werden.

Ein Sticky-Dienst hat zwei Typen, 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. Der Client wird als "sticky" gegenüber der 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.

Beispiel: Ein Webbrowser auf dem Client stellt mithilfe von drei verschiedenen TCP-Verbindungen eine Verbindung mit einer gemeinsam genutzten IP-Adresse an Port 80 her. Die Verbindungen tauschen jedoch zwischengespeicherte Sitzungsinformationen über den Dienst aus.

Eine Verallgemeinerung eines Sticky-Verfahrens erstreckt sich auf mehrere Scalable-Dienste, die im Hintergrund Sitzungsinformationen bei derselben Instanz austauschen. Wenn diese Dienste im Hintergrund Sitzungsinformation bei derselben Instanz austauschen, wird der Client als "sticky" bezeichnet, weil mehrere Serverinstanzen auf demselben Knoten unterschiedliche Ports abhören. .

Beispiel: Ein E-Commerce-Kunde füllt seinen Einkaufskorb mit Artikeln mithilfe von HTTP an Port 80, wechselt dann jedoch zum Senden sicherer Daten mit SSL auf Port 443, um die Artikel im Einkaufskorb mit Kreditkarte zu bezahlen.

Platzhalter-Sticky-Dienste verwenden dynamisch zugewiesene Port-Nummern, erwarten jedoch trotzdem, dass die Client-Anforderungen an denselben Knoten geleitet werden. Der Client ist "Sticky-Platzhalter" bei Ports, die dieselbe IP-Adresse aufweisen.

Ein gutes Beispiel dieses Verfahrens ist der passive FTP-Modus. Beispiel: Ein Client stellt an Port 21 eine Verbindung mit einem FTP-Server her. Anschließend wird er vom Server angewiesen, eine neue Verbindung mit einem Listener-Port-Server im dynamischen Port-Bereich herzustellen. Alle Anforderungen an diese IP-Adresse werden an denselben Knoten weitergeleitet, den der Server dem Client über die Steuerinformationen angegeben hat. .

Für jedes dieser Sticky-Verfahren ist das gewichtete Lastausgleichsverfahren standardmäßig gültig. Daher wird die ursprüngliche Client-Anforderung an die vom Lastausgleich vorgegebene Instanz geleitet. Nachdem der Client eine Affinität zum Knoten mit der ausgeführten Instanz aufgebaut hat, werden zukünftige Anforderungen unter bestimmten Bedingungen an diese Instanz geleitet. Der Knoten muss zugänglich sein und das Lastausgleichsverfahren darf sich nicht geändert haben.

Weitere Details zu spezifischen Lastausgleichsverfahren werden nachstehend erläutert.

• Gewichtet. Die Last wird entsprechend den angegebenenen Gewichtungswerten auf mehrere Knoten verteilt. Dieses Verfahren wird mit dem LB_WEIGHTED-Wert für die Load_balancing_weights-Eigenschaft eingestellt. Wenn die Gewichtung für einen Knoten nicht ausdrücklich angegeben ist, beträgt die Standardgewichtung für diesen Knoten Eins.

  Das gewichtete Verfahren leitet einen gewissen Prozentsatz des Datenverkehrs von Clients auf einen bestimmten Knoten. Bei X=Gewichtung und A=Gesamtgewichtung aller aktiven Knoten ist davon auszugehen, dass etwa X/A aller neuen Verbindungen zu einem aktiven Knoten geleitet werden. Allerdings muss dafür die Gesamtanzahl der Verbindungen groß genug sein. Dieses Verfahren befasst sich nicht mit einzelnen Anforderungen.

  Beachten Sie, dass es sich nicht um ein Round-Robin-Verfahren handelt. Bei einem Round-Robin-Verfahren würde jede Anforderung eines Clients an einen unterschiedlichen Knoten geleitet. Beispielsweise würde die erste Anforderung an Knoten 1, die zweite Anforderung an Knoten 2 geleitet und so weiter.

• Sticky. Bei diesem Verfahren ist der Satz an Ports bei der Konfiguration der Anwendungsressourcen bekannt. Dieses Verfahren wird mit dem LB_STICKY-Wert für die Load_balancing_policy-Ressourceneigenschaft eingestellt.

• Sticky-Platzhalter. Dieses Verfahren ist eine Obermenge des normalen "Sticky"-Verfahrens. Bei einem durch die IP-Adresse identifizierten Scalable-Dienst werden die Ports vom Server zugewiesen (und sind vorher nicht bekannt). Die Ports können sich ändern. Dieses Verfahren wird mit dem LB_STICKY_WILD-Wert für die Load_balancing_policy-Ressourceneigenschaft eingestellt.

Failback-Einstellungen

Ressourcengruppen wechseln beim Failover von einem Knoten auf einen anderen. Wenn ein solcher Failover auftritt, wird der ursprüngliche Sekundärknoten zum neuen Primärknoten Die Failback-Einstellungen legen die Aktionen fest, die ausgeführt werden, sobald der ursprüngliche Primärknoten wieder online gebracht wird. Die Optionen sind, entweder den ursprünglichen Primärknoten wieder zum Primärknoten zu machen (Failback) oder den aktuellen Primärknoten als solchen zu belassen. Sie geben die gewünschte Option mit der Einstellung der Failback -Ressourcengruppeneigenschaft an.

Bei bestimmten Instanzen kann die Failback-Einstellung zu einer reduzierten Verfügbarkeit der Ressourcengruppe führen, wenn der Originalknoten mit der Ressource ausfällt und mehrmals neu bootet.

Fehler-Monitore der Datendienste

Jeder Sun Cluster-Datendienst stellt einen Fehler-Monitor zur Verfügung, der regelmäßig den Datendienst auf einwandfreies Funktionieren prüft. Ein Fehler-Monitor prüft, ob der bzw. die Anwendungsdämon(en) ausgeführt und die Clients bedient werden. Aufgrund der von den Testsignalen zurückgebenen Informationen können vordefinierte Aktionen wie ein Neustart eines Dämons oder das Einleiten eines Failovers ausgelöst werden.

Entwickeln neuer Datendienste

Sun stellt Vorlagen für Konfigurationsdateien und Verwaltungsmethoden zur Verfügung, mit denen Sie unterschiedliche Anwendungen zu Failover- oder Scalable-Diensten innerhalb eines Clusters machen können. Falls Sun die Anwendung, die Sie als Failover- oder Scalable-Dienst ausführen möchten, nicht anbietet, haben Sie eine Alternative. Verwenden Sie eine Sun Cluster-API oder die DSET-API , um die Anwendung als Failover- oder Scalable-Dienst zu konfigurieren. Es können jedoch nicht alle Anwendungen als Scalable-Dienst programmiert werden.

Eigenschaften von Scalable-Diensten

Sie können anhand einer Reihe von Kriterien feststellen, ob eine Anwendung als Scalable-Dienst ausgeführt werden kann. Um festzustellen, ob Ihre Anwendung als Scalable-Dienst ausgeführt werden kann, lesen Sie den Abschnitt Analysieren der Eignung einer Anwendung in Sun Cluster Entwicklerhandbuch Datendienste für Solaris OS. Diese Kriterien werden nachfolgend zusammengefasst.

• Erstens: Ein solcher Dienst besteht aus einer oder mehreren Server instanzen. Jede Instanz wird auf einem anderen Knoten des Clusters ausgeführt. Zwei oder mehr Instanzen desselben Dienstes können nicht auf demselben Knoten ausgeführt werden.

• Zweitens: Wenn der Dienst einen externen logischen Datenspeicher zur Verfügung stellt, müssen Sie mit Bedacht vorgehen. Der gleichzeitige Zugriff auf diesen Speicher durch mehrere Serverinstanzen muss synchronisiert werden, um den Verlust von Aktualisierungen oder das Lesen von Daten zu verhindern, wenn diese gerade geändert werden. Beachten Sie, dass der Begriff "extern" verwendet wird, um diesen Speicher vom Arbeitsspeicherstatus zu unterscheiden. Der Begriff "logisch" weist darauf hin, dass der Speicher als einzelne Entität angezeigt wird, obwohl er möglicherweise repliziert wurde. Außerdem hat dieser logische Datenspeicher die Eigenschaft, dass eine Aktualisierung des Speichers durch eine beliebige Instanz sofort von anderen Instanzen "erkannt" wird.

  Das Sun Cluster-System stellt einen solchen externen Speicher über das Cluster-Dateisystem und die globalen Partitionen im raw-Modus zur Verfügung. Angenommen, ein Dienst schreibt neue Daten in eine externe Protokolldatei oder ändert die dort vorhandenen Daten. Wenn mehrere Instanzen dieses Dienstes ausgeführt werden, hat jede Instanz Zugriff auf dieses externe Protokoll und jede kann gleichzeitig auf dieses Protokoll zugreifen. Jede Instanz muss den Zugriff auf dieses Protokoll synchronisieren, andernfalls kommt es zu Interferenzen zwischen den Instanzen. Der Dienst kann die normale Solaris-Dateisperrung über fcntl(2) und lockf(3C) verwenden, um die gewünschte Synchronisierung zu erreichen.

  Ein weiteres Beispiel für diese Art des Speichers ist eine Backend-Datenbank, wie beispielsweise Hochverfügbarkeits-Oracle Real Application Clusters Guard für SPARC-basierte Cluster oder Oracle. Bei diesem Typ von Backend-Datenbankserver ist die Synchronisierung über Datenbankabfragen oder Aktualisierungstransaktionen integriert. So müssen Serverinstanzen nicht für jede einzelne Instanz eine eigene Synchronisierung durchführen.

  Der Sun IMAP-Server ist ein Beispiel für einen Dienst, bei dem es sich nicht um einen Scalable-Dienst handelt. Der Dienst aktualisiert einen Speicher, aber dieser Speicher ist privat. Wenn mehrere IMAP-Instanzen in diesen Speicher schreiben, werden die jeweiligen Einträge überschrieben, weil die Aktualisierungen nicht synchronisiert sind. Der IMAP-Server muss für die Synchronisierung eines gleichzeitigen Zugriffs umgeschrieben werden.

• Beachten Sie schließlich, dass Instanzen über private Daten verfügen können, die von den Daten anderer Instanzen getrennt sind. In einem solchen Fall muss der Dienst den gleichzeitigen Zugriff nicht selbst synchronisieren, weil die Daten privat sind und nur diese Instanz sie bearbeiten kann. In diesem Fall müssen Sie darauf achten, diese privaten Daten nicht unter dem Cluster-Dateisystem zu speichern, weil die Möglichkeit eines globalen Zugriffs besteht.

Datendienst-API und API der Datendienst-Entwicklungsbibliothek-API

Das Sun Cluster-System bietet folgende Informationen, um Anwendungen hochverfügbar zu machen:

• Datendienste, die als Bestandteil des Sun Cluster-Systems bereitgestellt werden.

• Eine Datendienst-API,

• Eine Entwicklungsbibliotheks-API für Datendienste

• Einen "generischen" Datendienst.

Im Sun Cluster Data Services Planning and Administration Guide for Solaris OS wird die Installation und Konfiguration der Datendienste beschrieben, die im Lieferumfang des Sun Cluster-Systems enthalten sind. Im Sun Cluster 3.1 9/04 Software Collection for Solaris OS (SPARC Platform Edition) wird beschrieben, wie andere Anwendungen für die Hochverfügbarkeit im Sun Cluster-Framework konfiguriert werden.

Mit den Sun Cluster-APIs können Anwendungsentwickler Fehler-Monitore sowie Skripts zum Starten und Anhalten von Datendienstinstanzen entwickeln. Mit diesen Tools kann eine Anwendung als Failover- oder Scalable-Datendienst eingerichtet werden. Das Sun Cluster-System stellt einen "generischen" Datendienst zur Verfügung. Verwenden Sie diesen generischen Datendienst, um schnell die erforderlichen Start- und Stoppmethoden zu generieren und den Datendienst als Failover- oder Scalable-Dienst zu implementieren.

Verwenden des Cluster-Interconnect für den Datendienstverkehr

Ein Cluster benötigt mehrere Netzwerkverbindungen zwischen den Knoten, die den Cluster-Interconnect bilden. Sun Cluster verwendet mehrere Interconnects, um folgende Ziele zu erreichen:

• Gewährleisten von Hochverfügbarkeit

• Verbessern der Leistung

Für den internen Datenverkehr, wie beispielsweise Dateisystemdaten oder Scalable-Dienstdaten, werden Meldungen über alle verfügbaren Interconnects im Round-Robin-Verfahren gesendet. Der Cluster-Interconnect steht auch Anwendungen zur hoch verfügbaren Kommunikation zwischen den Knoten zur Verfügung. Eine verteilte Anwendung kann zum Beispiel Komponenten auf unterschiedlichen Knoten ausführen, die miteinander kommunizieren müssen. Indem der Cluster-Interconnect anstelle des öffentlichen Netzwerks verwendet wird, bleiben diese Verbindungen beim Versagen einer einzelnen Verknüpfung bestehen.

Um den Cluster-Interconnect für die Datenverbindung zwischen den Knoten zu verwenden, muss eine Anwendung die während der Sun Cluster-Installation konfigurierten privaten Hostnamen verwenden. Wenn zum Beispiel der private Hostname für node 1 clusternode1-priv ist, sollten Sie diesen Namen verwenden, um mit node 1 für die Kommunikation über den Cluster-Interconnect zu kommunizieren. TCP-Sockets, die mit diesem Namen geöffnet wurden, werden über den Cluster-Interconnect geleitet und können bei einem Netzwerkfehler transparent umgeleitet werden.

Da die privaten Hostnamen während der Sun Cluster-Installation konfiguriert werden können, kann der Cluster-Interconnnect jeden beliebigen, während der Installation gewählten Namen verwenden. Den tatsächlichen Namen erhalten Sie über den scha_cluster_get(3HA)-Befehl mit dem Argument scha_privatelink_hostname_node.

Sowohl die Anwendungskommunikation als auch die Cluster-interne Kommunikation werden über alle Interconnects verteilt. Da die Anwendungen den Cluster-Interconnect mit dem internen Cluster-Datenverkehr teilen, hängt die für die Anwendung verfügbare Bandbreite von der Bandbreite ab, die für anderen Cluster-Datenverkehr verwendet wird. Bei einem Versagen werden der gesamte interne Datenverkehr und der Anwendungsdatenverkehr über alle verfügbaren Interconnects verteilt.

Jedem Knoten wird außerdem eine feste Pro-Knoten-Adresse zugewiesen. Diese Pro-Knoten-Adresse ist fest mit dem clprivnet-Treiber verknüpft. Die IP-Adresse ist dem privaten Hostnamen für den Knoten zugeordnet: clusternode1-priv. Informationen zum Sun Cluster-Treiber für private Netzwerke finden Sie in der Online-Dokumentation clprivnet(7).

Wenn die Anwendung an allen Stellen konsistente IP-Adressen benötigt, konfigurieren Sie die Anwendung so, dass die Pro-Knoten-Adresse sowohl an den Client als auch an den Server angebunden ist. In diesem Fall scheinen alle Verbindungen von der Pro-Knoten-Adresse zu stammen und zu dieser zurückzukehren.

Ressourcen, Ressourcengruppen und Ressourcentypen

Datendienste verwenden mehrere Typen von Ressourcen: Anwendungen wie Sun Java System Web Server oder Apache 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.

Datendienste sind Ressourcentypen. Sun Cluster HA für Oracle ist der Ressourcentyp SUNW.oracle-server und Sun Cluster HA für Apache ist der Ressourcentyp SUNW.apache.

Eine Ressource ist eine Instanz eines Ressourcentyps, der Cluster-weit definiert ist. Es sind mehrere Ressourcentypen definiert.

Netzwerkressourcen sind entweder SUNW.LogicalHostname- oder SUNW.SharedAddress-Ressourcentypen. Diese beiden Ressourcentypen sind von der Sun Cluster-Software vorregistriert.

Die Ressourcentypen HAStorage und HAStoragePlus werden zur Synchronisierung beim Starten von Ressourcen und Plattengerätegruppen verwendet, von denen die Ressourcen abhängen. Durch diese Ressourcentypen wird sichergestellt, dass die Pfade zu Einhängepunkten im Cluster-Dateisystem, globalen Geräten und Gerätegruppennamen verfügbar sind, bevor ein Datendienst startet. Weitere Informationen finden Sie unter "Synchronisieren der Startvorgänge zwischen Ressourcengruppen und Plattengerätegruppe" im Data Services Installation and Configuration Guide. Der HAStoragePlus-Ressourcentyp ist ab Sun Cluster 3.0 5/02 verfügbar und bietet eine weitere Funktion, um lokale Dateisysteme hoch verfügbar zu machen. Weitere Informationen zu dieser Funktion finden Sie unter HAStoragePlus Ressourcentyp .

RGM-verwaltete Ressourcen werden in so genannten Ressourcengruppen zusammengefasst, so dass sie als Einheit verwaltet werden können. Eine Ressourcengruppe migriert als Einheit, wenn ein Failover oder ein Switchover für die Ressourcengruppe eingeleitet wird.

Wenn Sie eine Ressourcengruppe mit Anwendungsressourcen online bringen, wird die Anwendung gestartet. Die Datendienst-Startmethode wartet, bis die Anwendung aktiv ist und ausgeführt wird, bevor sie erfolgreich beendet wird. Die Feststellung, wann die Anwendung aktiv ist und ausgeführt wird, erfolgt auf dieselbe Weise, in der Datendienst-Fehler-Monitor feststellt, ob ein Datendienst Clients bedient. Im Sun Cluster Data Services Planning and Administration Guide for Solaris OS erhalten Sie weitere Informationen über diesen Vorgang.

Ressourcengruppen-Manager (RGM)

Der RGM steuert Datendienste (Anwendungen) als Ressourcen, die mit Ressourcentypen-Implementierungen verwaltet werden. Diese Implementierungen werden entweder von Sun geliefert oder von einem Entwickler mithilfe einer generischen Datendienstvorlage, der API für die Datendienst-Entwicklungsbibliothek (DSDL-API) oder der Ressourcenverwaltungs-API (RMAPI), erstellt. Der Cluster-Verwalter erstellt und verwaltet Ressourcen in Containern, die als Ressourcengruppen bezeichnet werden. Der RGM stoppt und startet die Ressourcengruppen auf den ausgewählten Knoten je nach den Änderungen in der Cluster-Mitgliedschaft.

Der RGM verwaltet Ressourcen und Ressourcengruppen. Durch RGM-Aktionen wechseln Ressourcen und Ressourcengruppen zwischen dem Online- und Offline-Zustand. Eine umfassende Beschreibung dieser Zustände und der Einstellungen für Ressourcen und Ressourcengruppen finden Sie im Abschnitt Zustände und Einstellungen für Ressourcen und Ressourcengruppen .

Informationen über das Starten von Solaris-Projekten unter der Steuerung des RGM finden Sie unter Datendienst-Projektkonfiguration l.

Zustände und Einstellungen für Ressourcen und Ressourcengruppen

Ein Verwalter verwendet statische Einstellungen für Ressourcen und Ressourcengruppen. Diese Einstellungen können nur über Verwaltungsaktionen geändert werden. Der RGM ändert die dynamischen "Zustände" von Ressourcengruppen. Diese Einstellungen und Zustände sind in der nachstehenden Liste beschrieben.

• Verwaltet oder unverwaltet – Diese Cluster-weiten Einstellungen gelten nur für Ressourcengruppen. Ressourcengruppen werden vom RGM verwaltet. Mit dem scrgadm(1M)-Befehl wird die Verwaltung einer Ressourcengruppe durch den RGM aktiviert bzw. deaktiviert. Diese Einstellungen werden bei einer Cluster-Neukonfiguration nicht geändert.

  Wenn eine Ressourcengruppe zum ersten Mal erstellt wird, ist sie unverwaltet. Eine Ressourcengruppe muss verwaltet werden, bevor enthaltene Ressourcen aktiv werden können.

  Bei einigen Datendiensten, zum Beispiel einem Scalable-Webserver, muss diese Arbeit vor dem Starten und nach dem Anhalten der Netzwerkressourcen erledigt werden. Dies wird durch die Datendienstmethoden zum Initialisieren (INIT) und Beenden (FINI) erledigt. Die INIT-Methoden werden nur ausgeführt, wenn die Ressourcengruppe, zu der die Ressource gehört, den Zustand "Verwaltet" hat.

  Wenn der Status einer Ressourcengruppe von unverwaltet auf verwaltet gesetzt wird, werden alle registrierten INIT-Methoden für die in der Gruppe enthaltenen Ressourcen ausgeführt.

  Wenn der Status einer Ressourcengruppe von verwaltet auf unverwaltet gesetzt wird, werden alle registrierten FINI-Methoden aufgerufen, um eine Bereinigung durchzuführen.

  Am häufigsten werden INIT- und FINI-Methoden für Netzwerkressourcen für Scalable-Dienste eingesetzt. Sie können jedoch für alle beliebigen Initialisierungs- oder Bereinigungsaufgaben eingesetzt werden, die nicht von der Anwendung erledigt werden.

• Aktiviert oder deaktiviert – Diese Cluster-weiten Einstellungen gelten für Ressourcen. Der scrgadm(1M)-Befehl kann zur Aktivierung oder Deaktivierung einer Ressource verwendet werden. Diese Einstellungen werden bei einer Cluster-Neukonfiguration nicht geändert.

  Bei einer normalen Einstellung ist eine Ressource aktiviert und wird aktiv im System ausgeführt.

  Wenn die Ressource auf keinem Cluster-Knoten verfügbar sein soll, deaktivieren Sie die Ressource. Eine deaktivierte Ressource steht nicht zur allgemeinen Verwendung zur Verfügung.

• Online oder offline – Diese dynamischen Zustände gelten sowohl für Ressourcen als auch für Ressourcengruppen.

  Die Zustände "online" und "offline" ändern sich bei den Cluster-Übergängen im Verlauf der Cluster-Rekonfigurationsschritte bei einem Switchover oder Failover. Außerdem können diese Zustände über Verwaltungsaktionen geändert werden. Mit dem Befehl scswitch(1M) können Sie den Online- bzw. Offline-Zustand einer Ressource oder Ressourcengruppe ändern.

  Eine Failover-Ressource oder -Ressourcengruppe kann nur auf jeweils einem Knoten gleichzeitig online sein. Eine Scalable-Ressource oder -Ressourcengruppe kann gleichzeitig auf mehreren Knoten online und auf anderen offline sein. Während eines Switchovers oder Failovers werden Ressourcengruppen mit den darin enthaltenen Ressourcen auf einem Knoten offline genommen und auf einem anderen Knoten online gebracht.

  Wenn eine Ressourcengruppe offline ist, sind auch alle ihre Ressourcen offline. Wenn eine Ressourcengruppe online ist, sind auch alle ihre aktivierten Ressourcen online.

  Ressourcengruppen können mehrere Ressourcen mit Abhängigkeiten zwischen Ressourcen enthalten. Aufgrund dieser Abhängigkeiten müssen die Ressourcen in einer bestimmten Reihenfolge online gebracht und offline genommen werden. Die Methoden, um die Ressourcen online zu bringen und offline zu nehmen, können für jede Ressource unterschiedlich lange dauern. Die Zustände online und offline können für Ressourcen einer einzigen Ressourcengruppe aufgrund von Ressourcenabhängigkeiten und Unterschieden bei Start- und Stoppzeit bei einer Cluster-Rekonfiguration unterschiedlich sein.

Ressourcen- und Resourcengruppeneigenschaften

Sie können Eigenschaftenwerte für die Ressourcen und Ressourcengruppen Ihrer Sun Cluster-Datendienste konfigurieren. Standardeigenschaften sind für alle Datendienste gleich. Erweiterungseigenschaften sind für jeden Datendienst spezifisch. Einige Standard- und Erweiterungseigenschaften sind mit Standardeinstellungen konfiguriert, so dass Sie diese nicht ändern müssen. Andere müssen im Rahmen der Erstellung und Konfiguration von Ressourcen eingestellt werden. Die Dokumentation für jeden Datendienst gibt an, welche Ressourceneigenschaften eingestellt werden können und wie diese einzustellen sind.

Die Standardeigenschaften werden zur Konfiguration von Ressourcen- und Ressourcengruppeneigenschaften eingesetzt, die in der Regel von keinem bestimmten Datendienst abhängen. Die Standardeigenschaften werden in Anhang A, Standard Properties in Sun Cluster Data Services Planning and Administration Guide for Solaris OS aufgeführt.

Die RGM-Erweiterungseigenschaften liefern Informationen wie zum Beispiel den Speicherort von binären Anwendungsdateien und Konfigurationsdateien. Sie ändern die Erweiterungseigenschaften beim Konfigurieren der Datendienste. Die Erweiterungseigenschaften werden im Handbuch zum Datendienst im beschrieben.

Datendienst-Projektkonfiguration

Datendienste können für einen Start mit einem Solaris-Projektnamen konfiguriert werden, wenn sie mit dem RGM online gebracht werden. Die Konfiguration ordnet einer vom RGM verwalteten Ressource oder Ressourcengruppe eine Solaris Projekt-ID zu. Durch die Zuordnung der Ressource oder Ressourcengruppe zu einer Projekt-ID können Sie anspruchsvolle Steuerfunktionen, die im Solaris-Betriebssystem verfügbar sind, für die Verwaltung von Arbeitslasten und Verbrauch in Ihrem Cluster einsetzen.

Diese Konfiguration können Sie nur dann durchführen, wenn Sie mit der aktuellen Version der Sun Cluster-Software unter Solaris 9 oder höher arbeiten.

Mithilfe der Solaris-Verwaltungsfunktion in einer Sun Cluster-Umgebung können Sie sicherstellen, dass die wichtigsten Anwendungen Priorität erhalten, wenn sie einen Knoten mit anderen Anwendungen teilen. Anwendungen können einen Knoten teilen, wenn Sie mit konsolidierten Diensten arbeiten oder weil Anwendungen bei einem Failover den Knoten gewechselt haben. Die Verwendung der hier beschriebenen Verwaltungsfunktion kann die Verfügbarkeit einer kritischen Awendung verbessern, indem andere Anwendungen mit niedrigerer Priorität daran gehindert werden, zu viele Systemleistungen wie CPU-Zeit in Anspruch zu nehmen.

In der Solaris-Dokumentation zu dieser Funktion werden CPU-Zeit, Prozesse, Aufgaben und vergleichbare Komponenten als "Ressourcen" beschrieben. In der Sun Cluster-Dokumentation hingegen wird der Begriff "Ressourcen" zur Beschreibung von Entitäten verwendet, die vom RGM gesteuert werden. Im nachstehenden Abschnitt wird der Begriff "Ressource" für Sun Cluster-Entitäten verwendet, die vom RGM gesteuert werden. In diesem Abschnitt wird der Begriff "Leistungen" für CPU-Zeit, Prozesse und Aufgaben verwendet.

Dieser Abschnitt enthält eine konzeptuelle Beschreibung zur Konfiguration von Datendiensten, um die Prozesse in einem gegebenen Solaris 9 project(4) zu starten. In diesem Abschnitt werden auch mehrere Failover-Szenarien beschrieben. Des Weiteren enthält er Empfehlungen zur Planung, wie die im Solaris-Betriebssystem zur Verfügung gestellte Verwaltungsfunktion eingesetzt werden kann.

Detaillierte konzeptionelle und verfahrenstechnische Dokumentation zur Verwaltungsfunktion finden Sie im Kapitel 1, Network Service (Overview) in System Administration Guide: Network Services.

Solaris-Verwaltungsfunktion in einem Cluster können Sie folgenden Prozess auf höchster Ebene einsetzen:

1. Konfigurieren von Anwendungen als Teil der Ressource.

2. Konfigurieren von Ressourcen als Teil einer Ressourcengruppe.

3. Aktivieren von Ressourcen in der Ressourcengruppe.

4. Aktivieren der Verwaltung der Ressourcengruppe.

5. Erstellen eines Solaris-Projekts für die Ressourcengruppe.

6. Konfigurieren von Standardeigenschaften, um den Ressourcengruppennamen dem unter Punkt 5 erstellten Projekt zuzuordnen.

7. Online-bringen der Ressourcengruppe.

Verwenden Sie zur Konfiguration der Standardeigenschaften Resource_project_name oder RG_project_name die -y-Option mit dem scrgadm(1M)-Befehl, um die Solaris-Projekt-ID der Ressource oder Ressourcengruppe zuzuordnen. Stellen Sie die Eigenschaftenwerte für die Ressource oder die Ressourcengruppe ein. Die Definitionen der Eigenschaften finden Sie in Anhang A, Standard Properties in Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Eigenschaftsbeschreibungen finden Sie unter r_properties(5) und rg_properties(5).

Der angegebene Projektname muss in der Projektdatenbank (/etc/project) vorhanden sein und der Root-Benutzer muss als Mitglied des genannten Projekts konfiguriert sein. Konzeptionelle Informationen zur Projektnamen-Datenbank finden Sie in Kapitel 2, Projects and Tasks (Overview) in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones. Eine Beschreibung der Syntax der Projektdatei finden Sie unter project(4).

Wenn der RGM Ressourcen oder Ressourcengruppen online bringt, startet er die verknüpften Prozesse unter dem Projektnamen.

Benutzer können die Ressource oder Ressourcengruppe jederzeit einem Projekt zuordnen. Der neue Projektname ist jedoch erst gültig, wenn die Ressource oder Ressourcengruppe mit dem RGM offline genommen und wieder online gebracht wurde.

Durch das Starten von Ressourcen und Ressourcengruppen unter dem Projektnamen können Sie die folgenden Funktionen zur Verwaltung der Systemleistungen in Ihrem Cluster konfigurieren.

• Erweiterte Berechnung – Ein flexibler Weg zur Aufzeichnung des Verbrauchs auf Aufgaben- oder Prozessbasis. Mit dieser Funktion können Sie die historische Nutzung nachverfolgen und den Leistungsbedarf für zukünftige Arbeitslasten beurteilen.

• Steuerungen – Ein Mechanismus zur Einschränkung von Systemleistungen. Damit kann verhindert werden, dass Prozesse, Aufgaben und Projekte große Anteile von bestimmten Systemleistungen verbrauchen.

• Faire Nutzungsplanung (FSS) – Damit besteht die Möglichkeit, die Zuweisung der verfügbaren CPU-Zeit auf die Arbeitslasten je nach ihrer Bedeutung zu steuern. Die Bedeutung der Arbeitslast wird durch die Anteile an CPU-Zeit ausgedrückt, die Sie jeder Arbeitslast zuweisen. Weitere Informationen erhalten Sie auf den folgenden Man Pages:

  • dispadmin(1M)

  • priocntl(1)

  • ps(1)

  • FSS(7)

• Pools – Damit besteht die Möglichkeit, Partitionen je nach Anwendungsanforderungen für interaktive Anwendungen zu nutzen. Pools können zur Partitionierung eines Servers eingesetzt werden, der eine Reihe unterschiedlicher Softwareanwendungen unterstützt. Die Verwendung von Pools führt zu einer besser vorhersehbaren Antwort für jede Anwendung.

Bestimmen der Anforderungen der Projektkonfiguration

Bevor Sie die Datendienste zur Verwendung der von Solaris zur Verfügung gestellten Steuermöglichkeiten in einer Sun Cluster-Umgebung konfigurieren, müssen Sie entscheiden, wie Sie die Ressourcen bei Switchover- oder Failover-Vorgängen steuern und verfolgen möchten. Identifizieren Sie vor der Konfiguration eines neuen Projekts die Abhängigkeiten innerhalb des Clusters. Ressourcen und Ressourcengruppen hängen zum Beispiel von Plattengerätegruppen ab.

Verwenden Sie die Ressourcengruppeneigenschaften nodelist, failback, maximum_primaries und desired_primaries, die mit scrgadm(1M) konfiguriert sind, um die Prioritäten in der Knotenliste für Ihre Ressourcengruppe zu identifizieren.

• Eine kurze Erläuterung der Abhängigkeiten in der Knotenliste zwischen Ressourcengruppen und Plattengerätegruppen finden Sie unter Relationship Between Resource Groups and Disk Device Groups in Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

• Detaillierte Beschreibungen der Eigenschaften finden Sie unter rg_properties(5).

Legen Sie die Prioritäten der Knotenliste für die Plattengerätegruppe mit den Eigenschaften preferenced und failback fest, die mit scrgadm(1M) und scsetup(1M) konfiguriert werden.

• Konzeptionelle Informationen zur Eigenschaft preferenced finden Sie unter Multiport-Plattengerätegruppen .

• Verfahrenstechnische Informationen finden Sie unter "How To Change Disk Device Properties" in Verwalten von Plattengerätegruppen in Sun Cluster Handbuch Systemverwaltung für Solaris OS.

• Konzeptionelle Informationen zur Knotenkonfiguration und dem Verhalten von Failover- und Scalable-Datendiensten finden Sie unter Hardware- und Softwarekomponenten des Sun Cluster-Systems .

Wenn Sie alle Cluster-Knoten gleich konfigurieren, werden die Nutzungsgrenzen auf Primär- und Sekundärknoten identisch durchgesetzt. Die Konfigurationsparameter der Projekte müssen nicht für alle Anwendungen in den Konfigurationsdateien auf allen Knoten gleich sein. Auf alle der Anwendung zugeordneten Projekte muss zumindest die Projektdatenbank auf allen potenziellen Mastern der Anwendung zugreifen können. Angenommen, der Master für Anwendung 1 ist phys-schost-1 kann aber durch ein Switchover oder Failover auch phys-schost-2 oder phys-schost-3 sein. Auf allen drei Knoten (phys-schost-1, phys-schost-2 und phys-schost-3) muss Zugriff auf das der Anwendung 1 zugeordnete Projekt bestehen.

Die Projektdatenbank-Informationen können sich in einer lokalen /etc/project-Datenbankdatei befinden oder in der NIS-Karte oder im LDAP-Verzeichnisdienst gespeichert sein.

Die Solaris-Umgebung ermöglicht eine flexible Konfiguration der Nutzungsparameter und Sun Cluster erlegt nur wenige Einschränkungen auf. Die Konfigurationsauswahl hängt von den Standortbedürfnissen ab. Beachten Sie die allgemeinen Richtlinien in den nachfolgenden Abschnitten, bevor Sie Ihre Systeme konfigurieren.

Einstellen virtueller Speicherbegrenzungen für Prozesse

Stellen Sie die process.max-address-space-Steuerung ein, um den virtuellen Speicher auf Prozessbasis zu begrenzen. Unter rctladm(1M) finden Sie detaillierte Informationen zur Einstellung des process.max-address-space-Wertes.

Konfigurieren Sie bei Verwendung von Verwaltungssteuerungen mit der Sun Cluster-Software die Speicherbegrenzung angemessen, um unnötige Failover-Vorgänge von Anwendungen und einen "Ping-Pong"-Effekt bei den Anwendungen zu vermeiden. Im Allgemeinen sollten Sie sich an folgende Richtlinien halten:

• Stellen Sie die Speicherbegrenzungen nicht zu niedrig ein.

  Wenn eine Anwendung die Speicherbegrenzung erreicht, kann ein Failover erfolgen. Diese Richtlinie ist besonders für Datenbankanwendungen von Bedeutung, wo das Erreichen einer virtuellen Speicherbegrenzung unerwartete Folgen haben kann.

• Stellen Sie die Speicherbegrenzungen für Primär- und Sekundärknoten nicht identisch ein.

  Identische Begrenzungen können einen Ping-Pong-Effekt auslösen, wenn eine Anwendung die Speichergrenze erreicht und ein Failover auf einen Sekundärknoten mit einer identischen Speicherbegrenzung erfolgt. Stellen Sie die Speicherbegrenzung auf dem Sekundärknoten etwas höher ein. Network MultipathingDer Unterschied bei den Speicherbegrenzungen trägt zur Vermeidung des Ping-Pong-Szenarios bei und gibt dem Systemverwalter Zeit, die Parameter nach Bedarf zu korrigieren.

• Verwenden Sie die Speicherbegrenzung der Ressourcenverwaltung für den Lastausgleich.

  Sie können zum Beispiel eine fehlerhaft arbeitende Anwendung mit Speicherbegrenzungen davon abhalten, zu viel Auslagerungsspeicher zu belegen.

Failover-Szenarien

Sie können die Verwaltungsparameter so konfigurieren, dass die Zuweisung in der Projektkonfiguration (/etc/project) im normalen Cluster-Betrieb und in Switchover- und Failover-Situationen funktioniert.

Die nachfolgenden Abschnitte sind als Beispiel gedachte Szenarien.

• In den ersten beiden Abschnitte, "Zwei-Knoten-Cluster mit zwei Anwendungen" und "Zwei-Knoten-Cluster mit drei Anwendungen," werden Failover-Szenarien für ganze Knoten beschrieben.

• Der Abschnitt "Failover der Ressourcengruppe" illustriert den Failover-Vorgang einer einzigen Anwendung.

In einer Sun Cluster-Umgebung konfigurieren Sie Anwendungen als Teil der Ressource. Anschließend konfigurieren Sie eine Ressource als Teil einer Ressourcengruppe (RG). Wenn ein Fehler auftritt, wechselt die Ressourcengruppe zusammen mit den zugeordneten Anwendungen auf einen anderen Knoten. In den nachstehenden Beispielen sind die Ressourcen nicht explizit angegeben. Angenommen, jede Ressource umfasst nur eine Anwendung.

Ein Failover erfolgt in der bevorzugten Reihenfolge, wie sie in der Knotenliste im RGM angegeben ist.

Für die nachstehenden Beispiele gelten folgende Beschränkungen:

• Anwendung 1 (Anw-1) ist in der Ressourcengruppe RG-1 konfiguriert.

• Anwendung 2 (Anw-2) ist in der Ressourcengruppe RG-2 konfiguriert.

• Anwendung 3 (Anw-3) ist in der Ressourcengruppe RG-3 konfiguriert.

Obwohl die Anzahl der zugeordneten Anteile gleich bleibt, ändert sich der jeder Anwendung zugewiesene Prozentsatz an CPU-Zeit nach dem Failover. Dieser Prozentsatz hängt von der Anzahl der auf dem Knoten ausgeführten Anwendungen sowie von der Anzahl an Anteilen ab, die jeder aktiven Anwendung zugeordnet sind.

In diesen Szenarien werden folgende Konfigurationen vorausgesetzt.

• Alle Anwendungen sind unter einem gemeinsamen Projekt konfiguriert.

• Jede Ressource enthält nur eine einzige Anwendung.

• Die Anwendungen sind die einzigen aktiven Prozesse auf den Knoten.

• Die Projektdatenbanken sind auf allen Knoten des Clusters gleich konfiguriert.

Zwei-Knoten-Cluster mit zwei Anwendungen

Auf einem Zwei-Cluster-Knoten können Sie zwei Anwendungen konfigurieren, um sicherzustellen, dass jeder reale Host (phys-schost-1, phys-schost-2) als Standardmaster für eine Anwendung fungiert. Jeder reale Host fungiert als Sekundärknoten für den anderen realen Host. Alle Projekte, die Anwendung 1 und Anwendung 2 zugeordnet sind, müssen in den Datenbankdateien der Projekte auf beiden Knoten vertreten sein. Im normalen Cluster-Betrieb wird jede Anwendung auf dem eigenen Standard-Master ausgeführt und erhält über die Verwaltungsfunkton die gesamte CPU-Zeit zugewiesen.

Nach einem Failover oder Switchover werden beide Anwendungen auf einem einzigen Knoten ausgeführt und erhalten die Anteile zugewiesen, die in der Konfigurationsdatei angegeben wurden. Dieser Eintrag in der /etc/project-Datei gibt zum Beispiel an, dass Anwendung 1 vier Anteile zugewiesen werden und Anwendung 2 ein Anteil zugewiesen wird.

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

Die nachstehende Abbildung illustriert den normalen und den Failover-Betrieb in dieser Konfiguration. Die Anzahl der zugewiesenen Anteile ändert sich nicht. Der Prozentsatz an CPU-Zeit, der jeder Anwendung zur Verfügung steht, kann sich jedoch ändern. Der Prozentsatz hängt von der Anzahl der Anteile ab, die jedem Prozess mit CPU-Zeit-Bedarf zugewiesen sind.

Zwei-Knoten-Cluster mit drei Anwendungen

Auf einem Zwei-Knoten-Cluster mit drei Anwendungen können Sie einen realen Host (phys-schost-1) als Standard-Master für eine Anwendung konfigurieren. Den zweiten realen Host (phys-schost-2) können Sie als Standard-Master für die restlichen beiden Anwendungen konfigurieren. Im folgenden Beispiel wird davon ausgegangen, dass die Projekt-Datenbankdatei auf jedem Knoten vorhanden ist. Die Projekt-Datenbankdatei wird bei einem Failover oder Switchover nicht geändert.

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none) 
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)  

Im normalen Cluster-Betrieb sind der Anwendung 1 fünf Anteile auf dem entsprechenden Standard-Master phys-schost-1 zugewiesen. Dies entspricht 100 Prozent der CPU-Zeit, weil es die einzige Anwendung ist, die CPU-Zeit auf diesem Knoten benötigt. Den Anwendungen 2 und 3 sind jeweils drei und zwei Anteile auf dem dazugehörigen Standard-Master phys-schost-2 zugewiesen. Damit entfällt auf Anwendung 2 60 Prozent der CPU-Zeit und auf Anwendung 3 40 Prozent der CPU-Zeit im normalen Betrieb.

Wenn Anwendung 1 bei einem Failover oder Switchover auf phys-schost-2 wechselt, bleiben die Anteile für alle drei Anwendungen gleich. Aber der Prozentsatz der CPU-Ressourcen wird anhand der Projekt-Datenbankdatei neu zugewiesen.

• Anwendung 1 erhält mit 5 Anteilen 50 Prozent der CPU.

• Anwendung 2 erhält mit 3 Anteilen 30 Prozent der CPU.

• Anwendung 3 erhält mit 2 Anteilen 20 Prozent der CPU.

Die nachstehende Abbildung illustriert den normalen und den Failover-Betrieb in dieser Konfiguration.

Failover der Ressourcengruppe

In einer Konfiguration, in der mehrere Ressourcengruppen denselben Standard-Master haben, kann eine Ressourcengruppe (und die zugeordneten Anwendungen) bei einem Failover oder Switchover auf einen Sekundärknoten wechseln. Dabei läuft der Standard-Master im Cluster weiter.

Die Anwendung, die den Failover-Vorgang durchführt, erhält dabei die Ressourcen auf dem Sekundärknoten zugewiesen, die in der Konfigurationsdatei angegeben sind. In diesem Beispiel haben die Projekt-Datenbankdateien auf Primär- und Sekundärknoten dieselbe Konfiguration.

Diese Beispielskonfigurationsdatei gibt an, dass Anwendung 1 ein Anteil, Anwendung 2 zwei Anteile und Anwendung 3 zwei Anteile zugewiesen werden.

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)
 

Die nachstehende Abbildung illustriert den normalen und den Failover-Betrieb in dieser Konfiguration, wobei RG-2 mit Anwendung 2 zu phys-schost-2 wechselt. Beachten Sie, dass sich die Anzahl der zugewiesenen Anteile nicht ändert. Der Prozentsatz an CPU-Zeit, der jeder Anwendung zur Verfügung steht, kann sich jedoch je nach Anzahl der Anteile ändern, die jeder Anwendung mit CPU-Zeit-Bedarf zugewiesen werden.

Öffentliche Netzwerkadapter und Internet Protocol (IP) Network Multipathing

Clients führen über das öffentliche Netzwerk Datenanforderungen an den Cluster durch. Jeder Cluster-Knoten ist über ein Paar öffentlicher Netzwerkadapter mit mindestens einem öffentlichen Netzwerk verbunden.

Die Solaris IPMP-Software (Internet Protocol Network Multipathing) von Sun Cluster liefert den Basismechanismus für die Überwachung öffentlicher Netzwerkadapter und das Wechseln von IP-Adressen von einem Adapter auf einen anderen, wenn ein Fehler erkannt wird. Jeder Cluster-Knoten hat seine eigene Internet Protocol (IP) Network Multipathing-Konfiguration, die sich von der auf anderen Cluster-Knoten unterscheiden kann.

Ö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. Alternativ können Sie Standby-Schnittstellen konfigurieren, die bis zum Auftreten eines Failovers inaktiv bleiben.

Der in.mpathd-Multipathing-Dämon verwendet eine IP-Testadresse, um Fehler und Reparaturen zu erkennen. Erkennt der Multipathing-Dämon einen Fehler auf einem der Adapter, erfolgt ein Failover. Der gesamte Netzwerkzugriff geht vom fehlerhaften Adapter auf einen anderen funktionsfähigen Adapter in der Multipathing-Gruppe über. Daher bleibt die Konnektivität des öffentlichen Netzwerkes für den Knoten erhalten. Wenn eine Standby-Schnittstelle konfiguriert wurde, wählt der Dämon die Standby-Schnittstelle aus. Anderenfalls wählt der Dämone die Schnittstelle mit der niedrigsten Anzahl von IP-Adressen aus Da das Failover auf Adapterschnittstellenebene erfolgt, sind Verbindungen auf höherer Ebene wie TCP mit Ausnahme einer kurzen Zeitspanne während des Failover-Vorgangs nicht betroffen Wenn das Failover der IP-Adressen erfolgreich abgeschlossen ist, werden ARP-Übertragungen gesendet Der Dämon erhält also die Konnektivität der Remote-Clients aufrecht.

Aufgrund der TCP-Wiederherstellungseigenschaften bei Stau kann an TCP-Endpunkten nach einem erfolgreichen Failover eine weitere Verzögerung entstehen. Einige Segmente sind möglicherweise beim Failover verloren gegangen, wodurch der Stausteuermechanismus im TCP aktiviert wird.

Multipathing-Gruppen bilden die Bausteine für logische Hostnamen und gemeinsam genutzte Adressen. Sie können auch unabhängig von logischen Hostnamen und gemeinsam genutzten Adressen Multipathing-Gruppen erstellen, um die Konnektivität der Cluster-Knoten mit dem öffentlichen Netzwerk zu überwachen. Dieselbe Multipathing-Gruppe kann auf einem Knoten eine beliebige Anzahl logischer Hostnamen oder gemeinsam genutzter Adressen hosten. Weitere Informationen zu logischen Hostnamen und gemeinsam genutzten Adressen finden Sie im Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Der Internet Protocol (IP) Network Multipathing-Mechanismus ist auf das Erkennen und Verbergen von Adapterfehlern ausgelegt. Er dient nicht dazu, eine Wiederherstellung durchzuführen, nachdem ein Verwalter mit ifconfig(1M) eine der logischen (oder gemeinsam genutzten) IP-Adressen entfernt hat.. Die Sun Cluster-Software zeigt die logischen und gemeinsam genutzten IP-Adressen als Ressourcen an, die von RGM verwaltet werden. Ein Verwalter muss eine IP-Adresse mit scrgadm(1M) entfernen oder hinzufügen, um die Ressourcengruppe zu ändern, die die Ressource enthält.

Weitere Informationen zur Solaris-Implementierung von IP Network Multipathing finden Sie in der entsprechenden Dokumentation zu dem auf Ihrem Cluster installierten Solaris-Betriebssystem.

SPARC: Unterstützung der dynamischen Rekonfiguration

Die Softwarefunktion zur Unterstützung der dynamischen Rekonfiguration (DR) in Sun Cluster 3.1 8/05 wird schrittweise umgesetzt. In diesem Abschnitt werden Konzepte und Erwägungen im Hinblick auf die Unterstützung der DR-Funktion durch Sun Cluster 3.1 8/05 beschrieben.

Alle für die DR-Funktion von Solaris dokumentierten Anforderungen, Verfahren und Einschränkungen gelten auch für die DR-Unterstützung von Sun Cluster (mit Ausnahme des Vorgangs zur Stilllegung der Betriebsumgebung). Lesen Sie daher die Dokumentation zur Solaris DR-Funktion, bevor Sie die DR-Funktion mit der Sun Cluster-Software verwenden. Lesen Sie insbesondere die Themen, die sich mit nicht vernetzten E/A-Geräten während eines DR-Trennungsvorgangs beschäftigen

Das Sun Enterprise 10000 Dynamic Reconfiguration User Guide und das Sun Enterprise 10000 Dynamic Reconfiguration Reference Manual (aus den Dokumentationsreihen Solaris 8 on Sun Hardware oder Solaris 9 on Sun Hardware) können von http://docs.sun.com heruntergeladen werden.

SPARC: Allgemeine Beschreibung der dynamischen Rekonfiguration

Die DR-Funktion ermöglicht bestimmte Vorgänge wie zum Beispiel das Entfernen von Systemhardware bei laufenden Systemen. Die DR-Prozesse sind so ausgelegt, dass sie einen kontinuierlichen Systembetrieb sicherstellen, ohne das System anhalten oder die Cluster-Verfügbarkeit unterbrechen zu müssen.

DR arbeitet auf Board-Ebene. Deswegen hat ein DR-Vorgang Auswirkungen auf alle Komponenten eines Boards. Jedes Board kann mehrere Komponenten enthalten, einschließlich CPUs, Speicher und Peripherieschnittstellen für Plattenlaufwerke, Bandlaufwerke und Netzwerkverbindungen.

Das Entfernen eines Boards mit aktiven Komponenten führt zu Systemfehlern. Vor dem Entfernen eines Boards fragt das DR-Teilsystem andere Teilsysteme wie Sun Cluster ab, um festzustellen, ob die Komponenten des Boards genutzt werden. Wenn das DR-Teilsystem eine Board-Nutzung feststellt, wird der DR-Vorgang zur Board-Entfernung nicht ausgeführt. Ein DR-Vorgang zur Board-Entfernung ist insofern immer sicher, als das DR-Teilsystem Vorgänge an Boards mit aktiven Komponenten ablehnt.

Der DR-Vorgang zur Board-Hinzufügung ist ebenfalls immer sicher. CPUs und Speicher auf einem neu hinzugefügten Board werden automatisch vom System verfügbar gemacht. Der Systemverwalter muss den Cluster jedoch manuell konfigurieren, um Komponenten des neu hinzugefügten Boards aktiv nutzen zu können.

Das DR-Teilsystem hat mehrere Ebenen. Wenn ein Fehler auf einer unteren Ebene gemeldet wird, meldet auch die übergeordnete Ebene einen Fehler. Die untere Ebene meldet den spezifischen Fehler, die übergeordnete Ebene meldet jedoch nur Unbekannter Fehler. Diese Fehlermeldung können Sie gefahrlos ignorieren.

Die folgenden Abschnitte enthalten DR-spezifische Erwägungen zu den unterschiedlichen Gerätetypen.

SPARC: Erwägungen zur DR von CPU-Geräten im Cluster

Die Sun Cluster-Software lehnt einen DR-Vorgang zur Board-Entfernung nicht aufgrund vorhandener CPU-Geräte ab.

Wenn ein DR-Vorgang zur Board-Hinzufügung erfolgt, werden die CPU-Geräte auf dem hinzugefügten Board automatisch in den Systembetrieb integriert.

SPARC: Erwägungen zur DR von Speichern im Cluster

Für DR-Zwecke sind zwei Speichertypen zu berücksichtigen.

• Kernel-Speichergehäuse

• Nicht-Kernel-Speichergehäuse

Diese beiden Typen unterscheiden sich lediglich bei ihrer Nutzung. Die aktuelle Hardware ist bei beiden Typen die gleiche. Das Kernel-Speichergehäuse ist der vom Solaris-Betriebssystem genutzte Speicher. Die Sun Cluster-Software unterstützt die Board-Entfernung bei einem Board, das Kernel-Speichergehäuse enthält, nicht und lehnt jeden derartigen Vorgang ab. Wenn ein DR-Vorgang zur Board-Hinzufügung Speicher betrifft, bei dem es sich nicht um das Kernel-Speichergehäuse handelt, lehnt die Sun Cluster-Software den Vorgang nicht ab. Wenn ein den Speicher betreffender DR-Vorgang zur Board-Hinzufügung durchgeführt wird, wird der Speicher auf dem hinzugefügten Board automatisch in den Systembetrieb integriert.

SPARC: Erwägungen zur DR von Platten- und Bandlaufwerken im Cluster

Sun Cluster lehnt DR-Vorgänge zur Board-Entfernung auf aktiven Laufwerken des Primärknotens ab. DR-Vorgänge zur Board-Entfernung können auf nicht aktiven Laufwerken des Primärknotens und auf allen Laufwerken der Sekundärknoten durchgeführt werden. Der Cluster-Datenzugriff unterliegt durch den DR-Vorgang keinerlei Änderungen.

Sun Cluster lehnt DR-Vorgänge ab, die sich auf die Verfügbarkeit von Quorum-Geräten auswirken. Weitere Erwägungen zu Quorum-Geräten und dem Verfahren zur Ausführung von DR-Vorgängen bei Cluster-Geräten finden Sie unter SPARC: Erwägungen zur DR von Quorum-Geräten im Cluster .

Unter Dynamische Rekonfiguration von Quorum-Geräten in Sun Cluster Handbuch Systemverwaltung für Solaris OS erhalten Sie detaillierte Anweisungen zur Durchführung dieser Vorgänge.

SPARC: Erwägungen zur DR von Quorum-Geräten im Cluster

Wenn der DR-Vorgang zur Board-Entfernung ein Board betrifft, das eine Schnittstelle zu einem für das Quorum konfigurierten Gerät enthält, lehnt die Sun Cluster-Software den Vorgang ab. Außerdem identifiziert die Sun Cluster-Software das Quorum-Gerät, das von diesem Vorgang betroffen wäre. Sie müssen dieses Gerät als Quorum-Gerät deaktivieren, bevor Sie einen DR-Vorgang zur Board-Entfernung durchführen können.

In Kapitel 5, Verwalten des Quorums in Sun Cluster Handbuch Systemverwaltung für Solaris OS erhalten Sie detaillierte Anweisungen zum Verwalten des Quorums.

SPARC: Erwägungen zur DR von Cluster-Interconnect-Schnittstellen im Cluster

Wenn der DR-Vorgang zur Board-Entfernung ein Board betrifft, das zu einer aktiven Cluster-Interconnect-Schnittstelle gehört, lehnt die Sun Cluster-Software den Vorgang ab. Außerdem identifiziert die Sun Cluster-Software die Schnittstelle, die von dem Vorgang betroffen wäre. Sie müssen die aktive Schnittstelle mit einem Sun Cluster-Verwaltungstool deaktivieren, bevor der DR-Vorgang erfolgen kann.

Die Sun Cluster-Software erfordert, dass jeder Cluster-Knoten über mindestens einen funktionsfähigen Pfad zu jedem anderen Cluster-Knoten verfügt. Deaktivieren Sie keine privaten Interconnect-Schnittstellen, die den letzten Pfad zu einem Cluster-Knoten unterstützen.

Unter Verwalten von Cluster-Interconnects in Sun Cluster Handbuch Systemverwaltung für Solaris OS erhalten Sie detaillierte Anweisungen zur Durchführung dieser Vorgänge.

SPARC: Erwägungen zur DR von öffentlichen Netzwerkschnittstellen im Cluster

Wenn der DR-Vorgang zur Board-Entfernung ein Board betrifft, das aktive öffentliche Netzwerkschnittstellen enthält, lehnt die Sun Cluster-Software den Vorgang ab. Außerdem identifiziert die Sun Cluster-Software die Schnittstelle, die von dem Vorgang betroffen wäre. Bevor ein Board mit einer aktiven öffentlichen Netzwerkschnittstelle entfernt werden kann, muss der gesamte Datenverkehr mithilfe des if_mpadm(1M)-Befehls von dieser Schnittstelle auf eine andere funktionsfähige Schnittstelle in der Multipathing-Gruppe umgeleitet werden.

Wenn der verbleibende Netzwerkadapter während des DR-Entfernungsvorgangs für den deaktivierten Netzwerkadapter ausfällt, wird die Verfügbarkeit beeinträchtigt. Der verbleibende Adapter hat keine Möglichkeit, für die Dauer des DR-Vorgangs zu wechseln.

Unter Verwalten des öffentlichen Netzwerks in Sun Cluster Handbuch Systemverwaltung für Solaris OS erhalten Sie detaillierte Anweisungen zur Durchführung eines DR-Entfernungsvorgangs in einem öffentlichen Netzwerk.