Dieses Kapitel enthält Planungsinformationen und Richtlinien zum Installieren einer SunCluster-Konfiguration.
In diesem Kapitel werden die folgenden Themen besprochen:
Die folgende Tabelle zeigt, wo die Anweisungen für die verschiedenen Installationsaufgaben für die SunCluster-Softwareinstallation zu finden sind und in welcher Reihenfolge Sie die Aufgaben ausführen sollten.
Tabelle 1–1 Informationen zu SunCluster-Softwareinstallationsaufgaben
Schritt |
Anweisungen |
---|---|
Konfigurieren der Cluster-Hardware |
Sun Cluster 3.1 - 3.2 Hardware Administration Manual for Solaris OS Dokumentation, die mit dem Server und den Speichergeräten mitgeliefert wird |
Planen der Cluster-Softwareinstallation | |
Installieren der Softwarepakete. Optional können Sie die Software Sun StorEdgeTM QFS installieren und konfigurieren. | |
Erstellen eines neuen Clusters oder eines neuen Cluster-Knotens | |
Konfigurieren von Solaris Volume Manager-Software. |
Konfigurieren der Solaris Volume Manager-Software Dokumentation zu Solaris Volume Manager. |
Installieren und Konfigurieren der Software VERITAS Volume Manager (VxVM) |
Installieren und Konfigurieren der Software VxVM Dokumentation zu VxVM |
Konfigurieren von Cluster-Dateisystemen, falls verwendet. | |
(Optional) Erstellen von nicht globalen Zonen auf dem Solaris 10-Betriebssystem. |
Erstellen einer nicht globalen Zone auf einem Cluster-Knoten |
(Optional) SPARC: Installieren und Konfigurieren des SunCluster-Moduls für Sun Management Center |
SPARC: Installieren des SunCluster-Moduls für Sun Management Center Sun Management Center-Dokumentation. |
Planen, Installieren und Konfigurieren von Ressourcengruppen und Datendiensten Erstellen von weitgehend verfügbaren lokalen Dateisystemen, falls verwendet. |
Sun Cluster Data Services Planning and Administration Guide for Solaris OS |
Entwickeln von benutzerdefinierten Datendiensten |
Dieser Abschnitt enthält die folgenden Richtlinien zum Planen der Solaris-Softwareinstallation in einer Cluster-Konfiguration.
Weitere Informationen zur Solaris-Software finden Sie in der Solaris-Installationsdokumentation.
Sie können die Solaris-Software von einer lokalen DVD-ROM oder von einem Netzwerk-Installationsserver mithilfe der JumpStartTM-Installationsmethode installieren. Außerdem bietet die SunCluster-Software eine benutzerdefinierte Methode für die Installation des Solaris-Betriebssystems und der SunCluster-Software mithilfe der JumpStart-Installationsmethode. Wenn Sie mehrere Cluster-Knoten installieren, ist möglicherweise eine Netzwerkinstallation empfehlenswert.
Weitere Informationen zur JumpStart-Installationsmethode scinstall finden Sie unter So installieren Sie die Solaris- und SunCluster-Software (JumpStart). Weitere Informationen zu den Solaris-Standardinstallationsmethoden finden Sie in der Solaris-Installationsdokumentation.
Berücksichtigen Sie die folgenden Punkte, wenn Sie das Solaris-Betriebssystem in einer SunCluster-Konfiguration verwenden möchten.
Solaris 10-Zonen - Installieren Sie SunCluster-Framework-Software nur in der globalen Zone.
Informationen dazu, ob Sie einen SunCluster-Datenservice direkt in einer nicht globalen Zone installieren können, finden Sie in der Dokumentation zum jeweiligen Datenservice.
Wenn Sie nicht globale Zonen auf einem Cluster-Knoten konfigurieren, muss das Loopback-Dateisystem (LOFS) aktiviert werden. Die zusätzlich zu berücksichtigenden Erwägungen finden Sie in den Informationen zum LOFS.
Loopback-Dateisystem (LOFS) - Während der Cluster-Erstellung mit der Solaris 9-Version der SunCluster-Software ist die LOFS-Fähigkeit standardmäßig deaktiviert. Bei der Cluster-Erstellung mit der Solaris 10-Version der SunCluster-Software ist die LOFS-Fähigkeit nicht standardmäßig deaktiviert.
Wenn der Cluster die folgenden beiden Bedingungen erfüllt, müssen Sie LOFS deaktivieren, damit Probleme beim Wechseln oder andere Fehler vermieden werden:
Sun Cluster HA für NFS wird auf einem hoch verfügbaren lokalen Dateisystem konfiguriert.
Der automountd-Dämon wird ausgeführt.
Wenn der Cluster nur eine der beiden Bedingungen erfüllt, können Sie LOFS problemlos aktivieren.
Wenn sowohl LOFS als auch der automountd-Dämon bei Ihnen aktiviert sein müssen, schließen Sie alle Dateien aus der Zuordnung für das automatische Einhängen aus, die zum hoch verfügbaren lokalen Dateisystem gehören, das durch Sun Cluster HA für NFS exportiert wird.
Schnittstellengruppen - Solaris-Schnittstellengruppen werden in einer SunCluster-Konfiguration nicht unterstützt. Die Solaris-Schnittstellengruppen-Funktion wird bei der Solaris-Softwareinstallation standardmäßig deaktiviert. Aktivieren Sie die Solaris-Schnittstellengruppen nicht erneut. Weitere Informationen zu den Solaris-Schnittstellengruppen finden Sie in der Online-Dokumentation unter ifconfig(1M).
Stromsparmodus - Der automatische Stromsparmodus wird in SunCluster-Konfigurationen nicht unterstützt und sollte daher nicht aktiviert werden. Weitere Informationen finden Sie in der Online-Dokumentation pmconfig(1M) und power.conf(4).
IP-Filter - SunCluster-Software unterstützt nicht die Solaris-IP-Filter-Funktion für skalierbare Dienste, aber sie unterstützt Solaris-IP-Filter für Failover-Dienste.
fssnap - SunCluster unterstützt nicht den fssnap-Befehl, der eine Funktion von UFS ist. Sie können den fssnap-Befehl jedoch auf lokalen Systemen verwenden, die nicht von SunCluster gesteuert werden. Für die fssnap-Unterstützung gelten folgende Einschränkungen:
Der fssnap-Befehl wird auf lokalen Dateisystemen unterstützt, die nicht von SunCluster verwaltet werden.
Der fssnap-Befehl wird nicht auf Cluster-Dateisystemen verwendet.
Der fssnap-Befehl wird nicht auf lokalen Dateisystemen unterstützt, die unter der Kontrolle von HAStoragePlus stehen.
Die Sun Cluster 3.2 2/08-Software erfordert mindestens die Softwaregruppe Solaris-Endbenutzer. Andere Komponenten der Cluster-Konfiguration können jedoch auch eigene Solaris-Softwareanforderungen aufweisen. Berücksichtigen Sie folgende Informationen, wenn Sie entscheiden, welche Solaris-Softwaregruppe Sie installieren.
Server - Prüfen Sie Ihre Server-Dokumentation auf Solaris-Softwareanforderungen. Für Sun EnterpriseTM 10000-Server beispielsweise ist die gesamte Solaris-Softwaregruppe plus OEM-Unterstützung erforderlich.
SCI-PCI-Adapter - Stellen Sie für die Verwendung der nur für SPARC-basierte Cluster zur Verfügung stehenden SCI-PCI-Adapter oder von Anwendungsprogrammierschnittstelle (API) für gemeinsam genutzten Remote-Speicher (RSM) (RSMAPI) sicher, dass die RSMAPI-Softwarepakete SUNWrsm und SUNWrsmo sowie für das Solaris 9-Betriebssystem auf SPARC-basierten Plattformen SUNWrsmx und SUNWrsmox installiert sind. Die RSMAPI-Softwarepakete sind nur in manchen Solaris-Softwaregruppen enthalten. Die Solaris-Softwaregruppe "Entwickler" enthält RSMAPI-Softwarepakete, die Solaris-Softwaregruppe "Endbenutzer" jedoch nicht.
Wenn die von Ihnen installierte Softwaregruppe die RSMAPI-Softwarepakete nicht enthält, installieren Sie die RSMAPI-Softwarepakete vor dem Installieren der SunCluster-Software manuell. Verwenden Sie den Befehlpkgadd(1M), um die Softwarepakete manuell zu installieren. Informationen zur Verwendung von RSMAPI finden Sie in Abschnitt (3RSM) der Manpages.
Zusätzliche Solaris-Pakete - Mglicherweise müssen Sie weitere Solaris-Softwarepakete installieren, die nicht Teil der Solaris-Endbenutzer-Softwaregruppe sind. Ein Beispiel wären die Apache HTTP Server-Pakete. Software von Drittherstellern wie ORACLE® erfordert möglicherweise ebenfalls zusätzliche Solaris-Softwarepakete. Angaben zu Solaris-Softwareanforderungen finden Sie in der Dokumentation der Dritthersteller.
Sie können die manuelle Installation der Solaris-Softwarepakete umgehen, indem Sie die gesamte Solaris-Softwaregruppe inklusive OEM-Unterstützung installieren.
Fügen Sie diese Informationen dem entsprechenden Arbeitsblatt Lokales Dateisystem-Layout hinzu.
Stellen Sie bei der Installation des Solaris-Betriebssystems sicher, dass Sie die erforderlichen SunCluster-Partitionen erstellen und dass alle Partitionen die Mindest-Speicherplatzanforderungen erfüllen.
swap – Der swap-Bereich, der Solaris und SunCluster-Software zugewiesen ist, muss insgesamt mindestens 750 MB betragen. Addieren Sie für optimale Ergebnisse mindestens 512 MB für die SunCluster-Software zum erforderlichen Speicher des Solaris-Betriebssystems. Weisen Sie außerdem den Auslagerungsspeicher zu, der von den Anwendungen benötigt wird, die auf dem Cluster-Knoten ausgeführt werden sollen.
Wenn Sie eine weitere Auslagerungsdatei erstellen möchten, tun Sie dies nicht auf einem globalen Gerät. Verwenden Sie nur eine lokale Platte als Auslagerungsgerät für den Knoten.
/globaldevices – Erstellen Sie ein mindestens 512 MB großes Dateisystem, das vom Dienstprogramm scinstall(1M) für globale Geräte verwendet werden soll.
Datenträger-Manager – Erstellen Sie eine 20-MB-Partition in Bereich 7 für die Verwendung durch den Datenträger-Manager. Wenn Sie im Cluster VERITAS Volume Manager (VxVM) verwenden und die Root-Platte einkapseln möchten, benötigen Sie zwei verfügbare Bereiche für die Verwendung durch VxVM.
Um diese Anforderungen zu erfüllen, müssen Sie eine benutzerdefinierte Partitionierung vornehmen, wenn Sie die interaktive Installation des Solaris-Betriebssystems ausführen.
Weitere Informationen zur Partitionsplanung finden Sie in folgenden Richtlinien:
Wie bei jedem System unter Solaris können Sie die Verzeichnisse root (/), /var, /usr und /opt als eigene Dateisysteme konfigurieren. Sie können aber auch alle diese Verzeichnisse im Root-Dateisystem (/) einschließen. Im Folgenden wird der Softwareinhalt der Verzeichnisse root (/), /var, /usr und /opt in einer SunCluster-Konfiguration beschrieben. Berücksichtigen Sie diese Informationen bei der Planung des Partitionsschemas.
Root (/) – Die SunCluster-Software selbst belegt weniger als 40 MB Speicherplatz im Root-Dateisystem (/). Die Software Solaris Volume Manager benötigt weniger als 5 MB und die Software VxVM weniger als 15 MB. Um ausreichenden zusätzlichen Speicherplatz und I-Knoten-Kapazität zu konfigurieren, addieren Sie mindestens 1000 MB zum Speicherplatz, den Sie normalerweise dem Root-Dateisystem (/) zuweisen würden. Dieser Speicherplatz wird für die Erstellung sowohl von blockorientierten Geräten als auch speziellen zeichenorientierten Geräten verwendet, die von Datenträgerverwaltungs-Software verwendet werden. Sie müssen insbesondere dann diesen Zusatzspeicherplatz zuweisen, wenn sich zahlreiche gemeinsam genutzte Platten im Cluster befinden.
/var – Die SunCluster-Software belegt während der Installation unerheblich wenig Speicherplatz im /var-Dateisystem. Sie müssen jedoch zusätzlichen Speicherplatz für die Protokolldateien reservieren. Außerdem können auf einem Cluster-Knoten mehr Meldungen protokolliert werden als auf einem typischen Standalone-Server. Weisen Sie deshalb dem /var-Dateisystem mindestens 100 MB zu.
/usr – Die SunCluster-Software belegt weniger als 25 MB Speicherplatz im /usr-Dateisystem. Solaris Volume Manager und VxVM benötigen jeweils weniger als 15 MB.
/opt – Die SunCluster-Framework-Software belegt weniger als 2 MB im /opt-Dateisystem. Jeder SunCluster-Datendienst kann jedoch 1 bis 5 MB verwenden. Die Software Solaris Volume Manager belegt keinen Speicherplatz im /opt-Dateisystem. Die Software VxVM belegt über 40 MB, wenn alle Pakete und Tools installiert werden.
Außerdem wird die meiste Datenbank- und Anwendungssoftware im /opt-Dateisystem installiert.
SPARC: Wenn Sie die Software Sun Management Center zur Cluster-Überwachung verwenden, benötigen Sie weitere 25 MB Speicherplatz auf jedem Knoten, um den Agenten von Sun Management Center und die SunCluster-Modulpakete zu unterstützen.
SunCluster erfordert, dass Sie ein spezielles Dateisystem auf einer der lokalen Platten zur Verwaltung von globalen Geräten reservieren. Dieses Dateisystem befindet sich normalerweise auf Ihrer Root-Platte. Wenn Sie allerdings einen anderen Speicher für das Dateisystem für globale Geräte, wie zum Beispiel einen Logical Volume Manager-Datenträger, verwenden, darf dieser nicht Teil eines gemeinsam genutzten Solaris Volume Manager-Plattensatzes oder einer anderen VxVM-Plattengruppe als einer Root-Plattengruppe sein. Dieses Dateisystem wird später als Cluster-Dateisystem eingehängt. Benennen Sie dieses Dateisystem mit dem Standardnamen /globaldevices, der vom Befehl scinstall(1M) erkannt wird.
Der scinstall-Befehl benennt das Dateisystem später in /global/.devices/node@nodeid um, wobei nodeid die Nummer darstellt, die einem Knoten zugewiesen wird, wenn er Cluster-Mitglied wird. Der ursprüngliche Einhängepunkt /globaldevices wird entfernt.
Das /globaldevices-Dateisystem muss ausreichenden Speicherplatz und ausreichende I-Knoten-Kapazität für die Erstellung von blockorientierten Geräten und speziellen zeichenorientierten Geräten aufweisen. Diese Richtlinie ist besonders dann wichtig, wenn sich zahlreiche Platten im Cluster befinden. Eine Dateisystemgröße von 512 MB sollte für die meisten Cluster-Konfigurationen ausreichend sein.
Wenn Sie die Software Solaris Volume Manager verwenden, müssen Sie einen Bereich auf der Root-Platte für die Verwendung bei der Erstellung des Zustands-Datenbankreplikats reservieren. Reservieren Sie hierfür einen spezifischen Bereich auf jeder lokalen Platte. Wenn Sie nur eine lokale Platte in einem Knoten haben, müssen Sie möglicherweise drei Zustands-Datenbankreplikate in demselben Bereich für die Software Solaris Volume Manager erstellen, damit sie ordnungsgemäß funktioniert. Weitere Informationen finden Sie in der Dokumentation zu Solaris Volume Manager.
Wenn Sie VERITAS Volume Manager (VxVM) verwenden und die Root-Platte einkapseln möchten, benötigen Sie zwei freie Bereiche, die für VxVM verfügbar sind. Außerdem benötigen Sie zusätzlichen, nicht zugewiesenen freien Speicherplatz am Beginn oder Ende der Platte. Informationen zum Einkapseln der Root-Platte finden Sie in der Dokumentation zu VxVM.
Tabelle 1–2 zeigt ein Partitionsschema für einen Cluster-Knoten mit weniger als 750 MB realem Speicher. Dieses Schema soll mit der Solaris-Softwaregruppe Endbenutzer, der SunCluster-Software und dem Datendienst Sun Cluster HA für NFS installiert werden. Der letzte Bereich auf der Platte, Bereich 7, wird mit einem kleinen Speicherplatz den Datenträger-Managern zugewiesen.
Dieses Layout ermöglicht die Verwendung der Software Solaris Volume Manager oder VxVM. Bei Verwendung der Software Solaris Volume Manager verwenden Sie Bereich 7 für das Zustands-Datenbankreplikat. Wenn Sie VxVM verwenden, machen Sie Bereich 7 später wieder frei, indem Sie ihm eine Null-Länge zuweisen. Dieses Layout sorgt für die erforderlichen beiden freien Bereiche, 4 und 7, und nicht verwendeten Speicherplatz am Ende der Platte.
Tabelle 1–2 Beispiel Dateisystemzuweisung
Bereich |
Inhalt |
Größenzuweisung |
Beschreibung |
---|---|---|---|
0 |
/ |
6,75 GB |
Restlicher freier Speicherplatz auf der Platte nach Zuweisung von Speicherplatz zu den Bereichen 1 bis 7. Wird für das Solaris-Betriebssystem, die SunCluster-Software, die Datendienste-Software, die Datenträger-Manager-Software, den Agenten von Sun Management Center und die SunCluster-Modulagentenpakete, die Root-Dateisysteme und die Datenbank- und Anwendungssoftware verwendet. |
1 |
swap |
1 GB |
512 MB für das Solaris-Betriebssystem. 512 MB für SunCluster-Software. |
2 |
Overlap |
8,43 GB |
Die gesamte Platte. |
3 |
/globaldevices |
512 MB |
Die SunCluster-Software weist diesen Bereich später einem anderen Einhängepunkt zu und hängt den Bereich als Cluster-Dateisystem ein. |
4 |
Nicht benutzt |
- |
Ist als freier Bereich zum Einkapseln der Root-Platte unter VxVM verfügbar. |
5 |
Nicht benutzt |
- |
- |
6 |
Nicht benutzt |
- |
- |
7 |
Datenträger-Manager |
20 MB |
Wird von der Software Solaris Volume Manager für das Zustands-Datenbankreplikat oder von VxVM für die Installation nach dem Freimachen dieses Bereichs verwendet. |
Informationen zu Zweck und Funktion von Solaris 10-Zonen in einem Cluster finden Sie unter Support for Solaris Zones on Sun Cluster Nodes in Sun Cluster Concepts Guide for Solaris OS.
Beachten Sie bei der Erstellung einer nicht globalen Solaris 10-Zone (vereinfacht Zone genannt) auf einem Cluster-Knoten folgende Punkte.
Einmaliger Zonenname - Der Zonenname im Knoten muss einmalig sein. Geben Sie mehreren Zonen im selben Knoten nicht denselben Namen.
Verwendung ein und desselben Zonennamens für mehrere Knoten - Zur Vereinfachung der Cluster-Verwaltung können Sie denselben Namen für eine Zone in jedem Knoten verwenden, in dem Ressourcengruppen in der jeweiligen Zone online gebracht werden sollen.
Private IP-Adressen - Versuchen Sie nicht, mehr private IP-Adressen zu verwenden als im Cluster verfügbar sind.
Mounts - Beziehen Sie keine globalen Mounts in Zonendefinitionen ein. Beziehen Sie nur Loopback-Mounts ein.
Ausfallsicherungsdienst - In Clustern mit mehreren Knoten ermöglicht es SunCluster, unterschiedliche Zonen auf ein und demselben Knoten in der Knotenliste einer Ausfallsicherungs-Ressourcengruppe anzugeben; dies ist jedoch nur beim Testen nützlich. Wenn ein Knoten alle Zonen in der Knotenliste beherbergt, wird der Knoten zu einer Schwachstelle für die Ressourcengruppe. Für eine größtmögliche Verfügbarkeit sollten sich die Zonen in der Knotenliste einer Ausfallsicherungs-Ressourcengruppe auf unterschiedlichen Knoten befinden.
In Clustern mit einem Knoten besteht kein funktionelles Risiko, wenn Sie mehrere Zonen in einer Knotenliste einer Ausfallsicherungs-Ressourcengruppe angeben.
Skalierbare Dienste - Erstellen Sie keine nicht globalen Zonen zur Verwendung in ein und demselben skalierbaren Dienst auf ein und demselben Knoten. Jede Instanz des skalierbaren Dienstes muss auf einem unterschiedlichen Cluster-Knoten ausgeführt werden.
LOFS - Für Solaris Zones muss das Loopback-Dateisystem (LOFS) aktiviert sein. Für den Sun Cluster HA für NFS-Datendienst muss das LOFS jedoch deaktiviert sein, damit Probleme beim Wechseln oder andere Fehler vermieden werden. Wenn Sie sowohl nicht globale Zonen als auch Sun Cluster HA für NFS in Ihrem Cluster konfigurieren, führen Sie eine der folgenden Maßnahmen durch, um mögliche Probleme im Datendienst zu vermeiden:
Deaktivieren Sie den automountd-Dämon.
Schließen Sie aus der Automounter-Zuordnung alle Dateien aus, die zum hoch verfügbaren Dateisystem gehören, das von Sun Cluster HA für NFS exportiert wird.
Dieser Abschnitt enthält Richtlinien für das Planen und Vorbereiten der folgenden Komponenten für die Installation und Konfiguration der SunCluster-Software:
Detaillierte Informationen zu den SunCluster-Komponenten finden Sie in Sun Cluster Overview for Solaris OS und in Sun Cluster Concepts Guide for Solaris OS.
Halten Sie alle erforderlichen Lizenzzertifikate bereit, bevor Sie mit der Softwareinstallation beginnen. Die SunCluster-Software erfordert kein Lizenzzertifikat, doch alle mit der SunCluster-Software installierten Knoten müssen von Ihrem SunCluster-Software-Lizenzvertrag gedeckt werden.
Informationen zu den Lizenzanforderungen der Datenträger-Manager- und der Anwendungssoftware finden Sie in der Installationsdokumentation dieser Produkte.
Nach der Installation der einzelnen Softwareprodukte müssen Sie auch alle jeweils erforderlichen Korrekturversionen installieren.
Informationen zu den aktuell erforderlichen Korrekturversionen finden Sie unter Patches and Required Firmware Levels in Sun Cluster 3.2 2/08 Release Notes for Solaris OS, oder wenden Sie sich an Ihren Sun-Kundendienst.
Allgemeine Richtlinien und Verfahren für die Anwendung von Patches finden Sie in Kapitel 10, Patching Sun Cluster Software and Firmware in Sun Cluster System Administration Guide for Solaris OS.
Informationen zur Verwendung öffentlicher Netzwerke durch den Cluster finden Sie unter Public Network Adapters and IP network multipathing in Sun Cluster Concepts Guide for Solaris OS.
Sie müssen je nach Cluster-Konfiguration eine Anzahl von IP-Adressen für öffentliche Netzwerke für verschiedene SunCluster-Komponenten konfigurieren. Jeder Knoten in der Cluster-Konfiguration muss mindestens eine öffentliche Netzwerkverbindung mit demselben Satz öffentlicher Teilnetze besitzen.
In der nachfolgenden Tabelle sind die Komponenten aufgeführt, denen IP-Adressen für öffentliche Netzwerke zugewiesen werden müssen. Fügen Sie diese IP-Adressen folgenden Speicherorten hinzu:
Allen verwendeten Benennungsdiensten
Der lokalen Datei /etc/inet/hosts auf jedem Cluster-Knoten, nachdem Sie die Solaris-Software installiert haben
Bei Solaris 10 der lokalen Datei /etc/inet/ipnodes auf allen Cluster-Knoten nach der Installation der Solaris-Software
Komponente |
Anzahl von benötigten IP-Adressen |
---|---|
1 IP-Adresse pro Subnetz. |
|
Cluster-Knoten |
1 IP-Adresse pro Knoten pro Subnetz. |
1 IP-Adresse pro Domäne. |
|
(Optional) Nicht globale Zonen |
1 IP-Adresse pro Subnetz. |
1 IP-Adresse. |
|
Logische Adressen |
1 IP-Adresse pro logischer Host-Ressource pro Subnetz. |
Quorum-Server |
1 IP-Adresse. |
Weitere Informationen zum Planen von IP-Adressen finden Sie in Kapitel 3, Planning Your TCP/IP Network (Task) in System Administration Guide: IP Services (Solaris 9) oder Kapitel 2, Planning Your TCP/IP Network (Tasks) in System Administration Guide: IP Services (Solaris 10).
Sie benötigen Konsolenzugriff auf alle Cluster-Knoten. Wenn Sie die Software Cluster-Steuerbereich auf einer Verwaltungskonsole installieren, müssen Sie den Hostnamen des Konsolenzugriffsgeräts angeben, das für die Kommunikation mit den Cluster-Knoten verwendet wird.
Für die Kommunikation zwischen Verwaltungskonsole und Cluster-Knotenkonsolen wird ein Terminal-Konzentrator verwendet.
Ein Sun Enterprise 10000-Server verwendet einen System Service Processor (SSP) anstelle eines Terminal-Konzentrators.
Ein Sun Fire-Server verwendet einen System-Controller anstelle eines Terminal-Konzentrators.
Informationen zum Konsolenzugriff finden Sie in Sun Cluster Concepts Guide for Solaris OS.
Wenn Sie eine Verwaltungskonsole direkt an Cluster-Knoten oder über ein Verwaltungsnetzwerk anschließen, geben Sie stattdessen den Hostnamen aller Cluster-Knoten und deren serielle Port-Nummer an, mit der die Verbindung zur Verwaltungskonsole bzw. dem Verwaltungsnetzwerk hergestellt wird.
Für jede Datendienst-Ressourcengruppe, die eine logische Adresse verwendet, muss ein Hostname für jedes öffentliche Netzwerk angegeben werden, von dem auf die logische Adresse zugegriffen werden kann.
Weitere Informationen finden Sie in Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Detaillierte Informationen zu Datendiensten und Ressourcen finden Sie auch in Sun Cluster Overview for Solaris OS und in Sun Cluster Concepts Guide for Solaris OS.
Öffentliche Netzwerke kommunizieren außerhalb des Clusters. Beachten Sie folgende Punkte bei der Planung der öffentlichen Netzwerkkonfiguration:
Trennung von öffentlichen und privaten Netzwerken - Für die öffentlichen Netzwerke und das private Netzwerk (Cluster-Verbindung) müssen getrennte Adapter verwendet werden, oder Sie müssen ein VLAN mit Tags auf damit kompatiblen Adaptern sowie VLAN-kompatible Switches verwenden, um dieselben Adapter sowohl für die private Verbindung als auch für das öffentliche Netzwerk zu verwenden.
Minimum - Alle Cluster-Knoten müssen mit mindestens einem öffentlichen Netzwerk verbunden sein. Für die Verbindungen mit dem öffentlichen Netzwerk können verschiedene Subnetze für verschiedene Knoten verwendet werden.
Maximum - Es sind so viele zusätzliche Verbindungen zum öffentlichen Netzwerk möglich, wie es die Hardwarekonfiguration erlaubt.
Skalierbare Dienste - Alle Knoten, auf denen ein skalierbarer Dienst ausgeführt wird, müssen entweder dasselbe Subnetz bzw. denselben Subnetz-Satz oder aber unterschiedliche Subnetze verwenden, die untereinander weitergeleitet werden können.
IPv4 - SunCluster Die Software unterstützt IPv4-Adressen im öffentlichen Netzwerk.
Die IPv6 - SunCluster-Software unterstützt unter folgenden Bedingungen bzw. Einschränkungen IPv6-Adressen im öffentlichen Netzwerk.
Die SunCluster-Software unterstützt keine IPv6-Adressen im öffentlichen Netzwerk, wenn das private Interconnect SCI-Adapter verwendet.
unterstützt SunCluster IPv6-Adressen für Failover und skalierbare Datendienste.
IPMP-Gruppen - Jeder öffentliche Netzwerkadapter, der für Datendienst-Verkehr verwendet wird, muss einer IP-Netzwerk-Multipathing (IPMP)-Gruppe angehören. Wenn ein öffentlicher Netzwerkadapter nicht für Datendienst-Verkehr verwendet wird, brauchen Sie ihn nicht in einer IPMP-Gruppe zu konfigurieren.
In der Version Sun Cluster 3.2 2/08 konfiguriert das Dienstprogramm scinstall eine IPMP-Einzeladaptergruppe während der SunCluster-Erstellung nicht mehr automatisch auf allen unkonfigurierten öffentlichen Netzwerkadaptern. Stattdessen konfiguriert das Dienstprogramm scinstall für alle öffentlichen Netzwerkadapter-Sätze im Cluster, die dasselbe Subnetz verwenden, automatisch eine IPMP-Mehrfachadaptergruppe. Unter Solaris 10 sind diese Gruppen probebasiert. Das Dienstprogramm scinstall ignoriert jedoch Adapter, die bereits in einer IPMP-Gruppe konfiguriert wurden. Wenn ein Adapter in einer IPMP-Gruppe, die vom Dienstprogramm scinstall konfiguriert wird, nicht für Datendienst-Verkehr verwendet wird, können Sie ihn aus der Gruppe entfernen.
Richtlinien und Anleitungen zur Konfiguration von IPMP-Gruppen finden Sie in den Verfahrensweisen in Teil II, Administering Interface Groups in System Administration Guide: Network Interfaces and Network Virtualization. Um IPMP-Gruppen nach der Cluster-Installation zu ändern, folgen Sie den Richtlinien in How to Administer IP Network Multipathing Groups in a Cluster in Sun Cluster System Administration Guide for Solaris OS sowie den Verfahren in Kapitel 28, Administering Network Multipathing (Task) in System Administration Guide: IP Services (Solaris 9) oder Kapitel 8, Administering IPMP in System Administration Guide: Network Interfaces and Network Virtualization(Solaris 10).
Unterstützung von lokalen MAC-Adressen - Alle öffentlichen Netzwerkadapter müssen Netzwerkschnittstellenkarten (NICs) verwenden, die die Zuweisung lokaler MAC-Adressen unterstützen. Die Zuweisung lokaler MAC-Adressen ist eine Anforderung von IPMP.
local-mac-address Einstellung - Die Variable local-mac-address? muss den Standardwert true für Ethernet-Adapter verwenden. Die SunCluster-Software unterstützt nicht den local-mac-address?-Wert false für Ethernet-Adapter. Diese Anforderung ist eine Änderung gegenüber SunCluster 3.0, bei der der local-mac-address?-Wert false erforderlich ist.
Weitere Informationen zu Schnittstellen mit dem öffentlichen Netzwerk finden Sie in Sun Cluster Concepts Guide for Solaris OS.
Sie können die SunCluster-Quorum Server-Software zur Konfiguration eines Rechners als Quorum-Server verwenden und anschließend den Quorum-Server als Quorum-Gerät Ihres Clusters konfigurieren. Sie können einen Quorum-Server anstelle von oder zusätzlich zu SCSI-Platten und NAS-Filer verwenden.
Berücksichtigen Sie die folgenden Punkte, wenn Sie einen Quorum-Server in einer SunCluster-Konfiguration verwenden möchten.
Netzwerkverbindung - Der Quorum-Server stellt eine Verbindung zu Ihrem Cluster über das öffentliche Netzwerk her.
Unterstützte Hardware - Die unterstützten Hardware-Plattformen für einen Quorum-Server sind dieselben wie für einen Cluster-Knoten.
Betriebssystem - Die Solaris-Softwareanforderungen für die Sun Cluster-Software gelten auch für die Quorum Server-Software.
Bedienung mehrerer Cluster - Sie können einen Quorum-Server als Quorum-Gerät für mehrere Cluster konfigurieren.
Gemischte Hardware und Software - Sie müssen einen Quorum-Server nicht auf der gleichen Hardware- oder Software-Plattform konfigurieren wie der bzw. die Cluster, die der Quorum-Server bedient. Beispiel: Ein x86-basierter Rechner, auf dem Solaris 9 OS ausgeführt wird, kann als Quorum-Server für einen SPARC-basierten Cluster konfiguriert werden, auf dem Solaris 10 OS ausgeführt wird.
Verwendung eines Cluster-Knotens als Quorum-Server - Sie können einen Quorum-Server auf einem Cluster-Knoten so konfigurieren, dass er Quorum-Dienste für andere Cluster leistet als den Cluster, zu dem der Knoten gehört Ein Quorum-Server, der auf einem Cluster-Knoten konfiguriert ist, ist jedoch nicht hochverfügbar.
Berücksichtigen Sie die folgenden Punkte, wenn Sie Network File System (NFS) in einer SunCluster-Konfiguration verwenden möchten.
NFS-Client - Kein SunCluster-Knoten kann als NFS-Client eines über Sun Cluster HA für NFS exportierten Dateisystems dienen, das auf einem Knoten im selben Cluster unterstützt wird. Ein derartiges übergreifendes Einhängen von Sun Cluster HA für NFS ist nicht zulässig. Verwenden Sie das Cluster-Dateisystem, damit Cluster-Knoten Dateien gemeinsam nutzen können.
NFSv3-Protokoll - Wenn Sie Dateisysteme auf den Cluster-Knoten von externen NFS-Servern wie z. B. NAS-Filter einhängen und das NFSv3-Protokoll verwenden, können Sie NFS-Client-Mounts und den Sun Cluster HA für NFS-Datendienst nicht auf demselben Cluster-Knoten ausführen. Wenn Sie dies trotzdem tun, veranlassen bestimmte Sun Cluster HA für NFS-Datendienste die NFS-Dämonen zum Stoppen und Neustarten, wodurch die NFS-Dienste unterbrochen werden. Sie können den Sun Cluster HA für NFS-Datendienst jedoch problemlos ausführen, wenn Sie das NFSv4-Protokoll zum Einhängen externer NFS-Dateisysteme in die Cluster-Knoten verwenden.
Sperren - Anwendungen, die lokal im Cluster laufen, dürfen Dateien in einem über NFS exportierten Dateisystem nicht sperren. Sonst könnten lokale Sperren (z. B. flock(3UCB) oder fcntl(2)) die Möglichkeit zum Neustarten von Lock Manager ( lockd(1M)) stören. Beim Neustart könnte einem gesperrten lokalen Prozess eine Sperre gewährt werden, die eigentlich einem Remote-Client vorbehalten sein sollte. Das würde ein unvorhersehbares Verhalten verursachen.
NFS-Sicherheitsfunktionen - SunCluster unterstützt die folgenden Optionen des Befehls share_nfs(1M) nicht:
secure
sec=dh
Allerdings unterstützt die SunCluster-Software folgende Sicherheitsfunktionen für NFS:
Die Verwendung von sicheren Ports für NFS. Sie aktivieren sichere Ports für NFS durch Hinzufügen des Eintragssatzes nfssrv:nfs_portmon=1 zur Datei /etc/system auf Cluster-Knoten.
Die Verwendung von Kerberos mit NFS. Weitere Informationen finden Sie unter Securing Sun Cluster HA for NFS With Kerberos V5 in Sun Cluster Data Service for NFS Guide for Solaris OS.
Betrachten Sie folgende Diensteinschränkungen für SunCluster-Konfigurationen:
Router -Konfigurieren Sie Cluster-Knoten nicht als Router (Gateways). Wenn das System abstürzt, finden die Clients keinen alternativen Router und können nicht wieder hergestellt werden.
NIS+-Server - Konfigurieren Sie Cluster-Knoten nicht als NIS- oder NIS+-Server. Für NIS oder NIS+ ist kein Datendienst verfügbar. Cluster-Knoten können jedoch NIS oder NIS+-Clients sein.
Booten und Installieren von Servern - Verwenden Sie eine SunCluster-Konfiguration nicht zur Bereitstellung eines weitgehend verfügbaren Boot- oder Installationsdienstes auf Client-Systemen.
RARP - Verwenden Sie eine SunCluster-Konfiguration nicht zur Bereitstellung eines rarpd-Dienstes.
RPC-Programmnummern - Wenn Sie einen RPC-Dienst auf dem Cluster installieren, darf dieser keine der folgenden Programmnummern verwenden:
100141
100142
100248
Diese Nummern sind den Sun Cluster-Dämonen rgmd_receptionist, fed und pmfd vorbehalten.
Wenn der von Ihnen installierte RPC-Dienst ebenfalls eine dieser Programmnummern verwendet, müssen Sie ihn dahin gehend ändern, dass er eine andere Programmnummer verwendet.
Zeitplanklassen - SunCluster unterstützt die Ausführung von Zeitplanklassen mit hoher Priorität auf Cluster-Knoten nicht. Führen Sie keinen der folgenden beiden Prozesstypen auf Cluster-Knoten aus:
Prozesse, die in der Time-Sharing-Zeitplanklasse mit hoher Priorität ausgeführt werden
Prozesse, die in der Echtzeit-Zeitplanklasse ausgeführt werden
Die SunCluster-Software beruht auf Kernel-Threads, die in der Echtzeit-Planungsklasse nicht ausgeführt werden können. Time-Sharing-Prozesse, die mit einer höheren als der normalen Priorität ausgeführt werden, oder Echtzeitprozesse können verhindern, dass die SunCluster-Kernel-Threads erforderliche CPU-Zyklen erhalten.
Dieser Abschnitt enthält Richtlinien für folgende SunCluster-Komponenten, die Sie konfigurieren:
Fügen Sie diese Informationen zum entsprechenden Konfigurationsplanungs-Arbeitsblatt hinzu.
Geben Sie bei der SunCluster-Konfiguration einen Namen für den Cluster ein. Der Cluster-Name muss im gesamten Unternehmen einmalig sein.
Der Cluster-Knotenname ist der Name, den Sie dem Rechner zuweisen, wenn Sie das Solaris-Betriebssystem installieren. Informationen zu Anforderungen im Hinblick auf die Benennung finden Sie auf der Manpage hosts(4).
Bei Einzelknoten-Cluster-Installationen ist der Standard-Cluster-Name mit dem Knotennamen identisch.
Bei der SunCluster-Konfiguration geben Sie die Namen aller Knoten an, die Sie im Cluster installieren.
Verwenden Sie unter Solaris 10 die Namenskonvention nodename:nodename, um eine nicht globale Zone für einen SunCluster-Befehl anzugeben.
Der nodename ist der Name des Cluster-Knotens.
Der nodename ist der Name, den Sie der nicht globalen Zone bei Erstellung der Zone auf dem Knoten geben. Der Zonenname muss auf dem Knoten einmalig sein. Sie können jedoch denselben Zonnenamen auf unterschiedlichen Knoten verwenden, da der gesamte Name der nicht globalen Zone im Cluster durch den unterschiedlichen Knotennamen in nodename:nodename einmalig wird.
Zur Angabe der globalen Zone brauchen Sie lediglich den Knotennamen anzugeben.
Für einen Ein-Knoten-Cluster müssen Sie kein privates Netzwerk konfigurieren. Das Dienstprogramm scinstall weist automatisch die Standardadresse und Netzmaske des privaten Netzwerks zu, und zwar auch dann, wenn vom Cluster kein privates Netzwerk verwendet wird.
SunCluster verwendet das private Netzwerk für die interne Kommunikation zwischen Knoten sowie zwischen von SunCluster verwalteten nicht globalen Zonen. Eine SunCluster-Konfiguration erfordert mindestens zwei Verbindungen mit dem Cluster-Interconnect im privaten Netzwerk. Wenn Sie SunCluster auf dem ersten Knoten des Clusters konfigurieren, geben Sie die private Netzwerkadresse und die Netzmaske auf eine der folgenden Arten an:
Übernehmen Sie die Standardadresse des privaten Netzwerks (172.16.0.0) und die Netzmaske (255.255.248.0). Dieser IP-Adressbereich unterstützt eine kombinierte Höchstanzahl von 64 Knoten und nicht globalen Zonen sowie eine Höchstanzahl von 10 privaten Netzwerken.
Die Höchstanzahl Knoten, die ein IP-Adressbereich unterstützen kann, spiegelt nicht die Höchstanzahl der Knoten wider, die von der Hardwarekonfiguration unterstützt werden kann.
Geben Sie eine andere zulässige private Netzwerkadresse an und übernehmen Sie die Standard-Netzmaske.
Übernehmen Sie die Standardadresse des privaten Netzwerks und geben Sie eine andere Netzmaske an.
Geben Sie eine andere private Netzwerkadresse und eine andere Netzmaske an.
Wenn Sie eine andere Netzmaske angeben, werden Sie vom Dienstprogramm scinstall zur Eingabe der Anzahl Knoten sowie der Anzahl der privaten Netzwerke aufgefordert, die der IP-Adressbereich unterstützen soll. In der angegebenen Anzahl Knoten soll auch die erwartete Anzahl nicht globaler Zonen enthalten sein, die das private Netzwerk verwenden werden.
Das Dienstprogramm berechnet die Netzmaske für den IP-Mindest-Adressbereich, der die angegebene Anzahl Knoten und private Netzwerke unterstützen soll. Die berechnete Netzmaske unterstützt möglicherweise eine größere Anzahl Knoten als die angegebene, einschließlich nicht globaler Zonen und privater Netzwerke. Außerdem berechnet das Dienstprogramm scinstall eine zweite Netzmaske, die das Minimum für die Unterstützung der doppelten Anzahl Knoten und privater Netzwerke darstellt. Mit dieser zweiten Netzmaske ist der Cluster in der Lage, weiteren Zuwachs aufzunehmen, ohne dass der IP-Adressbereich neu knofiguriert werden muss.
Anschließend fragt Sie das Dienstprogramm, welche Netzmaske ausgewählt werden soll. Sie können eine der berechneten Netzmasken oder angeben oder eine andere bereitstellen. Die angegebene Netzmaske muss mindestens die Anzahl Knoten und private Netzwerke unterstützen, die Sie im Dienstprogramm angegeben haben.
Informationen zum Ändern der privaten Netzwerkadresse und der Netzmaske nach dem Einrichten des Clusters finden Sie unter How to Change the Private Network Address or Address Range of an Existing Cluster in Sun Cluster System Administration Guide for Solaris OS. Um diese Änderungen vorzunehmen, müssen Sie den Cluster herunterfahren.
Das Ändern der privaten IP-Adresse des Clusters ist möglicherweise erforderlich, um zusätzliche Knoten, nicht globale Zonen oder private Netzwerke aufzunehmen.
Wenn Sie statt der Standardadresse eine andere private Netzwerkadresse angeben, muss diese folgende Anforderungen erfüllen:
Adressen- und Netzmaskengröße - Die private Netzwerkadresse darf nicht kleiner als die Netzmaske sein. So können Sie beispielsweise eine private Netzwerkadresse 172.16.10.0 mit einer Netzmaske 255.255.255.0 verwenden. Sie können jedoch keine private Netzwerkadresse 172.16.10.0 mit einer Netzmaske 255.255.255.0 verwenden.
Akzeptable Adressen - Die Adressen müssen in dem Adressblock enthalten sein, den RFC 1918 für die Verwendung in privaten Netzwerken reserviert. Wenden Sie sich an InterNIC, um Kopien der RFCs zu erhalten, oder zeigen Sie die RFCs online unter http://www.rfcs.org an.
Verwendung in mehreren Clustern - Ein und dieselbe private Netzwerkadresse kann in mehreren Clustern verwendet werden. Auf private IP-Netzwerkadressen kann von außerhalb des Clusters aus nicht zugegriffen werden.
IPv6 - Die SunCluster-Software unterstützt keine IPv6-Adressen für das private Interconnect. Das System konfiguriert jedoch IPv6-Adressen auf den Adaptern für das private Netzwerk so, dass sie skalierbare Dienste unterstützen, die IPv6-Adressen verwenden. Allerdings werden diese IPv6-Adressen nicht für die Kommunikation zwischen den Knoten im privaten Netzwerk verwendet.
Siehe Planning Your TCP/IP Network (Tasks), in System Administration Guide: IP Services (Solaris 9 oder Solaris 10) für weitere Informationen zu privaten Netzwerken.
Der private Hostname ist der Name, der für die Verbindung zwischen den Knoten auf der Schnittstelle des privaten Netzwerks verwendet wird. Private Hostnamen werden bei der SunCluster-Konfiguration automatisch erstellt. Diese privaten Hostnamen entsprechen der Benennungskonvention clusternodenodeid -priv, wobei nodeid das Numeral der internen Knoten-ID ist. Bei der SunCluster-Konfiguration wird die Knoten-ID-Nummer automatisch jedem Knoten zugeordnet, wenn er Cluster-Mitglied wird. Nachdem der Cluster konfiguriert ist, können Sie private Hostnamen mithilfe des Dienstprogramms clsetup(1CL) ändern.
Die Erstellung eines privaten Hostnamens für eine nicht globale Zone ist unter Solaris 10 optional. Der private Hostname einer nicht globalen Zone unterliegt keinerlei Namenskonventionen.
Die Cluster-Interconnects stellen Hardware-Bahnen für private Netzwerkkommunikation zwischen Cluster-Knoten bereit. Jeder Interconnect besteht aus einem Kabel, das auf eine der folgenden Arten angeschlossen ist:
Zwischen zwei Transportadaptern,
Zwischen einem Transportadapter und einem Transport-Switch,
Weitere Informationen zu Zweck und Funktion des Cluster-Interconnect finden Sie unter Cluster Interconnect in Sun Cluster Concepts Guide for Solaris OS.
Für einen Ein-Knoten-Cluster müssen Sie keinen Cluster-Interconnect konfigurieren. Wenn Sie jedoch erwarten, einer Ein-Knoten-Cluster-Konfiguration später Knoten hinzuzufügen, möchten Sie den Cluster-Interconnect für zukünftige Verwendung möglicherweise bereits konfigurieren.
Bei der SunCluster-Konfiguration geben Sie Konfigurationsinformationen an für einen oder zwei Cluster-Interconnects.
Die Verwendung von zwei Cluster-Interconnects bietet eine höhere Verfügbarkeit als nur ein Interconnect. Ist die Anzahl verfügbarer Adapter-Ports beschränkt, können Sie VLANs mit Tags verwenden, um denselben Adapter sowohl mit dem privaten als auch dem öffentlichen Netzwerk zu verwenden. Weitere Informationen finden Sie in den Richtlinien für VLAN-Adapter mit Tags in Transportadapter.
Die Verwendung eines einzigen Cluster-Interconnects reduziert die Anzahl an Adapter-Ports, die für den privaten Interconnect verwendet werden, bietet aber weniger Verfügbarkeit. Darüber hinaus würde der Cluster mehr Zeit für die automatische Wiederherstellung aufwenden, falls der einfache private Interconnect ausfällt.
Sie können nach der Einrichtung des Clusters mithilfe des Dienstprogramms clsetup(1CL) weitere Cluster-Interconnects konfigurieren.
Richtlinien zur Cluster-Interconnect-Hardware finden Sie unter Interconnect Requirements and Restrictions in Sun Cluster 3.1 - 3.2 Hardware Administration Manual for Solaris OS. Allgemeine Informationen zum Cluster-Interconnect finden Sie unter Cluster-Interconnect Components in Sun Cluster Overview for Solaris OS und im Sun Cluster Concepts Guide for Solaris OS.
Geben Sie für die Transportadapter, wie beispielsweise Ports im Netzwerkschnittstellen, die Namen der Transportadapter und den Transporttyp an. Wenn die Konfiguration ein Zwei-Knoten-Cluster ist, geben Sie auch an, ob der Interconnect Punkt-zu-Punkt angeschlossen ist (Adapter zu Adapter) oder einen Transport-Switch verwendet.
Beachten Sie folgende Richtlinien und Einschränkungen:
IPv6 - Die SunCluster unterstützt keine IPv6-Verbindungen über die privaten Interconnects.
Zuweisung lokaler MAC-Adressen - Alle Adapter für private Netzwerke müssen Netzwerk-Schnittstellenkarten (NICs) verwenden, die die Zuweisung lokaler MAC-Adressen unterstützen. Link-local IPv6-Adressen, die bei Adaptern für private Netzwerke zur Unterstüzung von IPv6-Adressen im öffentlichen Netzwerk erforderlich sind, werden aus den lokalen MAC-Adressen abgeleitet.
Adapter für VLAN mit Tags – Die SunCluster-Software unterstützt bei Virtual Local Area Networks (VLANs) mit Tags die gemeinsame Nutzung eines Adapters für das private Cluster-Interconnect und das öffentliche Netzwerk. Um einen Adapter für VLAN mit Tags für das Cluster-Interconnect zu konfigurieren, müssen Sie den Adapternamen und die zugehörige VLAN-ID (VID) in einer der folgenden Weisen angeben:
Geben Sie den üblichen Adapternamen an. Hierbei handelt es sich um den Gerätenamen und die Instanznummer des realen Verbindungspunktes (Physical Point of Attachment, PPA). Beispiel: Der Name von Instanz 2 eines Cassini Gigabit Ethernet-Adapters wäre ce2. Wenn das Dienstprogramm scinstall die Frage ausgibt, ob der Adapter Teil eines gemeinsam genutzten virtuellen LAN ist, antworten Sie mit yes und geben Sie die VID-Nummer des Adapters an.
Geben Sie den Adapter anhand seines virtuellen VLAN-Gerätenamens an. Dieser Name setzt sich aus dem Adapternamen und der Nummer der VLAN-Instanz zusammen. Die Nummer der VLAN-Instanz wird abgeleitet aus der Formel (1000*V)+N, wobei V die VID-Nummer und N der PPA ist.
Beispiel: Für VID 73 auf Adapter ce2 wird die VLAN-Instanznummer als (1000*73)+2 berechnet. Daher geben Sie den Adapternamen als ce73002 an, um zu kennzeichnen, dass er Teil eines gemeinsam verwendeten virtuellen LAN ist.
Informationen zum Konfigurieren von VLAN in einem Cluster finden Sie unter Configuring VLANs as Private Interconnect Networks in Sun Cluster 3.1 - 3.2 Hardware Administration Manual for Solaris OS. Allgemeine Informationen zu VLAN finden Sie unter Administering Virtual Local Area Networks in System Administration Guide: IP Services.
SBus SCI-Adapter – Das SBus Scalable Coherent Interface (SCI) wird nicht als Cluster-Interconnect akzeptiert. Die SCI-PCI-Schnittstelle wird jedoch unterstützt.
Logische Netzwerschnittstellen - Logische Netzwerkschnittstellen sind für die Verwendung durch die SunCluster-Software reserviert.
Informationen zu spezifischen Transportadaptern finden Sie in der Online-Dokumentationsfamilie scconf_trans_adap_*(1M).
Wenn Sie Transport-Switches verwenden, wie zum Beispiel einen Netzwerk-Switch, geben Sie für jeden Interconnect einen Transport-Switch-Namen an. Sie können den Standardnamen switchN verwenden, wobei N eine Nummer ist, die bei der Konfiguration automatisch zugewiesen wird. Sie können aber auch einen anderen Namen erstellen.
Geben Sie außerdem den Switch-Port-Namen an oder übernehmen Sie den Standardnamen. Der standardmäßige Port-Name ist mit der internen Knoten-ID-Nummer des Knotens identisch, der das Adapterende des Kabels aufnimmt. Für bestimmte Adaptertypen, wie SCI-PCI, können Sie jedoch den Standardnamen nicht verwenden.
Cluster mit drei oder mehr Knoten müssen Transport-Switches verwenden. Direktverbindungen zwischen Cluster-Knoten werden nur bei Zwei-Knoten-Clustern unterstützt.
Auch wenn der Zwei-Knoten-Cluster direkt angeschlossen ist, können Sie einen Transport-Switch für den Interconnect angeben.
Wenn Sie einen Transport-Switch angeben, können Sie dem Cluster später einfacher einen weiteren Knoten hinzufügen.
SunCluster-Konfigurationen verwenden Quorum-Geräte, um die Daten- und Ressourcenintegrität zu erhalten. Wenn der Cluster vorübergehend die Verbindung mit einem Knoten verliert, verhindert das Quorum-Gerät Amnesiezustände oder Split-Brain-Probleme, wenn der Cluster-Knoten wieder dem Cluster beitreten möchte. Weitere Informationen zu Zweck und Funktion von Quorum-Geräten finden Sie unter Quorum and Quorum Devices in Sun Cluster Concepts Guide for Solaris OS.
Bei der SunCluster-Installation eines Zwei-Knoten-Clusters können Sie das Dienstprogramm scinstall automatisch ein SCSI-Quorum-Gerät oder ein Sun-NAS-Gerät konfigurieren lassen. Dieses Quorum-Gerät wird aus den verfügbaren gemeinsam verwendeten SCSI-Speicherplatten und Sun NAS-Geräten ausgewählt. Das Dienstprogramm scinstall geht davon aus, dass alle verfügbaren gemeinsam genutzten SCSI-Speicherplatten als Quorum-Gerät unterstützt werden.
Wenn Sie einen Quorum-Server oder ein Network Appliance NAS-Gerät als Quorum-Gerät verwenden möchten. konfigurieren Sie es, nachdem die Verarbeitung durch scinstall abgeschlossen ist.
Nach der Installation können Sie mit dem Dienstprogramm clsetup(1CL) auch zusätzliche Quorum-Geräte konfigurieren.
Für einen Ein-Knoten-Cluster müssen Sie keine Quorum-Geräte konfigurieren.
Wenn zu Ihrer Cluster-Konfiguration gemeinsam genutzte Drittanbieter-Speichergeräte gehören, die nicht als Quorum-Geräte verwendet werden können, müssen Sie das Quorum mit dem Dienstprogramm clsetup manuell konfigurieren.
Beachten Sie folgende Punkte, wenn Sie Quorum-Geräte planen.
Minimum – Ein Zwei-Knoten-Cluster muss mindestens ein Quorum-Gerät enthalten, bei dem es sich um eine gemeinsam genutzte SCSI-Platte, ein Quorum-Gerät oder ein Network Appliance NAS-Gerät handeln kann. Bei anderen Topologien sind die Quorum-Geräte optional.
Ungerade-Zahl-Regel – Wenn in einem Zwei-Knoten-Cluster oder in einem direkt mit dem Quorum-Gerät verbundenen Cluster-Paar mehrere Quorum-Geräte konfiguriert werden, müssen Sie eine ungerade Anzahl von Quorum-Geräten konfigurieren. Diese Konfiguration stellt sicher, dass die Quorum-Geräte bei einem Ausfall völlig unabhängige Bahnen haben.
Verteilung von Quorum-Stimmen - Stellen Sie für eine weitgehende Verfügbarkeit des Clusters sicher, dass die Gesamtanzahl an von Quorum-Geräten gelieferten Stimmen unter der Gesamtanzahl der Stimmen liegt, die von Knoten geliefert wurden. Andernfalls können die Knoten keinen Cluster bilden, wenn alle Quorum-Geräte nicht verfügbar sind, und zwar auch dann nicht, wenn sämtliche Knoten funktionsfähig sind.
Verbindung – Sie müssen ein Quorum-Gerät mit mindestens zwei Knoten verbinden.
SCSI-Fencing-Protokoll – Wenn ein SCSI-Quorum-Gerät konfiguriert wird, wird dessen SCSI-Protokoll in einem Zwei-Knoten-Cluster automatisch auf SCSI-2 und in einem Cluster mit drei oder mehr Knoten auf SCSI-3 eingestellt. Nachdem ein Gerät als Quorum-Gerät konfiguriert wurde, können Sie sein SCSI-Protokoll nicht ändern.
Replizierte Geräte – Die SunCluster-Software unterstützt keine replizierten Geräte als Quorum-Geräte.
ZFS-Speicherpools - Fügen Sie einem ZFS-Speicherpool kein konfiguriertes Quorum-Gerät hinzu. Wenn ein konfiguriertes Quorum-Gerät einem ZFS-Speicherpool hinzugefügt wird, wird die Platte als EFI-Platte neu gekennzeichnet, und die Quorum-Konfigurations-Informationen gehen verloren. Die Platte kann dann keine Quorum-Stimme mehr an den Cluster abgeben.
Sobald sich eine Platte in einem Speicherpool befindet, können Sie diese als Quorum-Gerät konfigurieren. Sie können auch die Konfiguration des Quorum-Geräts aufheben, es dem Speicherpool hinzufügen und anschließend als Quorum-Gerät neu konfigurieren.
Weitere Informationen zu Quorum-Geräten finden Sie unter Quorum and Quorum Devices in Sun Cluster Concepts Guide for Solaris OS und unter Quorum Devices in Sun Cluster Overview for Solaris OS.
Dieser Abschnitt enthält folgende Richtlinien zum Planen von globalen Geräten und Cluster-Dateisystemen:
Informationen zu Zweck und Funktion von globalen Geräten finden Sie unter Global Devices, Local Devices, and Device Groups in Sun Cluster Overview for Solaris OS und Global Devices in Sun Cluster Concepts Guide for Solaris OS.
Die SunCluster-Software stellt keine besonderen Anforderungen an das Platten-Layout oder die Dateisystemgröße. Beachten Sie bei der Planung Ihres Layouts für globale Geräte die folgenden Punkte.
Spiegeln – Sie müssen alle globalen Geräte spiegeln, damit das globale Gerät als hoch verfügbar betrachtet wird. Sie müssen keine Softwarespiegelung verwenden, wenn das Speichergerät über Hardware-RAID sowie redundante Pfade zur Platte verfügt.
Platten – Erstellen Sie das Layout der Dateisysteme beim Spiegeln so, dass die Dateisysteme Laufwerkgruppen-übergreifend gespiegelt werden.
Verfügbarkeit – Sie müssen ein globales Gerät real an mehrere Knoten im Cluster anschließen, damit es als hoch verfügbar betrachtet wird. Ein globales Gerät mit mehreren realen Anschlüssen kann den Ausfall eines Knotens verkraften. Ein globales Gerät mit nur einem realen Anschluss wird unterstützt, doch auf das globale Gerät kann von anderen Knoten nicht zugegriffen werden, wenn der Knoten mit dem Anschluss ausgefallen ist.
Auslagerungsgeräte - Erstellen Sie auf einem globalen Gerät keine Auslagerungsdateien.
Nicht globale Zonen - Globale Geräte sind über eine nicht globale Zone nicht direkt zugänglich. Lediglich Daten des Cluster-Dateisystems sind über eine nicht globale Zone zugänglich.
Informationen zu Zweck und Funktion von Gerätegruppen finden Sie unter Global Devices, Local Devices, and Device Groups in Sun Cluster Overview for Solaris OS und Device Groups in Sun Cluster Concepts Guide for Solaris OS.
Nehmen Sie diese Planungsinformationen in das Arbeitsblatt Gerätegruppen-Konfigurationen auf.
Beachten Sie folgende Punkte, wenn Sie Gerätegruppen planen.
Failover – Sie können Multihost-Platten und ordnungsgemäß konfigurierte Datenträger-Manager-Geräte als Failover-Geräte konfigurieren. Die ordnungsgemäße Konfiguration eines Datenträger-Manager-Geräts schließt Multihost-Platten und die richtige Einrichtung des Datenträger-Managers selbst ein. Diese Konfiguration stellt sicher, dass mehrere Knoten das exportierte Gerät hosten können. Sie können keine Bandlaufwerke, CD-ROMs oder DVD-ROMS oder einfach angeschlossene Geräte als Failover-Geräte konfigurieren.
Spiegeln – Sie müssen die Platten spiegeln, um die Daten vor Plattenausfällen zu schützen. Weitere Richtlinien finden Sie unter Richtlinien für das Spiegeln. Anweisungen zum Spiegeln finden Sie unter Konfigurieren der Solaris Volume Manager-Software oder Installieren und Konfigurieren der Software VxVM und in der Datenträger-Manager-Dokumentation.
Speicherbasierte Replikation - Von den Platten in einer Gerätegruppe müssen entweder alle oder keine repliziert werden. In einer Gerätegruppe kann keine Mischung aus replizierten und nicht replizierten Platten verwendet werden.
Informationen zu Zweck und Funktion von Cluster-Dateisystemen finden Sie unter Cluster File Systems in Sun Cluster Overview for Solaris OS und Cluster File Systems in Sun Cluster Concepts Guide for Solaris OS.
Sie können alternativ dazu hochverfügbare lokale Dateisysteme konfigurieren. Hiermit kann eine höhere Leistung bei der Unterstützung eines Datendienstes mit hohem E/A erzielt oder die Verwendung bestimmter Funktionen des Dateisystems ermöglicht werden, die in einem Cluster-Dateisystem nicht unterstützt werden. Weitere Informationen finden Sie unter Enabling Highly Available Local File Systems in Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
Beachten Sie folgende Punkte bei der Planung von Cluster-Dateisystemen.
Kontingente - Kontingente werden auf Cluster-Dateisystemen nicht unterstützt. In weitgehend verfügbaren lokalen Dateisystemen werden Kontingente jedoch unterstützt.
Nicht globale Zonen - Wenn über eine nicht globale Zone auf ein Cluster-Dateisystem zugegriffen werden soll, muss es erst in der globalen Zone eingehängt werden. Anschließend wird das Cluster-Dateisystem mithilfe eines Loopback-Mount in die nicht globale Zone eingehängt. Daher muss das Loopback-Dateisystem (LOFS) in einem Cluster, der nicht globale Zonen enthält, aktiviert werden.
Loopback-Dateisystem (LOFS) - Während der Cluster-Erstellung mit der Solaris 9-Version der SunCluster-Software ist die LOFS-Fähigkeit standardmäßig deaktiviert. Während der Cluster-Erstellung mit der Solaris 10-Version von SunCluster ist das LOFS standardmäßig aktiviert.
Wenn der Cluster die beiden folgenden Bedingungen erfüllt, müssen Sie das LOFS manuell auf allen Cluster-Knoten deaktivieren:
Sun Cluster HA für NFS wird auf einem hoch verfügbaren lokalen Dateisystem konfiguriert.
Der automountd-Dämon wird ausgeführt.
Wenn der Cluster beide Bedingungen erfüllt, müssen Sie das LOFS deaktivieren, um Probleme beim Wechseln oder andere Fehler zu vermeiden. Wenn der Cluster nur eine der beiden Bedingungen erfüllt, können Sie LOFS problemlos aktivieren.
Wenn sowohl LOFS als auch der automountd-Dämon bei Ihnen aktiviert sein müssen, schließen Sie alle Dateien aus der Zuordnung für das automatische Einhängen aus, die zum hoch verfügbaren lokalen Dateisystem gehören, das durch Sun Cluster HA für NFS exportiert wird.
Verarbeiten von Abrechnungsprotokolldateien - Platzieren Sie keine Prozessabrechnungs-Protokolldateien auf einem Cluster-Dateisystem oder einem hoch verfügbaren lokalen Dateisystem. Ein Switchover würde durch Schreibvorgänge in die Protokolldatei blockiert, was wiederum zum Stillstand des Knotens führen würde. Verwenden Sie für die Prozessabrechnungs-Protokolldateien nur ein lokales Dateisystem.
Kommunikationsendpunkte - Das Cluster-Dateisystem unterstützt keine der Dateisystemfunktionen der Solaris-Software, bei denen in den Namensraum des Dateisystems ein Kommunikationsendpunkt platziert wird.
Sie können zwar ein UNIX-Domain-Socket erstellen, dessen Name ein Pfadname zum Cluster-Dateisystem ist. Dieses Socket würde jedoch kein Knoten-Failover überstehen.
Auf keine der FIFOs oder Named Pipes, die Sie in einem Cluster-Dateisystem erstellen, wäre ein globaler Zugriff möglich.
Versuchen Sie daher nicht, den Befehl fattach von einem anderen Knoten aus zu verwenden als dem lokalen Knoten.
Spezielle Gerätedateien - In einem Cluster-Dateisystem werden weder spezielle Blockdateien noch spezielle Zeichendateien unterstützt. Erstellen Sie zur Angabe eines Pfadnamens zu einem Geräteknoten in einer Cluster-Datei im Verzeichnis /dev eine symbolische Verknüpfung zum Gerätenamen. Verwenden Sie hierzu nicht den Befehl mknod.
atime - atime wird in Cluster-Dateisystemen nicht beibehalten.
ctime - Wenn auf eine Datei im Cluster-Dateisystem zugegriffen wird, verzögert sich die Aktualisierung des ctime der Datei möglicherweise.
Installieren von Anwendungen - Wenn sich die Binärdateien einer hochverfügbaren Anwendung in einem Cluster-Dateisystem befinden sollen, warten Sie mit der Installation der Anwendung, bis das Cluster-Dateisystem konfiguriert wurde. Wenn die Anwendung mit dem Java System- installer-Programm installiert wird und die Anwendung von gemeinsamen Komponenten abhängt, installieren Sie diese auf allen Knoten im Cluster, die nicht mit der Anwendung installiert werden.
In diesem Abschnitt sind die Anforderungen und Einschränkungen zu den folgenden Cluster-Dateisystemtypen beschrieben:
Sie können alternativ diese und andere Typen von Dateisystemen als weitgehend verfügbare lokale Dateisysteme konfigurieren. Weitere Informationen finden Sie unter Enabling Highly Available Local File Systems in Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
Legen Sie anhand dieser Richtlinien fest, welche Einhängoptionen bei der Erstellung von Cluster-Dateisystemen verwendet werden sollen.
Weitere Informationen zu UFS-Einhängeoptionen finden Sie in der Online-Dokumentation unter mount_ufs(1M).
Einhängeoption |
Syntax |
Beschreibung |
---|---|---|
global |
Erforderlich |
Mit dieser Option wird das Dateisystem für alle Knoten im Cluster sichtbar. |
log |
Erforderlich |
Diese Option aktiviert die Protokollierung. |
Weitere Informationen zu den VxFS-Einhängoptionen finden Sie in der Online-Dokumentation VxFS mount_vxfs und unter Overview of Administering Cluster File Systems in Sun Cluster System Administration Guide for Solaris OS.
Beachten Sie folgende Punkte bei der Planung der Einhängepunkte für die Cluster-Dateisysteme.
Einhängepunkt-Speicherort – Erstellen Sie Einhängepunkte für die Cluster-Dateisysteme im/global-Verzeichnis, es sei denn, andere Softwareprodukte lassen dies nicht zu. Wenn Sie das /global-Verzeichnis verwenden, können Sie die global verfügbaren Cluster-Dateisysteme einfacher von den lokalen Dateisystemen unterscheiden.
SPARC: VxFS Einhängeanforderung – Wenn Sie VERITAS File System (VxFS) verwenden, sollten Sie ein VxFS-Dateisystem global vom Primärknoten aus ein- und aushängen. Der Primärknoten ist der Knoten, der die Platte unterstützt, auf der sich das VxFS-Dateisystem befindet. Diese Methode stellt sicher, dass das Einhängen und Aushängen erfolgreich sind. Das Einhängen oder Aushängen eines VxFS-Dateisystems von einem Sekundärknoten kann scheitern.
SPARC: VxFS-Funktions-Einschränkungen -
Die folgenden VxFS-Funktionen werden in einem SunCluster 3.2-Cluster-Dateisystem nicht unterstützt. In einem lokalen Dateisystem werden Sie jedoch unterstützt.
Quick I/O
Snapshots
Speicher-Checkpoints
VxFS-spezifische Mount-Optionen:
convosync (O_SYNC konvertieren)
mincache
qlog, delaylog, tmplog
VERITAS Cluster-Datesystem (erfordert die VxVM-Cluster-Funktion & VERITAS Cluster Server)
Cache-Berater können verwendet werden, doch ihre Wirkung kann nur auf dem gegebenen Knoten beobachtet werden.
Alle anderen VxFS-Funktionen, die in einem Cluster-Dateisystem unterstützt werden, werden von SunCluster 3.2 unterstützt. Einzelheiten zu den VxFS-Optionen, die in einer Cluster-Konfiguration unterstützt werden, finden Sie in der VxFS-Dokumentation.
Geschachtelte Einhängepunkte – Im Normalfall sollten Sie die Einhängepunkte für Cluster-Dateisysteme nicht schachteln. Richten Sie zum Beispiel weder auf /global/a noch auf /global/a/b eingehängte Dateisysteme ein. Die Missachtung dieser Regel kann zu Problemen bei der Verfügbarkeit und der Boot-Reihenfolge des Knotens führen. Diese Probleme treten auf, wenn der übergeordnete Einhängepunkt nicht vorhanden ist, wenn das System versucht, einen untergeordneten einzuhängen. Die einzige Ausnahme von dieser Regel ist, wenn die Geräte der beiden Dateisysteme dieselbe reale Knotenkonnektivität besitzen. Ein Beispiel sind unterschiedliche Bereiche derselben Platte.
forcedirectio - SunCluster unterstützt nicht die Ausführung von Binärdateien abseits von Cluster-Dateisystemen, die mit der Einhängoption forcedirectio eingehängt werden.
Nehmen Sie diese Planungsinformationen in das Arbeitsblatt Gerätegruppen-Konfigurationen und das Arbeitsblatt Datenträger-Manager-Konfigurationen auf. Fügen Sie für Solaris Volume Manager auch diese Planungsinformationen zum Arbeitsblatt Datenträger (Solaris Volume Manager) hinzu.
Dieser Abschnitt enthält folgende Richtlinien für die Planung der Datenträgerverwaltung für die Cluster-Konfiguration:
Die SunCluster-Software verwendet Datenträger-Manager-Software, um Platten zu Plattengerätegruppen zu gruppieren, die dann als eine Einheit verwaltet werden können. Die SunCluster-Software unterstützt die Software Solaris Volume Manager und VERITAS Volume Manager (VxVM), die Sie folgendermaßen installieren oder verwenden.
Tabelle 1–4 Unterstützte Verwendung von Datenträger-Manager mit der SunCluster-Software
Datenträger-Manager-Software |
Anforderungen |
---|---|
Solaris Volume Manager |
Sie müssen die Software Solaris Volume Manager auf allen Knoten des Clusters installieren, unabhängig davon, ob Sie auf manchen Knoten VxVM zum Verwalten von Platten verwenden. |
Sie müssen VxVM mit der Cluster-Funktion auf allen Knoten des Clusters installieren und lizenzieren. |
|
VxVM ohne Cluster-Funktion |
Sie müssen VxVM nur auf den Knoten installieren und lizenzieren, die an Speichergeräte angehängt sind, die von VxVM verwaltet werden. |
Wenn Sie beide Datenträger-Manager auf demselben Knoten installieren, müssen Sie die Software Solaris Volume Manager verwenden, um die jeweils lokalen Platten eines Knotens zu verwalten. Lokale Platten beinhalten die Root-Platte. Verwenden Sie VxVM, um alle gemeinsam genutzten Platten zu verwalten. |
Anweisungen zur Installation und Konfiguration der Datenträger-Manager-Software finden Sie in der Datenträger-Manager-Dokumentation und unterKonfigurieren der Solaris Volume Manager-Software oder Installieren und Konfigurieren der Software VxVM . Weitere Informationen zur Verwendung von Datenträger-Management in einer Cluster-Konfiguration finden Sie unter Multihost Devices in Sun Cluster Concepts Guide for Solaris OS und Device Groups in Sun Cluster Concepts Guide for Solaris OS.
Beachten Sie folgende allgemeine Richtlinien, wenn Sie Platten mit Datenträger-Manager-Software konfigurieren:
Software-RAID –Die SunCluster-Software unterstützt nicht Software-RAID 5.
Gespiegelte Multihost-Platten – Sie müssen alle Multihost-Platten Plattenerweiterungseinheiten-übergreifend spiegeln. Informationen zum Spiegeln von Multihost-Platten finden Sie in Richtlinien für das Spiegeln von Multihost-Platten. Sie müssen keine Softwarespiegelung verwenden, wenn das Speichergerät über Hardware-RAID sowie redundante Pfade zum Gerät verfügt.
Gespiegelte Root-Platte – Spiegeln der Root-Platte stellt hohe Verfügbarkeit sicher, ist aber nicht obligatorisch. Richtlinien für die Entscheidung, die Root-Platte zu spiegeln, finden Sie unter Richtlinien für das Spiegeln.
Eindeutige Namen – Möglicherweise haben Sie lokale Solaris Volume Manager oder VxVM Datenträger, die als Geräte verwendet werden, auf denen die /global/.devices/node@nodeid-Dateisysteme eingehängt sind. Wenn dies der Fall ist, muss der Name jedes lokalen Datenträgers, auf dem ein /global/.devices/node@nodeid-Dateisystem eingehängt werden soll, im gesamten Cluster einmalig sein.
Knotenlisten – Um die hohe Verfügbarkeit einer Plattengerätegruppe sicherzustellen, konfigurieren Sie ihre Knotenliste von potenziellen Mastern und ihre Failback-Verfahren identisch mit allen zugeordneten Ressourcengruppen. Oder konfigurieren Sie die Knotenliste der skalierbaren Ressourcengruppe, wenn sie mehr Knoten oder Zonen als ihre zugeordnete Plattengerätegruppe verwendet, als Obergruppe der Knotenliste der Plattengerätegruppe. Informationen zu Knotenlisten finden Sie in den Planungsinformationen für Ressourcengruppen in Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
Multihost-Platten – Sie müssen sämtliche Geräte, die zur Bildung einer Gerätegruppe dienen, mit allen Knoten verbinden, bzw. an die Knoten anschließen, die in der Knotenliste für die entsprechende Gerätegruppe konfiguriert wurden. Die Software Solaris Volume Manager kann automatisch diese Verbindungen prüfen, wenn einem Plattensatz die Geräte hinzugefügt werden. Konfigurierte VxVM-Plattengruppen sind jedoch keiner bestimmten Knotengruppe zugeordnet.
Hot-Spare-Platten – Sie können Hot-Spare-Platten verwenden, um die Verfügbarkeit zu erhöhen. Hot-Spare-Platten sind jedoch nicht erforderlich.
Informationen zu Platten-Layout-Empfehlungen und weitere Einschränkungen finden Sie in der Datenträger-Manager-Dokumentation.
Beachten Sie folgende Punkte bei der Planung von Konfigurationen mit Solaris Volume Manager:
Lokale Datenträgernamen – Der Name jedes lokalen Solaris Volume Manager-Datenträgers, auf dem ein Dateisystem für globale Geräte, /global/.devices/node@nodeid, eingehängt ist, muss eindeutig im gesamten Cluster sein. Der Name darf auch nicht mit dem Geräte-ID-Namen identisch sein.
Doppelverkettungsvermittler – Jeder Plattensatz, der mit genau zwei Plattenverkettungseinheiten konfiguriert und von genau zwei Knoten unterstützt wird, muss für den Plattensatz konfigurierte Solaris Volume Manager-Vermittler aufweisen. Eine Plattenverkettungseinheit besteht aus einem Plattengehäuse, den realen Platten, den Kabeln vom Gehäuse zu dem/n Knoten und den Schnittstellen-Adapterkarten. Beachten Sie folgende Regeln beim Konfigurieren von Doppelverkettungsvermittlern:
Sie müssen jeden Plattensatz mit genau zwei Knoten als Vermittler konfigurieren.
Sie müssen dieselben beiden Knoten für alle Plattensätze verwenden, die Vermittler erfordern. Diese beiden Knoten müssen diese Plattensätze unterstützen.
Vermittler können nicht für Plattensätze konfiguriert werden, welche die Doppelverkettungs- und Zwei-Host-Anforderungen nicht erfüllen.
Weitere Informationen finden Sie in der Online-Dokumentation unter mediator(7D).
/kernel/drv/md.conf Einstellungen – SPARC: Auf den Solaris 9 OS werden Solaris Volume Manager-Datenträger, die von jedem Plattensatz verwendet werden, im Voraus beim Rekonfigurations-Booten erstellt. Diese Rekonfiguration basiert auf den Konfigurationsparametern, die in der Datei /kernel/drv/md.conf vorhanden sind.
In Version Solaris 10 wurde Solaris Volume Manager so verbessert, dass eine dynamische Konfiguration von Datenträgern möglich ist. Sie brauchen nicht mehr die Parameter nmd und md_nsets in der Datei /kernel/drv/md.conf zu bearbeiten. Neue Datenträger werden nach Bedarf neu erstellt.
Sie müssen die Felder nmd und md_nsets wie folgt ändern, damit eine SunCluster-Konfiguration unter Solaris 9 OS unterstützt wird:
Alle Cluster-Knoten müssen identische /kernel/drv/md.conf-Dateien aufweisen, unabhängig von der Anzahl von Plattensätzen, die von jedem Knoten bedient werden. Die Nichtbeachtung dieser Richtlinie kann zu schweren Fehlern von Solaris Volume Manager und Datenverlusten führen.
md_nsets – Das Feld md_nsets definiert die Gesamtanzahl an Plattensätzen, die für ein System erstellt werden können, um den Anforderungen des gesamten Clusters gerecht zu werden. Stellen Sie den Wert von md_nsets auf die im Cluster erwartete Anzahl von Plattensätzen plus einem Plattensatz ein. Die Solaris Volume Manager-Software verwendet den zusätzlichen Plattensatz zum Verwalten der privaten Platten auf dem lokalen Host.
Pro Cluster sind maximal 32 Plattensätze zulässig. Die Zahl lässt 31 Plattensätze für die allgemeine Verwendung plus einem Plattensatz für die Privatplattenverwaltung zu. Der Standardwert von md_nsets beträgt 4.
nmd – Das Feld nmd definiert den höchsten vorhergesagten Wert für den Namen eines Datenträgers, der im Cluster vorhanden sein wird. Beispiel: Wenn der höchste Wert für den Namen eines Datenträgers in den ersten 15 Plattensätzen 10 lautet, der höchste Wert für den Namen eines Datenträgers im 16. Plattensatz jedoch 1000 ist, müssen Sie den Wert von nmd mindestens auf 1000 setzen. Außerdem muss der Wert von nmd groß genug sein, um zu gewährleisten, dass für jeden Geräte-ID-Namen genügend Nummern vorhanden sind. Die Zahl muss auch hoch genug sein, um sicherzustellen, dass jeder Datenträgername im gesamten Cluster einmalig sein kann.
Der höchste zulässige Wert eines Datenträgernamens pro Plattensatz beträgt 8192. Der Standardwert von nmd beträgt 128.
Stellen Sie diese Felder bei der Installation so ein, dass auch zukünftige Erweiterungen des Clusters möglich sind. Das Erhöhen der Werte dieser Felder ist zeitaufwändig, wenn der Cluster schon produktiv ist. Das Ändern der Werte erfordert ein Rekonfigurations-Neubooten jedes Knotens. Das Anheben der Werte im Nachhinein erhöht auch die Möglichkeit von ungeeigneten Speicherplatzzuweisungen im Root-Dateisystem (/), um alle gewünschten Geräte zu erstellen.
Halten Sie gleichzeitig den Wert des Feldes nmdund md_nsets so niedrig wie möglich. Für alle möglichen Geräte sind Speicherstrukturen gemäß den Festlegungen in nmd und md_nsets vorhanden, auch wenn Sie diese Geräte nicht erstellt haben. Setzen Sie für eine optimale Leistung die Werte von nmd und md_nsets nur geringfügig höher als die Anzahl von Datenträgern, die Sie zu verwenden planen.
Siehe System Files and Startup Files in Solaris Volume Manager Administration Guide (Solaris 9 oder Solaris 10) für weitere Informationen zur Datei md.conf.
Beachten Sie folgende Punkte bei der Planung von Konfigurationen mit VERITAS Volume Manager (VxVM).
Zugänglichkeit zu Knoten - Sie müssen alle Plattengruppen des Datenträger-Managers als SunCluster-Gerätegruppen oder nur lokale Plattengruppen konfigurieren. Wenn Sie die Plattengruppe nicht auf eine dieser beiden Arten konfigurieren, sind die Geräte in der Plattengruppe für die Knoten im Cluster nicht zugänglich.
Eine Gerätegruppe ermöglicht, dass ein Sekundärknoten Multihostplatten hostet, wenn der Primärknoten ausfällt.
Eine nur lokale Plattengruppe liegt außerhalb des Steuerbereichs der SunCluster-Software und es kann nur jeweils ein Knoten darauf zugreifen.
Gehäusebasierte Benennung – Wenn Sie die Gehäusebasierte Benennung von Geräten verwenden, sollten Sie sicherstellen, dass einheitliche Gerätenamen für alle Cluster-Knoten verwendet werden, die denselben Speicher gemeinsam nutzen. VxVM koordiniert diese Namen nicht, weshalb der Verwalter sicherstellen muss, dass VxVM denselben Geräten dieselben Namen von unterschiedlichen Knoten zuweist. Die Nichtbeachtung der konsistenten Namenszuweisung beeinträchtigt das korrekte Cluster-Verhalten nicht. Inkonsistente Namen komplizieren jedoch die Cluster-Verwaltung und erhöhen die Wahrscheinlichkeit von Konfigurationsfehlern, die potenziell zu Datenverlusten führen können.
Root-Plattengruppe – Die Erstellung einer Root-Plattengruppe ist optional.
Eine Root-Plattengruppe kann auf folgenden Platten erstellt werden:
Die Root-Platte, die eingekapselt werden muss.
Eine oder mehrere lokale Nicht-Root-Platten, die Sie einkapseln oder initialisieren können.
Eine Kombination von Root- und Nicht-Root-Platten.
Die Root-Plattengruppe muss lokal im Knoten sein.
Einfache Root-Plattengruppen – Einfache Root-Plattengruppen, die in einem einzelnen Bereich der Root-Platte erstellt werden, werden von VxVM in der SunCluster-Software nicht als Plattentypen unterstützt. Es handelt sich hierbei um eine allgemeine VxVM-Software-Einschränkung.
Einkapselung – Platten, die eingekapselt werden sollen, müssen zwei freie Plattenbereichs-Tabelleneinträge aufweisen.
Anzahl von Datenträgern – Schätzen Sie bei der Erstellung der Plattengerätegruppe die maximale Anzahl von Datenträgern, die eine Plattengerätegruppe verwenden kann.
Wenn die Anzahl von Datenträgern weniger als 1000 beträgt, können Sie die Standard-Unternummern verwenden.
Wenn die Anzahl von Datenträgern 1000 oder mehr beträgt, müssen Sie sorgfältig planen, wie die Unternummern den Gerätegruppen-Datenträgern zugewiesen werden. Die Unternummernzuweisungen dürfen sich in keinen Gerätegruppen überlappen.
Dirty Region Logging –> Die Verwendung von Dirty Region Logging (DRL) senkt die Wiederherstellungszeit nach einem Knotenausfall. Die Verwendung von DRL kann die E/A-Leistung senken.
Dynamic Multipathing (DMP) – Die Verwendung von DMP zur bloßen Verwaltung mehrerer E/A-Pfade pro Knoten zum gemeinsam genutzten Speicher wird nicht unterstützt. Die Verwendung von DMP wird nur in folgenden Konfigurationen unterstützt:
Ein einziger E/A-Pfad pro Knoten zum gemeinsam genutzten Cluster-Speicher.
Eine unterstützte Multipathing-Lösung, wie zum Beispiel Sun Traffic Manager, EMC PowerPath oder Hiatchi HDLM, die mehrere E/A-Pfade pro Knoten zum gemeinsam genutzten Cluster-Speicher verwaltet.
Weitere Informationen finden Sie in der Installationsdokumentation von VxVM.
Die Protokollierung ist für UFS- und VxFS-Cluster-Dateisysteme erforderlich. Die SunCluster-Software unterstützt folgende Möglichkeiten der Dateisystem-Protokollierung:
Solaris UFS-Protokollierung – Weitere Informationen finden Sie in der Online-Dokumentation unter mount_ufs(1M).
SPARC: VERITAS File System (VxFS) logging – Weitere Informationen finden Sie in der Online-Dokumentation zu mount_vxfs, die im Lieferumfang der VxFS-Software enthalten ist.
Sowohl Solaris Volume Manager als auch VERITAS Volume Manager unterstützen beide Arten der Dateisystem-Protokollierung.
Dieser Abschnitt bietet folgende Richtlinien für die Planung der Spiegelung der Cluster-Konfiguration:
Das Spiegeln sämtlicher Multihostplatten in einer SunCluster-Konfiguration gewährleistet, dass die Konfiguration Ausfälle einzelner Geräte toleriert. Die SunCluster-Software erfordert, dass Sie alle Multihost-Platten Erweiterungseinheiten-übergreifend spiegeln. Sie müssen keine Softwarespiegelung verwenden, wenn das Speichergerät über Hardware-RAID sowie redundante Pfade zum Gerät verfügt.
Beachten Sie beim Spiegeln von Multihost-Platten folgende Punkte:
Getrennte Plattenerweiterungseinheiten –Jeder Unterspiegel eines gegebenen Spiegels oder Plex sollte sich auf einer anderen Multihost-Erweiterungseinheit befinden.
Festplattenkapazität – Das Spiegeln verdoppelt die erforderliche Festplattenkapazität.
Dreifach-Spiegelung – Solaris Volume Manager-Software und VERITAS Volume Manager (VxVM) unterstützen Dreifach-Spiegelung. Die SunCluster-Software erfordert jedoch nur Zweifach-Spiegelung.
Unterschiedliche Gerätegrößen – Wenn Sie ein Gerät auf ein Gerät mit unterschiedlicher Größe spiegeln, ist die Spiegelungskapazität auf die Kapazität des kleinsten Unterspiegels oder Plex beschränkt.
Weitere Informationen zu Multihost-Platten finden Sie unter Multihost Disk Storage in Sun Cluster Overview for Solaris OS und in Sun Cluster Concepts Guide for Solaris OS.
Nehmen Sie diese Planungsinformationen in das Arbeitsblatt Lokales Dateisystem-Layout auf.
Maximale Verfügbarkeit erzielen Sie, wenn Sie root (/), /usr, /var, /opt und swap auf den lokalen Platten spiegeln. Unter VxVM kapseln Sie die Root-Platte ein und spiegeln die generierten Unterplatten. Für die SunCluster-Software ist es jedoch nicht erforderlich, dass Sie die Root-Platte spiegeln.
Bevor Sie entscheiden, ob Sie die Root-Platte spiegeln, wägen Sie die Risiken, die Komplexität, die Kosten und den Verwaltungsaufwand der verschiedenen Alternativen ab, die die Root-Platte betreffen. Es gibt keine Spiegelungsstrategie, die für alle Konfigurationen gültig ist. Vielleicht ist es hilfreich, die bevorzugte Lösung Ihres lokalen Sun-Servicevertreters zu kennen, wenn Sie entscheiden, ob Sie die Root-Platte spiegeln sollen.
Anweisungen zum Spiegeln der Root-Platte finden Sie in der Datenträger-Manager-Dokumentation und unter Konfigurieren der Solaris Volume Manager-Software oder Installieren und Konfigurieren der Software VxVM.
Beachten Sie folgende Punkte, wenn Sie entscheiden, ob Sie die Root-Platte spiegeln.
Startdatenträger – Sie können den Spiegel als bootfähige Root-Platte konfigurieren. Sie können dann vom Spiegel booten, wenn der Primär-Startdatenträger ausfällt.
Komplexität – Das Spiegeln der Root-Platte macht die Systemverwaltung komplexer. Durch das Spiegeln der Root-Platte wird auch das Booten im Einzelbenutzermodus komplizierter.
Sicherungen – Unabhängig davon, ob Sie die Root-Platte spiegeln oder nicht, sollten Sie regelmäßig Sicherungskopien des Root erstellen. Das Spiegeln allein schützt nicht vor Verwaltungsfehlern. Nur ein Sicherungsplan ermöglicht Ihnen, Dateien wiederherzustellen, die unbeabsichtigt geändert oder gelöscht wurden.
Quorum-Geräte – Verwenden Sie keine als Quorum-Gerät konfigurierte Platte zum Spiegeln einer Root-Platte.
Quorum – Unter der Software Solaris Volume Manager können Sie bei einem Ausfallszenario mit verloren gegangenem Zustands-Datenbankquorum das System erst neu booten, wenn die Wartung erfolgt ist. Informationen zu Zustands-Datenbanken und Zustands-Datenbankreplikate finden Sie in der Dokumentation zu Solaris Volume Manager.
Getrennte Controller – Höchste Verfügbarkeit wird erreicht, wenn die Root-Platte auf einem getrennten Controller gespiegelt wird.
Sekundäre Root-Platte – Bei einer gespiegelten Root-Platte kann die primäre Root-Platte ausfallen und die Arbeit dennoch auf der (gespiegelten) sekundären Root-Platte fortgesetzt werden. Später kann die primäre Root-Platte, zum Beispiel nach einem Kurzschluss oder vorübergehenden E/A-Fehlern, wieder in Betrieb genommen werden. Die nachfolgenden Boot-Vorgänge werden dann auf der primären Root-Platte durchgeführt, die für den eeprom(1M) boot-device-Parameter angegeben ist. In diesem Fall erfolgen keine manuellen Reparaturarbeiten, doch das Laufwerk beginnt ausreichend gut zu arbeiten, um zu starten. Bei der Solaris Volume Manager-Software erfolgt eine Resynchronisierung. Eine Resynchronisierung erfordert einen manuellen Schritt, wenn das Laufwerk wieder in Betrieb genommen wird.
Wenn Änderungen an Dateien der (gespiegelten) sekundären Root-Platte vorgenommen wurden, sind diese beim Starten der primären Root-Platte nicht vorhanden. Diese Bedingung führt zu einem veralteten Unterspiegel. Änderungen an der Datei /etc/system würden zum Beispiel verloren gehen. Bei der Solaris Volume Manager-Software könnten manche Verwaltungsbefehle die Datei /etc/system geändert haben, während die primäre Root-Platte außer Betrieb war.
Das Boot-Programm prüft nicht, ob das System von einem Spiegel oder vom zugrunde liegenden realen Gerät bootet. Wenn die Datenträger geladen sind, wird die Spiegelung durch den Boot-Prozess eine aktive Bahn. Daher ist das System bis zu diesem Punkt für Probleme aufgrund veralteter Unterspiegel anfällig.