Quand un PRA tourne mal et vire au cauchemard … PART 2

Good morning virtual addicts …

 

Comme promis je vous écris la deuxième partie de mes aventures cauchemardes sur la mise en place d’un PRA (Plan de Reprise d’Activité) sous Hyper-v 2012 et SC Virtual Machine Manager 2012 SP1.

 

Pour ceux n’ayant pas lu la premère partie, je vous invite à vous rendre sur la page suivante : http://bit.ly/1igcWcK

 

 

Lorsque vous mettez en place une infrastructure virtuelle hautement dispo sous Hyper-v digne de ce nom (cela dépend du besoin client bien évidemment) : cluster x noeuds avec 2 baies de stockage SAN en mode mirroring répartis sur 2 salles, il est indispensable de bien se poser toutes les bonnes questions, de vérifier qu’en cas de crash ou de destruction du premier site, la continuité de service de votre SI s’effectuera sans impacter votre coeur de métier et vos utilisateurs.

 

Lorsque mon client a souhaité déployer un PRA sur tous ses sites distants, je me suis remémoré une expérience passée chez un Grand Compte où j’avais effectué une mission similaire mais là entre 2 Datacenter : cluster 6 noeuds Hyper-v avec 2 baies de stockage EMC de type SAN en mode asynchrone. Nous avions préparé le terrain à l’avance en auditant les besoins, les configurations apportées, toutes les actions devant petre réalisées le jour J du test du PRA. Résultat des courses : cela a été un succès du fait de la coordination des opérations et des équipes.

 

Pour en revenir à nos moutons, il y a des actions importantes et primordiales qu’il vous faut prendre en compte :

  • Déployer un cluster avec un nombre de noeuds pair
  • Disposer de serveurs de marque identique et de même configuration
  • Se procurer des baies de stockage utilisant le mirroring
  • Installer tous les noeuds avec la même version d’OS
  • Avoir tous les noeuds à jour en termes de patchs et d’hotfix
  • Vérifier que le Live Migration fonctionne
  • Paramétrer les propriétés des VM lors de la bascule
  • Mettre en place les baies de stockage avec la fonction mirroring
  • Créer et déclarer les LUN de chaque côté avec les mêmes ID
  • Initialiser la synchronisation stockage

 

C’est à partir de ce moment que ce beau projet tourna au cauchemard … Je rentre donc dans les détails pour vous expliquer la tournure.

Pour information, heureusement que le PRA fut joué en environnements de développement afin de s’assurer de la solution pérenne.

Une fois l’infrastructure mise en place, nous avons joué avec le client la situation de PRA. Nous avons alors crashés volontairement la première baie de stockage afin de valider le fait que les LUN mirrorées prennent le relais sur la seconde baie et que le Live Migration bascule l’ensemble des VM sur les serveurs de l’autre salle. Le résultat fut catastrophique …

  • Perte de toutes les VM de tests
  • Impossibilité de les récupérer
  • Les machines virtuelles se sont mises en Save State
  • Les CSV n’ont pas récupéré le même nom de volume
  • Non synchronisation des LUN

 

 

Vous vous imaginez la situation et les sueurs froides commençant à couler le long de votre visage. Comment en était-on arrivé là ? La personne ayant mis en place le stockage vérifia pendant quelques minutes la configuration et là bingo. Les LUN mirrorées sur la seconde baie n’avaient pas le même ID que celles déclarées sur la première baie. Par conséquent, il était normal que les CSV prennent un autre nom de volume et donc que les VM ne soient plus accessibles et fonctionnelles : la configuration avait été modifiée …

 

En revanche, pourquoi mes machines virtuelles étaient-elles en Save State ? Pour rappel, j’ai déployé un environnement SCVMM 2012 SP1 pour gérer mon cluster et créer / gérer mes VMs. Normalement, en cas de crash d’un hôte physique, les VMs devaient :

  • S’éteindre proprement
  • Redémarrer automatiquement

 

J’ai donc affiché les propriétés de mes VMs et là j’ai remarqué que les choix voulus n’étaient pas paramétrés correctement. Plus précisément, en cas de crash de mon hôte Hyper-v 2012, la machine virtuelle se mettait en Save State. Pourquoi cela … Je me suis souvenu que ma VM avait été déployée via VMM et non via ma console Clustering. En effet, lorsque vous déployez un ordinateur virtuel depuis SCVMM, il s’avère que vous n’avez pas la possibilité de configurer les paramètres de “PRA” dans les propriétés de la VM en cas de panne d’un hôte de virtualisation. Le Save State était donc normal étant donné que les Settings par défaut étaient choisis.

 

 

 

Je vais donc vous décrire ci-dessous les solutions trouvées :

 

Situation 1

Les serveurs Hyper-v n’avaient pas accès sur Internet. Par conséquent, il m’était assez difficile de les mettre à jour. Comme vous le savez, lorsque l’on déploie une infra virtuelle hautement disponible, il y a plusieurs hotfix et patch Hyper-v-Cluster à installer sur tous les noeuds afin de corriger certains bugs stockage, réseau ou même système. Il me fallait donc absolument les déployer. Après réflexions, j’ai pu trouver un contournement. En effet, je disposais d’un serveur Hyper-v standalone en 2012 R2 ayant une patte sur Internet. J’ai donc créé un switch virtuel bindé sur la carte physique externer. Une fois le commutateur finalisé, je me suis empressé de déployer un serveur virtuel WSUS Windows Server 2012 paramétré avec deux cartes virtuelles : une sur le LAN entreprise et une sur l’extérieur. Grâce au WSUS, j’ai pu mettre à jour tous mes noeuds afin de bénéficier des derniers hotfix.

 

 

Situation 2

Lorsque vous mettez en place du mirroring stockage au niveau de 2 baies SAN, il est nécessaire et primordial que vos LUN déclarées sur les baies aient les mêmes ID afin qu’en cas de perte d’une première baie, la seconde prenne le relai avec les bons ID et récupère les mêmes noms de volumes au sein de votre cluster Hyper-v. Cela vous évitera ainsi de perdre l’intégralité de vos VMs étant donné qu’en cas de changement de noms de volumes, l’accès au VHDx sera modifié.

Pour faire suite à cette situation, je vous prépare un post sur comment les CSV se voient attribués leur nom au sein du cluster.

 

 

Situation 3

Comme indiqué ci-dessus, mes machines virtuelles se mettaient en Save State en cas de crashs d’un hôte de virtualisation Hyper-v, ce qui n’était pas souhaitable étant donné que dans cet état, la machine virtuelle crée un fichier VSV : celle-ci ne pouvait plus redémarrer étant donné que le nom de volume avait été changé par la mauvaise configuration de l’ID au niveau des LUN. Par précaution, j’ai ouvert la console Failover Clustering afin de modifier le comportement des VMs :

 

Untitled

 

Untitled1

 

 

Une fois toutes ces solutions mises en place, notre PRA a fonctionné parfaitement et le client a été super content.

 

J’espère en tous cas que mon post et mon expérience vous sera utile lorsque l’un de vos client vous demandera de mettre en place un PRA avec Hyper-v. En tous les cas, je vous souhaite bon courage …

 

 

 

David LACHARI – Le savoir ne vaut que s’il est partagé …

becloud

Passionné par la virtualisation, David est MVP Virtual Machine depuis 2010. Il intervient quotidiennement auprès de grands comptes afin de définir et déployer des architectures virtuelles. David est le fondateur de la société VSTART, spécialisée dans le conseil et l’expertise des solutions de virtualisation Microsoft.
Non classé

becloud

Passionné par la virtualisation, David est MVP Virtual Machine depuis 2010. Il intervient quotidiennement auprès de grands comptes afin de définir et déployer des architectures virtuelles. David est le fondateur de la société VSTART, spécialisée dans le conseil et l’expertise des solutions de virtualisation Microsoft.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *