Intégration SAN HP 3PAR avec le Storage Replication Adapter pour Site Recovery Manager 6.5

Comme pour l’autre article sur HDS  :

1ere étape : VMware Compatibility Guide, trouver la version de SRM compatible avec votre SRM et votre stockage, voir aussi le site du fabricant lorsque les versions proposées ne sont plus toutes récentes…

2eme étape : Récupérer le SRA depuis my.vmware.com, bien choisir sa version de SRM puis « Drivers & Tools » > « Go to Downloads »

3eme étape : installer le SRA sur vos serveurs SRM : setup > next > next > next …

4eme étape: ajouter le gestionnaire pour votre baie

Selection du SRA de la 3PAR

5eme étape: Ici, il suffit de se connecter à la baie (vérifier les ouvertures firewall le cas échéant) Hitachi puisque nous nous connectons directement à la baie et non pas au travers d’instance de command device.

L’option des préfixes est intéressante, car vous pouvez segmentez les « Remote Copy Groups » visiblent en fonction de leur nom ainsi avec une bonne convention physique/virtuel et vos différents environnements vous ne verrez que les « Remote Copy Groups » correspondant aux VMs protégées par SRM.

6eme étape régler les éventuels problèmes :

 Ci-dessous quelques messages d’erreurs que j’ai rencontré pendant la configuration des baies

 

 

 

 

La commande SRA ‘discoverArrays’ a échoué.

Cause :
A parameter in XML was input from SRM to the SRA, but it could not be found in any parameters.
Confirm if SRM was passed appropriate parameters in XML from own SRM log message.

Ce message correspond à des ouvertures firewall manquantes.

 

Ou bien,

La commande SRA « discoverArrays » a échoué.

Cause:
Error. Exception has occurred: Login failed. Invalid user (ESX_SRA_LO) or password.
If the problem still persists, please contact HPE 3PAR support for assistance.

Mauvais Compte ou mot de passe pour la connection à la baie.

 

Mais encore,

La commande SRA « discoverArrays » a échoué.

Cause:
Server certificate is not accepted yet. Please run  ‘TpdSrm.exe validatecert’ to accept and save the server certificate.
Please run  ‘TpdSrm.exe validatecert’ to accept and save the server certificate.

Commande à passer sur les serveurs SRM pour accepter le certificat : TPDSrm.exe validatecert -sys « ip » -user « toto » -pass « pwd »

Une fois les éventuels problèmes réglés, félicitation vous êtes correctement connectez aux baies :

 

Intégration SAN Hitachi HDS avec le Storage Replication Adapter dans Site Recovery Manager 6.5

1ere étape : VMware Compatibility Guide, trouver la version de SRM compatible avec votre SRM et votre stockage, voir aussi le site du fabricant lorsque les versions proposées ne sont plus toutes récentes…

2eme étape : Récupérer le SRA depuis my.vmware.com, bien choisir sa version de SRM puis « Drivers & Tools » > « Go to Downloads »

Sélectionner le SRA qui correspond au type de stockage à piloter, ici du SAN Hitachi:

3eme étape : installer le SRA sur vos serveurs SRM : setup > next > next > next …

4eme étape : vérifier la présence du SRA dans SRM :

5eme étape, si comme nous vous avez limité l’accès aux Command Devices en ssh, ajouter les opérations suivantes à défaut vous aurez droit au message  :

 

 

Créer un gestionnaire de baies : com.vmware.vcDr.dr.stockage.fault.CommandFailed.summary

Cause:  com.vmware.vcDR.dr.storage.fault.LocalizableAdapterFault.summary

 

Ici, il faut ajouter la variable d’environnement RMSRA_USE_SSH à 1.

Le serveur distant est un linux Suse donc nous avons deux autres variables à configurer:

RMSRA_TEL_RESPS à vt100

et RMSRA_TEL_WAITS à /terminal type\? /i

soit


setx RMSRA_TEL_WAITS "/terminal type\? /i" /m

setx RMSRA_TEL_RESPS vt100 /m

setx RMSRA_USE_SSH 1 /m

Toutes ces spécificités et bien d’autres sont documentés dans le pdf qui accompagne le SRA. Il y est d’ailleurs indiqué comment enregistrer le fingerprint de la clé RSA mais je n’ai jamais réussi à exploiter leur ligne de commande donc j’utilise plutôt celle-ci

echo y | plink.exe -ssh root@HORCM_IP "exit"

6eme étape : Configurer la connexion avec le stockage aux travers du SRA

L’option par défaut nous permettra de configurer directement chaque baie sur chaque site:

Ici la convention correspond au numéro de l’instance HORCM puis l’adresse IP du serveur par exemple HORCMINST=3@192.168.0.50.

C’est très pratique, chacun son instance plutôt que de multipler les serveurs, avec une baie qui  héberge aussi du stockage pour des machines physiques cela évite d’avoir la visibilité sur toutes les réplications, mais pas d’inquiétude dans tous les cas SRM ne pilotera que les réplications avec des VMs.

Puis on passe à l’autre site vers l’autre baie

Les paires s’appairent

Félicitation, si tout est OK, vous devriez voir vos réplications et leur sens depuis chacun des SRA.

L’environnement 6.5 prend petit à petit de l’ampleur et je me suis retrouvé avec des VMs à retirer de l’inventaire.

La nouvelle interface web cache un peu l’option et celle-ci n’est pas disponible directement depuis un clic droit donc voici le chemin pour retirer une machine de l’inventaire : Clic droit > All Virtual Infrastructure Actions > More Uncategorized Actions > Remove from Inventory.

J’ai fait une petite erreur pendant le setup d’un de mes SRM 6.5 et le moyen le plus simple de la corriger est de rejouer l’installation depuis le panneau de configuration :

J’ai d’abord eu un problème d’UAC qui est largement documenté dans la KB2097033 : Running modify install in the VMware vCenter Site Recovery Manager on Windows server 2012 fails with the error : Setup requires User Access Control (UAC) to be disabled while changing the existing installation.

Comme indiqué dans le message d’erreur, désactiver l’UAC…

 

J’ai ensuite rencontré un problème de permissions et je n’ai pas trouvé de référence donc voici l’astuce qui a fonctionné pour moi.

Évidemment, le compte que j’utilisais été déjà « Administrateur de la machine », puis que je venais de désactiver de l’UAC, mais en ajoutant le compte directement dans le groupe « Administrator » de la machine le setup fonctionne normalement, sans fermeture de session, ni reboot.

Je n’ai pas testé, mais j’imagine que la modification du setup fonctionne aussi directement avec un compte administrateur local, mais je n’y ai pas accès ici.

Après la modification, on enlève cette verrue, et si l’un d’entre vous à une explication qu’il n’hésite pas à poster un commentaire.

J’ai eu besoin d’étendre un disque d’une machine virtuelle Windows 2012, répliqué entre deux sites distants, innocemment je pensais en avoir pour quelques secondes, et j’avoue avoir été surpris de constater que l’agrandissement d’une machine protégée avec vSphere Replication n’est pas du tout « user-friendly ».

Il faut respecter scrupuleusement la KB2042790  Resizing virtual machine disk files that are protected by vSphere Replication using VMware vCenter Site Recovery Manager.

1re étape : renommer le répertoire de destination de la synchronisation afin d’empêcher vSphere Replication de la détruire lorsque nous stopperons la synchronisation.

2e étape : noter les paramètres de la réplication.

3e étape : supprimer ladite réplication : à noter qu’à l’exécution de l’opération plusieurs erreurs apparaissent, car ils ne retrouvent plus les fichiers à supprimer.

4e étape : Augmenter le disque de la VM, lorsqu’il s’agit d’une extension supérieure à 2TB, il faut malheureusement réaliser l’opération à froid en éteignant la VM et avec le vSphere Web Client. cf:  KB2058287  Support for virtual machine disks larger than 2 TB in VMware ESXi 5.5.x and 6.0.x

Ci-dessous le message d’erreur qui est très clair, pas d’augmentation à chaud au-delà de 2TB.

5e étape : on attaque un ESXi ayant accès au stockage du replica afin d’augmenter en ligne de commande avec vmkfstools la taille de son disque autant dire que cette partie nécessiterais clairement une amélioration.

J’avais besoin d’augmenter à 8TB la volumétrie du disque et je confirme que le commutateur [tT] pour tera fonctionne malgré qu’il ne soit pas mentionné dans la doc : vmkfstools—X—extendvirtualdisk newSize [kK|mM|gG] .(source Extending a Virtual Disk)

Pour exemple : vmkfstools -X 8T test-VM.vmdk fonctionne. La commande s’exécute sur le vmdk et non sur le -flat.vmdk.

6e étape : Reconfigurer le nom d’origine du répertoire du replica.

7e étape : Reconfigurer la réplication.

8e étape : Si votre extension été supérieur à 2TB, rallumer la VM.

J’avais besoin pour mon homelab d’un nœud de réplication nutanix, je me suis mis en tête de faire une installation « one node » sur un VMware Workstation, la version actuellement disponible est la 2017.05.22, mais si vous avez déjà fait une installation sur VMware vous savez qu’il est nécessaire d’avoir un fichier de description pour le vmdk.

 

Les descripteurs disponibles sur le net correspondent à une ancienne version de Nutanix, donc voici le fichier qui correspond à la version 2017.05.22 :


# Disk DescriptorFile

version=1

encoding="UTF-8"

CID=fffffffe

parentCID=ffffffff

isNativeSnapshot="no"

createType="vmfs"

# Extent description

RW 14540800 VMFS "ce-2017.05.22-stable-flat.vmdk"

# The Disk Data Base

#DDB

ddb.adapterType = "lsilogic"

ddb.geometry.cylinders = "905"

ddb.geometry.heads = "255"

ddb.geometry.sectors = "63"

ddb.longContentID = "d00bc92d928c5ea1ad1e2ee1fffffffe"

ddb.thinProvisioned = "1"

ddb.uuid = "60 00 C2 93 e0 e7 ce 39-87 57 b1 3f 79 7d 6f 69"

ddb.virtualHWVersion = "10")

Sinon vous pouvez faire comme moi et utiliser cette KB VMware « Recreating a missing virtual machine disk descriptor file (1002511) » pour créer le fichier avec vmkfstools.

Un admin de la platforme VMware m’a remonté un problème de connexion au vCenter, je n’arrivais pas à reproduire le problème mais une rapide recherche sur internet la KB VMware : « vSphere Client will time out before authentication to ESXi is complete (2072539) » nous donnait une explication :

Dans notre cas, c’est le nombre trop important de groupe dont l’utilisateur est membre mais le timeout est personnalisable depuis la clé de registre :

HKCU\Software\VMware\VMware Infrastructure Client\Preferences\CLIENT_CMD_TIMEOUT

Voici le script que j’utilise en ce moment pour les mises en maintenance des hôtes AHV des clusters Nutanix avec un menu à choix multiples :


Disconnect-NTNXCluster *

#Choisir le cluster 
$ClusterNut = Read-Host "Entrer the Ip or DNS name of your Nutanix Cluster to manage"

Connect-NTNXCluster $ClusterNut -AcceptInvalidSSLCerts -ForcedConnection
$Clusterlist = $null


for () {

# récupère la liste des noms d'hôtes du cluster
$Clusterlist = Get-NTNXHost

    #défini integer à 0
    $i=0

    $ClusterName = (Get-NTNXCluster).name

    Write-Host "Vous avez selectionné le cluster $($(Get-NTNXCluster).name)
    "

    # Créer un menu : Pour chaque hôte du cluster ajouter 1 à i et afficher le nom d'hôte associé
    write-host "0 : Sortir du script"
    foreach ($ht in $Clusterlist) {
        $i++
        Write-Host "$i : $($ht.Name) : état  $($ht.hypervisorState) : Hyperviseur $($ht.hypervisorAddress) : IPMI $($ht.ipmiAddress) " 
        }

    do {
    $Menu = Read-Host "Choisir le numéro d'hôte"
    #juste affichage : tant que le chiffre indiqué n'est pas un nombre d'un hôte possible on boucle ici
    if (0..$Clusterlist.Count -notcontains $Menu) {Write-Host "Merci d'indiquer le numéro correspond au noeud à mettre en maintenance" -ForegroundColor Red}
    }

    #tant que le chiffre indiqué n'est pas un nombre d'un hôte possible on boucle ici
    while (0..$Clusterlist.Count -notcontains $Menu)

    #Conserve le nom de l'hôte dans la variable ChoiceMenu le -1 sert car le count debute à 0.
    if ($menu -eq 0) {
                        #Déco
                        Disconnect-NTNXCluster *
                        exit
                      } 
    $ChoiceMenu = ($Clusterlist).name[$menu-1]
    write-host "Vous avez choisi le $ChoiceMenu"

    Write-Host -ForegroundColor Green "Choisir l'option 1 pour Mettre en Maintenance et l'option 2 pour remettre en ligne" 
    $Menu1 = Read-Host 

    if ($Menu1 -eq 1) {
        $uuid = (Get-NTNXHost | where {$_.name -like $ChoiceMenu}).uuid
        
        write-host "La tache de mise en maintenance de l'hôte $ChoiceMenu est en cours"
        Start-NTNXMaintenanceMode -Hostid $uuid -EvacuationOption LIVE_MIGRATE
        sleep 3 
        
    }

    if ($Menu1 -eq 2) {
    write-host "La tache remise en prod de l'hôte $ChoiceMenu est en cours"
    Stop-NTNXMaintenanceMode -Hostid $uuid
    sleep 3
    }
    
}