Sun Cluster Handbuch Softwareinstallation für Solaris OS

Planen der Datenträgerverwaltung

Fügen Sie dem Arbeitsblatt Plattengerätegruppen-Konfigurationen und dem Arbeitsblatt Datenträger-Manager-Konfigurationen diese Planungsinformationen hinzu. Fügen Sie bei Solstice DiskSuite/Solaris Volume Manager auch dem Arbeitsblatt Metageräte (Solstice DiskSuite/Solaris Volume Manager) diese Planungsinformationen 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 Solstice DiskSuite/Solaris Volume Manager und VERITAS Volume Manager (VxVM), die Sie folgendermaßen installieren oder verwenden.

Tabelle 1–5 Unterstützte Verwendung von Datenträger-Managern mit der Sun Cluster-Software


Datenträger-Manager-Software	Anforderungen
Solstice DiskSuite/Solaris Volume Manager	Sie müssen die Software Solstice DiskSuite/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.
SPARC: 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.
SPARC: Solstice DiskSuite/Solaris Volume Manager und VxVM	Wenn Sie beide Datenträger-Manager auf demselben Knoten installieren, müssen Sie die Software Solstice DiskSuite/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 unter Installieren und Konfigurieren der Software Solstice DiskSuite/Solaris Volume Manager oder SPARC: Installieren und Konfigurieren der Software VxVM. Weitere Information zur Datenträgerverwaltung in einer Cluster-Konfiguration finden Sie im 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:

Gespiegelte Multihost-Platten – Sie müssen alle Multihost-Platten Plattenerweiterungseinheiten-übergreifend spiegeln. Richtlinien für das Spiegeln von Multihostplatten finden Sie unter Richtlinien für das Spiegeln von Multihostplatten. Sie müssen keine Softwarespiegelung verwenden, wenn das Speichergerät über Hardware-RAID sowie redundante Pfade zur Platte verfügt.
Gespiegelte Root-Platte – Das 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.
Einmalige Benennung – Sie können über lokale Solstice DiskSuite-Metageräte, lokale Solaris Volume Manager-Datenträger oder VxVM-Datenträger verfügen, die als Geräte verwendet werden, in denen /global/.devices/node@Knoten-ID-Dateisysteme eingehängt sind. Wenn dies der Fall ist, muss der Name jedes lokalen Metageräts oder lokalen Datenträgers 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 Scalable-Ressourcengruppe, wenn sie mehr Knoten als ihre zugeordnete Plattengerätegruppe verwendet, als Obergruppe der Knotenliste der Plattengerätegruppe. Informationen zu Knotenlisten finden in den Planungsinformationen für Ressourcengruppen im Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
Multiport-Platten – Sie müssen alle Platten, die eine Gerätegruppe im Cluster bilden, mit allen Knoten, die in der Knotenliste dieser Gerätegruppe konfiguriert sind, verbinden oder daran anschließen. Die Software Solstice DiskSuite/Solaris Volume Manager kann automatisch diese Verbindungen prüfen, wenn einem Plattensatz die Platten 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.

Richtlinien für die Software Solstice DiskSuite/Solaris Volume Manager

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

Lokale Metageräte- oder Datenträger-Namen – Der Name eines Solstice DiskSuite-Metageräts oder Solaris Volume Manager-Datenträgers 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 Solstice DiskSuite/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 – Alle Solstice DiskSuite-Metageräte oder 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.

Achtung –
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 Solstice DiskSuite/Solaris Volume Manager und Datenverlusten führen.

Sie müssen die Felder nmd und md_nsets wie folgt ändern, damit sie eine Sun Cluster-Konfiguration unterstützen:
- md_nsets – Das md_nsets-Feld definiert die Gesamtanzahl der Plattensätze, die für ein System erstellt werden können, um die Anforderungen des gesamten Clusters zu erfüllen. Stellen Sie den Wert von md_nsets auf die im Cluster erwartete Anzahl von Plattensätzen plus einem Plattensatz ein. Die Solstice DiskSuite/Solaris Volume Manager-Software verwendet den zusätzlichen Plattensatz zum Verwalten der privaten Platten auf dem lokalen Host. Die privaten Platten sind die Metageräte oder Datenträger, die sich nicht im lokalen Plattensatz befinden.
  
  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 die Anzahl von Metageräten oder Datenträgern, die für jeden Plattensatz erstellt werden. Stellen Sie den Wert von nmd auf den erwarteten höchsten Wert eines Metageräte- oder Datenträger-Namens ein, der von einem der Plattensätze im Cluster verwendet wird. Wenn ein Cluster zum Beispiel 10 Metageräte oder Datenträger in den ersten 15 Plattensätzen verwendet, aber 1000 Metageräte oder Datenträger im 16. Plattensatz, stellen Sie den Wert von nmd auf mindestens 1000 ein. Der Wert von nmd muss auch hoch genug sein, um sicherzustellen, dass genug Nummern für jeden Geräte-ID-Namen vorhanden sind. Die Zahl muss auch hoch genug sein, um sicherzustellen, dass jeder lokale Metageräte- oder Datenträgername im gesamten Cluster einmalig sein kann.
  
  Der höchste zulässige Wert eines Metageräte- oder 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 der Felder nmd und 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_nsetsnur geringfügig höher als die Anzahl von Metageräten oder Datenträgern, die Sie zu verwenden planen.

Weitere Informationen zur Datei md.conf finden Sie unter “System and Startup Files” im Solstice DiskSuite 4.2.1 Reference Guide oder “System Files and Startup Files” in Solaris Volume Manager Administration Guide.

SPARC: Richtlinien für die Software VERITAS Volume Manager

Beachten Sie folgende Punkte bei der Planung von Konfigurationen mit VERITAS Volume Manager (VxVM).

Gehäusebasierte Benennung – Die gehäusebasierte Benennung ist eine Funktion, die in der Version 3.2 von VxVM eingeführt wurde. Mit der gehäusebasierten Benennung von Geräten stellen Sie sicher, dass Sie konsistente Gerätenamen auf allen Cluster-Knoten verwenden, die denselben Speicherplatz 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 – Sie müssen eine standardmäßige Root-Plattengruppe auf jedem Knoten erstellen. Die 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.
Einkapselung – Die Platten, die eingekapselt werden sollen, müssen zwei freie Einträge 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 Plattengerätegruppen-Datenträgern zugewiesen werden. Die Unternummernzuweisungen dürfen sich in keinen Plattengerätegruppen überlappen.
Dirty Region Logging – Verwenden 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 allein für die 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.

Dateisystem-Protokollierung

Protokollierung ist für Cluster-Dateisysteme erforderlich. Die Sun Cluster-Software unterstützt folgende Möglichkeiten der Dateisystem-Protokollierung:

Solaris UFS logging – Weitere Informationen finden Sie in der Online-Dokumentation unter mount_ufs(1M).
Solstice DiskSuite trans-metadevice logging oder Solaris Volume Manager transactional-volume logging – Weitere Informationen finden Sie unter “Creating DiskSuite Objects” in Solstice DiskSuite 4.2.1 User's Guide oder “Transactional Volumes (Overview)” in Solaris Volume Manager Administration Guide.
SPARC: VERITAS File System (VxFS), Protokollierung – Weitere Informationen finden Sie in der Online-Dokumentation zu mount_vxfs, die mit der VxFS-Software mitgeliefert wird.

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

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


Datenträger-Manager	Unterstützte Dateisystem-Protokollierung
Solstice DiskSuite/Solaris Volume Manager	Solaris UFS logging, Solstice DiskSuite trans-metadevice logging oder Solaris Volume Manager transactional-volume logging, VxFS-Protokollierung
SPARC: VERITAS Volume Manager	Solaris UFS logging, VxFS-Protokollierung

Beachten Sie folgende Punkte, wenn Sie zwischen Solaris UFS logging und Solstice DiskSuite trans-metadevice logging/Solaris Volume Manager transactional-volume logging wählen:

Es ist geplant, Solaris Volume Manager transactional-volume logging (früher Solstice DiskSuite trans-metadevice logging) bei einer kommenden Solaris-Version aus der Solaris-Betriebsumgebung zu entfernen. Solaris UFS logging bietet dieselben Funktionen, aber höhere Leistung bei geringeren Systemverwaltungsanforderungen und -aufwand.
Solaris UFS-Protokollgröße – Solaris UFS logging 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.
Protokoll-Metagerät/Transaktions-Datenträger – Ein Solstice DiskSuite-Transaktions-Metagerät oder ein Solaris Volume Manager-Transaktions-Datenträger unterstützt UFS-Protokollierung. Die Protokollierungs-Gerätekomponente eines Transaktions-Metageräts oder Transaktions-Datenträgers ist ein Metagerät oder ein Datenträger, das Spiegeln und Striping zulässt. 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 Multihostplatten

Wenn Sie alle Multihostplatten in einer Sun Cluster-Konfiguration spiegeln, kann die Konfiguration Ausfälle von einzelnen Platten tolerieren. Die Sun Cluster-Software erfordert, dass Sie alle Multihostplatten Plattenerweiterungseinheiten-übergreifend spiegeln. Sie müssen keine Softwarespiegelung verwenden, wenn das Speichergerät über Hardware-RAID sowie redundante Pfade zur Platte verfügt.

Beachten Sie folgende Punkte, wenn Sie Multihostplatten spiegeln.

Getrennte Plattenerweiterungseinheiten – Jeder Unterspiegel eines gegebenen Spiegels oder Plex sollte sich auf einer anderen Multihostplatten-Erweiterungseinheit befinden.
Festplattenkapazität – Das Spiegeln verdoppelt die erforderliche Festplattenkapazität.
Dreifach-Spiegelung – Solstice DiskSuite/Solaris Volume Manager-Software und VERITAS Volume Manager (VxVM) unterstützen Dreifach-Spiegelung. Die Sun Cluster-Software erfordert jedoch nur Zweifach-Spiegelung.
Anzahl von Metageräten oder Datenträgern – Unter der Software Solstice DiskSuite/Solaris Volume Manager bestehen die Spiegel aus anderen Solstice DiskSuite-Metageräten oder Solaris Volume Manager-Datenträgern wie Verkettungen oder Stripes. Große Konfigurationen können eine große Anzahl von Metageräten oder Datenträgern umfassen.
Unterschiedliche Plattengrößen – Wenn Sie eine Platte auf einer Platte mit unterschiedlicher Kapazität 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 im Sun Cluster Concepts Guide for Solaris OS.

Richtlinien für das Spiegeln der Root-Platte

Fügen Sie dem Arbeitsblatt Lokales Dateisystem-Layout diese Planungsinformationen hinzu.

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 Installieren und Konfigurieren der Software Solstice DiskSuite/Solaris Volume Manager oder SPARC: 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 Solstice DiskSuite/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 Solstice DiskSuite/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 Solstice DiskSuite/Solaris Volume Manager 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 Solstice DiskSuite/Solaris Volume Manager 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 Metageräte oder 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.