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

• Richtlinien für das Spiegeln der Root-Platte

Richtlinien für das Spiegeln von Multihost-Platten

Das Spiegeln sämtlicher Multihosplatten 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 – Solstice DiskSuite oder 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 Kapazität des kleinsten Unterspiegels oder Plex beschränkt.

Weitere Informationen zu Multhost-Platten finden Sie unter Multihost-Plattenspeicher in Sun Cluster Überblick für das Betriebssystem Solaris und Sun Cluster Konzepthandbuch für 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 Installieren und Konfigurieren der Software Solstice DiskSuite oder 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 oder 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 oder 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 Solstice DiskSuite oder 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 Solstice DiskSuite oder 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 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.