Kapitel 3 Schlüsselkonzepte – Verwaltung und Anwendungsentwicklung

Dieses Kapitel beschreibt die Schlüsselkonzepte im Zusammenhang mit den Softwarekomponenten eines SunPlex-Systems. Zu den behandelten Themen gehören:

• Verwaltungsschnittstellen

• Cluster-Zeit

• Hoch verfügbares Framework

• Globale Geräte

• Plattengerätegruppen

• Globaler Namensraum

• Cluster-Dateisysteme

• Quorum und Quorum-Geräte

• Datendienste

• Entwickeln von neuen Datendiensten

• Ressourcen, Ressourcengruppen und Ressourcentypen

• Öffentliche Netzwerkadapter und IPMP_Long;

• SPARC: Unterstützung der dynamischen Rekonfiguration

Cluster-Verwaltung und Anwendungsentwicklung

Diese Informationen richten sich in erster Linie an Systemverwalter und Anwendungsentwickler, die mit der SunPlex-API und dem SDK arbeiten. Cluster-Systemverwalter können diese Informationen als Hintergrund 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 SunPlex-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 SunPlex-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. Eine vollständige Beschreibung der Verwaltungsschnittstellen finden Sie im Einführungskapitel im Sun Cluster System Administration Guide.

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 SunPlex-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) (interaktiv oder innerhalb von cron-Skripts) 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 die Solaris-Betriebsumgebung 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. Die Sun Cluster-Software stellt eine Vorlagendatei zur Verfügung, ntp.cluster (siehe /etc/inet/ntp.cluster auf einem installierten Cluster-Knoten), die eine Peer-Beziehung zwischen allen Cluster-Knoten mit einem Knoten als “bevorzugtem” Knoten festlegt. Knoten werden durch ihre privaten Hostnamen identifiziert und die Zeitsynchronisierung erfolgt über den Cluster-Interconnect. Die Anweisungen zur Cluster-Konfiguration für NTP finden Sie im Sun Cluster Software Installation Guide.

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 jedoch bei der Installation der Solaris-Betriebsumgebung falsch eingestellt wurde und Sie diese ändern möchten, finden Sie die Beschreibung der Vorgehensweise im Sun Cluster System Administration Guide.

Hoch verfügbares Framework

Das SunPlex-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 Multihostplatten. 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 SunPlex-Komponentenfehlern (bei Hardware und Software) und die entsprechende Form der Wiederherstellung, die in das 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 wieder hergestellt. Die Semantik des Framework-Ressourcenzugriffs bleibt bei einem Knotenfehler vollständig erhalten. Die Anwendungen nehmen einfach nicht wahr, dass der Framework-Ressourcenserver auf einen anderen Knoten verschoben wurde. Das Versagen eines einzigen Knotens ist für die Programme auf den restlichen Knoten vollständig transparent, die so lange die mit diesem Knoten verbundenen Dateien, Geräte und Datenträger verwenden, wie ein alternativer Hardwarepfad zu den Platten eines anderen Knotens vorhanden ist. Ein Beispiel ist die Verwendung von Multihostplatten mit Ports für mehrere Knoten.

Cluster-Mitglieder-Monitor

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 der die Cluster-Ressourcen ggf. 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 Quorum und Quorum-Geräte.

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 Fehlerschutz.

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

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 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 auto-boot?mit eeprom(1M) an der OpenBoot PROM ok-Eingabeaufforderung einstellen.

Cluster-Konfigurations-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 SunPlex-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, und zwar unabhängig davon, wo das Gerät real angeschlossen ist. Wenn ein Knoten ausfällt, während er Zugriff auf ein globales Gerät bietet, erkennt die Sun Cluster-Software im Allgemeinen automatisch einen anderen Pfad zum Gerät und leitet den Zugriff auf diesen Pfad um. Zu den globalen Geräten bei SunPlex gehören Platten, CD-ROM und Bänder. Dabei sind die Platten jedoch die einzigen globalen Multiport-Geräte, die unterstützt werden. 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-ID (DID)

Die Sun Cluster-Software verwaltet globale Geräte über ein Gebilde, das als DID-Pseudotreiber (Device ID, DID) bezeichnet wird. 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. Knoten1 kann eine Multihostplatte zum Beispiel als c1t2d0 führen, während Knoten2 dieselbe Platte vollkommen anders, nämlich als c3t2d0, führt. Der DID-Treiber weist einen globalen Namen zu, wie d10, den der Knoten statt dessen 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 finden Sie in der jeweiligen Online-Dokumentation.

Plattengerätegruppen

Im SunPlex-System müssen alle Multihostplatten 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 Multihostplatten. 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 SunPlex-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 Plattengruppe(n) 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 zur Zuordnung von Plattengerätegruppen und Ressourcengruppen finden Sie im Überblickskapitel im Sun Cluster Data Services Planning and Administration Guide.

Mit einer Plattengerätegruppe wird die Datenträger-Manager-Plattengruppe “global”, weil sie Multipathing für die dazugehörigen Platten unterstützt. Jeder mit den Multihostplatten real verbundener 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ätegruppen-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, entspricht dem des Gerätedienstes.

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 hat Ihre Plattengerätegruppe einen Primär- und einen Sekundärknoten. Die restlichen verfügbaren Anbieterknoten werden im Spare-Zustand online gebracht. 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 Eins 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öchten ggf. die numsecondaries-Eigenschaft ändern und die Knotenliste querprüfen, wenn Sie der Konfiguration Knoten 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.Sie verwalten das Hinzufügen oder Entfernen von Knoten aus Ihrer Konfiguration mit dem metaset(1M)-Befehl für Solaris Volume Manager-Gerätegruppen oder mit dem scconf(1M)-Befehl für VxVM-Plattengerätegruppen, wenn Sie Veritas Volume Manager verwenden, zusammen mit der Einstellung der Eigenschaften preferenced und numsecondaries. Verfahrenstechnische Informationen über das Ändern der Plattengerätegruppen-Eigenschaften finden Sie unter “Administering Cluster File Systems Overview” in Sun Cluster System Administration Guide for 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 ebenso wie 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/Plattengruppe und /dev/vx/rdsk/Plattengruppe. 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 SunPlex-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@Knoten-ID ersetzt, wobei Knoten-ID 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.

Zu den Vorteilen des globalen Namensraumes gehört Folgendes:

• 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, und 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 Knoten ausgeführt werden, können den Datenzugriff unter Verwendung der kooperativen Dateisperrung für eine Cluster-Dateisystem-Datei synchronisieren. 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 (zum Beispiel /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. Das bedeutet, der Client sieht das zugrunde liegende Dateisystem (zum Beispiel UFS).

Verwenden von Cluster-Dateisystemen

Im SunPlex-System sind alle Multihost-Platten in Plattengerätegruppen eingebunden. Hierbei kann es sich um Solaris Volume Manager-Plattensätze, VxVM-Plattengruppen oder einzelne 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.

Wie bei normalen Dateisystemen können Sie auch Cluster-Dateisysteme auf zwei Arten einhängen:

• Manuell — Verwenden Sie den mount-Befehl 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/Plattengerätegruppe. Weitere Informationen finden Sie im Sun Cluster Software Installation Guide und im Sun Cluster System Administration Guide.

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.

In den jeweiligen Datendienstkapiteln im Data Services Installation and Configuration Guide oder unter “Enabling Highly Available Local File Systems” in Kapitel 14, “Administering Data Services Resources”, finden Sie Informationen zur Verwendung 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 wesentliche bessere Leistung, wenn Sie syncdir nicht angeben. Bei Angabe von syncdir sind die Einträge garantiert POSIX-konform. Wird die Option nicht angegeben, verhält sich das System wie ein NFS-Dateisystem. In einigen Fällen würden Sie ohne syncdir 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 selten Probleme auf, wenn Siesyncdir nicht angeben. Wir empfehlen Ihnen deswegen, auf die Angabe von syncdir zu verzichten und den Leistungsgewinn zu nutzen.

Wenn Sie einen SPARC-basierten Cluster verwenden, hat Veritas 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 Häufige Fragen 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 System Administration Guide for Solaris OS.

DPM wird auf Knoten mit Versionen vor Sun Cluster 3.1 4/04 Software 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.

Ü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 den 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 unter 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 (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 MPxIO, 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 unter “Administering Sun Cluster With the Graphical User Interfaces” in Sun Cluster System Administration Guide for 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 Name 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 Knotenc1t0d0 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

Die Cluster-Knoten nutzen gemeinsam Daten und Ressourcen. Daher ist es wichtig, dass ein Cluster niemals in getrennte Partitionen zerfällt, die gleichzeitig aktiv sind. Der CMM stellt selbst bei partitionierten Cluster-Interconnects sicher, dass maximal jeweils ein Cluster in Betrieb ist.

Es gibt zwei Arten von Problemen, die aufgrund der Partitionierung von Clustern auftreten: Split Brain und Amnesie. Zum Split Brain kommt es, wenn der Cluster-Interconnect zwischen den Knoten verloren geht und der Cluster in Teil-Cluster zerfällt, die sich jeweils als die einzige Partition wahrnehmen. Die Ursache sind Kommunikationsprobleme zwischen den Cluster-Knoten. Zur Amnesie kommt es, wenn der Cluster nach dem Herunterfahren mit Cluster-Daten neu startet, die älter als die Daten zum Zeitpunkt des Herunterfahrens sind. Dazu kann es kommen, wenn mehrere Versionen der Framework-Daten auf der Platte gespeichert sind und eine neue Cluster-Zusammensetzung ohne die neueste Version gestartet wird.

Split Brain und Amnesie können vermieden werden, indem jeder Knoten eine Stimme erhält und eine Stimmenmehrzahl für den Betrieb eines Clusters vorgeschrieben wird. Eine Partition mit der Mehrheit der Stimmen hat ein Quorum und erhält die Erlaubnis zum Arbeiten. Dieser Mechanismus der Stimmenmehrheit arbeitet einwandfrei, wenn der Cluster aus mehr als zwei Knoten besteht. In einem Zwei-Knoten-Cluster ist zwei eine Mehrheit. Wenn ein solcher Cluster in Partitionen zerfällt, wird eine externe Stimme benötigt, damit eine der Partitionen das Quorum erreicht. Diese externe Stimme wird von einem Quorum-Gerät beigesteuert. Ein Quorum-Gerät kann jede Platte sein, die von beiden Knoten gemeinsam genutzt wird. Als Quorum-Geräte verwendete Platten können Benutzerdaten enthalten.

Der Quorum-Algorithmus arbeitet dynamisch: Da seine Berechnungen durch Cluster-Ereignisse ausgelöst werden, können sich die Rechenergebnisse während der Lebenszeit eines Clusters ändern.

Stimmenanzahl Quorum

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

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

Sie konfigurieren Quorum-Geräte entweder im Verlauf der Cluster-Installation oder später mit den Verfahren, die im Sun Cluster System Administration Guide beschrieben sind.

Ein Quorum-Gerät trägt nur dann zur Stimmenanzahl bei, wenn mindestens einer der Knoten, mit dem es derzeit verbunden ist, ein Cluster-Mitglied ist. Auch beim Booten von Clustern trägt ein Quorum-Gerät nur dann zur Anzahl bei, wenn mindestens einer der Knoten, mit denen es derzeit verbunden ist, bootet und Mitglied des vor dem Herunterfahren zuletzt gebooteten Clusters war.

Quorum-Konfigurationen

Quorum-Konfigurationen hängen von der Anzahl der Knoten im Cluster ab:

• Zwei-Knoten-Cluster – Zwei Quorum-Stimmen sind erforderlich, damit ein Zwei-Knoten-Cluster gebildet werden kann. Diese beiden Stimmen können von den beiden Cluster-Knoten kommen oder von nur einem der Knoten und einem Quorum-Gerät. Trotzdem muss ein Quorum-Gerät für einen Zwei-Knoten-Cluster konfiguriert sein, um sicherzustellen, dass ein einziger Knoten weiterarbeiten kann, wenn der andere Knoten ausfällt.

• Cluster mit mehr als zwei Knoten – Sie sollten für jedes Knotenpaar mit gemeinsamem Zugriff auf ein Plattenspeichergehäuse ein Quorum-Gerät angeben. Angenommen, Sie haben einen Drei-Knoten-Cluster, der mit dem Cluster in Abbildung 3–2 vergleichbar ist. In dieser Abbildung haben KnotenA und KnotenB gemeinsam Zugriff auf dasselbe Plattengehäuse, und KnotenB und KnotenC haben gemeinsam Zugriff auf ein anderes Plattengehäuse. Damit läge die Gesamtanzahl von Quorum-Stimmen bei fünf. Drei stammen von den Knoten und zwei von den Quorum-Geräten, die von den Knoten geteilt werden. Ein Cluster benötigt eine Mehrheit von Quorum-Stimmen, um gebildet zu werden.

  Die Angabe eines Quorum-Geräts zwischen jedem Knotenpaar, das gemeinsam auf ein Plattenspeichergehäuse zugreift, ist nicht erforderlich und ist von der Sun Cluster-Software nicht zwingend vorgeschrieben. Allerdings kann dies erforderliche Quorum-Stimmen liefern, wenn eine N+1-Konfiguration zu einer Zwei-Knoten-Cluster-Konfiguration degeneriert und dann der Knoten mit Zugriff auf beide Plattengehäuse ebenfalls ausfällt. Wenn Sie Quorum-Geräte zwischen allen Paaren konfiguriert haben, kann der übrige Knoten weiterhin als Cluster arbeiten.

  Beispiele zu diesen Konfigurationen finden Sie in Abbildung 3–2.

Abbildung 3–2 Beispiele zu Quorum-Gerätekonfigurationen

Quorum-Richtlinien

Befolgen Sie beim Konfigurieren von Quorum-Geräten folgende Richtlinien:

• Legen Sie ein Quorum-Gerät für alle Knoten fest, die an dasselbe gemeinsame Plattenspeichergehäuse angeschlossen sind. Fügen Sie eine Platte als Quorum-Gerät innerhalb des gemeinsam genutzten Gehäuses hinzu, um sicherzustellen, dass bei Versagen eines Knotens die restlichen Knoten das Quorum erhalten und als Master der Plattengerätegruppe im gemeinsamen Gehäuse fungieren können.

• Sie müssen das Quorum-Gerät mit mindestens zwei Knoten verbinden.

• Ein Quorum-Gerät kann jede beliebige SCSI-2- oder SCSI-3-Platte sein, die als Quorum-Gerät mit zwei Ports eingesetzt wird. Platten, die mit mehr als zwei Knoten verbunden sind, müssen SCSI-3-PGR (Persistent Group Reservation) unterstützen, unabhängig davon, ob die Platte als Quorum-Gerät eingesetzt wird. Weitere Informationen finden Sie im Kapitel zur Planung im Sun Cluster Software Installation Guide.

• Sie können eine Platte mit Benutzerdaten als Quorum-Gerät verwenden.

Fehlerschutz

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

Der Fehlerschutz schränkt den Knotenzugriff auf die Multihostplatten 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 Multihostplatten verwenden. Wenn ein aktuell als Primärknoten (Eigentümer) der Plattengruppe fungierendes Cluster-Mitglied ausfällt oder nicht mehr erreicht werden kann, wird ein neuer Primärknoten ausgewählt, und nach einer einer unbedeutenden Unterbrechung kann wieder auf die Plattengerätegruppe zugegriffen werden. Während dieses Prozesses muss der alte Primärknoten den Zugriff auf die Geräte abgeben, 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 SunPlex-System verwendet SCSI-Plattenreservierungen zur Implementierung des Fehlerschutzes. Mit den SCSI-Reservierungen werden die Multihostplatten vor den ausgefallenen Knoten “geschützt” und der Zugriff auf diese Platten wird verhindert.

SCSI-2-Plattenreservierungen unterstützen eine Form der Reservierung, die entweder allen mit der Platte verbundenen Knoten Zugriff erteilt (wenn keine Reservierung vorliegt) oder den Zugriff auf einen einzigen Knoten beschränkt (auf den Knoten, für den die Reservierung gilt).

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. Bei einem solchen Fehlerschutz ist es normal, dass der geschützte Knoten in Panik gerät und mit einer Meldung “reservation conflict” in der Konsole reagiert.

Der Reservierungskonflikt tritt nach der Feststellung auf, dass ein Knoten kein Cluster-Mitglied mehr ist, da auf allen Platten, die dieser Knoten mit den restlichen Knoten teilt, eine SCSI-Reservierung erfolgte. Der geschützte Knoten nimmt den Schutz möglicherweise nicht wahr. Wenn er versucht, auf eine der gemeinsam genutzten Platten zuzugreifen, erkennt er die Reservierung und gerät in Panik.

Failfast-Mechanismus zum Fehlerschutz

Der Mechanismus, mit dem Cluster Framework sicherstellt, dass ein ausgefallener Knoten nicht neu booten und in gemeinsam genutzte 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 Anweisung für den Plattentreiber. Damit kann sich der Knoten selbst in einen Panik-Zustand versetzen, wenn er nicht auf die Platte zugreifen kann, weil diese von anderen Knoten reserviert wurde.

Das MHIOCENFAILFAST-ioctl löst eine Prüfung der Fehlerrückgaben aus jedem Lese- und Schreibvorgang aus, die von einem Knoten für den Fehlercode Reservation_Conflict an die Platte zurückgegeben werden. Das ioctl führt im Hintergrund regelmäßige Testvorgänge auf der Platte aus, um sie auf Reservation_Conflict zu prüfen. Sowohl der Kontrollflusspfad im Vordergrund als auch der im Hintergrund 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. Für 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 arbeitet immer gleich, unabhängig davon, ob Sie 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 führt als Teil der Partition, die ein Quorum erzielt, Reservierungen auf den gemeinsam genutzten Platten aus. Wenn der Knoten ohne Quorum nun versucht, auf die gemeinsam genutzten Platten zuzugreifen, erhält er einen Reservierungskonflikt als Antwort und gerät infolge des 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 am OpenBoot^TM PROM (OBP)-Eingabeaufforderung bleiben. Welche Aktion eingeleitet wird, bestimmt die Einstellung des auto-boot?-Parameters. Sie können auto-boot? mit eeprom(1M) in einem SPARC-basierten Cluster an der OpenBoot PROM ok-Eingabeaufforderung einstellen oder mit dem SCSI-Dienstprogramm, das Sie optional nach dem Starten der Bios in einem x86-basierten Cluster ausführen.

Datendienste

Der Begriff Datendienst beschreibt eine Anwendung von Drittherstellern wie Sun Java System Web Server (früher Sun Java System Web Server) oder Oracle für SPARC-basierte Cluster, 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.

• Start

• Stopp

• Überwachen und Ergreifen von Korrekturmaßnahmen

• Informationen zu Datendienst-Typen finden Sie unter “Data Services” in Sun Cluster Overview for Solaris OS.

In Abbildung 3–3 wird eine Anwendung, die auf einem einzigen Anwendungsserver ausgeführt wird (Einzelservermodell) mit derselben Anwendung auf einem Cluster (Cluster-Servermodell) verglichen. Beachten Sie, dass aus der Benutzerperspektive kein Unterschied zwischen den beiden Konfigurationen besteht. Die Cluster-Anwendung wird ggf. schneller ausgeführt und zeigt eine bessere Hochverfügbarkeit.

Abbildung 3–3 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 — sie 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 — sie kann zwischen den realen Servern migrieren.

Eine Netzwerkressource ist zunächst einem Knoten zugeordnet, dem Primärknoten. Wenn der Primärknoten ausfällt, werden Netzwerkressource und Anwendungsressource mit einem Failover-Vorgang auf einen anderen Cluster-Knoten umgeleitet (einen Sekundärknoten). 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–4 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–4 Festgelegter Hostname versus logischer Hostname

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

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 einen anderen Knoten verlegt 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–5 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–5 Festgelegter Hostname versus gemeinsam genutzte Adresse

Datendienstmethoden

Die Sun Cluster-Software stellt eine Reihe von Dienstverwaltungsmethoden zur Verfügung. Diese Methoden werden vom Resource Group 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 Multihostplatten 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 SunPlex-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 als inaktiv und auf einem anderen Knoten als aktiv 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), je nachdem, wie der Datendienst konfiguriert wurde.

Scalable-Datendienste

Der Scalable-Datendienst kann aktive Instanzen auf mehreren Knoten ausführen. Scalable-Dienste verwenden zwei Ressourcengruppen: Eine Scalable-Ressourcengruppe mit den Anwendungsressourcen und eine Failover-Ressourcengruppe mit den 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) und werden anhand unterschiedlicher, vordefinierter Algorithmen auf die Knoten verteilt, die im Rahmen des Lastausgleichsverfahrens eingestellt wurden. Der Cluster kann die Dienstlast mithilfe des Lastausgleichsverfahrens zwischen mehreren Knoten ausgleichen. Beachten Sie, dass mehrere globale Schnittstellen auf anderen Knoten weitere, gemeinsam genutzte Adressen hosten können.

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 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 er 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–6 zeigt ein Beispiel für eine Failover- und eine Scalabe-Ressourcengruppe und die Abhängigkeiten für Scalable-Dienste. Dieses Beispiel enthält drei Ressourcengruppen. Die Failover-Ressourcengruppe enthält Anwendungsressourcen für hoch verfügbaren DNS und Netzwerkressourcen, die sowohl vom hoch verfügbaren DNS als auch vom hoch verfügbaren Apache Web Server genutzt werden (nur für SPARC-basierte Cluster verfügbar). 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, und dass alle Apache-Anwendungsressourcen von der Netzwerkressource schost-2 abhängen, die eine gemeinsam genutzte Adresse ist (gestrichelte Linien).

Abbildung 3–6 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: reine und sticky. Ein reiner Dienst ist ein Dienst, bei dem jede Instanz Client-Anforderungen beantworten kann. Ein Sticky-Dienst ist ein Dienst, bei dem ein Client Anforderungen an dieselbe Instanz sendet. 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 GUI von SunPlex-Manager 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” bezeichnet, weil die Serverinstanz 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.

Ein Webbrowser auf dem Client stellt zum Beispiel mithilfe von drei verschiedenen TCP-Verbindungen eine Verbindung mit einer gemeinsam genutzten IP-Adresse an Port 80 her, aber die Verbindungen tauschen zwischengespeicherte Sitzungsinformationen mit dem 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 Sitzungsinformationen bei derselben Instanz austauschen, wird der Client als “sticky” bezeichnet, weil mehrere Serverinstanzen auf demselben Knoten unterschiedliche Ports abhören.

Ein E-Commerce-Kunde füllt seinen Einkaufskorb zum Beispiel mit Artikeln und verwendet das normale 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 in Bezug auf dieselbe IP-Adresse “Sticky-Platzhalter” bei den Ports.

Ein gutes Beispiel dieses Verfahrens ist der passive FTP-Modus. Ein Client stellt an Port 21 eine Verbindung mit einem FTP-Server her und wird 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 mit den Steuerinformationen angegeben hat.

Beachten Sie, dass das gewichtete Lastausgleichsverfahren für jedes dieser Sticky-Verfahren standardmäßig gültig ist, so dass die ursprüngliche Client-Anforderung an die vom Lastausgleich vorgegebene Instanz geleitet wird. Nachdem der Client eine Affinität zum Knoten mit der ausgeführten Instanz aufgebaut hat, werden zukünftige Anforderungen an diese Instanz geleitet, solange der Knoten zugänglich ist und das Lastausgleichsverfahren nicht geändert wird.

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, wenn die Gesamtanzahl der Verbindungen groß genug ist. 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: die erste Anforderung an Knoten 1, die zweite Anforderung an Knoten 2 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 der 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 der Load_balancing_policy-Ressourceneigenschaft eingestellt.

Failback-Einstellungen

Ressourcengruppen wechseln beim Failover von einem Knoten auf einen anderen. In diesem Fall 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 SunPlex-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 von neuen Datendiensten

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. Wenn die Anwendung, die Sie als Failover- oder Scalable-Dienst ausführen möchten, von Sun derzeit nicht angeboten wird, können Sie diese Anwendung mit einer API oder mit der DSET-API als Failover- oder Scalable-Dienst konfigurieren.

Es gibt eine Reihe von Kriterien, mit denen Sie feststellen können, ob eine Anwendung als Failover-Dienst ausgeführt werden kann. Die Beschreibung des spezifischen Kriteriums finden Sie in den SunPlex-Dokumenten zu den APIs, die Sie für Ihre Anwendung verwenden können.

Wir stellen Ihnen hier einige Richtlinien vor, mit deren Hilfe Sie erkennen können, ob Ihr Dienst die Scalable-Datendienst-Architektur nutzbringend einsetzen kann. Allgemeine Informationen zu Scalable-Diensten finden Sie unter Scalable-Datendienste.

Neue Dienste, die folgende Richtlinien erfüllen, können Scalable-Dienste verwenden. Wenn ein vorhandener Dienst diese Richtlinien nicht genau einhält, müssen Teile davon möglicherweise neu geschrieben werden, damit der Dienst den Richtlinien entspricht.

Ein Scalable-Datendienst weist folgende Merkmale auf. Erstens: Ein solcher Dienst besteht aus einer oder mehreren Serverinstanz(en). 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, muss der gleichzeitige Zugriff auf diesen Speicher durch mehrere Serverinstanzen 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 den Speicher vom Arbeitsspeicherstatus zu unterscheiden, und der Begriff “logisch”, weil der Speicher als einzelne Entität angezeigt wird, auch wenn er möglicherweise repliziert ist. Außerdem hat dieser logische Datenspeicher die Eigenschaft, dass eine Aktualisierung des Speichers durch eine beliebige Instanz sofort von anderen Instanzen erkannt wird.

Das SunPlex-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 diesen Speichertyp ist eine Backend-Datenbank wie das hoch verfügbare Oracle oder Oracle Parallel Server/Real Application Clusters für SPARC-basierte Cluster. Beachten Sie, dass bei diesem Typ von Backend-Datenbankserver die Synchronisierung über Datenbankabfragen oder Aktualisierungstransaktionen integriert ist, so dass bei mehreren Serverinstanzen nicht jede einzelne Instanz eine eigene Synchronisierung durchführen muss.

Ein Beispiel für einen nicht skalierbaren Dienst ist die aktuelle Zusammensetzung des IMAP-Servers von Sun. 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 sznchronisieren, 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

Das SunPlex-System stellt Folgendes zur Verfügung, um Anwendungen hoch verfügbar zu machen:

• Datendienste, die zum Lieferumfang des SunPlex-Systems gehören,

• Eine Datendienst-API,

• Eine API für die Datendienst-Entwicklungsbibliothek,

• Einen “generischen” Datendienst.

Im Sun Cluster Data Services Planning and Administration Guide wird die Installation und Konfiguration der Datendienste beschrieben, die zum Lieferumfang des SunPlex-Systems gehören. Im Sun Cluster Data Services Developer's Guide wird das Einrichten anderer Anwendungen als hoch verfügbar im Sun Cluster-Framework beschrieben.

Mit den Sun Cluster-APIs können Anwendungsprogrammierer Fehler-Monitore sowie Skripts zum Starten und Anhalten von Datendienstinstanzen entwickeln. Mit diesen Tools kann eine Anwendung als Failover- oder Scalable-Datendienst eingerichtet werden. Zudem stellt das SunPlex-System einen “generischen” Datendienst zur Verfügung, mit dem die benötigten Start- und Stoppmethoden für eine Anwendung, die als Failover- oder Scalable-Dienst ausgeführt werden soll, schnell generiert werden können.

Verwenden des Cluster-Interconnect für den Datendienstverkehr

Ein Cluster benötigt mehrere Netzwerkverbindungen zwischen den Knoten, die den Cluster-Interconnect bilden. Die Cluster-Software verwendet mehrere Interconnects, um die Hochverfügbarkeit und die Leistung zu verbessern. Für den internen Datenverkehr (zum Beispiel 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 Cluster-Installation konfigurierten privaten Hostnamen verwenden. Wenn zum Beispiel der private Hostname für Knoten 1 clusternode1-priv ist, kommunizieren Sie mit diesem Namen über den Cluster-Interconnect mit Knoten 1. TCP-Sockets, die mit diesem Namen geöffnet wurden, werden über den Cluster-Interconnect geleitet und können bei einem Netzwerkfehler transparent umgeleitet werden.

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

Bei Verwendung des Cluster-Interconnects auf Anwendungsebene wird ein einizger Interconnect zwischen jedem Knotenpaar eingesetzt; wenn möglich werden jedoch getrennte Interconnects für unterschiedliche Knotenpaare eingesetzt. Angenommen, eine Anwendung wird auf drei SPARC-basierten Knoten ausgeführt und kommuniziert über den Cluster-Interconnect. Die Kommunikation zwischen den Knoten 1 und 2 kann über die Schnittstelle hme0 erfolgen, während die Kommunikation zwischen den Knoten 1 und 3 über die Schnittstelle qfe1 erfolgen kann. Das bedeutet, dass die Anwendungskommunikation zwischen zwei beliebigen Knoten auf einen einzigen Interconnect beschränkt ist, während die Cluster-interne Kommunikation über alle Interconnects verteilt wird.

Beachten Sie, dass die Anwendung den Interconnect mit dem internen Cluster-Datenverkehr teilt, so dass die für die Anwendung verfügbare Bandbreite von der Bandbreite abhängt, die für anderen Cluster-Datenverkehr verwendet wird. Im Fall eines Versagens kann der interne Datenverkehr im Round-Robin-Verfahren auf die restlichen Interconnects umgeleitet werden, während die Anwendungsverbindungen mit einem versagenden Interconnect auf einen funktionierenden Interconnect umgeschaltet werden können.

Zwei Adresstypen unterstützen den Cluster-Interconnect, und mit gethostbyname(3N) werden für einen privaten Hostnamen in der Regel zwei IP-Adressen zurückgegeben. Die erste Adresse wird als logische Pro-Paar-Adresse bezeichnet, die zweite Adresse als logische Pro-Knoten-Adresse.

Jedem Knotenpaar wird eine eigene logische Pro-Paar-Adresse zugewiesen. Dieses kleine logische Netzwerk unterstützt Failover-Vorgänge von Verbindungen. Jedem Knoten wird außerdem eine feste Pro-Knoten-Adresse zugewiesen. Mit anderen Worten, die logischen Pro-Paar-Adressen für clusternode1-priv sind auf jedem Knoten anders, während die logische Pro-Knoten-Adresse für clusternode1-priv für jeden Knoten gleich ist. Ein Knoten hat jedoch für sich selbst keine Pro-Paar-Adresse, so dass mit gethostbyname (clusternode1-priv) auf Knoten 1 nur die logische Pro-Knoten-Adresse zurückgegeben wird.

Beachten Sie, dass Anwendungen, die Verbindungen über den Cluster-Interconnect zulassen und dann aus Sicherheitsgründen die IP-Adresse überprüfen, alle IP-Adressen überprüfen müssen, die mit gethostbyname zurückgegeben werden, und nicht nur die erste IP-Adresse.

Wenn Sie in Ihrer Anwendung an allen Stellen konsistente IP-Adressen benötigen, konfigurieren Sie Anwendung so, dass die Pro-Knoten-Adresse sowohl an die Client- als auch an die Serverseite angebunden ist; so scheinen alle Verbindungen über die Pro-Knoten-Adresse zu laufen.

Ressourcen, Ressourcengruppen und Ressourcentypen

Datendienste verwenden mehrere Typen von Ressourcen: Anwendungen wie Sun Java System Web Server (früher 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 for Oracle ist zum Beispiel der Ressourcentyp SUNW.oracle-server und Sun Cluster HA for Apache der Ressourcentyp SUNW.apache.

Der Ressourcentyp SUNW.oracle-server wird nur in SPARC-basierten Clustern eingesetzt

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

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

Die Ressourcentypen SUNW.HAStorage und HAStoragePlus werden zur Synchronisierung beim Starten von Ressourcen und Plattengerätegruppen verwendet, von denen die Ressourcen abhängen. Damit 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 fnden Sie unter “Synchronizing the Startups Between Resource Groups and Disk Device Group” im Data Services Installation and Configuration Guide. (Der HAStoragePlus-Ressourcentyp ist ab Sun Cluster 3.0 5/02 verfügbar und damit 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 Gruppen zusammengefasst, die als Ressourcengruppen bezeichnet werden, 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. Weitere Informationen zu diesem Prozess finden Sie im Sun Cluster Data Services Planning and Administration Guide.

Resource Group 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 die 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. RGM-Aktionen ändern den Zustand von Ressourcen und Ressourcengruppen von online zu offline und umgekehrt. 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 des Ressourcenverwaltungsprojekts unter der Steuerung des RGM finden Sie unter Ressourcen, Ressourcengruppen und Ressourcentypen.

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. Sie 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, aber sie können 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 aus bestimmten Gründen 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.

  Diese Zustände ändern sich bei den Cluster-Übergangen im Verlauf der Cluster-Rekonfigurationsschritte bei einem Switchover oder Failover. Sie können auch durch Verwaltungsaktionen geändert werden. Mit scswitch(1M) können Sie den Zustand einer Ressource oder einer Ressourcengruppe von online zu offline und umgekehrt ä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 alle dazugehörigen Ressourcen offline. Wenn eine Ressourcengruppe online ist, sind alle dazugehörigen 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 SunPlex-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 einem Anhang im Sun Cluster Data Services Planning and Administration Guide beschrieben.

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 Kapitel zum Datendienst im Sun Cluster Data Services Planning and Administration Guide 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 in der Solaris-Umgebung 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 arbeiten.

Mithilfe der Solaris-Verwaltungsfunktion in einer 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, und der Begriff 'Leistungen' für CPU-Zeit, Prozesse und Aufgaben.

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 in der Solaris-Umgebung zur Verfügung gestellte Verwaltungsfunktion eingesetzt werden kann. Detaillierte konzeptionelle und verfahrenstechnische Dokumentation zur Verwaltungsfunktion finden Sie im System Administration Guide: Resource Management and Network Services aus der Solaris 9 System Administrator Collection.

Bei der Konfiguration von Ressourcen und Ressourcengruppen zur Verwendung der 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 einer 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 unter “Standard Properties” in Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Siehe r_properties(5) und rg_properties(5) for property descriptions.

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 unter “Projects and Tasks” in System Administration Guide: Resource Management and Network Servicesin der Solaris 9 System Administrator Collection. 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 wird.

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. Eine Beschreibung der Befehlszeile, um FSS als Ihren Standardplaner festzulegen, finden Sie unter dispadmin(1M). Weitere Informationen finden Sie unter priocntl(1), ps(1) und 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 Ihres 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 werden, 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. Verfahrenstechnische Informationen finden Sie unter “So ändern Sie die Plattengeräteeigenschaften” unter “Administering Disk Device Groups” in Sun Cluster System Administration Guide for Solaris OS. Konzeptionelle Informationen zur Knotenkonfiguration und dem Verhalten von Failover- und Scalable-Datendiensten finden Sie unter SunPlex-System-Hardware- und Softwarekomponenten.

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 eine lokale /etc/project-Datenbankdatei sein 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. Detaillierte Informationen zur Einstellung des process.max-address-space-Wertes finden Sie unter rctladm(1M).

Konfigurieren Sie bei Verwendung von Verwaltungssteuerungen die Speicherbegrenzung angemessen, um unnötige Failover-Vorgänge von Anwendungen und einen “Ping-Pong”-Effekt bei den Anwendungen zu vermeiden. Im Allgemeinen gilt Folgendes:

• 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 Cluster-Umgebung wird eine Anwendung als Teil einer Ressource und eine Ressource als Teil einer Ressourcengruppe (RG) konfiguriert. 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 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 je nach Anzahl der Anteile ändern, die jedem Prozess mit CPU-Zeit-Bedarf zugewiesen werden.

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 und den zweiten realen Host (phys-schost-2 ) als Standard-Master für die restlichen zwei 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 IPMP_Long;

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 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 oder Sie können Standby-Schnittstellen konfigurieren, die bis zum Auftreten eines Failovers inaktiv bleiben. Der in.mpathd-Mutlipathing-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 unter Aufrechterhaltung der Konnektivität des öffentlichen Netzwerkes für den Knoten über. Wenn eine Standby-Schnittstelle konfiguriert wurde, wählt der Dämon die Standby-Schnittstelle aus. Andernfalls wählt in.mpathd 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 freie ARP-Übertragungen gesendet. Die Konnektivität der Remote-Clients bleibt damit erhalten.

Aufgrund der TCP-Wiederherstellungseigenschaften bei Stau kann an TCP-Endpunkten nach einem erfolgreichen Failover eine weitere Verzögerung entstehen, da einige Segmente beim Failover verloren gehen können und 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 Information zu den Ressourcen logischer Hostname und gemeinsam genutzte Adressen finden Sie im Sun Cluster Data Services Planning and Administration Guide.

Der IP Network Multipathing-Mechanismus ist auf das Erkennen und Verbergen von Adapterfehlern ausgelegt. Zweck dieser Gestaltung ist nicht, die Wiederherstellung von einem Verwalter durchzuführen und mit ifconfig(1M) eine der logischen (oder gemeinsam genutzten) IP-Adressen zu entfernen. Die Sun Cluster-Software zeigt die logischen und gemeinsam genutzten IP-Adressen als Ressourcen an, die vom RGM verwaltet werden. Ein Verwalter muss eine IP-Adresse mit scrgadm(1M) entfernen oder hinzufügen, um die Ressourcengruppe mit der Ressource zu ändern.

Weitere Informationen zur Solaris-Implementierung von IP Network Multipathing finden Sie in der entsprechenden Dokumentation zur Solaris-Betriebsumgebung, die auf Ihrem Cluster installiert ist.

SPARC: Unterstützung der dynamischen Rekonfiguration

Die Softwarefunktion zur Unterstützung der dynamischen Rekonfiguration (DR) in Sun Cluster 3.1 4/04 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 4/04 beschrieben.

Beachten Sie, dass alle für die DR-Funktion von Solaris dokumentierten Anforderungen, Verfahren und Einschränkungen auch für die DR-Unterstützung von Sun Cluster gelten (mit Ausnahme des Vorgangs zur Stilllegung der Betriebsumgebung). Sehen Sie deswegen die Dokumentation zur Solaris DR-Funktion nochmals durch, bevor Sie die DR-Funktion mit der Sun Cluster-Software verwenden. Lesen Sie insbesondere nochmals 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.” Systemverwalter sollten die Meldung “Unbekannter Fehler” aus der übergeordneten Ebene 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 wird einen DR-Vorgang zur Board-Entfernung aufgrund der vorhandenen CPU-Geräte nicht ablehnen.

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. Diese beiden Typen unterscheiden sich lediglich bei ihrer Nutzung. Die aktuelle Hardware ist bei beiden Typen die gleiche.

Der vom Betriebssystem genutzte Speicher wird als Kernel-Speichergehäuse bezeichnet. Die Sun Cluster-Software unterstützt die Board-Entfernung bei dem Board mit dem Kernel-Speichergehäuse nicht und lehnt jeden derartigen Vorgang ab. Wenn ein DR-Vorgang zur Board-Entfernung einen Speicher betrifft, der nicht das Kernel-Speichergehäuse ist, lehnt Sun Cluster 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.

Detailierte Anweisungen zur Ausführung dieser Aktionen finden Sie im Sun Cluster System Administration Guide.

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 Sun Cluster den Vorgang ab und identifiziert 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.

Detailierte Anweisungen zur Ausführung dieser Aktionen finden Sie im Sun Cluster System Administration Guide.

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 Sun Cluster den Vorgang ab und identifiziert 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 (siehe auch den nachstehenden Abschnitt neben “Achtung”).

Detailierte Anweisungen zur Ausführung dieser Aktionen finden Sie im Sun Cluster System Administration Guide.

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

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 Sun Cluster den Vorgang ab und identifiziert 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.

Detaillierte Anweisungen zur Durchführung eines DR-Vorgangs zur Entfernung einer öffentlichen Netzwerkschnittstelle finden Sie im Sun Cluster System Administration Guide.