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.