Dieses Kapitel enthält Richtlinien für die Konfiguration der Datenreplikation zwischen Clustern mithilfe der Sun StorEdge Availability Suite 3.1-Software.
Des Weiteren wird anhand eines Beispiels dargestellt, wie die Datenreplikation für eine NFS-Anwendung mithilfe der Sun StorEdge Availability Suite 3.1-Software konfiguriert wurde. In diesem Beispiel wird eine spezifische Cluster-Konfiguration verwendet. Zudem werden detaillierte Informationen zur Durchführung einzelner Aufgaben bereitgestellt. Für andere Anwendungen oder andere Cluster-Konfigurationen erforderliche Schritte werden jedoch nicht aufgeführt.
Dieses Kapitel enthält die folgenden Abschnitte:
In diesem Kapitel werden folgende Verfahren beschrieben:
So konfigurieren Sie eine Plattengerätegruppe auf dem primären Cluster,
So konfigurieren Sie eine Plattengerätegruppe im sekundären Cluster,
So konfigurieren Sie das Dateisystem im primären Cluster für die NFS-Anwendung,
So konfigurieren Sie das Dateisystem im sekundären Cluster für die NFS-Anwendung,
So erstellen Sie eine Replikations-Ressourcengruppe auf dem primären Cluster,
So erstellen Sie eine Replikations-Ressourcengruppe im sekundären Cluster,
So erstellen Sie eine Anwendungs-Ressourcengruppe im primären Cluster,
So erstellen Sie eine Anwendungs-Ressourcengruppe im sekundären Cluster,
So überprüfen Sie die Richtigkeit der Replikationskonfiguration,
So konfigurieren Sie die Anwendung zum Lesen und Schreiben auf dem sekundären Datenträger.
In diesem Abschnitt wird das Konzept der Ausfalltoleranz eingeführt. Daneben werden die von der Sun StorEdge Availability Suite 3.1-Software verwendeten Datenreplikationsmethoden beschrieben.
Unter Ausfalltoleranz wird die Fähigkeit eines Systems verstanden, eine Anwendung bei Ausfall des Primär-Clusters auf einem anderen Cluster wiederherzustellen. Grundlage der Ausfalltoleranz sind Datenreplikation und Failover.
Unter Datenreplikation wird das Kopieren von Daten von einem primären Cluster auf einen Sicherungs- oder sekundären Cluster verstanden. Dank der Datenreplikation verfügt der sekundäre Cluster über eine aktuelle Kopie der Daten des primären Clusters. Der sekundäre Cluster kann sich vom primären Cluster weit entfernt befinden.
Unter Failover wird die automatische Verschiebung einer Ressourcen- oder Gerätegruppe von einem primären Cluster auf einen sekundären Cluster verstanden. Bei einem Ausfall des primären Clusters stehen die Daten sofort auf dem sekundären Cluster zur Verfügung.
In diesem Abschnitt werden die von der Sun StorEdge Availability Suite 3.1-Software verwendeten Replikationsmethoden beschrieben, die Replikation mit remotem Spiegel und die Schnappschuss-Kopie. Diese Software verwendet die Befehle sndradm(1RPC) und iiadm(1II) zur Datenreplikation. Weitere Informationen zu diesen Befehlen finden Sie im Sun Cluster 3.0 and Sun StorEdge Software Integration Guide.
Die Replikation mit remotem Spiegel wird in Abbildung 6–1 veranschaulicht. Daten vom Master-Datenträger der primären Platte werden auf den Master-Datenträger der sekundären Platte über eine TCP/IP-Verbindung repliziert. Ein remotes Spiegel-Bitmap verfolgt die Unterschiede zwischen dem Master-Datenträger auf der primären Platte und dem Master-Datenträger auf der sekundären Platte.
Die Replikation mit remotem Spiegel kann synchron in Echtzeit oder asynchron erfolgen. Jeder Datenträgersatz im Cluster kann einzeln für synchrone oder asynchrone Replikation konfiguriert werden.
Bei der synchronen Datenreplikation wird ein Schreibvorgang erst nach der Aktualisierung des remoten Datenträgers bestätigt.
Bei der asynchronen Datenreplikation wird ein Schreibvorgang vor der Aktualisierung des remoten Datenträgers bestätigt. Die asynchrone Datenreplikation verleiht höhere Flexibilität im Falle großer Distanzen und geringer Bandbreite.
Die Schnappschuss-Kopie ist in Abbildung 6–2 abgebildet. Die Daten auf dem Master-Datenträger jeder Platte wird auf den Schattendatenträger derselben Platte kopiert. Das punktuelle Bitmap verfolgt die Unterschiede zwischen dem Master-Datenträger und dem Schattendatenträger. Das punktuelle Bitmap wird beim Kopieren der Daten auf den Schattendatenträger zurückgesetzt.
Die folgende Abbildung zeigt die Verwendung der Replikation mit remotem Spiegel und mit Schnappschuss-Kopie in Beispielkonfiguration.
Dieser Abschnitt enthält Richtlinien zum Konfigurieren der Datenreplikation zwischen Clustern. Der Abschnitt enthält auch Tipps zum Konfigurieren der Replikations- und Anwendungs-Ressourcengruppen. Verwenden Sie diese Richtlinien beim Konfigurieren der Datenreplikation für Ihren Cluster.
In diesem Abschnitt werden folgende Themen behandelt:
Konfigurieren von Ressourcengruppen für eine Failover-Anwendung
Konfigurieren von Ressourcengruppen für eine Scalable-Anwendung
Replikations-Ressourcengruppen stellen die Gerätegruppe unter die Steuerung der Sun StorEdge Availability Suite 3.1-Software mit der Ressource logischer Hostname. Eine Replikations-Ressourcengruppe muss folgende Merkmale aufweisen:
Sie muss eine Failover-Ressourcengruppe sein
Eine Failover-Ressource kann nur auf einem Knoten ausgeführt werden. Bei einem Failover ist die Failover-Ressource am Failover beteiligt.
Sie muss eine Ressource logischer Hostname aufweisen
Der logische Hostname muss vom primären Cluster gehostet werden. Nach einem Failover oder einem Switchover muss der logische Hostname vom sekundären Cluster gehostet werden. Das Domain Name System (DNS) wird zum Zuordnen des logischen Hostnamens zu einem Cluster verwendet.
Sie muss eine HAStoragePlus-Ressource aufweisen
Die HAStoragePlus-Ressource erzwingt im Falle eines Failover oder Switchover der Replikations-Ressourcengruppe das Switchover der Gerätegruppe. Die Sun Cluster-Software erzwingt bei einem Switchover der Gerätegruppe auch das Switchover der Replikations-Ressourcengruppe. Auf diese Weise sind die Replikations-Ressourcengruppe und die Gerätegruppe immer demselben Knoten zugewiesen bzw. werden immer von demselben Knoten unterstützt.
Die folgenden Erweiterungseigenschaften müssen in der HAStoragePlus-Ressource definiert sein:
GlobalDevicePaths. Diese Erweiterungseigenschaft definiert die Gerätegruppe, zu der ein Datenträger gehört.
AffinityOn property = True. Diese Erweiterungseigenschaft veranlasst bei einem Switchover oder Failover der Replikations-Ressourcengruppe das Switchover oder Failover der Gerätegruppe. Diese Funktion wird als Affinitäts-Switchover bezeichnet.
Weitere Informationen zu HAStoragePlus finden Sie in der Online-Dokumentation unter SUNW.HAStoragePlus(5).
Sie muss nach der Gerätegruppe benannt werden, der sie zugeordnet ist, gefolgt von -stor-rg
Beispiel: Gerätegruppe-stor-rg.
Sowohl der primäre als auch der sekundäre Cluster müssen online sein
Damit eine Anwendung hoch verfügbar ist, muss sie als Ressource in einer Anwendungs-Ressourcengruppe verwaltet werden. Eine Anwendungs-Ressourcengruppe kann für eine Failover-Anwendung oder eine Scalable-Anwendung konfiguriert werden.
Anwendungs-Ressourcen und Anwendungs-Ressourcengruppen, die auf dem primären Cluster konfiguriert sind, müssen auch auf dem sekundären Cluster konfiguriert sein. Auch die Daten, auf die die Anwendungsressource zugreift, müssen auf den sekundären Cluster repliziert werden.
Dieser Abschnitt enthält Richtlinien zum Konfigurieren der folgenden Anwendungs-Ressourcengruppen:
Konfigurieren von Ressourcengruppen für eine Failover-Anwendung
Konfigurieren von Ressourcengruppen für eine Scalable-Anwendung
In einer Failover-Anwendung wird eine Anwendung auf einem Knoten ausgeführt. Fällt dieser Knoten aus, wird die Anwendung in einem Failover auf einen anderen Knoten in demselben Cluster verschoben. Eine Ressourcengruppe muss für eine Failover-Anwendung folgende Merkmale aufweisen:
Mit einer HAStoragePlus-Ressource muss sie bei einem Switchover oder Failover der Anwendungs-Ressourcengruppe das Switchover der Gerätegruppe erzwingen.
Die Gerätegruppe wird der Replikations-Ressourcengruppe und der Anwendungs-Ressourcengruppe zugeordnet. Daher erzwingt das Switchover der Anwendungs-Ressourcengruppe das Switchover der Gerätegruppe und der Replikations-Ressourcengruppe. Die Anwendungs-Ressourcengruppe, die Replikations-Ressourcengruppe und die Gerätegruppe werden von demselben Knoten unterstützt.
Beachten Sie jedoch, dass ein Switchover oder Failover der Gerätegruppe oder der Replikations-Ressourcengruppe kein Switchover oder Failover der Anwendungs-Ressourcengruppe erzwingt.
Wenn die Anwendungsdaten global eingehängt sind, ist das Vorhandensein einer HAStoragePlus-Ressource in der Anwendungs-Ressourcengruppe ratsam, aber nicht obligatorisch.
Wenn die Anwendungsdaten lokal eingehängt sind, ist das Vorhandensein einer HAStoragePlus-Ressource in der Anwendungs-Ressourcengruppe obligatorisch.
Ohne eine HAStoragePlus-Ressource löst das Switchover oder Failover der Anwendungs-Ressourcengruppe kein Switchover oder Failover der Replikations-Ressourcengruppe und Gerätegruppe aus. Nach einem Switchover oder Failover werden die Anwendungs-Ressourcengruppe, die Replikations-Ressourcengruppe und die Gerätegruppe nicht von demselben Knoten unterstützt.
Weitere Informationen zu HAStoragePlus finden Sie in der Online-Dokumentation unter SUNW.HAStoragePlus(5).
Sie muss auf dem primären Cluster online und auf dem sekundären Cluster offline sein
Die Anwendungs-Ressourcengruppe muss auf dem sekundären Cluster online gebracht werden, wenn der sekundäre Cluster zum primären Cluster wird.
Die folgende Abbildung zeigt die Konfiguration einer Anwendungs-Ressourcengruppe und einer Replikations-Ressourcengruppe in einer Failover-Anwendung.
In einer Scalable-Anwendung läuft eine Anwendung auf mehreren Knoten, um einen einzigen logischen Dienst zu erstellen. Wenn ein Knoten mit einer Scalable-Anwendung ausfällt, tritt kein Failover ein. Die Anwendung wird auf den anderen Knoten weiterhin ausgeführt.
Wenn eine Scalable-Anwendung als eine Ressource in einer Anwendungs-Ressourcengruppe verwaltet wird, muss die Anwendungs-Ressourcengruppe der Gerätegruppe nicht zugeordnet werden. Daher ist auch die Erstellung einer HAStoragePlus-Ressource für die Anwendungs-Ressourcengruppe nicht notwendig.
Eine Ressourcengruppe muss für eine Scalable-Anwendung folgende Merkmale aufweisen:
Sie muss eine Abhängigkeit von der gemeinsam genutzten Adresse aufweisen
Die gemeinsam genutzte Adresse wird von den Knoten verwendet, auf denen die Scalable-Anwendung zum Verteilen eingehender Daten ausgeführt wird.
Sie muss auf dem primären Cluster online und auf dem sekundären Cluster offline sein
Die folgende Abbildung zeigt die Konfiguration der Ressourcengruppen in einer Scalable-Anwendung.
Wenn der primäre Cluster ausfällt, muss die Anwendung so schnell wie möglich auf den sekundären Cluster umgeschaltet werden. Damit der sekundäre Cluster zum primären Cluster wird, muss das DNS aktualisiert werden. Daneben muss der sekundäre Datenträger in dem Einhängepunktverzeichnis für das Anwendungs-Dateisystem eingehängt werden.
Das DNS ordnet einem Client den logischen Hostnamen einer Anwendung zu. Nach einem Failover oder Switchover muss die DNS-Zuordnung zum primären Cluster entfernt und eine DNS-Zuordnung zum sekundären Cluster erstellt werden. Die folgende Abbildung zeigt, wie das DNS einem Cluster einen Client zuordnet.
Aktualisieren Sie das DNS mit dem nsupdate-Befehl. Informationen finden Sie in der Online-Dokumentation unter nsupdate(1M). Ein Beispiel für den Umgang mit einem Failover oder einem Switchover finden Sie unter Beispiel für den Umgang mit einem Failover oder Switchover.
Nach einer Wartung kann der primäre Cluster wieder online gebracht werden. Führen Sie folgende Schritte durch, um zum originalen primären Cluster zurückzuschalten:
Synchronisieren Sie den primären Cluster mit dem sekundären Cluster, um sicherzustellen, dass der primäre Datenträger aktuell ist.
Aktualisieren Sie das DNS, so dass die Clients auf die Anwendung auf dem primären Cluster zugreifen können.
Hängen Sie den primären Datenträger im Einhängepunktverzeichnis für das Anwendungs-Dateisystem ein.
Anhand eines Beispiels wird in diesem Abschnitt das Konfigurieren der Datenreplikation für eine NFS-Anwendung mithilfe der Sun StorEdge Availability Suite 3.1-Software Schritt für Schritt erläutert.
Abbildung 6–7 zeigt die Cluster-Konfiguration der Beispielkonfiguration. Der sekundäre Cluster in der Beispielkonfiguration enthält einen Knoten. Es können jedoch auch andere Cluster-Konfigurationen verwendet werden.
Tabelle 6–1 fasst die für die Beispielkonfiguration erforderliche Hardware und Software zusammen. Die Betriebsumgebung, Sun Cluster-Software und Datenträger-Manager-Software muss vor der Installation der Sun StorEdge Availability Suite 3.1-Software undder Korrekturversionen auf den Cluster-Knoten installiert werden.
Tabelle 6–1 Erforderliche Hardware und Software
Hardware oder Software |
Anforderung |
---|---|
Knoten-Hardware |
Die Sun StorEdge Availability Suite 3.1-Software wird auf allen Servern unter der Solaris-Betriebsumgebung unterstützt. Informationen zur erforderlichen Hardware finden Sie im Sun Cluster 3.x Hardware Administration Manual for Solaris OS |
Festplattenkapazität |
Ca. 11 MB. |
Die Betriebssystemumgebung |
Die Solaris 8- oder Solaris 9-Versionen, die von der Sun Cluster-Software unterstützt werden. Alle Knoten müssen dieselbe Betriebsumgebungsversion verwenden. Informationen zur Installation finden Sie unter Installieren der Software. |
Sun Cluster-Software |
Sun Cluster 3.1 4/04-Software. Informationen zur Installation finden Sie unter Kapitel 2 und So installieren Sie die Sun Cluster-Software in einem Ein-Knoten-Cluster. |
Datenträger-Manager-Software |
Solstice DiskSuite/Solaris Volume Manager oder VERITAS Volume Manager (VxVM). Alle Knoten müssen dieselbe Version der Datenträger-Manager-Software verwenden. Informationen zur Installation finden Sie unter Installieren und Konfigurieren der Software Solstice DiskSuite/Solaris Volume Manager und SPARC: Installieren und Konfigurieren der Software VxVM. |
Sun StorEdge Availability Suite 3.1-Software |
Informationen zur Software-Installation finden Sie im Sun StorEdge Availability Suite 3.1 Point-in-Time Copy Software Installation Guide und im Sun StorEdge Availability Suite 3.1 Remote Mirror Software Installation Guide. |
Korrekturversionen der Sun StorEdge Availability Suite 3.1-Software |
Informationen zu den neuesten Korrekturversionen finden Sie unter http://sunsolve.sun.com. |
In diesem Kapitel wird beschrieben, wie Plattengeräte- und Ressourcengruppen für eine NFS-Anwendung konfiguriert werden. In der folgenden Tabelle werden die Namen der Gruppen und Ressourcen genannt, die für die Beispielkonfiguration erstellt wurden.
Tabelle 6–2 Übersicht über die Gruppen und Ressourcen der Beispielkonfiguration
Gruppe oder Ressource |
Name |
Beschreibung |
---|---|---|
Plattengerätegruppe |
Gerätegruppe |
Die Plattengerätegruppe. |
Replikations-Ressourcengruppe und Ressourcen |
Gerätegruppe-stor-rg |
Die Replikations-Ressourcengruppe. |
lHost-RepRG-Prim, lHost-RepRG-Sek |
Die logischen Hostnamen für die Replikations-Ressourcengruppe auf dem primären und dem sekundären Cluster. |
|
Gerätegruppenspeicher |
Die HAStoragePlus-Ressource für die Replikations-Ressourcengruppe. |
|
Anwendungs-Ressourcengruppe und Ressourcen |
NFS-RG |
Die Anwendungs-Ressourcengruppe. |
lHost-NFSRG-Prim, lHost-NFSRG-Sek |
Die logischen Hostnamen für die Anwendungs-Ressourcengruppe auf dem primären und dem sekundären Cluster. |
|
NFS-GG-RS |
Die HAStoragePlus-Ressource für die Anwendung. |
|
NFS-RS |
Die NFS-Ressource. |
Mit Ausnahme von Gerätegruppe-stor-rg handelt es sich bei den Gruppen- und Ressourcennamen um Beispielnamen, die nach Bedarf geändert werden können. Die Replikations-Ressourcengruppe muss einen Namen wie Gerätegruppe-stor-rg aufweisen.
In diesem Abschnitt wird das Konfigurieren einer Plattengerätegruppe auf dem primären und dem sekundären Cluster beschrieben. In dieser Beispielkonfiguration wird die VxVM-Software verwendet. Informationen zur Solstice DiskSuite/Solaris Volume Manager-Software finden Sie unter Kapitel 3.
Die folgende Abbildung zeigt die in der Plattengerätegruppe erstellten Datenträger.
Die in diesem Abschnitt definierten Datenträger müssen keine privaten Bereiche für die Festplattenbezeichnung aufweisen, wie zum Beispiel Zylinder 0. Diese Einschränkung wird automatisch von der VxVM-Software verwaltet.
Erstellen Sie eine Plattengruppe mit vier Datenträgern (Datenträger 1 bis Datenträger 4).
Informationen zum Konfigurieren einer Plattengruppe mithilfe der VxVMSoftware finden Sie unter Kapitel 4.
Greifen Sie als Superbenutzer auf nodeA zu.
nodeA ist der erste Knoten des primären Clusters. In Abbildung 6–7 können Sie sich nochmals den Knoten in Erinnerung rufen, um den es sich bei nodeA handelt.
Konfigurieren Sie die Plattengruppe, um eine Plattengerätegruppe zu erstellen.
KnotenA# /usr/cluster/bin/scconf -a -D type=vxvm,name=Gerätegruppe \ ,nodelist=KnotenA:KnotenB |
Die Plattengerätegruppe wird als Gerätegruppe bezeichnet.
Starten Sie die Plattengerätegruppe.
KnotenA# /usr/cluster/bin/scswitch -z -D Gerätegruppe -h KnotenA |
Synchronisieren Sie die Plattengerätegruppe mit der Sun Cluster-Software.
KnotenA# /usr/cluster/bin/scconf -c -D name=Gerätegruppe,sync |
Erstellen Sie das Dateisystem für die Plattengerätegruppe.
KnotenA# /usr/sbin/newfs /dev/vx/rdsk/Gerätegruppe/vol01 < /dev/null KnotenA# /usr/sbin/newfs /dev/vx/rdsk/Gerätegruppe/vol02 < /dev/null KnotenA# /usr/sbin/newfs /dev/vx/rdsk/Gerätegruppe/vol03 < /dev/null KnotenA# /usr/sbin/newfs /dev/vx/rdsk/Gerätegruppe/vol04 < /dev/null |
Aktivieren Sie den Remote-Zugriff zwischen den Knoten im primären und sekundären Cluster, indem Sie der /.rhosts-Datei auf dem nodeA und nodeB folgende Entitäten hinzufügen.
nodeC + + root |
Führen Sie das Verfahren in So konfigurieren Sie eine Plattengerätegruppe auf dem primären Cluster mit folgenden Ausnahmen aus:
Ersetzen Sie nodeA durch nodeC.
Verwenden Sie nicht nodeB.
Nehmen Sie in Schritt 3 nodeC nur in die Knotenliste auf. Beispiel:
KnotenC# /usr/cluster/bin/scconf -a -D type=vxvm,name=Gerätegruppe \ ,nodelist=KnotenC |
Fügen Sie in Schritt 7 der /.rhosts-Datei nur auf nodeC die folgenden Entitäten hinzu:
nodeA + nodeB + + root |
In diesem Abschnitt wird beschrieben, wie die Dateisysteme für die NFS-Anwendung konfiguriert wurden.
Erstellen Sie auf nodeA und nodeB ein Einhängepunktverzeichnis für das NFS-Dateisystem.
Beispiel:
KnotenA# mkdir /global/Einhängepunkt |
Konfigurieren Sie auf nodeA und nodeB den Master-Datenträger so, dass er automatisch im Einhängepunkt eingehängt wird.
Fügen Sie der /etc/vfstab-Datei auf nodeA und nodeB folgenden Text hinzu bzw. ersetzen Sie den Text. Der Text darf eine Zeile nicht überschreiten.
/dev/vx/dsk/Gerätegruppe/vol01 /dev/vx/rdsk/Gerätegruppe/vol01 \ /global/Einhängepunkt ufs 3 no global,logging |
In Abbildung 6–8 können Sie die Namen und Nummern der Datenträger in der Plattengerätegruppe nachschlagen.
Erstellen Sie auf nodeA einen Datenträger für die Dateisysteminformationen, die von der Sun StorEdge Availability Suite 3.1-Software verwendet werden.
KnotenA# /usr/sbin/vxassist -g Gerätegruppe make vol05 120m Platte1 |
Datenträger 5 enthält die Dateisysteminformationen, die von der Sun StorEdge Availability Suite 3.1-Software verwendet werden.
Synchronisieren Sie die Gerätegruppe mit der Sun Cluster-Software erneut auf nodeA.
KnotenA# /usr/cluster/bin/scconf -c -D name=Gerätegruppe,sync |
Erstellen Sie auf nodeA das Dateisystem für Datenträger 5.
KnotenA# /usr/sbin/newfs /dev/vx/rdsk/Gerätegruppe/vol05 |
Erstellen Sie auf nodeA und nodeB einen Einhängepunkt für Datenträger 5.
Beispiel:
KnotenA# mkdir /global/etc |
Konfigurieren Sie auf nodeA und nodeB Datenträger 5 so, dass er automatisch im Einhängepunkt eingehängt wird.
Fügen Sie der /etc/vfstab-Datei auf nodeA und nodeB folgenden Text hinzu bzw. ersetzen Sie den Text. Der Text darf eine Zeile nicht überschreiten.
/dev/vx/dsk/Gerätegruppe/vol05 /dev/vx/rdsk/Gerätegruppe/vol05 \ /global/etc ufs 3 yes global,logging |
Hängen Sie den Datenträger 5 im nodeA ein.
KnotenA# mount /global/etc |
Machen Sie den Datenträger 5 für Remote-Systeme zugänglich.
Erstellen Sie das Verzeichnis /global/etc/SUNW.nfs auf nodeA.
KnotenA# mkdir -p /global/etc/SUNW.nfs |
Erstellen Sie die Datei /global/etc/SUNW.nfs/dfstab.nfs-rs auf nodeA.
KnotenA# touch /global/etc/SUNW.nfs/dfstab.nfs-rs |
Fügen Sie der Datei /global/etc/SUNW.nfs/dfstab.nfs-rs auf nodeA folgende Zeile hinzu:
share -F nfs -o rw -d "HA NFS" /global/Einhängepunkt |
Wiederholen Sie das Verfahren in So konfigurieren Sie das Dateisystem im primären Cluster für die NFS-Anwendung mit folgenden Ausnahmen:
Ersetzen Sie nodeA durch nodeC.
Verwenden Sie nicht nodeB.
In diesem Abschnitt wird das Erstellen einer Replikations-Ressourcengruppe auf dem primären und dem sekundären Cluster beschrieben.
Greifen Sie als Superbenutzer auf nodeA zu.
Registrieren Sie SUNW.HAStoragePlus als Ressourcentyp.
KnotenA# /usr/cluster/bin/scrgadm -a -t SUNW.HAStoragePlus |
Erstellen Sie eine Replikations-Ressourcengruppe für die Plattengerätegruppe.
KnotenA# /usr/cluster/bin/scrgadm -a -g Gerätegruppe-stor-rg -h KnotenA,KnotenB |
Der Name der Plattegerätegruppe.
Der Name der Replikations-Ressourcengruppe.
Gibt die Cluster-Knoten an, die die Replikations-Ressourcengruppe unterstützen kann.
Fügen Sie der Replikations-Ressourcengruppe eine SUNW.HAStoragePlus-Ressource hinzu.
KnotenA# /usr/cluster/bin/scrgadm -a -j Gerätegruppenspeicher \ -g Gerätegruppe-stor-rg -t SUNW.HAStoragePlus \ -x GlobalDevicePaths=Gerätegruppe \ -x AffinityOn=True |
Die HAStoragePlus-Ressource für die Replikations-Ressourcengruppe.
Gibt die Erweiterungseigenschaft an, auf der die Sun StorEdge Availability Suite 3.1-Software basiert.
Gibt an, dass die SUNW.HAStoragePlus-Ressource ein Affinitäts-Switchover für die von -x GlobalDevicePaths= definierten globalen Geräte und Cluster-Dateisysteme durchführen muss. Daher wird bei einem Failover oder Switchover der Replikations-Ressourcengruppe ein Switchover für die Gerätegruppe durchgeführt.
Weitere Informationen zu diesen Erweiterungseigenschaften finden Sie in der Online-Dokumentation unter SUNW.HAStoragePlus(5).
Fügen Sie der Replikations-Ressourcengruppe eine Ressource logischer Hostname hinzu.
KnotenA# /usr/cluster/bin/scrgadm -a -L \ -j lHost-RepRG-Prim -g Gerätegruppe-stor-rg -l lHost-RepRG-Prim |
lHost-RepRG-Prim ist hierbei der logische Hostname für die Replikations-Ressourcengruppe im primären Cluster.
Aktivieren Sie die Ressourcen, verwalten Sie die Ressourcengruppe, und bringen Sie die Ressourcengruppe online.
KnotenA# /usr/cluster/bin/scswitch -Z -g Gerätegruppe-stor-rg KnotenA# /usr/cluster/bin/scswitch -z -g Gerätegruppe-stor-rg -h KnotenA |
Überprüfen Sie, ob die Ressourcengruppe online ist.
KnotenA# /usr/cluster/bin/scstat -g |
Prüfen Sie das Statusfeld der Ressourcengruppe, um zu bestätigen, dass die Replikations-Ressourcengruppe für nodeA und nodeB online ist.
Wiederholen Sie das Verfahren in So erstellen Sie eine Replikations-Ressourcengruppe auf dem primären Cluster mit folgenden Ausnahmen:
Ersetzen Sie nodeA durch nodeC.
Verwenden Sie nicht nodeB.
Ersetzen Sie Verweise auf lhost-reprg-prim durch lhost-reprg-sec.
In diesem Abschnitt wird das Erstellen der Anwendungs-Ressourcengruppen für eine NFS-Anwendung beschrieben. Die in diesem Abschnitt vorgestellten Verfahren sind anwendungsspezifisch. Die Verfahren können nicht für einen anderen Anwendungstyp verwendet werden.
Greifen Sie als Superbenutzer auf nodeA zu.
Registrieren Sie SUNW.nfs als Ressourcentyp.
KnotenA# scrgadm -a -t SUNW.nfs |
Sollte SUNW.HAStoragePlus noch nicht als Ressourcentyp registriert sein, führen Sie die Registrierung jetzt aus.
KnotenA# scrgadm -a -t SUNW.HAStoragePlus |
Erstellen Sie eine Anwendungs-Ressourcengruppe für Gerätegruppe.
KnotenA# scrgadm -a -g nfs-rg \ -y Pathprefix=/global/etc \ -y Auto_start_on_new_cluster=False \ -y RG_dependencies=Gerätegruppe-stor-rg |
Der Name der Anwendungs-Ressourcengruppe.
Gibt ein Verzeichnis an, in das die Ressourcen in der Gruppe Verwaltungsdateien schreiben können.
Gibt an, dass die Anwendungs-Ressourcengruppe nicht automatisch gestartet wird.
Gibt die Ressourcengruppen an, von denen die Anwendungs-Ressourcengruppe abhängt. In diesem Beispiel hängt die Anwendungs-Ressourcengruppe von der Replikations-Ressourcengruppe ab.
Wenn die Anwendungs-Ressourcengruppe auf den neuen Primärknoten umgeschaltet wird, wird die Replikations-Ressourcengruppe automatisch umgeschaltet. Wenn jedoch die Replikations-Ressourcengruppe auf den neuen Primärknoten umgeschaltet wird, muss die Anwendungs-Ressourcengruppe manuell umgeschaltet werden.
Fügen Sie der Anwendungs-Ressourcengruppe eine SUNW.HAStoragePlus-Ressource hinzu.
KnotenA# scrgadm -a -j NFS-GG-RS -g NFS-RG \ -t SUNW.HAStoragePlus \ -x FileSystemMountPoints=/global/Einhängepunkt \ -x AffinityOn=True |
Der Name der HAStoragePlus-Ressource für die NFS-Anwendung.
Gibt an, dass der Einhängepunkt für das Dateisystem global ist.
Gibt an, dass die Ressource vom Typ SUNW.HAStoragePlus ist.
Gibt an, dass die Anwendungsressource für die von -x GlobalDevicePaths= definierten globalen Geräte und Cluster-Dateisysteme ein Affinitäts-Switchover durchführen muss. Daher wird bei einem Failover oder Switchover der Ressourcengruppe für die zugehörige Gerätegruppe ein Switchover ausgeführt.
Weitere Informationen zu diesen Erweiterungseigenschaften finden Sie in der Online-Dokumentation unter SUNW.HAStoragePlus(5).
Fügen Sie der Anwendungs-Ressourcengruppe eine Ressource logischer Hostname hinzu.
KnotenA# /usr/cluster/bin/scrgadm -a -L -j lHost-NFSRG-Prim -g NFS-RG \ -l lHost-NFSRG-Prim |
lHost-NFSRG-Prim ist hierbei der logische Hostname der Anwendungs-Ressourcengruppe im primären Cluster.
Aktivieren Sie die Ressourcen, verwalten Sie die Anwendungs-Ressourcengruppe, und bringen Sie die Anwendungs-Ressourcengruppe online.
Bringen Sie die HAStoragePlus-Ressource für die NFS-Anwendung online.
KnotenA# /usr/cluster/bin/scrgadm -a -g NFS-RG \ -j NFS-RS -t SUNW.nfs -y Resource_dependencies=NFS-GG-RS |
Bringen Sie die Anwendungs-Ressourcengruppe auf nodeA online.
KnotenA# /usr/cluster/bin/scswitch -Z -g NFS-RG KnotenA# /usr/cluster/bin/scswitch -z -g NFS-RG -h KnotenA |
Überprüfen Sie, ob die Anwendungs-Ressourcengruppe online ist.
KnotenA# /usr/cluster/bin/scstat -g |
Prüfen Sie das Statusfeld der Ressourcengruppe, um zu ermitteln, ob die Anwendungs-Ressourcengruppe für nodeA und nodeB online ist.
Erstellen Sie die Anwendungs-Ressourcengruppe gemäß Schritt 1 bis Schritt 6 von So erstellen Sie eine Anwendungs-Ressourcengruppe im primären Cluster mit folgenden Ausnahmen:
Ersetzen Sie nodeA durch nodeC.
Ignorieren Sie die Verweise auf nodeB.
Ersetzen Sie die Verweise auf lHost-NFSRG-Prim durch lHost-NFSRG-Sek.
Stellen Sie sicher, dass die Anwendungs-Ressourcengruppe nicht auf nodeC online gebracht wird.
KnotenC# /usr/cluster/bin/scswitch -n -j NFS-RS KnotenC# /usr/cluster/bin/scswitch -n -j NFS-GG-RS KnotenC# /usr/cluster/bin/scswitch -n -j lHost-NFSRG-Sek KnotenC# /usr/cluster/bin/scswitch -z -g NFS-RG -h "" |
Die Ressourcengruppe bleibt nach einem Neubooten offline, weil Auto_start_on_new_cluster=False.
Wenn der globale Datenträger im primären Cluster eingehängt ist, hängen Sie ihn aus dem sekundären Cluster aus.
KnotenC# umount /global/Einhängepunkt |
Wenn der Datenträger im sekundären Cluster eingehängt ist, schlägt die Synchronisierung fehl.
In diesem Abschnitt wird das Aktivieren der Datenreplikation für die Beispielkonfiguration beschrieben. In diesem Abschnitt werden die Befehle sndradm und iiadm der Sun StorEdge Availability Suite 3.1-Software verwendet. Weitere Informationen zu diesen Befehlen finden Sie im Sun Cluster 3.0 and Sun StorEdge Software Integration Guide.
Greifen Sie als Superbenutzer auf nodeA zu.
Löschen Sie alle Transaktionen.
KnotenA# /usr/sbin/lockfs -a -f |
Bestätigen Sie, dass die logischen Hostnamen lHost-RepRG-Prim und lHost-RepRG-Sek online gebracht wurden.
KnotenA# /usr/cluster/bin/scstat -g |
Prüfen Sie das Statusfeld der Ressourcengruppe.
Aktivieren Sie die Replikation mit remotem Spiegel vom primären Cluster auf den sekundären Cluster.
Mit diesem Schritt wird die Replikation vom Master-Datenträger des primären Clusters auf den Master-Datenträger des sekundären Clusters aktiviert. Des Weiteren aktiviert dieser Schritt auch die Replikation auf das remote Spiegel-Bitmap auf Datenträger 4.
Wenn der primäre und sekundäre Cluster nicht synchronisiert sind, führen Sie diesen Befehl aus:
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -n -e lHost-RepRG-Prim \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 lHost-RepRG-Sek \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 ip sync |
Wenn der primäre und sekundäre Cluster synchronisiert sind, führen Sie diesen Befehl aus:
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -n -E lHost-RepRG-Prim \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 lHost-RepRG-Sek \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 ip sync |
Aktivieren Sie die Auto-Synchronisierung.
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -n -a on lHost-RepRG-Prim \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 lHost-RepRG-Sek \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 ip sync |
Mit diesem Schritt wird die Auto-Synchronisierung aktiviert. Wenn der aktive Zustand der Auto-Synchronisierung auf on eingestellt ist, werden die Datenträgersätze neu synchronisiert, sollte das System neu booten oder ein Fehler auftreten.
Überprüfen Sie, ob sich der Cluster im Protokollierungsmodus befindet.
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -P |
Die Ausgabe sollte der folgenden ähneln:
/dev/vx/rdsk/Gerätegruppe/vol01 -> lHost-RepRG-Sek:/dev/vx/rdsk/Gerätegruppe/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: Gerätegruppe, state: logging |
Im Protokollierungsmodus lautet der Zustand logging und der aktive Zustand der Auto-Synchronisierung off. Wenn der Daten-Datenträger auf der Platte beschrieben wird, wird die Bitmap-Datei auf derselben Platte aktualisiert.
Aktivieren Sie die Schnappschuss-Kopie.
KnotenA# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol02 \ /dev/vx/rdsk/Gerätegruppe/vol03 KnotenA# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/Gerätegruppe/vol02 |
Mit diesem Schritt wird das Kopieren des Master-Datenträgers der primären Platte auf den Schattendatenträger derselben Platte aktiviert. In diesem Beispiel ist der Master-Datenträger Datenträger 1, der Schattendatenträger ist Datenträger 2, und der punktuelle Bitmap-Datenträger ist Datenträger 3.
Hängen Sie die Schnappschuss-Kopie an den remoten Spiegelsatz an.
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol02 \ /dev/vx/rdsk/Gerätegruppe/vol03 |
In diesem Schritt wird die Schnappschuss-Kopie dem remoten Spiegel-Datenträgersatz zugeordnet. Die Sun StorEdge Availability Suite 3.1-Software stellt sicher, dass vor der Replikation mit remotem Spiegel eine Schnappschuss-Kopie aufgenommen wird.
Greifen Sie als Superbenutzer auf nodeC zu.
Löschen Sie alle Transaktionen.
KnotenC# /usr/sbin/lockfs -a -f |
Aktivieren Sie die Replikation mit remotem Spiegel vom primären Cluster auf den sekundären Cluster.
KnotenC# /usr/opt/SUNWesm/sbin/sndradm -n -e lHost-RepRG-Prim \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 lHost-RepRG-Sek \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 ip sync |
Der primäre Cluster erkennt die Anwesenheit des sekundären Clusters und startet die Synchronisierung. Informationen zum Status der Cluster finden in der Systemprotokolldatei /var/opt/SUNWesm/ds.log.
Aktivieren Sie die unabhängige Schnappschuss-Kopie.
KnotenC# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol02 \ /dev/vx/rdsk/Gerätegruppe/vol03 KnotenC# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/Gerätegruppe/vol02 |
Hängen Sie die Schnappschuss-Kopìe an den remoten Spiegelsatz an.
KnotenC# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol02 \ /dev/vx/rdsk/Gerätegruppe/vol03 |
In diesem Abschnitt wird das Ausführen der Datenreplikation für die Beispielkonfiguration beschrieben. In diesem Abschnitt werden die Befehle sndradm und iiadm der Sun StorEdge Availability Suite 3.1-Software verwendet. Weitere Informationen zu diesen Befehlen finden Sie im Sun Cluster 3.0 and Sun StorEdge Software Integration Guide.
In diesem Verfahren wird der Master-Datenträger der primären Platte auf den Master-Datenträger der sekundären Platte repliziert. Der Master-Datenträger ist Datenträger 1 und der remote Spiegel-Bitmap-Datenträger ist Datenträger 4.
Greifen Sie als Superbenutzer auf nodeA zu.
Überprüfen Sie, ob sich der Cluster im Protokollierungsmodus befindet.
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -P |
Die Ausgabe sollte der folgenden ähneln:
/dev/vx/rdsk/Gerätegruppe/vol01 -> lHost-RepRG-Sek:/dev/vx/rdsk/Gerätegruppe/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: Gerätegruppe, state: logging |
Im Protokollierungsmodus lautet der Zustand logging und der aktive Zustand der Auto-Synchronisierung off. Wenn der Daten-Datenträger auf der Platte beschrieben wird, wird die Bitmap-Datei auf derselben Platte aktualisiert.
Löschen Sie alle Transaktionen.
KnotenA# /usr/sbin/lockfs -a -f |
Kopieren Sie den Master-Datenträger von nodeA auf den Master-Datenträger von nodeC.
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -n -m lHost-RepRG-Prim \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 lHost-RepRG-Sek \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 ip sync |
Warten Sie, bis die Replikation abgeschlossen ist und die Datenträger synchronisiert sind.
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -n -w lHost-RepRG-Prim \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 lHost-RepRG-Sek \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 ip sync |
Bestätigen Sie, dass sich der Cluster im Replikationsmodus befindet.
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -P |
Die Ausgabe sollte der folgenden ähneln:
/dev/vx/rdsk/Gerätegruppe/vol01 -> lHost-RepRG-Sek:/dev/vx/rdsk/Gerätegruppe/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: Gerätegruppe, state: replicating |
Im Replikationsmodus lautet der Zustand replicating und der aktive Zustand der Auto-Synchronisierung on. Wenn der primäre Datenträger beschrieben wird, wird der sekundäre Datenträger von der Sun StorEdge Availability Suite 3.1-Software aktualisiert.
In diesem Verfahren wurden der Schattendatenträger und der Master-Datenträger des primären Clusters mithilfe der Schnappschuss-Kopie synchronisiert. Der Master-Datenträger ist Datenträger 1, und der Schattendatenträger ist Datenträger 2.
Greifen Sie als Superbenutzer auf nodeA zu.
Halten Sie die Anwendung an, die auf nodeA ausgeführt wird.
KnotenA# /usr/cluster/bin/scswitch -n -j NFS-RS |
Versetzen Sie den primären Cluster in den Protokollierungsmodus.
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -n -l lHost-RepRG-Prim \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 lHost-RepRG-Sek \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 ip sync |
Wenn der Daten-Datenträger auf der Platte beschrieben wird, wird die Bitmap-Datei auf derselben Platte aktualisiert. Es findet keine Replikation statt.
Synchronisieren Sie den Schattendatenträger und den Master-Datenträger des primären Clusters.
KnotenA# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/Gerätegruppe/vol02 KnotenA# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/Gerätegruppe/vol02 |
Synchronisieren Sie den Schattendatenträger und den Master-Datenträger des sekundären Clusters.
KnotenC# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/Gerätegruppe/vol02 KnotenC# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/Gerätegruppe/vol02 |
Starten Sie die Anwendung auf nodeA neu.
KnotenA# /usr/cluster/bin/scswitch -e -j NFS-RS |
Synchronisieren Sie den sekundären Datenträger mit dem primären Datenträger erneut.
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -n -u lHost-RepRG-Prim \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 lHost-RepRG-Sek \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 ip sync |
In diesem Abschnitt wird beschrieben, wie die Replikationskonfiguration in der Beispielkonfiguration bestätigt wurde.
Überprüfen Sie, ob sich der primäre Cluster im Replikationsmodus befindet und die Auto-Synchronisierung aktiviert ist.
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -P |
Die Ausgabe sollte der folgenden ähneln:
/dev/vx/rdsk/Gerätegruppe/vol01 -> lHost-RepRG-Sek:/dev/vx/rdsk/Gerätegruppe/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: Gerätegruppe, state: replicating |
Im Replikationsmodus lautet der Zustand replicating und der aktive Zustand der Auto-Synchronisierung on. Wenn der primäre Datenträger beschrieben wird, wird der sekundäre Datenträger von der Sun StorEdge Availability Suite 3.1-Software aktualisiert.
Wenn sich der primäre Cluster nicht im Replikationsmodus befindet, versetzen Sie ihn wie folgt in diesen Modus:
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -n -u lHost-RepRG-Prim \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 lHost-RepRG-Sek \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 ip sync |
Erstellen Sie auf einem Client-Rechner ein Verzeichnis.
Hängen Sie das Verzeichnis in die Anwendung im primären Cluster ein, und zeigen Sie das eingehängte Verzeichnis an.
Hängen Sie das Verzeichnis in die Anwendung im sekundären Cluster ein, und zeigen Sie das eingehängte Verzeichnis an.
Hängen Sie das Verzeichnis aus der Anwendung im primären Cluster aus.
Client-Rechner# umount /Verz |
Nehmen Sie die Anwendungs-Ressourcengruppe im primären Cluster offline.
KnotenA# /usr/cluster/bin/scswitch -n -j NFS-RS KnotenA# /usr/cluster/bin/scswitch -n -j NFS-GG-RS KnotenA# /usr/cluster/bin/scswitch -n -j lHost-NFSRG-Prim KnotenA# /usr/cluster/bin/scswitch -z -g NFS-RG -h "" |
Versetzen Sie den primären Cluster in den Protokollierungsmodus.
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -n -l lHost-RepRG-Prim \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 lHost-RepRG-Sek \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 ip sync |
Wenn der Daten-Datenträger auf der Platte beschrieben wird, wird die Bitmap-Datei auf derselben Platte aktualisiert. Es findet keine Replikation statt.
Bringen Sie die Anwendungs-Ressourcengruppe im sekundären Cluster online.
KnotenC# /usr/cluster/bin/scswitch -Z -g NFS-RG |
Greifen Sie als Superbenutzer auf den Client-Rechner zu.
Es wird eine Eingabeaufforderung angezeigt, die der folgenden ähnelt:
Client-Rechner# |
Hängen Sie das in Schritt 2 erstellte Verzeichnis in die Anwendung im sekundären Cluster ein.
Client-Rechner# mount -o rw lHost-NFSRG-Sek:/global/Einhängepunkt /Verz |
Zeigen Sie das eingehängte Verzeichnis an.
Client-Rechner# ls /Verz |
Stellen Sie sicher, dass das in Schritt 3 angezeigte Verzeichnis mit dem in Schritt 4 angezeigten Verzeichnis identisch ist.
Bringen Sie die Anwendung im primären Cluster zum eingehängten Verzeichnis zurück.
Nehmen Sie die Anwendungs-Ressourcengruppe im sekundären Cluster offline.
KnotenC# /usr/cluster/bin/scswitch -n -j NFS-RS KnotenC# /usr/cluster/bin/scswitch -n -j NFS-GG-RS KnotenC# /usr/cluster/bin/scswitch -n -j lHost-NFSRG-Sek KnotenC# /usr/cluster/bin/scswitch -z -g NFS-RG -h "" |
Stellen Sie sicher, das der globale Datenträger aus dem sekundären Cluster ausgehängt ist.
KnotenC# umount /global/Einhängepunkt |
Bringen Sie die Anwendungs-Ressourcengruppe im primären Cluster online.
KnotenA# /usr/cluster/bin/scswitch -Z -g NFS-RG |
Versetzen Sie den primären Cluster in den Replikationsmodus.
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -n -u lHost-RepRG-Prim \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 lHost-RepRG-Sek \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 ip sync |
Wenn der primäre Datenträger beschrieben wird, wird der sekundäre Datenträger von der Sun StorEdge Availability Suite 3.1-Software aktualisiert.
In diesem Abschnitt wird beschrieben, wie ein Switchover verursacht und die Anwendung auf einen sekundären Cluster übertragen wurde. Nach einem Switchover oder Failover müssen Sie den DNS-Eintrag aktualisieren und die Anwendung zum Lesen und Schreiben auf den sekundären Datenträger konfigurieren.
Versetzen Sie den primären Cluster in den Protokollierungsmodus.
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -n -l lHost-RepRG-Prim \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 lHost-RepRG-Sek \ /dev/vx/rdsk/Gerätegruppe/vol01 \ /dev/vx/rdsk/Gerätegruppe/vol04 ip sync |
Wenn der Daten-Datenträger auf der Platte beschrieben wird, wird die Bitmap-Datei auf derselben Platte aktualisiert. Es findet keine Replikation statt.
Bestätigen Sie, dass sich sowohl der primäre als auch der sekundäre Cluster im Protokollierungsmodus befinden und die Auto-Synchronisierung deaktiviert ist.
Führen Sie auf nodeA diesen Befehl aus:
KnotenA# /usr/opt/SUNWesm/sbin/sndradm -P |
Die Ausgabe sollte der folgenden ähneln:
/dev/vx/rdsk/Gerätegruppe/vol01 -> lHost-RepRG-Sek:/dev/vx/rdsk/Gerätegruppe/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: Gerätegruppe, state: logging |
Führen Sie auf nodeC diesen Befehl aus:
KnotenC# /usr/opt/SUNWesm/sbin/sndradm -P |
Die Ausgabe sollte der folgenden ähneln:
/dev/vx/rdsk/Gerätegruppe/vol01 <- lHost-RepRG-Prim:/dev/vx/rdsk/Gerätegruppe/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: Gerätegruppe, state: logging |
Für nodeA und nodeC sollte der Zustand logging lauten, und der aktive Zustand der Auto-Synchronisierung sollte auf off eingestellt sein.
Bestätigen Sie, dass für den sekundären Cluster ein Takeover vom primären Cluster durchgeführt werden kann.
KnotenC# /usr/sbin/fsck -y /dev/vx/rdsk/Gerätegruppe/vol01 |
Schalten Sie auf den sekundären Cluster um.
KnotenC# scswitch -Z -g NFS-RG KnotenC# scswitch -Z -g NFS-RG -h KnotenC |
Die Abbildung einer DNS-Zuordnung zwischen einem Client und einem Cluster finden Sie in Abbildung 6–6.
Starten Sie den nsupdate-Befehl.
Weitere Informationen finden Sie in der Online-Dokumentation unter nsupdate(1M).
Entfernen Sie die aktuelle DNS-Zuordnung zwischen dem Client-Rechner und dem logischen Hostnamen der Anwendungs-Ressourcengruppe im primären Cluster.
> update delete Client-Rechner A > update delete IP-Adresse1.in-addr.arpa TTL PTR Client-Rechner |
Der volle Client-Name. Beispiel: mymachine.mycompany.com.
Die IP-Adresse des logischen Hostnamens lHost-NFSRG-Prim in umgekehrter Reihenfolge.
Die Lebensdauer in Sekunden. Ein typischer Wert ist 3600.
Erstellen Sie die neue DNS-Zuordnung zwischen dem Client-Rechner und dem logischen Hostnamen der Anwendungs-Ressourcengruppe im sekundären Cluster.
> update add Client-Rechner TTL A IP-Adresse2 > update add IP-Adresse3.in-addr.arpa TTL PTR Client-Rechner |
Die IP-Adresse des logischen Hostnamens lHost-NFSRG-Sek in fortlaufender Reihenfolge.
Die IP-Adresse des logischen Hostnamens lHost-NFSRG-Sek in umgekehrter Reihenfolge.
Konfigurieren Sie den sekundären Datenträger so, dass er im Einhängepunktverzeichnis für das NFS-Dateisystem eingehängt wird.
Client-Rechner# mount -o rw lHost-NFSRG-Sek:/global/Einhängepunkt /xxx |
Der Einhängepunkt wurde in Schritt 1 von So konfigurieren Sie das Dateisystem im primären Cluster für die NFS-Anwendung erstellt.
Bestätigen Sie, dass der sekundäre Cluster Schreibzugriff für den Einhängepunkt hat.
Client-Rechner# touch /xxx/data.1 Client-Rechner# umount /xxx |