Sun Cluster Handbuch Softwareinstallation für Solaris OS

Planen der Datenträgerverwaltung

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 Sun Cluster-Software verwendet Datenträger-Manager-Software, um Platten zu Plattengerätegruppen zu gruppieren, die dann als eine Einheit verwaltet werden können. Die Sun Cluster-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 Sun Cluster-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.
SPARC: VxVM mit der Cluster-Funktion	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.
Sowohl Solaris Volume Manager als auch VxVM	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 der Datenträgerverwaltung 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.

Richtlinien für Datenträger-Manager-Software

Beachten Sie folgende allgemeine Richtlinien, wenn Sie Platten mit Datenträger-Manager-Software konfigurieren:

Software-RAID – Die Sun Cluster-Software unterstützt nicht die 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.
Einmaliger Name – Es können lokale Solaris Volume Manager oder VxVM-Datenträger vorliegen, die als Geräte verwendet werden, bei denen die /global/.devices/node@nodeid-Dateisysteme eingehängt werden. 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 – Zur Gewährleistung der weitgehenden Verfügbarkeit einer Gerätegruppe gleichen Sie deren Knotenlisten der potenziellen Master und die Failback-Richtlinien an etwaige verbundene Ressourcengruppen an. Oder konfigurieren Sie die Knotenliste der Scalable-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 im 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 obligatorisch.

Informationen zu Platten-Layout-Empfehlungen und weitere Einschränkungen finden Sie in der Datenträger-Manager-Dokumentation.

Richtlinien für die Software Solaris Volume Manager

Beachten Sie folgende Punkte bei der Planung von Konfigurationen mit Solaris Volume Manager:

Lokale Datenträgernamen – Der Name aller lokalen Solaris Volume Manager -Datenträger, in die ein Dateisystem für globale Geräte /global/.devices/node@nodeid eingehängt ist, muss im gesamten Cluster einmalig 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: Alle Solaris 9 Solaris Volume Manager-Datenträger, die von jedem Plattensatz verwendet werden, werden im Voraus beim Rekonfigurations-Booten erstellt. Diese Rekonfiguration basiert auf den Konfigurationsparametern, die in der Datei /kernel/drv/md.conf vorhanden sind.

Hinweis –
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 Sun Cluster-Konfiguration unter Solaris 9 unterstützt wird:

Caution –
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 einen 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 lokale 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 (/) zur Erstellung aller gewünschten Geräte.

Halten Sie gleichzeitig den Wert des Feldes nmd und des Feldes 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.

Weitere Informationen zur md.conf-Datei finden Sie unter System Files and Startup Files im Solaris Volume Manager Administration Guide (Solaris 9 oder Solaris 10).

Richtlinien für die Software VERITAS Volume Manager

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 Sun Cluster-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 Multihost-Platten hostet, wenn der Primärknoten ausfällt.
- Eine nur lokale Plattengruppe liegt außerhalb des Steuerbereichs der Sun Cluster-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 Sie einheitliche Gerätenamen für alle Cluster-Knoten verwenden, 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-Plattengruppen – 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 (mit rootdg in einem einzelnen Bereich der Root-Platte erstellt) werden von VxVM in der Sun Cluster-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 Gerätegruppe die maximale Anzahl von Datenträgern, die eine Gerä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 genutzen 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.

Dateisystem-Protokollierung

Die Protokollierung ist für UFS- und VxFS-Cluster-Dateisysteme erforderlich. Diese Anforderung gilt nicht für gemeinsam genutzte QFS-Dateisysteme. Die Sun Cluster-Software unterstützt folgende Möglichkeiten der Dateisystem-Protokollierung:

Solaris UFS-Protokollierung – Weitere Informationen finden Sie auf der Manpage unter mount_ufs(1M).
(nur Solaris 9) SPARC: Solaris Volume Manager Transaktions-Datenträger-Protokollierung – Weitere Informationen finden Sie unter Transactional Volumes (Overview) in Solaris Volume Manager Administration Guide.

Hinweis –
Solaris Volume Manager Transaktions-Datenträger-Protokollierung wurde vom Betriebssystem Solaris 10 entfernt. Solaris UFS-Protokollierung bietet dieselben Funktionen, aber höhere Leistung bei geringeren Systemverwaltungsanforderungen und -aufwand.
SPARC: VERITAS File System -(VxFS)-Protokollierung – Weitere Informationen finden Sie unter mount_vxfs auf der mit der VxFS-Software gelieferten Manpage.

Die folgende Tabelle listet die Dateisystem-Protokollierung auf, die vom jeweiligen Datenträger-Manager unterstützt wird.

Tabelle 1–5 Matrix der unterstützten Dateisystem-Protokollierungen


Datenträger-Manager	Unterstützte Dateisystem-Protokollierung
Solaris Volume Manager	Solaris UFS-Protokollierung SPARC: Solaris Volume Manager Transaktions-Datenträger-Protokollierung (nur Solaris 9) VxFS-Protokollierung
VERITAS Volume Manager	Solaris UFS-Protokollierung VxFS-Protokollierung

SPARC: Beachten Sie unter Solaris 9 die folgenden Punkte bei der Wahl zwischen Solaris UFS-Protokollierung und Solaris Volume Manager Transaktions-Datenträger-Protokollierung für UFS-Cluster-Dateisysteme:

Solaris UFS-Protokollierung speichert das Protokoll immer unter Verwendung von freiem Speicherplatz im UFS-Dateisystem je nach Größe des Dateisystems.
- Bei Dateisystemen unter 1 GB belegt das Protokoll 1 MB.
- Bei 1 GB großen oder größeren Dateisystemen belegt das Protokoll 1 MB pro GB des Dateisystems bis zu maximal 64 MB.
Ein -Translations-Datenträger verwaltet die UFS-Protokollierung. Die Protokollier-Gerätekomponente eines Transaktions-Datenträgers ist ein Datenträger, den Sie spiegeln und streifen können. Sie können eine Protokollgröße bis zu maximal 1 GB erstellen, obwohl 64 MB für die meisten Dateisysteme ausreichend sind. Die Mindestprotokollgröße beträgt 1 MB.

Richtlinien für das Spiegeln

Dieser Abschnitt bietet folgende Richtlinien für die Planung der Spiegelung der Cluster-Konfiguration:

Richtlinien für das Spiegeln von Multihost-Platten

Das Spiegeln sämtlicher Multihost-Platten in einer Sun Cluster-Konfiguration gewährleistet, dass die Konfiguration Ausfälle einzelner Geräte toleriert. Die Sun Cluster-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 Sun Cluster-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 Größe 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 im Sun Cluster Concepts Guide for Solaris OS .

Richtlinien für das Spiegeln der Root-Platte

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 Sun Cluster-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önnen 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.