Vorhandene Beziehungen in SM-BC-Beziehungen konvertieren
-
PDF dieser Dokumentationssite
- Cluster-Administration
-
Volume-Administration
-
Logisches Storage-Management mit der CLI
- Verwenden Sie Quoten, um die Ressourcennutzung zu beschränken oder zu verfolgen
-
Logisches Storage-Management mit der CLI
-
NAS-Storage-Management
- Konfigurieren Sie NFS mit der CLI
- Verwalten Sie NFS mit der CLI
-
SMB lässt sich mit der CLI managen
- Verwalten Sie SMB-Server
- Verwalten Sie den Dateizugriff mit SMB
- SAN-Storage-Management
- Authentifizierung und Zugriffssteuerung
- Sicherheit und Datenverschlüsselung
-
Datensicherung und Disaster Recovery
-
Datensicherung mit der CLI
- Managen Sie die SnapMirror Volume-Replizierung
-
Datensicherung mit der CLI
Sammlung separater PDF-Dokumente
Creating your file...
Wenn Sie eine bestehende synchrone SnapMirror-Beziehung zwischen einem Quell- und Ziel-Cluster haben, können Sie sie in eine SM-BC-Beziehung konvertieren. Auf diese Weise können Sie die gespiegelten Volumes einer Konsistenzgruppe zuordnen, um für einen Workload mit mehreren Volumes einen RPO von null zu gewährleisten. Außerdem können Sie vorhandene SnapMirror Snapshots behalten, wenn Sie zu einem bestimmten Zeitpunkt vor dem Herstellen der SM-BC-Beziehung zurücksetzen müssen.
-
Zwischen dem primären und dem sekundären Cluster muss eine synchrone SnapMirror Beziehung mit einem RPO von null bestehen.
-
Die Zuordnung aller LUNs auf dem Ziel-Volume muss aufgehoben werden, bevor die SnapMirror Beziehung zum RTO von null erstellt werden kann.
-
SM-BC unterstützt nur SAN-Protokolle (keine NFS/CIFS). Stellen Sie sicher, dass für den NAS-Zugriff keine Komponente der Konsistenzgruppe bereitgestellt ist.
-
Sie müssen ein Cluster- und SVM-Administrator auf den primären und sekundären Clustern sein.
-
Sie können keine RPO von null auf ein RTO von null konvertieren, indem Sie die SnapMirror Richtlinie ändern.
-
Sie müssen sicherstellen, dass die Zuordnung der LUNs aufgehoben wird, bevor Sie die ausgeben
snapmirror create
Befehl.Wenn vorhandene LUNs auf dem sekundären Volume zugeordnet sind, und der
AutomatedFailover
Policy wird konfiguriert, dersnapmirror create
Löst einen Fehler aus.
-
Führen Sie aus dem sekundären Cluster ein SnapMirror Update der bestehenden Beziehung durch:
destination::>snapmirror update -destination-path vs1_dst:vol1
-
Überprüfen Sie, ob das SnapMirror Update erfolgreich abgeschlossen wurde:
destination::>snapmirror show
-
Stilllegung jeder der synchronen Beziehungen ohne RPO:
destination::>snapmirror quiesce -destination-path vs1_dst:vol1
destination::>snapmirror quiesce -destination-path vs1_dst:vol2
-
Sie löschen jede der synchronen Beziehungen ohne RPO:
destination::>snapmirror delete -destination-path vs1_dst:vol1
destination::>snapmirror delete -destination-path vs1_dst:vol2
-
Geben Sie die SnapMirror Quellbeziehung frei, behalten Sie die gemeinsamen Snapshot Kopien jedoch bei:
source::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol1
source::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol2
-
Erstellen einer Gruppe null RTO synchrone SnapMirror Beziehung:
destination::> snapmirror create -source-path vs1_src:/cg/cg_src -destination-path vs1_dst:/cg/cg_dst -cg-item-mappings vol1:@vol1,vol2:@vol2 -policy AutomatedFailover
-
Neusynchronisierung der Konsistenzgruppe:
destination::> snapmirror resync -destination-path vs1_dst:/cg/cg_dst
-
Wiederherstellen aller Pfade zu den LUNs durch erneute Überprüfung der Host-LUN-I/O-Pfade