ALERTE performance :  la classe Win32_OperatingSystem !

La  classe WMI Win32_OperatingSystem est très populaire (à juste titre) chez les administrateurs système. Elle est fréquemment utilisée par exemple pour exécuter des actions spécifiques ou appliquer des stratégies de groupes (GPO)  spécifiques à une version  de Windows.

Cette classe (cf http://msdn.microsoft.com/en-us/library/aa394239(v=vs.85).aspx ) semble bien anodine et ne « collecte » que des « informations statiques » .

C’est sans compter avec le champ NumberOfProcesses !

Pour déterminer la valeur de NumberOfProcesses, le provider WMI fait lui-même une requête WMI  « SELECT __RELPATH FROM Win32_Process  »  qui charge considérablement le système.

Par exemple sur un « large serveur » RDS/Citrix avec :

• Plusieurs GPOs ayant un filtre du type :Select * FROM Win32_OperatingSystem WHERE Version like '6.3%'

• De scripts de logon avec des « select * Win32_OperatingSystem »

• Des « brokers » ou des outils de monitoring exécutant des « Select * from Win32_Process »

• De nombreux « logon »

Vous observerez rapidement :

• une forte consommation CPU dans le process WMIPRVSE

• des temps de « logon » important

• une forte contention « kernel »  liée à l’énumération des processus qui peut avoir des conséquences diverses et variées (lenteur lors du lancement du gestionnaire de tâches,…)

La solution est de limiter les champs retournés par la requête WQL. Le provider de la classe Win32_OperatingSystem ne collecte alors que les infos demandées. La requête « select Version from   Win32_OperatingSystem » n’énumère pas  la liste des processus.

Tip :

L’activation du tracing « WMI-Activity » (http://msdn.microsoft.com/en-us/library/aa826686(v=vs.85).aspx) permet d’identifier ce type de problème.

Travaillons aujourd’hui sur un autre scénario assez simple : Celui de la suppression accidentelle d’une partition.

Supposons que cette partition

soit devenue

Comme d’habitude, on contrôle les secteurs habituels et on voit celui qui pourrait manquer.

Au secteur 0, on a un MBR montrant une partition GPT qui occupe tout le disque

Au secteur 1, on retrouve un GPT Header :

Données:

• Sector Signature : EFI PART
• Version 0.1
• Header Size : 5C
• CRC32 of the Header : 2153345396
• Current / Alternate GPT Header : 1 / 266338303
• First / Last Usable LBA : 34 / 266338270
• Disk GUID : {04D4F64A-0F7B-49CE-9013-CF4EF9121641}
• Partition Table Address : 2
• Partition Count : 128
• Partition Table Entry Size : 128
• CRC32 of Partition Table : 1583197318

Et le secteur 266338303 montre la même chose.

Le secteur 2 nous montre une table de partitions ne contenant que la partition MSR (comme quoi, rien n’est perdu), et le secteur 266338271 (Last usable +1) nous montre la même chose.

Allons donc voir si une partition NTFS pourrait trainer sur le disque.

Comme la partition MSR finit au secteur 262177, on devrait en trouver une plus loin, en principe aligné sur 64KB.

C’est au secteur 264192 que nous allons la trouver

Total Sectors : 266072063 (~126.8 GB) : Le secteur de fin devrait se trouver 266336255 ( = 266072063 + 264192 )

Clusters to MFT / MFTMirr : 786432 (LBA 6555648 = 264192 + 8*786432 ) / 2 (LBA 264208 = 264192 + 8*2)

Et ce sont bien des entrées de MFT que l’on trouve à ces secteurs:

Résumons-nous :

• LBA 0 : La partition GPT
• LBA 1 et Backup : Les GPT Headers
• LBA 2 et Backup : Une table de partition ne contenant que la partition MSR
• LBA 264192 et 266336255 : Encadrent la partition NTFS

En principe, comme pour une partition MBR :

• Sauvegarder le 1^er secteur de la partition NTFS
• Créer une partition occupant tout le disque sans la formater
• Ecraser le 1^er secteur de la nouvelle partition NTFS par celui précédemment sauvegardé.

Quand vient le moment de formater, ne pas formater.

A ce moment-là, le secteur 264192 a été vidé de son contenu (puisque nous n’avons pas fourni de file system)

En écrasant ce secteur par celui que nous avons sauvegardé, c’est comme si nous formatons la partition.

DskProbe.exe permet d’écraser un secteur du disque.

Après vérification rapide (secteur de fin de partition, MFT, MFTMirr) un rescan du disque fait revenir la partition comme par magie.

Serge Gourraud
55 AA

Maintenant que nous avons vu les structures qui décrivent les partitions des disques basiques GPT, voyons où nous pouvons rencontrer une corruption et comment la réparer (ou pas)

Si nous reprenons notre schéma, une corruption pourrait arriver :

• Dans le MBR
• Dans le GPT Header
• Dans la table de partition (qui occupe les secteurs 2 à 33)
• Dans les NTFS Boot Sectors
• Dans la MFT (utiliser chkdsk)

La structure GPT est très robuste en ceci que windows maintient une consistance entre les GPT Header de début et de fin, ainsi que dans les tables de partitions de début et de fin, de façon à ce que si quelqu’un vient à supprimer l’un d’eux, il sera réparé au moins au prochain reboot.

La partie non protégée est le MBR (secteur 0) et c’est jusqu’à présent la seule corruption que j’ai eu à réparer sur des disques GPT Basiques.

Nous n’allons donc voir que deux types de corruption

• MBR
• Partition Table
• NTFS : Déjà couvert dans les parties précédentes.

Premier type de corruption (le seul déjà rencontré au support) : Vidage du MBR

Voilà à quoi cela ressemble dans le gestionnaire de disque :

A l’éditeur hexa, on ne voit que des 00:

Le secteur 1 contient bien ce qui ressemble à un GPT Header

Ses données semblent correctes

Si on ouvre le GPT Header alternative, on retrouve les mêmes données :

Si on parcours la table de partition (LBA 2) on trouve une table de partition contenant la MSR et 3 partitions de données. Dans mon cas, je n’ai que 3 partitions sur mon disque donc, les autres LBAs (jusqu’au 33) sont vides.

On peut reporter les données dans ce tableau (pour l’interprétation, se référer au chapitre précédent)

Dans le cadre d’une réparation, il faut bien vérifier que les secteurs 264192/184416255 , 184416256/245854207 et 245854208/266334207 sont des secteurs NTFS et contrôler qu’ils pointent bien vers une MFT a priori correcte. (nous avons traité ces points dans les articles précédents)

Donc:

• Les "GPT Header" principal et secondaire sont Ok
• Les "GPT Entries" des "Partition Table" principale et secondaire sont Ok
• Les structures NTFS sont Ok

Seul le MBR est à reconstruire

Il ne nous reste plus qu’à réparer le MBR en se souvenant qu’ils sont tous identiques.

En utilisant un éditeur hexa il reste à écrire ces données :

Et c’est tout. Un rescan du disque et on n’en parle plus.

Serge Gourraud
55 AA

Maintenant que les disques basiques MBR (partitions primaires et étendues) n’ont plus de secrets pour nous, nous allons nous intéresser au disques basiques GPT.

Reprenons le schéma qui décrit la structure d’un disque basique GPT et essayons de voir à quoi cela ressemble concrètement.

Commençons par le secteur 0:

Remarques:

• Il n’y a plus de signature. Nous n’en avons plus besoin car nous identifions désormais le disque par GUID, et cette information sera stockée ailleurs.
• Il n’y a qu’une seule entrée dans la table de partition, et ses propriétés sont telles que tout le disque est occupé.

Le MBR est dit “protecteur” car il contient une partition qui couvre tout le disque (Relative Sector 1 / Total Sectors FFFFFFFF), et aussi car nous avons des secteurs importants

Voici ce à quoi ressemble le secteur 1 : 

Ce secteur est le GPT Header et contient ces informations :

Toutes les données sont importantes, mais celles qui nous intéressent pour faire des réparations sont :

• La signature ("EFI PART") : Pour reconnaitre le secteur (nous n’avons plus de 55 AA)
• Les CRC32 : Ceux-ci sont importants car ils permettent au système de vérifier que quelqu’un n’a pas modifié des entrées dans ses tables à la main, en by-passant le système.

• http://msdn.microsoft.com/en-us/library/dd905031(v=office.12).aspx

• L’adresse courante du header (1) et l’adresse du GPT Header alternatif (266338303)
• Le début de la table de partition (2) et le nombre de partition qu’elle peut contenir (128)
• Les 1ers et derniers secteurs utilisables (en général le dernier +1 contient le début de la table de partitions
• Un GUID qui représente le disque (sa signature)

Cette structure est décrite sur http://msdn.microsoft.com/en-us/library/windows/desktop/aa365449(v=vs.85).aspx

Regardons le secteur 2 : Début de la table de partition.

Il faut y voir 4 régions de 128 bytes chacune : Une entrée dans la table de partition fait 128 bytes

Dans le cas présent, les 2 premières entrées sont occupées et les autres sont vides

Première entrée

Seconde entrée

Vous pourrez trouver des informations complémentaires sur ces structures dans l’article http://msdn.microsoft.com/en-us/library/windows/desktop/aa365449(v=vs.85).aspx

Plus d’informations sur la Microsoft Data Partition (MSR) dans la FAQ GPT:

http://msdn.microsoft.com/en-us/library/windows/hardware/dn640535(v=vs.85).aspx#gpt_faq_what_is_msr

Donc, la première entrée est pour la MSR et la seconde pour la partition de données de type « Basic Data Partition ».

Puisqu’il s’agit d’une partition NTFS, nous pouvons trouver les NTFS Boot Sectors aux LBA 264192 et 266336255

Et voilà:

On peut y lire:

Déjà on retrouve notre signature 55 AA (qui commençait à manquer un des mes amis blogueurs)

• Le Relative Sector : 00 08 04 00 --> 00 04 08 00 = 40800 = 264192 LBA
• Total Sectors: FF EF DB 0F 00 00 00 00 --> FDBEFFF = 266072063 Secteurs

Le NTFS Boot sector de backup montrera la même information.

Le GPT Header nous avait parlé du Last Usable LBA (266338270)

Le LBA juste après montre bien une copie de la table de partition (266338270 + 1 = 266338271 )

Un espace de 128 entrées (si on en prend 4 par secteur de 512 ça fait 32 secteurs) est reservé pour y stocker toute la table de partitions

Les angoissés qui aiment que tout soit bien aligné éprouveront sans doute un plaisir non caché en constatant que 26638271 + 32 = 266338303 : C’est exactement l’emplacement du GPT Header alternatif.

C’est vrai que c’est rassurant quand même _{… quelque part … moi, je trouve ça rassurant.}

Comme on adore les schémas qui montre la beauté de l’alignement des secteurs, en voici un qui reprend les valeurs que nous avons trouvées.

Voilà, vous savez désormais tout sur la façon dont les partitions sont référencées dans des disques GPT. Dans le prochain article, nous allons voir où peuvent se glisser des corruptions et comment les réparer (ou pas).

Serge Gourraud
55 AA

Supposons maintenant que ce disque qui contient ces 3 partitions :

Se soit transformé en ceci:

Ce sont des choses qui arrivent quand le MBR (secteur 0 du disque) a été vidé.

Rappelons la structure d’un disque contenant 3 partitions et essayons de voir ce qu’on a concrètement sur le disque

Le secteur 0 est vide: Pas de signature, pas de code, pas de table de partitions

Sur des disques MBR Basiques c’est au secteur 2048 que démarre la première partition (sur les anciennes architectures, on aurait cherché au secteur 63 voire 31 mais ça nous ramené à NT4.0)

Le secteur 2048 nous montre ceci :

Et nous pouvons y lire ces informations :

• OEM ID (offset 30) : NTFS
• Bytes per Sector (offset 0B) : 00 02 -> 512
• Sectors per cluster (offset 0D) : 08
• Cluster per MFT Record (offset 40) : F6 -> 1K
• Total Sectors (offset 28) : FF 67 C5 09 00 00 00 00 -> 163932159 sectors (~78GB
  • Backup NTFS Boot Sector = 163932159 + 2048 = 163934207
• Clusters to MFT (offset 30) : 00 00 0C 00 00 00 00 00 -> 78643
  • La partition démarrant en 2048 : on trouvera la MFT en 2048 + 8 * 786432 = 629350
• Clusters to MFTMirr (offset 38) : 02 00 00 00 00 00 00 00 -> 2
  • 2048 + 8 * 2 = 2064

Pour résumer :

• Le dernier secteur de la partition devrait se trouver en 163934207
• La MFT en 786432 (et son "backup" en 2064
• Le champ $Volume en 6293510 ( = 6293504 + 2*3)

Le NTFS Boot Sector de backup en 163934207

Le secteur 786432 ressemble à un début de MFT

Et visiblement, on retrouve le nom du volume

Nous savons désormais que notre première partition démarre au secteur 2048 et finit au secteur 163934207

Comme tout est aligné, la seconde partition devrait démarrer au secteur 163934207 + 1 = 163934208

Fantastique!

On peut également y lire:

• OEMID (offset 30) : NTFS
• Bytes per Sector (offset 0B) : 00 02 -> 512
• Sectors per cluster (offset 0D) : 08
• Cluster per MFT Record (offset 40) : F6 -> 1 record MFT = 1K
• Total Sectors (offset 28) : FF 7F A9 03 00 00 00 00 : 61439999 sectors (~29 GB)
  • Backup NTFS Boot Sector : 61439999 + 163934208 = 225374207
• Clusters to MFT (offset 30) : 00 00 0C 00 00 00 00 00 : 786432 -> 163934208 + 8 * 786432 = 170225664
• Clusters to MFTMirr (offset 38) : 02 00 00 00 00 00 00 00 : 2 -> 163934208 + 8 * 2 = 163934224

De même, la 3ième partition sensé démarrer un secteur plus loin y est bien présente :

225374207 + 1 = 225374208

Total sectors: 0270FFFF = 40959999 = 40959999 *512 = 20971519488 Bytes

Backup Boot Sector : 40959999 + 225374208 = 266334207

Il faudra faire un contrôle complet de chaque secteur important (NTFS / Backup NTFS / MFTMirr / MFT / MFT.$Volume) et on peut dresser cette carte du disque :

• Première Partition :
  • Nom du volume Part1
  • Taille en secteurs: 163932159
  • Démarre au secteur: 2048
  • MFT localisée au secteur: 6293504
  • Termine au secteur: 16393420
• Deuxième Partition :
  • Nom du volume: Part2
  • Taille en secteurs: 61439999
  • Démarre au secteur: 163934208
  • MFT localisée au secteur: 170225664
  • Termine au secteur: 225374207
• Troisième Partition :
  • Nom du volume: Part3
  • Taille en secteurs: 40959999
  • Démarre au secteur: 225374208
  • MFT localisée au secteur: 231665664
  • Termine au secteur: 266334207

Il est très important de tout bien verifier: Si vous faites une erreur d’un secteur et que votre partition ne trouve pas sa MFT, notre  vieil ami chkdsk se fera un plaisir d’un générer automatiquement une toute nouvelle MFT, tout vide, juste pour vous. 

Et nous pouvons démarrer notre réparation

Première étape: Initialiser le disque (le code, la signature et une table de partition vide seront écrites)

Maintenant, il nous faut reprendre notre éditeur hexa préféré, le mien s’appelle DskProbe.exe car il permet d’appliquer un masque au données affichés par les secteurs.

(Pour information ce lien http://fr.wikipedia.org/wiki/%C3%89diteur_hexad%C3%A9cimalpropose une liste de produits)

Le secteur 0 que nous venons de réécrire (par initialisation) ressemble désormais à cela :

Avec DskProbe, nous pouvons faire paraitre la table de partition de ce secteur.

Les valeurs de début et fin de Head (=Side), Secteur et Cylindre dépendent de l’architecture, mais sont souvent les mêmes et voici celle qui convient de mettre pour la première partition de notre disque.

(Si vous avez plusieurs disques identiques sur votre ordinateur, ou un autre ordinateur avec le même disque qui n’a pas eu de soucis, vous pouvez récupérer les mêmes données)

Note : Il faut ajouter un secteur au Total Sectors du MBR par rapport au Total Sectors du NTFS Boot Sector puisqu’à cet endroit il faut compter les deux NTFS Boot Sector qui encadrent la partition, alors que dans le NTFS Boot Sector, on ne compte pas le dernier.

En récrivant « 07 » à l’offset du FileSystem de la première entrée de la table de partition.

Un rescan disk dans le Disk Manager nous fait reparaitre la partition comme par miracle:

On peut faire reparaitre les deux autres partitions en remplissant mes Start/End Side/Sector/Cylinder comme suit, et en adaptant les Relative et Total Sectors aux données relevées et en plaçant le type de système à NTFS (07) aux offset 01C2, 01D2, 01E2, 01F2 correspondant aux partitions respectives.

Si une des partitions par en chdksk, pas de chances : Soit vous vous êtes trompés dans vos calculs, soit la MFT avait besoin d’une réparation avant vos opérations.

Comme expliqué au premier article, toutes ces opérations sont des opérations de dernier recours, et ne garantissent aucunement la récupération de vos données.

Dans la prochaine série, nous nous intéressons aux disques GPT.

Serge Gourraud
55 AA

Pour faire reparaitre une partition disparue, nous avons besoin de peu de chose pour faire cette recuperation:

• Le NTFS Boot Sector de backup
• Savoir retrouver la MFT pour être certain de récupérer la bonne partition

Nous allons voir comment récupérer une partition qui a disparu suite à une opération manuelle malencontreuse.

Windows étant un petit paresseux, nous savons que quand on supprime une partition, seule l’entrée dans la table de partition est supprimée.

Vérification: 

Dans les architectures récentes, les partitions NTFS commencent le plus souvent au secteur 2048 (les anciennes démarraient au secteur 63).

Si ce n’est pas le cas, il faut chercher sur le disque. Certains éditeurs hexa permettent de le faire, dskprobe le permet.

Dans notre cas, le secteur 2048 est bien un secteur d’amorçage NTFS :

Nous pouvons identifier facilement :

• Le OEM ID String "NTFS"
• Bytes par secteurs : 512
• Secteurs par cluster : 8
• Partition Size en secteurs : FF E7 DF 0F 00 00 00 00 --> FDFE7FF = 266332159 secteurs (à peu près 127 GB : 266332159*512/1024/1024/1024)

Donc le NTFS Boot Sector de backup devrait se trouver au secteur 266334207 ( = 2048 + 266332159 )

Allons voir :

Vérifions que nous retrouvons bien la MFT

• Clusters to MFT : 00 00 0C 00 00 00 00 00 = 0xC0000 = 786432 clusters = 6291456 secteurs. En ajoutant 2048 ça fait:  6293504
• Clusters to MFTMirr : 02 00 00 00 00 00 00 00 = 0x2 = 2 clusters = 16 secteurs. En ajoutant 2048 ça fait:  2064

Le secteur 6293504 ressemble bien au premier metafichier de la MFT

Le metafichier $Volume nous fournit bien le bon nom de volume (à vérifier avec l’administrateur)

Donc en résumer, même si la partition a été supprimée, les données sont toujours présentes :

• La partition est encadrée par les NTFS Boot Sector de début et de fin
• Le NTFS Boot Sector pointe vers une MFT qui semble valide

Ce qui reste à faire est donc la chose suivante :

1. Enregistrer le contenu du secteur 2048 avec l’outil de votre choix (dskprobe permet de le faire)
2. Recréer une nouvelle partition dans le gestionnaire de disque ou diskpart : Ne pas la formater.

1. Si on formate la partition, on réécrit la MFT et toute les références au contenu de la partition. Gardons en tête que Windows est un petit paresseux : La MFT sera refaite, mais les données sur le disque seront toujours présentes jusqu’à ce qu’elles soient écrasées. Certains outils pourront encore vous aider mais il faudra y mettre le prix.
2. En créant cette nouvelle partition
   1. Une nouvelle entrée est créée dans la table de partition
   2. Le secteur 2048 a été vidé

• La dernière opération consiste en réécrire le secteur sauvegardé sur le 2048 et replacer le FileSystem à l’offset 01C2 : écrire 07

Un rescan devrait faire reparaitre le disque.

Ces étapes en image :

1. Sauvegarde du contenu du secteur 2048 avec dskprobe2.exe

2. Création de la partition sans la formater

Suivant … Suivant … Jusqu’à l’option de formatage : Choisir l’option "Do not format this volume"

Nous obtenons une partition RAW :

3. Ecraser le NTFS Boot sector par celui sauvegarder

Dans DskProbe se placer sur le secteur 2048 du disque, et ouvrir le fichier que nous venons de sauvegarder

Ecrire le fichier sur le secteur 2048

Vérifier qu’on écrit bien 1 secteur sur le secteur 2048 et cliquer sur "Write"

Retourner au secteur 0 et remplacer le "06" à l’offset 1C2 par "07" : bien presser la touche 0 et la touche 7.

Puis faire un Write

Un Rescan Disk dans le Disk Manager fait reparaitre le disque

Serge Gourraud
55 AA

Pour pouvoir récupérer une partition NTFS, il faut savoir l'identifier. Une partition NTFS contient essentiellement:

• Un secteur d'amorçage NTFS (NTFS BootSector) en début de partition
• Une MFT (la database de NTFS)
• Une copie alternative des 3 premiers enregistrements de cette MFT
• Un secteur de backup du NTFS Boot Sector en fin de partition

Pour une description complète de chacun des champs : http://technet.microsoft.com/fr-fr/library/cc781134(WS.10).aspx

Pour rappel, la table de partition 0 nous montrait une partition démarrant au secteur 2048 et occupant 122972160 :

Examinons en détails le NTFS Boot Sector

Si on dresse un tableau de ces données on obtient ça:

*La table de partition présente au secteur 0 nous avait indiqué une partition occupant 122972160 secteurs. Ca fait un secteur de plus, car dans cette table, on compte le 1er secteur de la partition ainsi que le dernier. Dans le secteur d’amorçage NTFS on compte un secteur de moins. Il faudra s’en rappeler quand nous ferons des réparations.

**La taille de chaque enregistrement. NTFS fera un enregistrement pour chaque fichier et répertoire de son volume. Ceux dont la taille est inférieur à la taille d’un enregistrement sont résident dans la MFT. Si ce nombre est positif (entre 00 et 7F) alors il represente le nombre de cluster par enregistrement. Si le nombre est négatif (de 80 à FF), alors la taille d’un enregistrement est 2 à la puissance la valeur absolue de la valeur de ce champ.

• Dans notre exemple, nous pouvons lire la valeur 0xF6. C’est une valeur négative, et sa valeur absolue est 0x0A (10 en décimal). Donc la taille d’un enregistrement sera de 2^10 = 1024 Bytes (1K)
• Si nous avions formaté la partition avec le paramètre /L, nous aurions lu la valeur 0x01 dans le champ clusters per MFT Record. Dans ces condition, la taille d’un record aurait été 1 cluster. Comme 1 cluster occupe 8 secteurs, ça nous aurait donné 4K par enregistrement (ce qui est bien le but du paramètre /L)

Clusters to MFT est de 786432, et nous avons 8 secteurs par cluster. Donc, la MFT est localisée au secteur 6293504 ( = 2048 + 786432 * 8 )

Nous pouvons voir à cet emplacement, le premier fichier de la MFT : $MFT

Sachant que chaque enregistrement occupe 1K, il est possible de parcourir tous les enregistrements de la MFT jusqu’à, par exemple, l’enregistrement $Volume qui fournit le nom du volume. Puisqu’il s’agit du 4ième, nous le trouverons au secteur 6293510.

Si nous ne trouvons rien de ce genre à cet emplacement, c’est que soit la donnée a été écrasée, soit qu’on n’est pas au bon endroit : Le secteur d’amorçage n’est peut-être pas le bon, ou contient de mauvaises informations

Dans l’article suivant nous récupérons une partition.

Serge Gourraud

55 AA

Recupération de partitions III : Structures des disques basiques MBR - Les partitions étendues

Dans l’article précédent, nous avons vu un exemple de partitionnement contenant une et plusieurs partitions primaires. Afin de pouvoir mettre plus de quatre partitions sur un disque, il existe un système de partition étendue. En quelques mots :

-        Si vous souhaitez 1 à 4 partitions : Vous aurez 4 partitions primaires

-        Si vous souhaitez 5 partitions ou plus : Vous aurez 3 partitions primaires et 1 partition étendue contenant autant de volumes que souhaité.

Si on observe la table de partition à l’éditeur hexa, on sait qu’il n’y a la place que pour 4 entrées et on voit bien que les 4 entrées sont occupées.

La dernière entrée a ceci de particulier qu’elle est de type 0x0F (partition étendue), et qu’elle occupe 30722048 secteurs (ce qui nous donnerait à peu près 14 GB pour des secteurs de 512 Bytes)

Donc, si nous refaisons notre petit tableau récapitulatif:

Avant d’aller plus loin regardons à quoi ressemble le premier secteur d’une partition NTFS. La première partition (PPart01) est sensé démarrer au secteur 2048, et voici le secteur 2048 :

Nous détaillerons le contenu de ce secteur dans la partie 4, mais pour l’instant nous avons juste besoin de savoir que ce secteur est signé "55 AA" et qu’il contient bien le OEM ID "NTFS".

Regardons maintenant ce qui se trouve au secteur 235614208 (entrée de la 4ième partition). Il est quasiment vide, mais nous pouvons y reconnaitre une nouvelle table de partition dans la partie inférieure.

Cette table de partition contient deux entrées:

En passant tout ça à la moulinette, on peut construire ce petit tableau:

Quand on parcours une partition étendue, le Relative Sector ne fait pas référence au début du disque, mais au début de la partition étendue.

Comme notre partition étendue démarre au secteur 235614208, le premier volume NTFS devrait se trouver au secteur 235616256 ( = 235614208 + 2048 )

Cela reseemble bien à un secteur NTFS:

Maintenant, regardons ce qui se trouve à la seconde entrée de la table de partition. Son Relative Sector est 10242048 et la partition étendue démarrait au secteur 235614208. Donc l’entrée doit nous faire pointer vers le secteur 245856256 ( = 235614208 + 10242048 ). Allons voir :

C'est une nouvelle table de partition contenant ces informations:

La partition NTFS suivante démarre au secteur 245858304 ( = 245856256 + 2048 ) et la prochaine table de partition au secteur 252000256 ( = 235614208 + 16386048 )

Comme nous n’avons que 3 volumes dans la partition étendue, ce table de partition devrait être la dernière qui pointe vers une partition NTFS et nous n’avons qu’une seule entrée puisque nous n’avons pas d’autres volumes à déclarer.

Voilà comment Windows s’y prend pour faire entrer plusieurs partitions dans des tables qui ne peuvent en contenir que 4.

Dans l’article suivant, nous allons détailler le contenu d’un secteur d’amorçage NTFS afin de pouvoir commencer les réparations.

Serge Gourraud

55 AA

Dans l'article précédent, nous avons vu comment sont structurés les partitions et volumes sur les disques. Nous allons voir cela da façon concrète sur un disque MBR Basique.

Pour cela, j'utilise un éditeur hexadécimal et ouvre le disque aux secteurs qui m'interressent. L'éditeur que j'utilise s'apelle dskprobe.exe (un outil Microsoft assez basique qui affiche les secteurs par pages de 512 Bytes) mais vous pouvez utiliser celui qui vous convient le mieux. Une liste est disponible sur http://fr.wikipedia.org/wiki/%C3%89diteur_hexad%C3%A9cimal

Ouvrons le secteur 0 d'un disque MBR Basique.

En rouge:

• La signature du disque de l'offset 0x01B8 à l'offset 0x01BB : 26 A8 75 C2.
  • Il faut lire cette information en little endian : C275A826
• Une sorte de signature du secteur : 55 AA
  • Vous la trouverez sur pas mal de secteurs importants du disque. Elle est indispensable.

En surligné : La table de partition, contenant 4 entrée.

• La 1ère entrée commence à l'offset 0x1BE et termine à l'offset 0x1CD : Elle contient les coordonnées d'une partition
• La 2ième entrée commence à l'offset 0x1CE et termine à l'offset 0x1DD : Celle-ci est vide
• La 3ème entrée commence à l'offset 0x1DE et termine à l'offset 0x1ED : Celle-ci est vide
• La 4ème entrée commence à l'offset 0x1EE et termine à l'offset 0x1FD : Celle-ci est vide

La partie au dessus est du code.

Focalisons-nous sur la première entrée de la table de partition, et essayons de lui faire correspondre la description disponible sur http://technet.microsoft.com/en-us/library/cc739412(v=ws.10).aspx

Ca veut dire que ce disque contient une partition NTFS qui démarre au secteur 2048 et occupe 266332160 secteurs.

Nous ne savons pas encore exactement quelle taille cela fait en Bytes, mais la plupart du temps, 1 secteur occupe 512 bytes. Ce qui nous fait (si on a des secteurs de 512 bytes)

• 266332160 * 512 = 136362065920 bytes
• 136362065920 / 1024 / 1024 / 1024 = 126.9971 GBytes

Considérons maintenant quelque chose d'un peu plus fréquent: Un disque contenant plusieurs partitions.

Notre table de partition au secteur 0 pourrait bien ressembler à cela:

Ce qui nous donne ce petit tableau récapitulatif:

* *Toujours en suivant la petite moulinette de ne garder que 6 bits sur le 1er champ, et d'ajouter les 2 restants aux 8 d champs suivant

*A lire en little endian

Dans l’article suivant, nous détaillerons un disque contenant des partitions étendues.

Serge Gourraud

55 AA

Dans les articles qui suivent, nous évoquerons ces termes à maintes reprises. Autant se familiariser tout de suite avec ces termes :

• LBA = Logical Block Address : Le numéro du secteur. En général, un secteur fait 512 bytes ou 4 KBytes
  • http://support.microsoft.com/default.aspx?scid=kb;en-US;2510009
• LDM = Logical Disk Manager
• MFT = Master File Table. La database du système de fichiers NTFS.
  • http://msdn.microsoft.com/en-us/library/windows/desktop/aa365230(v=vs.85).aspx
• MBR = Master Boot Recor
  • Le secteur le plus important du disque : Le secteur (LBA) 0
  • http://technet.microsoft.com/en-us/library/cc976786.aspx
• PBS = Partition Boot Sector : Le premier secteur d'une partition.
• BPB : BIOS Parameter Block : Une partie du PBS
• GPT = GUID Partition Table.

L'objectif de ces articles est de parcourir les secteurs importants des disques pour comprendre où pourrait se placer une corruption et de la réparer (quand c'est possible) juste en écrivant la bonne information au bon endroit. Toutes les structures que nous allons parcourir sont déjà décrites dans MSDN.

Aussi, si vous souhaitez avoir plutôt une approche développeur, un bon point de départ serait d'invoquer un DeviceIoControl en utilisant le control code IOCTL_DISK_GET_DRIVE_LAYOUT_EX (cf. http://msdn.microsoft.com/fr-fr/library/windows/desktop/aa365174(v=vs.85).aspxpour plus de détails)

Ce contrôle vous fournira une structure de type DRIVE_LAYOUT_INFORMATION_EX

typedef struct _DRIVE_LAYOUT_INFORMATION_EX {

DWORD PartitionStyle;

DWORD PartitionCount;

union {

DRIVE_LAYOUT_INFORMATION_MBR Mbr;

DRIVE_LAYOUT_INFORMATION_GPT Gpt;

};

PARTITION_INFORMATION_EX PartitionEntry[1];

} DRIVE_LAYOUT_INFORMATION_EX, *PDRIVE_LAYOUT_INFORMATION_EX;

Nous n'évoquerons pas d'avantage cette approche dans cette série, mais cela pourrait faire le sujet d'une autre série si la demande est forte.

Comme expliqué, la MSDn regorge de schémas explicatifs mais essayons de les présenter différemment afin d'afficher plutôt une comparaison de ces structures, si cela peut aider.

Comparaison MBR et GPT

Différences principales (liste non exhaustive) dans les fonctionnalités:

Quelques références:

• FAQ sur les GPT : http://msdn.microsoft.com/en-us/windows/hardware/gg463525
• Pour le fun et pour les amateurs des grandes tailles: Kilo, Mega, Giga, Téra, Péta, Exa, Zetta et Yotta : http://fr.wikipedia.org/wiki/Octet

Comparaisons des structures identifiables, écrites à plat sur les disques basiques

Pour avoir une vision complète des disques basiques, aller sur http://technet.microsoft.com/en-us/library/cc739412(v=ws.10).aspx

Comparaisons des structures identifiables, écrites à plat sur les disques dynamiques

Pour avoir une vision complète des disques dynamiques, aller sur http://technet.microsoft.com/fr-fr/library/cc758035(v=WS.10).aspx

Comparaisons des disques basique et dynamiques

Différences principales (liste non exhaustive) en terme de fonctionnalités

* Le nombre de volumes que peut supporter un disque dynamique n'est pas illimité car la database est limitée à 1 MB. Sachant que chaque disque dynamique attaché à un système contient la descroption de tous les volumes de ce système, rajouter des disques n'augmentera pas cette limite. Au contraire, il faudra rajouter des enregistrement pour en plus pour décrire le nouveau disque.

**Il est possible d'étendre un volume sur plusieurs disques dynamique, mais sur des disques basiques, on ne peut rester que sur le même disque.

Les différents types de volumes sont décrit sur : http://technet.microsoft.com/fr-fr/library/cc737048(v=WS.10).aspx

Dans le post suivant, nous allons tenter de voir concrètement comment cela se traduit en donnée brute écrite sur les disques.

Serge Gourraud

55 AA

Il arrive que les structures qui décrivent les partitions sur les disques soient perdues ou corrompues. Heureusement cela arrive assez rarement, mais quand c’est le cas, nous nous retrouvons en face d’un disque qui n’a plus du tout de partitions, ou des partitions affichées en RAW et on peut légitimement être inquiet, voire craindre d’avoir tout perdu. Comme ces données sont souvent cruciales, l’administrateur aura dans le meilleur des cas un backup (bien évident, puisque ces données sont cruciales) mais le temps de restauration de ce backup peut prendre plusieurs heures voire plusieurs journées. Dans le pire des cas, l’administrateur n’aura pas de backup (les données ne devaient pas être suffisamment importante).

Tant que (ou les) partitions sont absentes ou marquées comme RAW, la source du problème peut se trouver dans des erreurs au niveau des structures qui décrivent les partitions, et sous certaines conditions, il est possible de reconstruire ces structures et de faire reparaitre ces partitions dans Windows.

Le but des articles qui suivent est de décrire ces structures, les retrouver sur le disque, d’identifier les corruptions potentielles et de les corriger si possible.

La récupération d’une MFT corrompu ne fait pas l’objet de ces articles, et pour cela, nous ne pouvons que recommander l’utilisation de chkdsk.exe

Nous allons travailler sur les disques Basiques (MBR et GPT) et Dynamique (MBR et GPT) en suivant cet agenda:

• Partie 1 : Definitions & Etude comparative des structures
• Partie 2 : Structures des disques Basiques MBR : Configuration simples et les plus fréquentes
• Partie 3 : Structures des disques Basiques MBR : Configuration avec partition étendue
• Partie 4 : Identification d’une partition NTFS
• Partie 5 : Récupérer une partition Primaire NTFS sur disque MBR Basic : Exercice pratique
• Partie 6 : Aller plus loin dans l’identification des structures
• Partie 7 : Structures des disques GPT Basic
• Partie 8 : Identifier et corriger des structures GPT corrompues
• Partie 9 : Récupérer une partition supprimée par mégarde sur un disque basique GPT
• Partie 10 : Disques MBR Dynamiques
• Partie 11 : Disques GPT Dynamiques

Serge Gourraud

55 AA

Installer une application sous Terminal Server n’est pas anodin. En effet, le serveur étant multi-utilisateurs, il faut que l’application soit capable d’être utilisée simultanément par plusieurs utilisateurs. Il faut donc clairement séparer les données et paramètres communs, de ce qui ne l’est pas. Si l’application n’a pas été écrite en tenant compte de cela, les risques de plantage sont garantis.

Quand il arrive un incident sur un cluster, la majeure partie des informations nécessaires à l’explication se trouve dans les cluster logs. Cependant, il est fréquent que la période intéressante ne soit pas couverte par le cluster log. Pour pallier à ce désagrément, il est possible de créer une tâche programmée qui génèrera les cluster logs tous les jours, couvrant les dernières 24 heures.

De cette manière, si un incident arrive vous aurez toujours à votre disposition un historique de plusieurs semaines, voire de plusieurs mois en fonction de la quantité d’information que vous désirez garder.

Voici comment il est possible de s’y prendre.

1. Importer le script powershell ci-dessous dans le répertoire de votre choix (par exemple C:\Temp\ClusterLogs) sur un des nœuds du cluster

Ce script accepte quatre arguments :

- Le répertoire ou stocker les logs

- La quantité d’infirmation à relever en heures

- Un fichier de log qui enregistre l’exécution des relevés

- Une option « verbose » non utilisée dans la version actuelle

2. Ensuite, autoriser l’exécution de scripts Powershell sur le serveur. Dans l’exemple nous choisissons la stratégie « Unrestricted », mais il est possible d’affiner d’avantage. Pour cela, se référer à l’aide en ligne de la commande Set-ExecutionPolicy.

3. Enfin créer une tâche planifiée qui lancera le script :

a. Lancer le Task Scheduler.

b. Dans le « Task Scheduler », créer une « Basic Task ».

c. Dans le menu « Create a Basic Task », entrer le nom de la tâche et une description qui permettent de l’identifier aisément, puis cliquer sur « Next ».

d. Dans le menu « Task Trigger », choisir une tâche journalière puis cliquer sur « Next ».

e. Dans le menu « Daily », choisir la fréquence et l’heure à laquelle tournera la première instance, puis cliquer sur « Next ».

f. Dans le menu « Action », choisir l’action « Start a program » puis cliquer sur « Next ».

g. Dans le menu « Start a Program » entrer le moteur de script « Powershell.exe » dans la case « Program/Script », et dans la case « Add arguments (optional) » entrer les arguments de façons à ce que le script soit lancé avec les options qui vous intéressent, puis cliquer sur « Next ».

Par exemple :

C:\Temp\ClusterLogs\ClusterLogCollector.ps1 -r C:\Temp\ClusterLogs -h 24 -l Logging.log

h. Dans le menu « Summary », cocher la case « Open the Properties dialog for this task when I click Finish », puis cliquer sur « Finish ».

i. Dans l’onglet « General », prendre soin de faire en sorte que :

i. La tâche soit exécutée même si personne n’est loguée

ii. La tâche soit exécutée sous privilèges élevés

iii. La tâche soir configurée pour Windows® 7, Windows Server^TM 2008 R2

j. Dans l’onglet « Triggers », vérifier que tout est conforme aux options choisies précédemment

k. Faites de même pour les onglets « Actions » et « Conditions »

l. Dans l’onglet « Settings », vérifier que les paramètres correspondent à votre environnement. La valeur de timeout par défaut est de 6h et pourrait être justifiée en fonction des autres tâches qui tournent, du nombre de nœud dans le cluster et de la bande passante de chacun.

m. Enfin, en cliquant sur « OK », vous devrez entrer vos credentials.

Conclusion

Au bout de quelques temps vous aurez l’inextinguible joie de découvrir un historique de cluster logs long comme le bras et dont le support est si friand !

Serge Gourraud

A travers cet article, je vais tenter d’expliquer comment mettre en place le SSO (Single Sign On) pour l’utilisation de RemoteApp publiées sous RDS 2008 R2.

Pour les besoins de l’explication, je vais partir du principe que l’infrastructure en place est la suivante :

-          1 domaine : core.lab

-          1 ferme de 2 serveurs RDSH 

o   RDSH1.core.lab

o   RDSH2.core.lab

Le nom de la ferme est  RDFARM.core.lab

-          1 RD Connection Broker : RDCB.core.lab

-          1 RD Web Access : RDWA.core.lab

-          1 RD Gateway : RDGW : RDGW.core.lab

La mise en place du SSO peut se décomposer en plusieurs phases :

1)      Choix des certificats

2)      Génération des certificats

3)      Installation des certificats sur les différentes machines

4)      Paramétrage des RD Session Hosts

5)      Paramétrage du RD Connection Broker

6)      Paramétrage du RD Web Access

7)      Paramétrage du RD Gateway

8)      Créations des GPOs

1.     Choix des certificats

Un ou plusieurs certificats devront être générés.

Il y a besoin de certificat pour les éléments suivants :

-          Chaque serveur RD Session Host

-          Le serveur RD Connection Broker

-          Le serveur RD Web Access

-          Le serveur RD Gateway.

Les serveurs RD Session Hosts et le serveur RD Connection Broker devront partager le même certificat.

Les serveurs RD Web Access et RD Gateway peuvent chacun avoir un certificat différent.

En conclusion, il nous faut au maximum 3 certificats différents.

Le certificat des serveurs RD Session Host et du RD Connection Broker devra comporter les indications suivantes :

CN=RDFARM.core.lab

Le certificat du serveur RD Web Access devra comporter les indications suivantes :

CN=RDWA.core.lab

Le certificat du serveur RD Gateway devra comporter les indications suivantes :

CN=RDGW.core.lab

Il est possible de n’utiliser qu’un seul certificat pour tous ces serveurs.

Il faudrait alors soit utiliser un wildcard de type  *.core.lab dans le Subject Name, soit référencer les différents noms utiles, dans les champs SAN (Subject Alternative Name) du certificat.

Il est à noter toutefois que seuls les clients RDC 6.1 et au-delà peuvent faire usage de ces possibilités.

Pour l’utilisation de Subject Alternative Name dans notre exemple, il faudrait renseigner :

Subject Name :

CN=RDFARM.core.lab

Subject Alternative Name :

DNS= RDFARM.core.lab

DNS= RDWA.core.lab

DNS= RDGW.core.lab

On retrouve le nom RDFARM.core.lab, aussi bien dans le Subject Name que dans le Subject Alternative Name.

Cette répétition est volontaire.

Pour la suite de cet article, je vais considérer que nous allons utiliser 3 certificats différents.

2.     Génération des certificats

Pour générer nos certificats, il existe 2 possibilités :

-          Utiliser une autorité de certification au sein du domaine Active Directory

-          Acheter vos certificats auprès de société telles que VeriSign ™, Thawte ™, et autres…

Si l’ensemble des postes clients accédant à l’infrastructure visée sont sous contrôle de votre service informatique, vous pouvez vous contenter d’utiliser votre propre autorité de certification.

En effet, si ces postes sont dans la même forêt que l’autorité de certification, il y aura une approbation automatique de celle-ci.

Dans le cas contraire, ils devront être paramétrés pour approuver cette autorité de certification, et devront avoir un accès à la CRL (Certificate Revocation List) de celle-ci.

Pour créer vos propres certificats, je vous invite à consulter cet article.

3.     Installation des certificats sur les différentes machines

Une fois les certificats créés, il faut les installer sur les différents serveurs concernés.

Dans notre exemple, il s’agit des serveurs et certificats suivants :

Cela se fait de la manière suivante :

Depuis l’un des serveurs en question, lancer une MMC en élévation de privilège, faire« Add or Remove Snap-ins ».

Choisir le snap-in « certificate »

Sélectionner« Computer Account », puis « Local Computer »

Depuis le magasin « Personal », faire « All Tasks » puis« Import… »

Sélectionner le fichier en .pfx préalablement créé, saisir le mot de passe communiqué lors de l’export de la clé privée,

Sélectionner l’emplacement du  certificat dans le magasin « Personal » et faire l’import.

A la fin de l’opération, vous devez voir le certificat dans la console.

Cette opération est à refaire pour chacun des serveurs précédemment cités, avec leur certificat respectif.

4.     Paramétrage des RD Session Hosts

Sur les serveurs RD Session Hosts, il y a 2 choses à configurer :

-          Le protocole RDP

-          Les RemoteApp

Pour le protocole RDP, cela se passe au niveau de la MMC : « Remote Desktop Session Host Configuration ».

Ouvrir les propriétés de la connexion RDP-TCP, et dans l’onglet général, cliquer sur le bouton « Select » afin de sélectionner le certificat.

Mettre le certificat choisi en surbrillance, et cliquer sur « OK »

Le certificat sélectionné sera alors affiché.

Faire OK, pour appliquer les modifications.

Concernant les RemoteApp, ouvrir la MMC « RemoteApp Manager ».

Choisir le lien « Change » à coté de « Digital Signature Settings »

Cocher la case « Sign with a digital certificate » et cliquer sur le bouton « Change».

Choisir le certificat, et valider par « Ok »

Le certificat choisi doit alors s’afficher dans l’interface, comme ceci :

Faire la même opération avec l’autre serveur RD Session Host de la ferme.

5.     Paramétrage du RD Connection Broker

Sur le serveur RD Connection Broker, il y a 2 choses à configurer :

-          Le protocole RDP

-          Le certificat utilisé par le RD Connection Broker lui-même.

Pour le protocole RDP, procéder exactement de la même façon que pour les serveurs RD Sessions Hosts, à l’aide de la MMC « Remote Desktop Session Host Configuration ».

Pour le RD connection Broker, lancer la MMC « Remote Desktop Connection Manager ».

Puis, sélectionner l’option pour mettre à jour le certificat.

Cocher la case « Sign with a digital certificate » et cliquer sur le bouton «Select ».

Choisir le certificat, et valider par « Ok »

Le certificat choisi doit alors s’afficher dans l’interface, comme ceci :

6.     Paramétrage du RD Web Access

Sur le serveur RD Web Access, il y a 2 choses à configurer :

-          Le protocole RDP

-          Le certificat utilisé par le protocole HTTPS.

Pour le protocole RDP, procéder exactement de la même façon que pour les serveurs RD Sessions Hosts, à l’aide de la MMC « Remote Desktop Session Host Configuration ».

Pour le protocole HTTPS, lancer la MMC « Internet Information Services (IIS) Manager ».

Se positionner sur le « Default Web Site », puis sélectionner l’option de « Binding… ».

 Sélectionner ensuite le protocole HTTPS, puis le bouton « Edit… »

 Il ne reste plus qu’à sélectionner le certificat à employer, et à valider.

 Un redémarrage du site Web est à prévoir.

7.     Paramétrage du RD Gateway

Sur le serveur RD Gateway, il y a 2 choses à configurer :

-          Le protocole RDP

-          Le certificat utilisé par le protocole HTTPS.

Pour le protocole RDP, procéder exactement de la même façon que pour les serveurs RD Sessions Hosts, à l’aide de la MMC « Remote Desktop Session Host Configuration ».

Pour le protocole HTTPS, cette fois ci, on va passer par le « RD Connection Manager »

Lancer la MMC « RD Gateway Manager ».

Puis, sélectionner l’option pour mettre à jour le certificat.

Choisir ensuite l’import de certificat.

 Sélectionner ensuite le bon certificat, puis cliquer sur le bouton « Import », puis valider par « OK ».

8.     Créations des GPOs

Les GPOs à créer sont à mettre en place pour tous les postes clients qui souhaiteront exécuter des RemoteApp en faisant du SSO.

Dans notre exemple, j’ai créé une OU « Desktop » dans laquelle j’ai déplacé tous les postes utilisateurs.

Ensuite, depuis la MMC « Group Policy Management », il faut sélectionner l’OU en question, puis sélectionner « Create a GPO in this domain, and Link it here ».

Dans notre exemple, je l’ai nommée SSO for RDS.

Faire ensuite Edit

La MMC« Group Policy Management Editor » s’ouvre alors.

 Aller dans« Computer Configuration\Policies\Administrative Templates\System\Credentials Delegation »

Modifier le paramètre « Allow Delegating Default Credentials »

Selectionner« Enabled », puis cliquer sur le bouton « Show… »

Saisir ensuite le SPN pour les serveurs concernés.

Dans notre exemple , il faut saisir le nom de notre ferme.

Valider ensuite deux fois par « OK ».

Aller ensuite dans « Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Connection Client »

Le paramètre à modifier est « Specify SHA1 thumbprints of certificates representing trusted .rdp publishers »

Le « thumbprint »ou « empreinte » est à récupérer sur le certificat de la ferme.

Pour cela, depuis la console certificat, choisir le certificat RDFARM.core.lab, puis dans l’onglet « Details », récupérer les données du champ« Thumbprint »

Ces données sont à recopier, de préférence sans les espaces, pour éviter les« copier/coller » malheureux.

En effet, selon ce qui est sélectionné, des caractères non affichables peuvent être inclus dans le presse-papier, et ainsi corrompre les données.

 Une fois ceci fait et validé, la configuration du SSO est terminée.

Pour que la GPO soit prise en compte, ne pas oublier de fermer la MMC « Group Policy Management Editor ».

9.     Utilisation du site web RD Web Access

Une dernière chose est nécessaire pour que le SSO fonctionne correctement : il faut impérativement cocher la case “J’utilise un ordinateur privé” depuis le site RD Web Access.

Philippe

Windows Core Support Escalation Engineer

A l’occasion des Microsoft TechDays 2012, j’aurais à nouveau le grand plaisir de présenter une session technique traitant du troubleshooting sur la technologie cluster.

Le teaser :

Comment identifier la cause réelle des problèmes impactant un cluster de basculement Windows. (SER402)

La majeure partie du temps, le service cluster subit les défaillances qui interviennent et réagit dans la mesure des moyens qui lui sont donnés. L'objectif de cette session est de comprendre comment utiliser les traces et outils de Windows pour identifier quel composant ou quel facteur a causé un dysfonctionnement au sein d'un cluster et comment mettre en place un plan d'action visant à anticiper d'éventuels futurs problèmes..

Guillaume

Windows Core - Sr Support Escalation Engineer

Cela fait quelques temps que nous peinons à poster des bulletins sur notre blog.

Je profite donc de l'occasion pour vous annoncer que les webcasts des TechDays 2010 sont disponibles.

En particulier la notre (nous ne sommes pas peu fiers Lionel et moi tout autant que Jérôme, notre acolyte d'un jour) qui concerne les meilleures pratiques autour du clustering :

Guillaume

Windows Core - Support Escalation Engineer

A l’occasion des Microsoft TechDays 2010, nous aurons le grand plaisir de présenter une session technique traitant des meilleurs pratiques et de notre retour d’expérience sur la technologie cluster.

Au menu, entre autres sujets, les nouveautés de Windows Server 2008 R2, comment mettre à jour votre cluster de Windows Server 2003 ou 2008 à Windows Server 2008 R2, comprendre l’outil de validation, les actions proactives à mettre en oeuvre pour assurer la stabilité du cluster, etc…

Le teaser :

Meilleures pratiques et retour d'expérience sur le cluster de basculement (Failover Clustering)

Le choix de la mise en place d'un cluster est guidé par le besoin de haute disponibilité mais il ne faut pas se laisser tromper par son apparente simplicité. Les ingénieurs support sont les premiers impliqués dans la gestion des incidents cluster. Venez profiter de notre retour d'expérience et de nos conseils concernant les bonnes pratiques et recommandations concernant la mise en place, le geo-clustering, l'upgrade ou l'exploitation d'une plateforme en cluster.

Nous serons pas moins de trois sur scène pour vous présenter cette session qui fait partie du parcours Windows 7 & Windows Server 2008 R2.

Guillaume

Windows Core Support Escalation Engineer

Tous les aficionados du cluster auront remarqué la disparition de la fonctionnalité pourtant très appréciée de partage automatique des sous-répertoires d’un partage clusterisé.

En dehors de la création manuelle de ces partages, point de salut.

Voilà une petite commande pour partager tous les sous-répertoires du répertoire courant.

FOR /F %i IN ('dir /b /a:d') DO net share %i=%CD%\%i

Si les partages doivent être cachés, la commande devient :

FOR /F %i IN ('dir /b /a:d') DO net share %i$=%CD%\%i

Explication :

dir /b /a:d renvoie la liste des répertoires contenus dans le répertoire courant

/b pour une liste simple et /a:d seulement les fichiers qui sont des répertoires (directory)

La boucle FOR va donc exécuter le code qui suit le DO pour chacune des entrées renvoyée par le dir

la commande net share permet le partage, on lui indique le nom du partage et le chemin d’accès complet au partage

%i ou %i$ sera le nom du partage (respectivement visible et caché), ce nom est le nom du répertoire lui même

%CD%\%i est la concaténation du chemin d’accès complet (répertoire actuel) et du nom du sous-répertoire à partager

Les 2 lignes de commandes citées devront être exécutées directement depuis l’invite de commande

Pour celles et ceux qui veulent inclure ces lignes dans un fichier .cmd ou .bat, voici la syntaxe à utiliser :

FOR /F %%i IN ('dir /b /a:d') DO net share %%i=%CD%\%%i

Si les partages doivent être cachés, la commande devient :

FOR /F %%i IN ('dir /b /a:d') DO net share %%i$=%CD%\%%i

le %i qui est la variable locale à notre commande doit avoir un double % pour être correctement interprétée

Le %CD% est une variable système et n’a donc pas besoin d’être doublé au niveau du %

J’ai rencontré un problème assez pénalisant en utilisant mes VMs Cluster sous Hyper-V :

Lors de chaque redémarrage de mes guest Windows 2008 pour faire des clusters virtuels, les connexions iSCSI restaient en état reconnecting. Je devais alors reconfigurer tous les initiators afin qu’ils puissent être de nouveau fonctionnel avec mon iSCSI Target.

J’ai utilisé une solution de contournement avec la clef de registre EnablePMTUDiscovery = 1 dans HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Maintenant, mes VMs se reconnectent correctement suite à leur reboot.

Note : Cette solution de contournement peut affecter les performances TCP et n’est valable que dans le cadre de testing…

Lien Technet

http://technet.microsoft.com/en-us/library/cc957539.aspx

La liste suivante décrit les paramètres que vous pouvez utiliser avec cette valeur du registre :

1 : Lorsque vous définissez EnablePMTUDiscovery sur 1, TCP tente de découvrir la taille de l'unité MTU (Maximum Transmission Unit ) ou la taille de paquet la plus élevée sur le chemin d'accès à un hôte distant. TCP peut éliminer la fragmentation sur les routeurs sur le chemin d'accès qui connecte des réseaux à différentes unités MTU, en découvrant l'unité MTU du chemin et en limitant les segments TCP à cette taille. Inversement, la fragmentation affecte le débit TCP.

0 : Nous vous recommandons de définir EnablePMTUDiscovery sur 0. Ainsi, une unité MTU de 576 octets est utilisée pour toutes les connexions qui ne sont pas des hôtes sur le sous-réseau local. Si vous ne définissez pas cette valeur sur 0, un attaquant peut forcer la valeur de l'unité MTU à une très petite valeur et ainsi surmener la pile.

Lionel

Windows Core Support Escalation Engineer

Le premier bulletin de cette série traitera de la gestion de la mémoire.

La gestion de la mémoire est un facteur crucial au sein d’un système d’exploitable.

Dans le monde de la virtualisation, le mécanisme visant à gérer les allocations mémoire est d’autant plus complexe et coûteux qu’il faut prendre en compte deux niveaux de mémoire alors qu’un système traditionnel n’en a qu’un seul (d’un point de vue très simplifié).

Gestion de la mémoire sur un système classique

Sur un système Windows classique, il y a une notion de mémoire physique et une notion de mémoire virtuelle.

Le système alloue un espace mémoire au kernel et un espace mémoire au mode user dans ce que l’on appelle la mémoire virtuelle. Cette mémoire virtuelle est adressée dans la mémoire physique et la mémoire paginée (le pagefile).

Sur un système 32 bit, cet espace mémoire virtuel alloue par défaut 2GB au kernel et 2GB au mode user (avec le /3GB : 1GB pour le kernel et 3GB pour le mode user).

Sur un système 64 bit, la répartition est de 8TB pour le kernel et 8TB pour le mode user.

Dans les deux cas, même si la mémoire physique disponible est inférieure à 4GB.

Une partie du travail du Memory Manager est donc de traduire les adresses virtuelles en adresses physiques (qui se trouvent soit en mémoire physique soit dans le pagefile).

Gestion de la mémoire sur un système virtualisé

Sur un système où un hypervisor s’exécute, on retrouve un niveau de mémoire supplémentaire : la mémoire allouée aux machines virtuelles et vue par celles-ci comme de la mémoire physique.

Et c’est là où ça se complique un peu et où il est nécessaire d’utiliser tout un jeu d’acronymes barbares pour comprendre ce que doit assumer l’hypervisor:

• SPA (System Physical Address Space) : l’espace d’adressage physique réel (en gros dans les barrettes de RAM)
• GPA (Guest Physical Address Space) : l’espace d’adressage physique vu d’une machine virtuelle (dans la représentation qu’a la machine virtuelle de la mémoire physique qui lui est présentée par l’hypervisor)
• GVA (Guest Virtual Address Space) : l’espace d’adressage virtuel d’une machine virtuelle (ou de l’hôte)

Ces espaces sont représentés d’une autre manière dans le schéma ci-dessous :

Dans cette situation, le système d’exploitation s’exécutant dans la machine virtuelle traduit les adresses mémoires virtuelles (GVA) en adresses mémoires “physiques” (GPA) et l’hypervisor va traduit les adresses “physiques” des pages mémoires (GPA) de la machine virtuelle en adresses physiques réelles (SPA).

Ce qui correspond au schéma ci-dessous :

La translation d’adresse GPA vers SPA est donc prise en charge par l’hypervisor. C’est une solution de translation d’adresse logicielle.

Dans le détail, le processeur maintient une liste de correspondance des adresses de la mémoire virtuelle (GVA) utilisées par les machines virtuelles avec la mémoire physique (SPA) dans ce qu’on appelle un Translation Looksaside Buffer (TLB). Lorsque la machine virtuelle tente d’accéder à une donnée ou une fonction qui est référencée par une adresse virtuelle mais que cette adresse virtuelle ne correspond à aucun contenu cela résulte en une faute de page (Page Fault). Cette faute de page est interceptée par l’hypervisor qui charge en mémoire la donnée ou la fonction et établit la translation d’adresse en spécifiant l’adresse physique dans la page TLB.

Comme on peut le comprendre, comme toute opération traitée par du logiciel, cette tâche de translation d’adresse est consommatrice en temps CPU. Bien plus que par du microcode embarqué dans du silicium.

C’est ce que nous appellons Second Level Address Translation (SLAT).

Prise en charge de la translation d’adresse par le CPU

J’en viens alors au premier avantage qu’apportent les nouvelles fonctionnalités d’AMD et d’Intel® : le déport de cette mécanique de l’hypervisor vers le CPU.

• Pour Intel®, cette tâche est assurée par la technologie Intel VT Extended Page Tables
• Pour AMD, c’est la technologie Rapid Virtualization Indexing (ou Nested Page Tables) qui assume ce rôle

Les deux fondeurs utilisent une terminologie différente mais le principe est le même, et cela permet de libérer l’hypervisor de cette tâche lui donnant plus de temps pour effectuer des actions plus importantes sinon plus utiles.

Cette fonctionnalité mise en oeuvre par les CPUs est supporté par Hyper-V v2 disponible avec Windows Server 2008 R2.

Ressources

 

 

KB555223 - RAM, Virtual Memory, Pagefile and all that stuff

Virtual Address Space

(WO/2007/073624) VIRTUAL TRANSLATION LOOKASIDE BUFFER (World Intellectual Property Organisation, en Anglais)

The very first independent Nested Paging Virtualization tests (Anandtech - AMD Nested Pagaing benchmark)

Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3B: System Programming Guide, Part 2 (en Anglais) – Extended Page Tables, chapitre 25.2

AMD-V™ Nested Paging

Rapid Virtualization Indexing with Windows Server 2008 R2 Hyper-V

Guest Post: Intel Inside for Hyper-V Virtualization

PDC 2008: Virtualization, An overview of the hardware features that give rise to world-class virtualization and cloud computing

Guillaume

Windows Core Support Escalation Engineer

Objectif:

Ressources en ligne:

How a Server Cluster Works: http://technet2.microsoft.com/WindowsServer/en/library/4aa0be73-ef61-4f9c-a071-b390278b47731033.mspx?mfr=true

Checkpointing  http://msdn2.microsoft.com/en-us/library/aa367195.aspx

ClusterRecovery tool: http://www.microsoft.com/downloads/details.aspx?familyid=2BE7EBF0-A408-4232-9353-64AAFD65306D&displaylang=en

Knowledge Base:

Restore registry check points stop working after you restore a server cluster

http://support.microsoft.com/default.aspx?scid=kb;EN-US;307469

174070  Registry replication in Microsoft Cluster Server

http://support.microsoft.com/default.aspx?scid=kb;EN-US;174070

Règles relatives au checkpoint Registry

1. Lors de tout changement sur la clé de registre ‘Checkpointée’ et lorsque la ressource est en ligne, le service cluster stocke une copie de ce registre sur la ressource quorum.
   
2. Un changement fait sur une clé de registre ‘Checkpointée’ pendant que la ressource se trouve ‘Offline’ sera ré-écrasé par la précédente valeur stockée lorsque l’application passera ‘Online’
   
3. Si les ressources basculent sur un autre nœud, le service cluster restaure les valeurs de registre depuis les fichiers stockées sur le quorum vers le nouveau nœud avant de mettre en ligne la ressource concernée par le Checkpoint.
   
4. Si une ressource est supprimée, le Checkpoint est aussi supprimé mais pas les informations contenu dans le registre local.
   
5. Les Checkpoints sont inclus dans les backup créés par la function  BackupClusterDatabase
   Plusieurs instances de ressources sur différents nœuds doivent être manipulées avec attention. Par exemple, une ressource A[0] stocke une valeur data[0] dans un Checkpoint A sur le nœud 0. Une ressource A[1] stocke une valeur data[1] dans un Checkpoint A sur le nœud 1. Si la ressource A[1] basculent sur le nœud 0, le service Cluster remplacera data[0] par data[1] pour le checkpoint A. Si la ressource A[0] dépend de data[0], elle sera aussi en échec. Une solution à ce problème consiste à donner des noms différents de clef ‘Checkpointé’ sur les différents nœuds. 

cluster . /checkpoints

Ajouter un Checkpoint au Cluster

cluster . resource "< Nom de la ressource >" /addcheckpoints:"\Software\...”

Supprimer un Checkpoint au Cluster

cluster . resource "< Nom de la ressource >" /removecheck :"\Software\...”

Mise en situation :

Imaginons que nous avons créé une application Client/Serveur ‘Onyone’ dont les données de registre sont stockées sous HKLM\Software\Onyone et HKLM\Software\Onyone2. Nous souhaitons la mettre dans un cluster sous forme d’application générique afin d’offrir aux utilisateurs une haute disponibilité.
Pour assurer la copie des clefs précédentes, nous allons ajouter à l’aide de la commande CLUSTER.EXE, deux checkpoints sur la ressource Network Name ‘Network Name DATA’ de cette application.

C:\>cluster resource "Network Name DATA" /addcheckpoints:"SOFTWARE\Microsoft\onyone"
Adding registry checkpoint 'SOFTWARE\Microsoft\onyone' for resource 'Network Name DATA'...

C:\>cluster resource "Network Name DATA" /addcheckpoints:"SOFTWARE\Microsoft\onyone2"
Adding registry checkpoint 'SOFTWARE\Microsoft\onyone2' for resource 'Network Name DATA'...

Regardons maintenant la prise en compte de ces commandes :

C:\>Cluster . resource /checkpoints
No resource name specified.

Listing registry checkpoints for all resources...

Resource             Registry Checkpoint
-------------------- --------------------------------------------------------
Quorum Disk          None

Cluster IP Address   None

Cluster Name         None

Disk P:              None

IP File Share        None

Network Name DATA    'SOFTWARE\Microsoft\onyone'

Network Name DATA    'SOFTWARE\Microsoft\onyone2'

File Share           None

Sur le disque du quorum, nous retrouvons dans le répertoire \MSCS (par défaut), un nouveau répertoire qui a été créé et ayant le GUID de la ressource concernée et contenant deux fichiers CPT :

Ce GUID est peut être retrouvé dans la clef HKLM\Cluster.

Lionel

Windows Core Support Escalation Engineer

La HCL , WSC ou matrice de compatibilité Cluster, ça vous dit quelque chose?

Mais si, ce sont ces fameuses listes qui répertorie l'ensemble des élements composant une solution Cluster 2000/2003. L'ennui est qu'il est difficile de trouver sa configuraiton et  les matériels et logiciels évoluant, elle n'est pas forcement à jour. C'est pour cela que je vous ai regroupé différents pointeurs vers les OEM les plus connus pour limiter les spectres de vos recherches. Si vous avez un doute sur la compatibilité de votre matériel avec le MSCS, il est facile de demander à votre OEM le lien vers vers votre solution en place.

• EMC Support Matrices : http://www.emc.com/interoperability/
• HP Cluster Configuration Support Matrices http://h18022.www1.hp.com/solutions/enterprise/highavailability/answercenter/configuration-all.html
• HP Support Matrices : http://h20272.www2.hp.com/
• Dell Support Matrices : http://www.dell.com/content/topics/global.aspx/sitelets/solutions/cluster_grid/clustering_ha?c=us&cs=555&l=en&s=biz&~tab=4
• Brocade Compatibility Matrix : http://www.brocadekorea.com/download/resource/CompatibilityMatrix_4_03.pdf
• Cisco Disk Storage Interoperability Matrix http://www.cisco.com/en/US/docs/switches/datacenter/mds9000/interoperability/matrix/Matrix1.html
• IBM Support Matrices : http://www-03.ibm.com/systems/storage/product/interop.html
• HCL/WSC Microsoft : http://www.windowsservercatalog.com/results.aspx?bCatID=1291&cpID=0&avc=10&OR=1

Et pour Failover Cluster 2008 et 2008 R2? et bien, c'est beaucoup plus simple : il suffit que vos composants (hosts, HBA, SAN et softtware) aient reçus le logo Certified for Windows Server 2008 ou Certified for Windows Server 2008 R2 et que les tests de Validate passent avec succès. That's All!

The Microsoft Support Policy for Windows Server 2008 Failover Clusters : http://support.microsoft.com/kb/943984

Lionel

Windows Core Support Escalation Engineer

Peu de choses à relever pendant ce mois de Septembre, les groupes Windows et Virtualisation fourbissent leurs armes pour le 23 Octobre, date de sortie générale de Windows 7 et Windows Server 2008 R2.

Du côté de la mobilité, Windows Mobile 6.5 pointera son nez début Octobre…

Bref, le calme avant la tempête ? L’avenir nous le dira.

Infrastructure Planning and Design Guide for Windows Server Virtualization

Mis à jour pour Windows Server 2008 R2.

Téléchargement : IPD Guide for Windows Server Virtualization

Infrastructure Planning and Design Guide for System Center Virtual Machine Manager 2008 R2

Lien : Infrastructure Planning and Design Guides for System Center

Outils de support, d’analyse de performances et de charge

Une liste intéressante d’outils pouvant être utilisés pour estimer ou planifier la charge sur vos serveurs. A priori orienté vers Hyper-V, le bulletin sur le blog du EEC liste des ressources exploitables dans plusieurs cas de figure.

Lien : Hyper-V Support, Performance and Load Tools - The Enterprise Engineering Center Blog

Le Datacenter de Dublin en mode décapotable ?

Non seulement ce centre de traitement est le plus grand Datacenter Microsoft en dehors des Etats-Unis mais surtout il met en oeuvre la vision décrite précédemment dans la newsletter de Fevrier. A savoir les Datacenter de 4ème génération que je ne pensais pas voir si tôt.

Pour la petite histoire, ce Datacenter hébergera les services du Cloud, Live et Microsoft Online.

Lien : Dublin Data Center Celebrates Grand Opening

Un paquet de ressources IBM

Suite à la mise à disposition du Microsoft Assesment Planning Tool, IBM nous gate en éditant la version adaptée à ses systèmes.

En bonus, quelques liens techniques.

Lien : Microsoft System Management Solutions for IBM Servers

Quelques outils qui accompagnent Windows 7

Bien avant la date butoir, l’équipe en charge de développer la version de Microsoft Deployment Toolkit 2010 a publié la version finale dernièrement. Quelques changements ont été apportés à l’interface d’administration (le Workbench) et des améliorations disséminées un peu partout mais le principe reste le même. Cet outil reste un incontournable du déploiement.

Téléchargement : Microsoft Deployment Toolkit (MDT) 2010

Utiles et indispensables, les outils d’administration à distance pour Windows 7.

Téléchargement : Remote Server Administration Tools for Windows 7

De quoi préparer la migration de Windows XP à Windows 7 en préservant ses données.

Téléchargement : Windows Easy Transfer for transferring from Windows XP to Windows 7

Security Essentials disponible

La suite de protection anti-virus gratuite remplaçant OneCare et ayant pour nom de code Morro est disponible en version finale.

Lien : Microsoft Security Essentials

Guillaume

Windows Core Support Escalation Engineer

Par curiosité personnelle et un peu professionnelle, je me suis intéressé depuis quelques temps à tout ce sur quoi repose Hyper-V pour fonctionner et fournir une plateforme de virtualisation performante.

Au fil de mes recherches et au vu du nombre de sujets à aborder, il m’a paru intéressant de reporter ce que j’ai pu comprendre dans une série de bulletins visant à démontrer que l’implémentation d’une plateforme de virtualisation ne reposait pas uniquement sur le choix du logiciel mais également sur le choix du matériel. En l’occurrence, le processeur, le chipset et les adaptateurs réseau.

La question amenée par cette série de bulletins ne se porte surtout pas sur le choix d’un fondeur particulier, AMD ou Intel®, mais plutôt sur le choix de l’anticipation.

Anticipation quant à la sélection des composants embarqués dans les serveurs que vous dédierez à la virtualisation avec les génération d’hypervisors à venir (bon… Hyper-V v2, on est d’accord ?).

Jusqu’à présent le choix des serveurs se limitait aux notions évidentes de performance et de capacité de leurs composants :

• Fréquence du processeur, éventuellement la capacité des différents niveaux de cache, le nombre de cores, …
• Capacité de la mémoire physique, fréquence, …
• Capacité des cartes réseau (100MB/1GB/…)
• Etc…

Tous ces critères restent valables pour la majorité des rôles endossés par la plupart des serveurs mais la virtualisation amène des nuances non négligeables qui peuvent faire la différence en terme de performances.

Il se peut cependant que j’enfonce des portes ouvertes étant donné que beaucoup de constructeurs de serveurs proposent déjà largement les technologies d’Intel® et d’AMD dans leurs plateformes. L’intérêt de ce bulletin et de ceux à venir consistera donc à mieux comprendre la forte adhérence du matériel avec les solutions de virtualisation.

Je tenterais de décrire dans cette série les produits et technologies d’AMD et d’Intel® listés ci-après et en expliquer les intérêts pour Hyper-V :

Mais, tout d’abord, en guise d’introduction et pour bien comprendre l’intérêt de considérer différemment les plateformes de virtualisation des autres systèmes, une petite explication sur ce que représente le matériel pour les hypervisors que nous connaissons.

Le terme “hypervisor” étant barbare, je pourrais également utiliser le terme “VMM” (Virtual Machine Monitor) tout au long de ces bulletins.

Hardware-Assisted Virtualization (la virtualisation assistée par le matériel)

La virtualisation n’est pas un concept nouveau… loin de là. Ce n’est que ces dernières années que le sujet est revenu à l’ordre du jour avec l’accroissement massif du nombre de serveurs et le besoin de revenir vers des prétentions plus réalistes.

En effet, le principe de la virtualisation a déjà été abordé par IBM au début des années 1980 avec l’IBM VM/370 puis le System/370-XA qui tentaient de répondre (ou répondaient) aux besoins amenés par l’hébergement de plusieurs systèmes sur un seul hôte physique : la gestion des I/Os et la gestion de la mémoire.

Ensuite, après le large déferlement du processeur x86 sur le monde, ce fut au tour d’AMD et d’Intel® d’implémenter dans leurs processeurs des fonctions permettant aux acteurs actuels du logiciel de proposer leur hypervisor.

Mais en quoi cela consiste ? Rien de bien compliqué… Juste l’ajout d’instructions spécifiques dans les processeurs permettant la mise en oeuvre d’un VMM sur une plateforme matérielle.

Ce VMM a alors pour tâches de gérer l’exécution des machines virtuelles, de leur allouer un espace mémoire et de leur permettre l’accès aux périphériques matériels. Je reviendrais plus tard sur chacun de ces aspects.

Ca ne paraît rien comme ça mais ces quelques instructions ont permis (dans le monde des processeurs AMD et Intel®) de faire basculer notre conception des plateformes systèmes.

Plateforme serveur classique	Plateforme virtualisée

Les deux schémas ci-dessus permettent d’illustrer la différence entre une plateforme serveur classique et une plateforme virtualisée.

Je n’ai repris qu’un seul modèle d’hypervisor (qui cible les environnements de production) sur lequel s’appuie Hyper-V. Ce modèle, qui s’appelle Type 1 ou Bare-Metal, s’appuie pour sa part sur les technologies de virtualisation des deux fabricants pour fonctionner : Intel® VT (Intel® Virtualization Technology) pour l’un, AMD-V™ (AMD-Virtualization™) pour l’autre.

Ressources

Virtualization for dummies – AMD Special Edition - PDF en anglais, pour les débutants !

Hardware Support for Efficient Virtualization - John Fisher-Ogden (University of California, San Diego) – Document en anglais donnant un aperçu assez global de la virtualisation.

Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 2B: Instruction Set Reference, N-Z – Document en anglais plus pointu où l’on peut retrouver le détail des instructions implémentées pour la virtualisation (chapitre 5).

A suivre…

Guillaume

Windows Core Support Escalation Engineer

C’est la première fois que je rencontre ce cas de figure et c’est presque un coup de chance qui m’a permis d’identifier la solution à ce problème.

Le contexte est le suivant : sur un cluster Windows Server 2008 deux noeuds, lorsque l’on passe la ressource IP Address offline ou que l’on forçe un failover du groupe contenant cette ressource il n’est plus possible de contacter le noeud qui détenait cette ressource à travers le réseau. Encore moins d’ouvrir une session en Remote Desktop.

Comportement qui laisse sceptique au début et qui relève de la magie lorsqu’on nous le montre…

En une images, la configuration simple pour reproduire ce comportement :

Trois réseaux (le problème apparaît avec deux voir un seul réseau) :

• Réseau publique : communication intra-cluster et connectivité clients
• Réseau pour le heartbeat : communication intra-cluster seule autorisée
• Réseau iSCSI : aucune communication cluster autorisée

Une ressource IP Address disposant de l’adresse IP 192.168.40.33

Les addresses IP des noeuds étant :

• LAB-WS08-SQL0 : 192.168.40.103
• LAB-WS08-SQL1 : 192.168.40.104

Après les quelques vérifications d’usage autour de la configuration des adaptateurs réseau de chaque noeud, nous avons vérifié la présence de paramétrages de routage spécifique, propre aux serveurs. Et il s’est avéré qu’une route statique avait été rajoutée sur chacun des noeuds.

Et c’est là que l’on pointe un sujet méconnu : l’adaptateur virtuel nommé Microsoft Failover Cluster Virtual Adapter.

La question est donc qu’est-ce que cet adaptateur et à quoi sert-il ?

En peu de mots, le code du cluster sous Windows Server 2008 a été en grande partie réécrite et la couche réseau en a bénéficié. Ce qui se traduit par l’apparition de cet adapateur qui a pour tâche de construire et de maintenir une structure de routage sur chacun des noeuds afin d’améliorer la connectivité réseau en cas de défaillance de l’un des adaptateur réseau.

C’est cette nouveauté qui permet de placer des noeuds d’un même cluster sur des sous-réseaux différents séparés par des routeurs, ce qui n’était pas possible avec Windows 2000 Server et Windows Server 2003.

Mais revenons à notre problème.

Sur ces deux serveurs, une route statique a été configurée, comme on peut le voir sur les captures d’écran ci-dessous :

LAB-WS08-SQL0	LAB-WS08-SQL1

On voit ici que cette route s’applique à tous les adaptateurs.

En rouge la route statique.

En bleu, l’adresse IP du noeud.

En vert l’adresse IP de la ressource IP Address du cluster.

Notez ce qui est entouré de jaune.

Lorsque l’on bascule la ressource IP Address ou que l’on passe offline cette ressource, la route statique du noeud disparait de la table de routage (du moins elle ne fait plus partie des routes actives) :

Ce qui rend impossible la connectivité vers et depuis le réseau 192.168.42.0 (le sous-réseau qui fait l’objet du routage statique).

Comment résoudre ce problème et utiliser tout de même un routage statique ? C’est simple, mettre en oeuvre le routage statique de manière recommandée, à savoir suivre la procédure suivante :

1. Supprimer la route statique :
   
   ROUTE DELETE 192.168.42.0
   
2. Identifier l’adaptateur réseau qui doit bénéficier de ce routage statique :
   
   NETSH INT IPV4 SHOW INT
   
   
   
3. Appliquer la route statique à cet adaptateur uniquement en exécutant la commande suivante :
   
   ROUTE –P ADD 192.168.42.0 MASK 255.255.255.0 0.0.0.0 IF 15
   
   où 15 correspond à l’adaptateur et 0.0.0.0 représente la route par défaut (en l’occurence la passerelle pour communiquer avec le réseau 192.168.42.0 sera l’adresse IP de l’adaptateur réseau du noeud)

On obtient ceci :

Table de routage avec la ressource IP Address online	Table de routage avec la ressource IP Address offline

On voit ici que la route statique reste active même lorsque la ressource IP Address est offline.

Meilleures pratiques

• Ne jamais modifier le paramétrage de l’adaptateur virtuel Microsoft Failover Cluster Virtual Adapter
  
• Ne jamais désactiver l’adaptateur virtuel Microsoft Failover Cluster Virtual Adapter
  
• Créer des routes statiques avec la méthode décrite ci-dessus

Ressources

Rendons à César ce qui appartient à César, le bulletin qui m’a permis de résoudre cet incident : Active Route gets removed on Windows Server 2008 offline Cluster IP Address – Blog Microsoft Enterprise Networking Team

What is a Microsoft Failover Cluster Virtual Adapter anyway? – Blog de l’équipe Core aux US

Multi-Site Failover Cluster Communications Connectivity – Blog de l’équipe Core aux US

Guillaume

Windows Core Support Escalation Engineer