Virtualisation

Réflexions sur la virtualisation (Hyper-V) – Gardez les pieds sur terre …

La déesse de la virtualisation à certainement déjà frappé à votre porte, ou ça ne saurait tarder. Ces solutions se présentent à vous, toutes plus efficaces et meilleures que les autres. Le déluge des arguments favorables à ces techniques vous submerge au risque de vous faire perdre de vue les fondamentaux des infrastructures dites « standards ».

A mon humble avis, la virtualisation d’un système représente une mutation profonde qui doit être réfléchie et métrée en amont, sur une période significative et projetée dans le temps, afin d’éviter toute décision que vous pourriez regretter à terme. Il faut admettre qu’il n’y pas de bonne ou de mauvaise solution, autre que celle qui correspond à vos besoins (et vos moyens financiers)

Mais cet article n’a pas pour vocation de comparer telle ou telle solution, mais bien de se concentrer sur quelques fondamentaux :

Je baserais ma rédaction sur la solution Hyper-V intégrée (bien que l’activation reste optionnelle) dans Windows Server 2008 x64 mais qui pourrait être étendue aux autres solutions

 

Les grandes incidences de la virtualisation :

 

La relativité du temps !

Comme vous le savez peut être, les ordinateurs (physiques) calculent le temps et donc l’horloge à partir d’une RTC (Real Time Clock). Un composant électronique (Quartz / pile électrique) fournissant ainsi une cadence d’horloge plus ou moins variable. Je vais donc dire acceptable à une petite échelle mais dont la précision s’éloigne inexorablement du fameux temps universel (UTC) qui constitue LA référence sur notre petite planète…. Il existe à cet effet des serveurs de temps ou dispositifs spécialisés qui proposent une source fiable au travers du protocole NTP.

Dans un environnement virtualisé, le cycle d’horloge (ou la pulsation) que reçoit la machine virtuelle est très subjectif puisqu’il est à la discrétion de l’hyperviseur ou plus généralement de la couche de virtualisation. Ainsi, vue de la machine virtuelle le temps réel n’existe pas ou tout au mieux n’est plus fiable. Pour cette raison, pratiquement tous les systèmes de virtualisation offre « un service de synchronisation horaire » qui permet de corriger dynamiquement ces variations.

 

Exemple concret : « Le contrôleur de domaine » – Utilise un protocole d’authentification horodaté (Kerberos) et impose donc une source de temps fiable. Il faut donc laisser le contrôleur virtualisé se baser sur son horloge interne bien que celle-ci soit virtuelle, le service de compensation fera le reste. (Vérifier simplement qu’il ne soit pas désactivé*). Reste donc la fiabilité de l’horloge du « porteur » physique que vous pouvez configurer comme un client NTP d’une source temps fiable et le tour est joué. En aucun cas, le client NTP (ou pire un serveur NTP) ne doit être installé dans une machine virtuelle !

(*) – La synchronisation horaire avec la partition racine d’Hyper-V est implicite et ne peut pas être désactivée par les interfaces d’administration.

A cela, j’ajouterais que concernant le fait de virtualiser un contrôleur de domaine, (Ce que Microsoft déconseille), il faut absolument proscrire l’usage des captures instantanées (snapshots) – En effet, les trames de synchronisation de l’annuaire sont horodatées et identifiées par chaque contrôleur. En conséquence, le recours à un cliché antérieur va engendrer un “paradoxe temporel” (cf retour vers le futur 🙂 ) que les autres serveurs ne seront pas en mesure de comprendre, particulièrement si la machine virtuelle assure un rôle décisionnaire (FSMO) tel que l’émulateur CDP.

 

Le stockage

  •  iSCSI = Réseau dédié !  Ce n’est pas parce qu’il s’agit du même type d’équipement qu’il faut les mutualiser avec d’autres utilisations. N’oubliez pas que ces équipements véhiculent des flux d’entrées/sorties de disques, et qu’ils tolèrent très mal des engorgements.
  • VHD – Taille Fixe ou dynamique ? Sachant qu’un disque virtuel à taille fixe peut être étendu (mais pas réduit), qu’il est généralement possible d’étendre une partition si l’espace disponible est contigu à celle-ci, ma préférence penche donc en faveur du disque virtuel à taille fixe. Ce choix permettra de limiter la fragmentation du fichier VHD hébergé sur le disque physique.

 

Il est inutile, voire dangereux de modifier la taille des unités d’allocation NTFS de l’hébergeur, tout comme celle des disques virtuels. En effet, les fichiers VHD étant  volumineux, la logique (concernant les réglages NTFS) tendrait à utiliser un formatage supérieur aux 4Ko par défaut. Cependant, intrinsèquement les fichiers .VHD sont également des ensembles de blocs élémentaires. Les fréquentes entrées /sorties sur ces « blocs de disques virtuels » doivent engendrer des accès sur des blocs physiques de taille similaire afin d’éviter l’effet d’amplification lié au décalage. Mais tout ceci reste très relatif et intimement lié aux performances des équipements de stockage  (caches, SSD, SAN ….)

Pour les machines virtuelles ayant des besoins particuliers en matière de stockage, vous avez la possibilité d’affecter directement un disque (passtrough) à une machine virtuelle. (Disque local ou LUN). Cela offre un niveau de performance pratiquement identique à celui d’une machine physique. Notez que vous perdrez la notion de capture instantanée (snapshot) en affectant cet accès direct de disque à une machine virtuelle.

 

Les réseaux

Dans un environnement tel que Hyper-V, on distingue 3 types de réseaux “virtuels”.

–          Réseau privé (isolé) dédié aux machines virtuelles

–          Réseau interne assurant une connexion entre l’hôte et les machines virtuelles qu’il héberge.

–          Réseau externe dédié ou non aux machines virtuelles

HV-Networks

Appelés également “commutateurs virtuels” en raison du fait qu’ils supportent chacun plusieurs connexions (ou ports), à l’instar d’un commutateur traditionnel (switch).

Chaque commutateur virtuel peut être relié à une interface Ethernet physique (carte réseau) dédiée ou non. Ce goulet d’engorgement potentiel peut être compensé par une agrégation de plusieurs cartes réseaux physiques (teaming)

Une certaine ambiguïté peut naitre de la “non réservation” des cartes physiques à un commutateur virtuel dit externe. En effet, hormis le fait qu’il soit conseillé de dédier une carte réseau pour les besoins d’administration distante d’un hyperviseur, la configuration d’un commutateur virtuel externe sur Hyper-V propose de “partager” cette connexion avec l’hébergeur. Dans ce cas, la connexion peut paraitre  “dédoublée” dans l’affichage des interfaces réseaux, l’une symbolisant le commutateur virtuel, (la carte réseau physique) l’autre le port de l’hôte sur ce commutateur (reprise des anciens réglages de la carte physique).

Dans la pratique, cette possibilité de mutualisation est utile dès lors que le nombre de carte(s) réseau(x) disponible(s) sur l’hôte est faible, typiquement pour des tests ou du maquettage. Pour une véritable mise en production, il faudra idéalement prévoir un minimum de 3 à 4 cartes réseaux pour :

  • Les machines hébergées (plusieurs interfaces et/ou teaming pour une bande passante maximale)
  • L’administration à distance de l’hébergeur
  • Le réseau de stockage iSCSI éventuel,
  • Un réseau de bascule / migration rapide dans le cas d’un cluster de basculement (Failover Clustering)


P2V ou la migration physique vers virtuel

Bien que séduisantes, ces solutions ne sont pas sans danger. En effet, il y a beaucoup de contraintes : les pilotes, UUID, @MAC, Activation produit, protections anti copie de certains logiciels, dongles. Il n’y a donc aucune garantie de résultat sur ce genre d’opération et son succès ne dépend pas uniquement de la solution retenue.

Exemple concret : Il ne faut jamais utiliser ces pratiques P2V sur un « contrôleur de domaine » – En fait, il est construit à partir d’informations matérielles et logicielles qui caractérisent son unicité sur laquelle repose celle du domaine tout entier. Techniquement simple et à moindre risque, il convient donc d’installer un contrôleur supplémentaire directement dans son environnement virtuel puis transférer, au besoin, les rôles FSMO et autres DNS comme s’il s’agissait d’un nouveau serveur physique.

Hyper-V et Anti-virus

La sécurité d’un système informatique est un tout composé de technologies numériques spécialisées, de protection physique mais également de comportements humains. Fort de ce constat, l’efficacité ne se mesure donc pas par la puissance ou la somme des éléments mais par la cohérence sans faille de l’ensemble. Pour faire court, ce n’est pas l’épaisseur des « murs » qu’il faut mesurer mais plutôt l’étanchéité.

Cet article n’a pas la prétention de traiter un sujet aussi vaste que celui de la sécurité informatique mais constitue une simple réflexion de bon sens, sans revenir sur les bonnes pratiques qui devaient être adoptés sur les serveurs Windows et systématiquement sans hésitation sur les machines « sensibles ».

Trêve de discours et entrons dans le cœur du sujet : Dans l’architecture Hyper-V, il convient de distinguer 3 grandes parties :

  • L’hyperviseur : C’est un pilote « signé numériquement » et chargé au tout début du démarrage dans la zone d’exécution « VT » du processeur parfois appelé « Ring -1 »
  • La partition parente ou racine (Root) : C’est en fait, le système d’exploitation (En l’occurrence Windows Server 2008 / R2) qui s’exécute « presque » comme un système Windows traditionnel dans les zones d’exécution normales (Rings 0 à 3)
  • Les partitions enfants : Elles contiennent les systèmes dits “Invités” (Guests OS) et l’on peut les assimiler à des machines virtuelles, plus ou moins conscientes de la présence d’un hyperviseur.

HV-Rings

En matière de sécurité, le choix d’installation d’un système antiviral dans la partition parente est tout à fait légitime mais doit prendre en considération les interférences potentielles de cette architecture particulière.

Il faut tout d’abord considérer la surface d’attaque de la partition parente au même titre qu’un système standard. Une installation minimale (Core) sera donc moins exposée par l’absence des principales applications et interfaces graphiques. Il va sans dire, mais je le précise malgré tout, que  les applications à hauts risques telles qu’un navigateur, un client de  messagerie, ou plus globalement toute application ayant un lien direct avec l’Internet, sont à proscrire !…

Dans la même lignée, il convient de désactiver la lecture / exécution automatique des supports et de valider toutes les mises à jour ou installations de logiciels (sources sures, pertinence, signature numérique) et tout particulièrement les pilotes.

N’oublions pas l’activation du pare-feu, et l’ouverture des ports d’administration aux seules machines autorisées (ie Réseau type « Public » sauf rares exceptions) – Ne confondez pas les cartes réseaux affectés aux commutateurs virtuels (externe et interne) visibles dans le parent. Notez également que tous les commutateurs virtuels sont de véritables commutateurs de niveau 2 qui ne supportent pas les modes de type « promiscuous / monitoring ». Il faut donc bien réfléchir à l’infrastructure réseau qui assure le routage des trames vers et en provenance de l’extérieur.

Si ces « bonnes pratiques » sont respectées, un système anti-virus serait logiquement inutile mais des utilisations particulières du parent, notamment en tant que serveur de fichier, ouvrent des failles potentielles par le stockage de données sur le système, et le spectre d’un antivirus commence alors à vous envouter.

Je vous laisse le soin de choisir l’éditeur qui vous convient (n’oubliez pas qu’il s’agit d’un système x64) et que si l’éditeur est certifié sur le sujet, vous serez plus serein.

Dans le cadre d’un antivirus plus « générique », il conviendra d’exclure du périmètre de contrôle, les fichiers déjà signés par Microsoft ou plus particulièrement   :

  • Le(s) répertoire(s) de configuration par défaut (C:\ProgramData\Microsoft\Windows\Hyper-V)
  • Le(s) répertoire(s) de configuration des machines virtuelles
  • Le(s) répertoire(s) de stockage des disques virtuels
  • Le(s) répertoire(s) des captures instantanées (snapshots)
  •  Le fichier vmms.exe (le processus d’administration d’hyper-v)
  •   Le fichier vmwp.exe (le(s) processus de travail des machines virtuelles ( worker processes)

J’espère que ce petit propos, quelque peu moraliste, aura su éclairer vos réflexions et en guise de conclusion, j’affirmerais simplement ceci :

« En informatique presque tout peut être “virtualisé”, à l’exception des problèmes ! 🙂 »

 

Bien à vous

 

Christophe

 

 

Article créé le : 17 juillet 2010

 

 

Laisser un commentaire

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

Ce site utilise Akismet pour réduire les indésirables. Apprenez comment les données de vos commentaires sont utilisées.