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