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:

Ce que l’on souhaite obtenir (avant la mise en place de SRM) c’est que chaque vCenter n’administre que les serveurs ESX de sa salle en conservant un Cluster Serveur et un Cluster Poste de Travail. Les 2 vCenters pourront au final être lié en Linked-Mode pour en simplifier l’administration globale. Voici le schéma de l’infrastructure après verticalisation:

Voici le mode opératoire pour arriver à ce résultat:

Migration des ESXs pour les VMs Serveur

• Renommer les DataCenters dans les 2 vCenters
• Ajouter les licences des serveurs ESXs dans le vCenter2 (dans « Administration > Licensing > Manage vSphere Licenses« )
• Créer un Cluster SRV2 dans le vCenter2 avec les mêmes paramètres que le Cluster SRV dans vCenter1
• Renommer le Cluster SRV en SRV1 dans vCenter1
• Mettre la configuration DRS des 2 Clusters SRVx en Manual (temporairement pour éviter le déplacement des VMs pendant la verticalisation)
• Enlever du vCenter1 les ESXs à migrer vers le vCenter2 (les VMs peuvent rester allumées, pas de coupure pendant la migration)
  • faire un « Disconnect« 
  • puis un « Remove« 
• Sur le Cluster SRV2 dans vCenter2, faire un « Add Host » pour le premier serveur ESX
  • renseigner le compte root,
  • valider l’avertissement du certificat,
  • sélectionner la clé de licence à affecter,
  • sélectionner « Create a new ressource pool for this hosts… » pour conserver la structure des Ressources Pools
  • et valider
• Modifier la structure des Ressources Pools en fonction de la structure attendue
• Répéter l’opération d’ajout d’ESX pour tous les ESXs et déplacer les VMs dans les bons Ressources Pools
• Remettre la configuration DRS des 2 Clusters SRVx en Auto
• Supprimer les licences des serveurs ESXs plus présent dans vCenter1 (dans « Administration > Licensing > Manage vSphere Licenses« )

Migration des ESXs pour les VMs View

• Créer un Cluster PdT1 dans le vCenter1 avec les mêmes paramètres que le Cluster PdT dans vCenter2.
• Renommer le Cluster PdT en PdT2 dans vCenter2
• Ajouter les licences des serveurs ESXs pour View dans le vCenter1 (dans « Administration > Licensing > Manage vSphere Licenses« )
• Si vous n’avez d’un seul View Connection Server, installer un View Connection Server de type Replica dans le Cluster PdT2 (on le migrera de coté avec la migration des ESXs)
• Ajout le serveur vCenter1 dans la configuration View Manager
  • Dans l’interface View Manager, aller dans « Configuration > Servers« 
  • Dans la partie « vCenter Servers« , cliquer sur « Add« 
  • Renseigner les informations de connection au vCenter1 et cliquer sur « OK« 
  • Vérifier qu’il n’y a pas d »erreur dans les Events et que le vCenter1 est bien présent dans la liste des serveurs vCenter utilisé par View Manager
• Mettre la configuration DRS des 2 Clusters PdTx en Manual (temporairement pour éviter le déplacement des VMs pendant la verticalisation)
• Vérifier que la VM View Connection Server Replica soit sur un des ESXs à migrer vers vCenter1
• Enlever du vCenter2 un premier ESX à migrer vers le vCenter1 (celui contenant le second View Connection Server)
• Sur le Cluster PdT1 dans vCenter1, ajouter l’ESX pour View (même procédure que précédemment)
• Si besoin modifier les Ressources Pools en fonction de la structure attendue
• Récupérer les différents paramètres des bureaux virtuels de cette ESX avant la suppression de la connexion (dans Summary, Monitors, Entilement et Policies)
• Supprimer la définition de connexion aux bureaux virtuels sur cette ESX (les utilisateurs ne perdent pas leur connexion)
  • Dans View Manager, aller dans « Global Desktop and Pool View > Desktops and Pools« 
  • Se positionner sur le bureau virtuel et cliquer sur « Delete« 
  • Sélectionner « Remove from View Connection Server Only » & « Leave Active » et cliquer sur « OK« 
• Recréer la définition de la connexion aux bureaux virtuels (avec le nouveau vCenter)
  • Dans View Manager, aller dans « Global Desktop and Pool View > Desktops and Pools » et cliquer sur « Add« 
  • Sélectionner « Individual Desktop« 
  • Puis « vCenter Virtual Machine« 
  • Sélectionner le nouveau vCenter: vCenter1
  • Renseigner l’identifiant et le commentaire de poste précédemment détaché
  • Saisir tous les paramètres préalablement récupérés
  • Choisir dans la liste la VM correspondant au Bureau Virtuel
• Redéfinition des utilisateurs accédant à ce Bureau Virtuel
  • Toujours dans « Global Desktop and Pool View > Desktops and Pools« , se positionner sur le Bureau Virtuel et cliquer sur « Entitlement« 
  • Cliquer sur « Add » pour ajouter le(s) utilisateurs et groupe(s) précédemment attaché à ce bureau virtuel
• Vérifier également les policies
• Répéter les opérations de réaffectation pour tous les Bureaux Virtuels de l’ESX migré
• Répéter les opérations pour tous les ESXs à migrer dans vCenter1
• Remettre la configuration DRS des 2 Clusters PdTx en Auto
• Supprimer les licences des serveurs ESXs qui ne sont plus présent dans vCenter2 (dans « Administration > Licensing > Manage vSphere Licenses« )

Interconnexion des vCenters

• Sur un des vCenters, par exemple vCenter2, se connecter avec un compte ayant des droits admin du domaine
• Lancer l’assistant Linked-Mode (dans « Start > All Programs > VMware > vCenter Server Linked Mode Configuration« )
• Sélectionner « Modify linked mode configuration« 
• Puis sélectionner « Join this vCenter Server instance to an existing linked mode group or another instance« 
• Renseigner le nom du vCenter à rejoindre (ici vCenter1) et laisser le port LDAP par défaut
• S’il y a des conflits, vous pouvez le laisser les résoudre avec « Yes, let VMware vCenter Server resolve the conflicts for me« 
• Cliquer « Finish » et attendre quelques minutes pour que la réplication soit opérationnelle

Et voila l’infrastructure virtuelle a été verticalisé, elle est maintenant prête pour la mise en place d’un PRA avec SRM.

Articles complémentaires:

1. séparation d'une infra en 2 vCenter
2. Resignature sur toute une infra VI3
3. Erreur 28039 à l'ajout d'un vCenter en linked Mode
4. la gamme ThinPrint pour View
5. View pour iPad