test TCP :
netcat -zv IP PORT
test UDP:
netcat -u HOST PORT
Auteur/autrice : mgioia
Upgrade Dell Nutanix SATA DOM with Life Cycle Management
Souvenez-vous, le SATADOM c’est ce module mémoire attaché à la carte mère de nos serveurs, ici Dell, qui contient les sources Nutanix avec la CVM et l’hyperviseur.
Depuis une récente mise à jour, j’avais une alerte sur l’obsolescence des firmwares de SATADOM sur mes plus anciens clusters :
Le support Dell a réalisé la première opération d’upgrade, rien de compliqué mais plusieurs heures de maintenances en webex et quelques lignes de commandes à exécuter, on était très loin du “One-clic Upgrade”.
Mais les choses ont changées puisque la dernière version de Life Cycle Management aka “LCM” prend justement en charge l’upgrade des SATA DOM !
Idéalement les CVM auront accès à internet, au minimum *.nutanix.com, il existe même une procédure pour LCM sans connexion intituler “Using the Life Cycle Manager Without Web Access“.
1er étape, lancer un inventaire afin qu’il détermine les composants et nouvelles versions disponibles: cliquez sur “Perfom Inventory”
2eme étape upgrade des LCM :
Sélectionnez les LCM à upgrader, puis cliquez “Save Selection”
Cliquez sur “Update Selected”
Cliquez sur “Apply x Updates”
Update en cours :
Opération terminée avec succès, LCM en version 1.1a492718:
3eme étape, on relance un scan afin qu’il détecte les nouveaux composants: cliquez sur “Perfom Inventory” depuis LCM.
Cliquez sur “Define”
Selection des noeuds à upgrader :
Mettre à niveau la sélection, cliquez sur “Update Selected”
étrangement sur cette écran on ne peut pas appliquer les updates, retourner sur “all updates” :
L’application des updates est bien disponible ici, cliquez sur “Apply x Updates” pour lancer l’assistant de connexion au vCenter car sur ce cluster les hôtes sont des ESXi :
Entrer les informations de connexion au vCenter qui héberge les machines concernées par l’update:
Vous devriez constater de mutiples vMotion afin de libérer les noeuds, puis l’operation d’upgrade debute, il faut etre patient c’est assez long.
L’opération s’est terminé pour moi en un peu moins de 2h pour 3 noeuds.
Je suis content de constater qu’il n’y a pas que le hardware nutanix concerné par LCM et que les OEM ont de plus en plus de composants supporter par ce superbe outil qui fait vraiment gagner en OPEX.
SRM 6.5 SRA HP 3PAR
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 :
SRM 6.5 SRA Hitachi HDS
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.
Rename SRM Site (6.5)
L’opération de renommage de site est encore simplifié dans cette dernière version !
Plus de fichier xml à modifier, plus d’édition des paramètres avancés, maintenant c’est clic droit > renommer 🙂
Bon apparemment c’était déjà le cas en 6.1, mais je n’ai jamais pratiqué cette version : Rename a Site Recovery Manager Site.