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

• Richtlinien für das Spiegeln der Root-Platte

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.