Archive pour la Catégorie: ‘SRM

10 articles trouvés dans cette archive
Août/12140
Par Dans SRM

Avec pas mal de retard, voici une synthèse de la session que j’ai présenté au PEX 2012 sur la partie vSphere Replication.

La réplication software asynchrone appelée « vSphere Replication » est apparue avec la version 5.0 de SRM. Les VMs peuvent ainsi être répliquées quel que soit le système de stockage sous-jacent et même entre des datastores hétérogènes. Il faut pour cela des composants supplémentaires à l’infrastructure SRM.

Lire la suite…

Sep/11150
Par Dans SRM

Aujourd’hui c’était la sortie GA de VMware Site Recovery Manager 5.0 (la Release Note) pas de changement depuis l’annonce à un détail près: les licences.

Depuis la version 4.1, on était passé d’un modèle par CPU d’ESX protégé à un modèle par VM protégées (par pack de 25 VMs).

 

Comme expliqué dans les KB2000394, KB2005000 & KB2000868 : on a maintenant 2 gammes de licences Standard & Enterprise:

Fonctionnalités Standard Enterprise
Prise en charge réplication coté Stockage
Plans de Reprise Centralisés
Test sans interruption
DR Failover automatisé
réplication vSphere
DR Failback automatisé
Migration Plannifiée
Nbre max de VMs protégés par site 75 VMs unlimited

Pour les migrations de licences des clients VMware SRM sous contrat de maintenance à jour, l’upgrade et la conversion de licences sont gratuites:

  • Les licences SRM 4.1 par VMs protégées => licences SRM 5 Enterprise par VMs protégées (Exemple: 1 licence SRM 4.1 pack 25 VMs = 1 licence SRM 5 Enterprise pack 25 VMs)
  • Les licences SRM 4.0 (ou inférieur) par CPU d’ESX protégés = 5 VMs protégées sous SRM 5 Enterprise (Exemple: 6 licences SRM 4.0 1 CPU pour 3 ESX bi-proc = 1 licence SRM 5 Enterprise pour 30 VMs)
Août/1113
Par , Dans SRM

Lors de la mise en place de PRA avec VMware Site Recovery Manager, il est plus qu’utile mettre en place des routines pour vérifier que les services applicatifs contenu sont bien repartis. Pour cela le produit inclut la possibilité de lancer des scripts, cependant si les commandes des scripts sont passées à travers le réseau elles sont incompatible avec le mode « Test » de SRM. En effet, lors du mode « Test », les VMs sont démarré dans un réseau isolé qui ne peut communiquer avec le serveur SRM qui doit lancer les scripts. Il est alors impossible de vérifier le bon fonctionnement des scripts.

Il y a cependant une solution: c’est d’utiliser VIX pour demander à la couche de virtualisation de lancer un script local aux VMs. Cette fonction est disponible en PowerCLI avec le cmdlet Invoke-VMScript. Pour info, cette partie sera intégré dans la prochaine version: SRM5.

Je vais donc présenter un exemple de lancement de scripts pour réaliser cela à l’étape « Post Power-On » des VMs. Il faut faire appel à plusieurs scripts qui en appel d’autres, l’important est d’être capable de récupérer les codes retour d’erreurs entre les différents contextes pour qu’ils soient prises en compte comme résultat par SRM.

Pour commencer, voici un synopsis de la communication en différents scripts et le traitement des codes retour:

Lire la suite…

Juil/1114

Et la génération 5 de VMware se décline aussi sur SRM: Site Recovery Manager 5. Les nouveautés sont expliquées dans un fichier PDF: « What’s New in VMware vCenter Site Recovery Manager 5.0« .

Même si l’on peut conserver l’ancienne manière de fonctionner, la partie Host-Based Replication modifie quelque peu l’architecture mise en place pour la réplication. Dans ce cas, il faut :

  • une virtual appliance de gestion:  vSphere Replication Management Server par site (vRMS). Elle contient la configuration de la réplication. La vRMS est enregistré en tant que plugin dans vCenter et stocke la configuration dans une base de données (SQL Server, Oracle ou DB2);
  • des agents: vSphere Replication Agent au niveau des hyperviseur (vRA). L’agent est situé dans les ESXi5 et surveille les changements sur les vDisks qui sont marqué à protéger, il envoie les modifications vers le site de secours;
  • et un serveur de réplication: vSphere Replication Server sur le site secours (vRS). Cette virtual appliance recoit les différences de modification à partir des vRA du site protégé.

Lire la suite…

Juil/11110
Par , Dans IBM, SRM

Pour pouvoir piloter les baies de stockage répliquées dans le cadre d’un PRA avec VMware SRM, il faut s’appuyer sur un SRA (Storage Replication Adapter) fournit par VMware mais développer par le constructeur de la baie. Voici quelques explications sur la configuration du SRA pour SVC (SAN Volume Controller) d’IBM.

Le SRA d’SVC communique avec le CIM Agent des contrôleurs SVC grâce au IBM Storage Service (installé en même temps que le SRA), cette partie contient un ensemble de 5 scripts Perl correspondants aux actions réalisé par SRM:

  • command.pl
  • discoverArrays.pl
  • discoverLuns.pl
  • testFailover.pl
  • failover.pl

Si la version de firmware SVC est 4.3.1.7 ou supérieur, le CIM agent est embarqué directement au niveau du code SVC dans les noeuds du cluster, on utilise alors directement l’adresse IP des cluster SVC. Sinon en version inférieure à 4.3.1.7, le CIM agent correspond à la console SSPC (il faut dans ce cas une master console par Cluster).  Dans les 2 cas, lors de la configuration de l’array dans SVC, il faudra préciser l’adresse IP avec le port 5989.

Pour la configuration SVC, se reporter au RedBook d’IBM : SAN Volume Controller – Best Practices and Performance Guidelines.

Lire la suite…

Juin/11280

Malgré que vous vous authentifiez bien, vous rencontrez des problèmes d’authentification dans Site Recovery Manager avec les cas d’erreur suivants:

Lorsque vous vous connectez à la partie SRM dans l’interface vCenter, vous avez le message d’erreur « Unable to login« .

Puis lorsque que lorsque vous essayer de modifier un paramètre, vous avez les message d’erreur « Connection to local Site Recovery Manager https://xxxxxxxxx:8095/dr lost. » et « Lost connection to remote vCenter Server du to invalid credentials. »

Il faut bien entendu vérifier les points suivants:

  • Le mot de passe est correcte 😉
  • vous utilisez un compte du domaine (avec la syntaxe DOMAINuser)
  • que lors de l’installation vous avez renseignez un compte domaine avec la syntaxe DOMAINuser (sinon faire un repair de l’install pour le modifier)

Mais le problème peut tout simplement venir (comme pour moi) du faite de lancer le vSphere client (avec le plugin SRM) en local sur le vCenter. Il ne faut donc pas ce connecter sur le localhost mais bien sur le nom du serveur vCenter.

Juin/1190

Généralement, en vue d’un PRA, l’infrastructure est déportée sur 2 salles. Et souvent, on part sur un premier stockage dans une salle, puis on le sécurise avec un autre dans la salle de secours. Mais la gestion en reste de façon globale aux 2 salles (infrastructure horizontale), ce qui est un bon début pour un PRA mais pas forcément automatisé.

Le produit VMware Site Recovery Manager est un produit gérant l’ordonnancement du PRA. Pour cela, il faut avoir un stockage (compatible SRM) répliqué entre 2 salles et surtout il faut que l’infrastructure virtuelle soit scinder en 2 salles pour qu’elles puissent fonctionner de façon autonome (permettant de faire repartir la Prod dans l’autre salle). Et c’est la qu’une évolution progressive d’une infrastructure virtuelle en vue d’un PRA, ne correspond pas à une architecture convenable pour SRM. C’est la justement qu’il va falloir verticaliser l’infrastructure pour la rendre compatible SRM.

Je ne vais pas m’étendre sur les pré-requis stockage ni d’installation de SRM. En partant d’un exemple concret, je vais plutôt expliquer le mode opératoire pour basculer une infrastructure virtuelle horizontale vers une infrastructure virtuelle verticale.

Donc partons de l’exemple ci-dessous, qui contient un premier vCenter dans une salle qui administre un ensemble de serveurs ESX pour les VMs Serveurs formant un Cluster entre 2 salles et un second vCenter dans l’autre salle qui administre un ensemble de serveurs ESX pour des VMs View formant un Cluster entre 2 salles:

Lire la suite…

Juin/1170
Par Dans SRM

Voici un petit schéma des ports de communication utilisé par SRM (Cf. la KB1012382):

Tous les communications sont de types TCP.

Si vous avez un firewall entre les 2 sites, attention tout de même à la configuration du firewall sur les sessions rémanentes. Sinon le Paired Site risque de passer souvent en « Disconnected ».

Oct/1090
Par Dans KB, SRM

Voici le Top 10 des KB utilisés par le support VMware pour Site Recovery Manager:

  1. KB1012382: Ports TCP et UDP pour l’accès Management
  2. KB1009073: Impossible de prendre un Snapshot Quiesced d’une VM
  3. KB1013166: Processus de mise à jour de SRM 4.0
  4. KB1016875: SRM – établissement de la réciprocité : « Error Permission to perform this operation was denied. You do not hold privilege « System.View » on ServiceInstance « DrServiceInstance »
  5. KB1021491: SRM: la configuration réseau d’une VM récupéré pendant le « testFailover » ou le « Failover » l’opération plante avec l’erreur « Network Device Not Found »
  6. KB1020796: Impossible d’ajouter une P2V VM à un protection group SRM
  7. KB1019890: VMware Site Recovery Manager, le Test Failover donne un times out avec le DRS activé
  8. KB1008283: Certain Arrays peuvent nécessité un second Rescan pendant le mode Test et le mode Recovery de SRM
  9. KB1025564: NetApp/IBM N-Series Disaster Recovery Adapter 1.4.3 donne l’erreur « Api nfs-exportfs-list-rules-2 requires license for nfs or flexcache_nfs »
  10. KB1019839: SRM, Impossible de récupérer un Datastore
Juil/105
Par , Dans SRM

La montée de version de VMware Site Recovery Manager 4 est documentée mais elle n’est pas bien détaillée sur le partie SRA.

Il faut quand même ce référer à la doc pour valider la compatibilité entre les versions et les pré-requis sur les certificats.

Niveau du mode opératoire, on fait d’abord le site protégé puis le site de secours. Il faut désactiver et désinstaller le SRA. Pour la partie mise à jour des ESXs et des VMs cela peut être fait n’importe quand après la mise à jour du vCenter, le plus simple est de le faire une fois que la partie SRM est opérationnelle. Normalement après redéfinition de la relations entre les vCenters dans SRM, vous devez retrouver vos PGs & RPs (garder une trace au cas ou vous devez les recréer).

Voici le mode opératoire à suivre pour mettre à jour une infra VI3 avec SRM en vSphere avec SRM4:

  1. Sauvegarder la base de données SRM des 2 sites
  2. Désactiver la configuration de la partie « Array Manager » dans SRM
  3. Désinstaller le SRA du site protégé
  4. Upgrader le vCenter du site protégé
  5. Upgrader SRM du site protégé
  6. Installer le nouveau SRA du site protégé
  7. Désinstaller le SRA du site de secours
  8. Upgrader le vCenter du site de secours
  9. Upgrader SRM du site de secours
  10. Installer le nouveau SRA du site de secours
  11. Upgrader le SRM plugin dans le vSphere Client
  12. Configurer la relation entre les vCenters (pair vCenter)
  13. Configurer la partie « Array Manager » dans SRM
  14. Installer les licences SRM dans les vCenter
  15. Upgrader les serveurs ESX des 2 sites
  16. Mettre à jour les VMware Tools et le Virtual Hardware des VMs

Pour plus d’info, il y a une KB 1013166: FAQ Upgrade SRM 4 & un échange intéressant sur la communauté VMTN.