SnapManager for Hyper-V
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Reconfigurer les systèmes de stockage après une reprise d’activité

Contributeurs

Après le basculement vers un système de stockage secondaire, SnapManager pour Hyper-V termine la reprise sur incident en rebasculer vers le système de stockage primaire d’origine. Le basculement restaure la fonction de stockage primaire vers le site de stockage principal d’origine après la réactivation ou le remplacement de ses systèmes de stockage.

Étapes

  1. En fonction de l’état du système de stockage principal, effectuer l’une des actions suivantes :

    Si le système de stockage primaire est…​ Alors…​

    Récupérable

    Redéplacez les données de l’hôte secondaire vers le système de stockage primaire.

    Complètement détruit

    Provisionnement d’un nouveau système de stockage.

  2. Gérer la relation SnapMirror :

    1. Initialiser la relation SnapMirror entre le système de stockage secondaire et le système de stockage primaire pour restaurer les données

    2. Resynchroniser la relation SnapMirror existante entre le système de stockage secondaire et le système de stockage principal.

    3. À l’aide de SnapDrive sur le système de stockage secondaire, lancez une mise à jour SnapMirror pour chacun des partages LUN ou SMB sur le système de stockage secondaire.

  3. En fonction de votre configuration, effectuer l’une des actions suivantes :

    Si le système de stockage primaire est…​ Alors…​

    Un hôte autonome (SAN)

    Connectez-vous à tous les points de montage et à tous les LUN sur le système de stockage primaire du même type.

    Un hôte en cluster (SAN)

    Depuis le nœud sur lequel le groupe de clusters est en ligne, connectez-vous à tous les points de montage et à tous les LUN du cluster.

    Data ONTAP 8.1.x configuré avec un seul LUN hébergeant des VM sur un volume FlexVol source (SAN)

    Pour que les mises à jour de SnapMirror réussissent, vous devez créer une seconde LUN de plus petite taille (10 Mo à 100 Mo) sur le volume FlexVol source avant de lancer une tâche de sauvegarde. Depuis le nœud sur lequel le groupe de clusters est en ligne, connectez-vous à tous les points de montage et à tous les LUN du cluster.

    Un hôte autonome ou en cluster (NAS)

    Démontez le volume protection des données (DP), montez le volume DP en tant que réinscriptible, vérifiez que le volume dispose d’autorisations RWX et créez des partages CIFS pour les différents volumes.

  4. Reconfigurer SnapInfo en fonction de votre environnement :

    Si votre configuration est…​ Alors…​

    SAN

    Restaurez le LUN SnapInfo à partir de sa dernière copie Snapshot.

    NAS

    Montez le répertoire SnapInfo.

    Pour NAS, si une erreur d’accès refusé se produit, ou si vous ne pouvez pas accéder à l’emplacement de partage SMB exposé, vous devrez peut-être réinitialiser la liste de contrôle d’accès sur le partage.

  5. Ajoutez l’hôte ou le cluster principal dans SnapManager pour les MMC Hyper-V et configurez-le à l’aide du chemin SnapInfo.

  6. Entrez les applets de commande suivantes :

    1. Récupérez la liste des machines virtuelles présentes dans les métadonnées de sauvegarde en utilisant l’applet de commande get-VMsFromBackup.

    2. Obtenez les copies de sauvegarde de chaque machine virtuelle à l’aide de la cmdlet Get-Backup pour obtenir les copies de sauvegarde de chaque machine virtuelle.

  7. Pour restaurer, utilisez Restore-Backup Avec le GUID de la machine virtuelle et la copie de sauvegarde avec les paramètres suivants :

    Pour restaurer à partir de…​ Entrez cette commande…​

    Un autre hôte

    Restore-Backup -Server Secondary_host_system_or_cluster_name -DisableVerifySnapshot -RestoreToAlternateHost

    Copie de sauvegarde répertoriée

    Restore-Backup -Server -VirtualMachinePath -SnapShotFilePath @VHD

    Pour @VHD, Un VM peut avoir plusieurs VHD ; vous devez entrer une paire source et un chemin de destination spécifiés pour chaque VHD.

  8. Si le système hôte secondaire est un cluster, procédez comme suit :

    1. Assurez-vous que les LUN sur lesquelles résident les machines virtuelles sont en ligne sur le nœud de cluster qui possède le groupe de clusters.

    2. Utilisez les applets de commande Failover PowerShell pour assurer la haute disponibilité des machines virtuelles.

    Dans le cas du NAS, une fois que les machines virtuelles sont exposées en tant que partages SMB à partir d’un nœud de cluster, ces machines virtuelles sont accessibles à tous les hôtes configurés pour utiliser le cluster du système de stockage.

Exemples de rétablissement

L’exemple suivant montre une configuration à deux clusters dans laquelle smhv-cluster-01 est le site principal et hv-19-cluster est le site secondaire :

PS C:\> Get-VMsFromBackup -Server smhv-cluster-01

winxp-x64c-135                593ABA72-B323-4AF7-9AC6-9514F64C0178
csv1-xp-3                     59B85C68-BAFA-4A49-8E85-A201045843F7
vm-w2k8r2sp1                  5A248757-872B-4FE7-8282-91C8E9D45CF9
um10_11_dr                    5AC1B2A8-6603-4F90-98F5-4F2F435AB0C2
winxp-x64c-30                 5B47D3CF-5D96-495D-9BAB-FB394392CF31
winxp-x64c-126                5B57EED1-B4F1-45A3-A649-24C6947CB79C
winxp-x64c-118                5B5D417B-70DC-427C-94BB-97FF81C5B92B
winxp-x64c-122                5BEE26B8-BE57-4879-A28E-9250A6A5EEFC
csv4-w2k3-19                  5D0613E5-B193-4293-8AAD-F8B94A5D851F

PS C:\> Get-Backup -Server smhv-cluster-01 -ResourceName
um10_11_dr

BackupName    : smhv-ccb-ds_04-10-2012_10.37.58
RetentionType : hourly
DatasetName   : smhv-ccb-ds
BackupId      : smhv-ccb-ds_04-10-2012_10.37.58
BackupTime    : 4/10/2012 10:37:58 AM
BackupType    : Application consistent
BackedupVMs   : {um10_11_dr}

PS C:\> Restore-Backup -Server smhv-cluster-01 -ResourceName
um10_11_dr -BackupName smhv-ccb-ds_04-10-2012_10.37.58
-DisableVerifySnapshot -RestoreToAlternateHost

L’exemple suivant montre une opération de restauration SAN vers un chemin secondaire pour lequel N:\ est la destination et i:\ est le chemin de LUN source :

PS C:\> Restore-Backup -Resourcename dr-san-ded1
-RestoreToAlternateHost -DisableVerifySnapshot -BackupName san_dr_09-11-2013_10.57.31 -Verbose
-VirtualMachinePath "N:\dr-san-ded1" -SnapshotFilePath "N:\dr-san-ded1" -VHDs @(@{"SourceFilePath" = "I:\dr-san-ded1\Virtual Hard Disks\dr-san-ded1.vhdx"; "DestinationFilePath" = "N:\dr-san-ded1\Virtual Hard Disks\dr-san-ded1"})

L’exemple suivant montre une opération de restauration NAS vers un chemin alternatif pour lequel \\172.17.162.174\ est le chemin du partage SMB source et \\172.17.175.82\ est le chemin du partage SMB de destination :

PS C:\> Restore-Backup -Resourcename vm_claba87_cifs1
-RestoreToAlternateHost -DisableVerifySnapshot -BackupName ag-DR_09-09-2013_16.59.16 -Verbose
-VirtualMachinePath "\\172.17.175.82\vol_new_dest_share\ag-vm1" -SnapshotFilePath "\\172.17.175.82\vol_new_dest_share\ag-vm1" -VHDs @(@{"SourceFilePath" = "\\172.17.162.174\vol_test_src_share\ag-vm1\Virtual Hard Disks\ag-vm1.vhdx"; "DestinationFilePath" = "\\172.17.175.82\vol_new_dest_share\ag-vm1\Virtual Hard Disks\ag-vm1.vhdx"})

Informations connexes

"Guide de sauvegarde et de restauration en ligne pour la protection des données Data ONTAP 8.2 7-mode"

"Référence SMB/CIFS"