Introduction

Une solution de PRA dans le Cloud public utilise une technologie de virtualisation (Xen ou KVM) généralement différente de l'hyperviseur source (souvent VMware/Hyper-V).

Lors de la remontée des infrastructures de nos clients dans le Cloud lors de tests de PRA, cette différence est la cause de la non remontée automatique de certains disques dans Windows.

Cela empêche les services, dont les données se trouvent sur ces disques, de démarrer et nécessite une intervention humaine qui peut avoir un impact sur le RTO du serveur et ajouter une charge de travail dont les équipes techniques se passeraient bien.

Qui plus est, lors de l'activation des serveurs, ils peuvent ne pas avoir la bonne lettre disque associée et chaque lettre de lecteur est à changer. Ceci peut arriver quand le serveur a été configuré avec des lecteurs dont les lettres ne suivent pas l'ordre alphabétique : un serveur utilisant les disques C: U: et W:.

Online Disk, Root Cause Analysis

Depuis Windows Server 2008 R2, le mécanisme d'activation de disque ne place pas ceux-ci en ligne automatiquement afin d'éviter de corrompre les données de disques partagés ou liés à un cluster de fichiers.

 

En bref et plus globalement, ce paramètre affecte tous les disques SCSI dont l'identifiant matériel n'a pas encoré été reconnu au préalable par l'OS.

Notre solution utilisant un Cloud public pour fournir l'infrastructure sur laquelle nous restaurons les données, nous n'avons pas le choix des identifiants matériels présentés aux OS invités.

Donc un disque sauvegardé, qui in-situ est connecté en IDE ou SATA, sera présenté sous forme de disque Virtuel KVM ou Xen lors de sa restauration (en fonction du besoin de performances de la machine), changeant au passage d'identifiants matériels : il est donc bloqué au démarrage par cette protection de disque Windows.

Correction et industrialisation

Afin d'éviter ce problème, il nous a fallu trouver un moyen de le corriger et d'automatiser cette correction pour l'intégrer dans notre processus d'industrialisation.

Le mécanisme de gestion des disques est normalement piloté via les outils diskpart (CLI) et la console diskmgmt.msc (GUI). 

Cependant, la correction doit avoir lieu avant le premier démarrage de la machine restaurée, donc à l'instar de l'injection de drivers, il s'agit de modifier le paramètre approprié sans que l'OS ait démarré.

Pour ce faire, il nous est nécessaire d'éditer la base de registre de la machine restaurée, et d'y changer les paramètres de gestion de disques.

Nos investigations ont menées à deux clés de registres : 

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mountmgr
  • propriété "NoAutoMount" => a placer à "0" (DWORD)
    • On change ce paramètre afin d'éviter un blocage du montage des disques, analogue à une sécurité que l'on retire.
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\partmgr\Parameters
  •  propriété "SanPolicy" => à placer à "1" (DWORD)
    • Ici, on change le comportement de Windows quand un nouveau disque est branché, 1 équivalant à "tous les disques en ligne" (OnlineAll)

Edition de Hive registre Windows hors-ligne pour automatisation

Lors du montage de la hive HKLM d'un serveur restauré, le petit détail qui vient mettre un grain de sable dans la machine, c'est que sous "HKLM/SYSTEM", il n'existe pas de clé "CurrentControlSet".

En effet, Windows ne stocke dans la Hive que les clés "ControlSet1" et "ControlSet2". "CurrentControlSet" est en fait un lien symbolique vers une des deux sous-clés, l'autre servant de "dernière configuration valide avec lequel le système à démarré".

Gestion de lettres de lecteur et orchestration

Si nous nous en tenons la, les disques remontent tout seul, mais rapidement un autre problème apparait dans certains cas : les disques s'activent bien, mais avec des lettres différentes de celles prévues à la base.

Le lecteur W: est remonté sur D:, et F: remonté sur E: ...

Cela n'aide pas beaucoup un administrateur qui devra encore effectuer ce travail de remise des lettres à la main.

Root cause analysis 2 : le retour

L'association entre une partition et sa lettre de lecteur est enregistrée sous "HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices".

A chaque lettre de lecteur est associé une clé de registre, qui conserve la signature de la partition vers laquelle elle pointe.

Par exemple : "\DosDevices\G:"=*Du binaire sous forme hexadécimale ici*

Si aucune lettre ne corresponds à une partition, par exemple lors de l'ajout d'un nouveau disque, Windows assigne la prochaine lettre disponible dans l'ordre alphabetique et enregistre la signature dans une nouvelle clé.

Automatisation de la réparation

Dans notre modèle, chaque lecteur Windows est restauré séparément, il nous est donc possible, en fin de la restauration, d'extraire la nouvelle signature d'un disque restauré.

Lorsque tous les lecteurs d'une machine ont fini leur restauration et nous disposons de toutes les signatures, une étape supplémentaire à été ajoutée au processus automatisé afin de

1. monter le disque système de la machine
2. monter le registre HKLM restauré
3. écraser les précédentes clés de registre avec les nouvelles signatures.

Conclusion

Toute cette procédure a pour but de consacrer le moins de temps possible à exécuter un processus automatisable afin d'éviter une perte de temps humain lors de la restauration de l'infrastructure d'un client.

J'espère que cela vous permets de voir le résultat technique d'une periode de recherche et développement face à un problème que nous avons rencontré à de multiples reprise.

Si cela vous interesse d'en savoir plus, venez dire bonjour sur notre Twitter @nuabee_fr !