Convertir les relations existantes en relations SM-BC
-
Un fichier PDF de toute la documentation
- Administration du cluster
-
L'administration des volumes
-
Gestion du stockage logique avec l'interface de ligne de commandes
- Utilisez des quotas pour limiter ou suivre l'utilisation des ressources
-
Gestion du stockage logique avec l'interface de ligne de commandes
-
Gestion du stockage NAS
- Configurez NFS avec l'interface de ligne de commande
- Gérez NFS avec l'interface de ligne de commande
-
Gestion de SMB avec l'interface de ligne de commandes
- Gérer les serveurs SMB
- Gérer l'accès aux fichiers via SMB
- Gestion du stockage SAN
- Authentification et contrôle d'accès
-
Sécurité et chiffrement des données
- Utilisez FPolicy pour le contrôle et la gestion des fichiers sur SVM
-
Protection des données et reprise d'activité
- Protection des données via l'interface de ligne de commandes
Plusieurs fichiers PDF
Creating your file...
Si vous avez une relation SnapMirror synchrone existante entre un cluster source et un cluster destination, vous pouvez la convertir en relation SM-BC. Vous pouvez ainsi associer les volumes en miroir à un groupe de cohérence, garantissant ainsi un RPO nul sur une charge de travail à plusieurs volumes. En outre, vous pouvez conserver les snapshots SnapMirror existants si vous devez revenir à un point dans le temps avant d'établir la relation SM-BC.
-
Une relation SnapMirror synchrone avec RPO nul doit exister entre le cluster principal et le cluster secondaire.
-
Avant de pouvoir créer la relation SnapMirror avec un objectif RTO nul, toutes les LUN du volume de destination doivent être démappées.
-
SM-BC prend uniquement en charge les protocoles SAN (et non NFS/CIFS). Assurez-vous qu'aucun composant du groupe de cohérence n'est monté pour l'accès au NAS.
-
Vous devez être administrateur du cluster et SVM sur les clusters principal et secondaire.
-
Vous ne pouvez pas convertir le RPO nul en synchronisation RTO zéro en modifiant la règle SnapMirror.
-
Vous devez vous assurer que le mappage des LUN est annulé avant d'émettre le
snapmirror create
commande.Si les LUN existantes du volume secondaire sont mappées et l'
AutomatedFailover
la règle est configurée, lesnapmirror create
déclenche une erreur.
-
Depuis le cluster secondaire, effectuer une mise à jour SnapMirror sur la relation existante :
destination::>snapmirror update -destination-path vs1_dst:vol1
-
Vérifier que la mise à jour SnapMirror a été correctement effectuée :
destination::>snapmirror show
-
Arrêter chaque relation synchrone RPO zéro :
destination::>snapmirror quiesce -destination-path vs1_dst:vol1
destination::>snapmirror quiesce -destination-path vs1_dst:vol2
-
Supprimez chacune des relations synchrones RPO zéro :
destination::>snapmirror delete -destination-path vs1_dst:vol1
destination::>snapmirror delete -destination-path vs1_dst:vol2
-
Relâcher la relation SnapMirror source mais conserver les copies Snapshot courantes :
source::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol1
source::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol2
-
Création d'une relation SnapMirror synchrone RTO nul groupe :
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
-
Resynchroniser le groupe de cohérence :
destination::> snapmirror resync -destination-path vs1_dst:/cg/cg_dst
-
Relancez les chemins d'E/S de la LUN hôte pour restaurer tous les chemins d'accès aux LUN.