Microsoft Hyper-V vNext : nouvelles fonctionnalités

• Mise à jour des clusters Hyper-V à chaud

Le processus de mise à niveau des clusters Windows Server 2012 vers Windows Server 2012 R2 était assez simple notamment grâce à la possibilité de migrer à chaud les machines virtuelles de l’ancien cluster vers le nouveau. On notera que le seul inconvénient était la récupération ou l’acquisition d’au moins une ou deux  machines pour créer le nouveau cluster.

Avec Hyper-V vNext et la nouvelle notion de niveau fonctionnel de cluster, le processus est vraiment simplifié puisqu’il est désormais possible d’ajouter de nouveaux nœuds Hyper-V vNext au sein d’un cluster Hyper-V 2012 R2 existant.

Ensuite, la méthode consiste à libérer chaque nœud l’un après l’autre pour réaliser la mise à niveau vers Hyper-V vNext et finalement rehausser le niveau fonctionnel du cluster via la commande Windows PowerShell Update-ClusterFunctionalLevel.

Bien entendu, une fois l’opération réalisée, il ne sera plus possible d’ajouter de nouvelles machines hôtes Hyper-V 2012 R2, mais par contre, il sera possible de mettre à jour les VM en v6 – toujours via PowerShell avec la commande Update-VMConfigurationVersion.

Au final, comme les machines virtuelles v5 d’Hyper-V 2012 R2 sont compatibles avec Hyper-V vNext, cette dernière opération quasi instantanée – mais nécessitant l’arrêt de la machine virtuelle, pourra être réalisée progressivement en fonction des fonctionnalités souhaitées ou des contraintes de production.

• Compatibilité des VM et nouveaux fichiers de configuration vNext

Avec Windows Server 2012 R2, les fichiers de configuration des machines virtuelles sont des fichiers textes de type XML.

Afin d’éviter les erreurs de configuration liées aux manipulations directes de ces fichiers par les administrateurs et aussi d’apporter un suivi des opérations liées aux changements de configuration – Change log, les machines virtuelles V6 d’Hyper-V vNext utilisent de nouveaux fichiers binaires – .

VMCX pour les données de configuration et .VMRS pour les données d’état d’exécution – Runtime State.

En plus de ces avancées, ces changements doivent améliorer l’efficacité des opérations de lecture et d’écriture pour les configurations de type Datacenter, tout en minimisant les risques potentiels de corruption.

Pour rappel, les fichiers de disques virtuels VHDX apparus avec Windows Server 2012 R2 avaient aussi pour objet d’apporter une grande résistance aux corruptions via la gestion des transactions.

Une autre nouveauté importante concerne la compatibilité et le retour arrière vers Hyper-V 2012 R2. En effet, les machines virtuelles créées sous Windows Server 2012 R2 (VM en versions 5 avec fichiers XML) sont directement utilisables sans aucune opération de conversion sous Hyper-V vNext. De fait, il n’y a aucun problème pour déplacer les machines virtuelles de Windows Server2012 R2 vers Windows Server vNext et vice-versa !

Ensuite, pour accéder aux nouvelles fonctionnalités apportées par Hyper-V vNext, l’administrateur décidera du meilleur moment pour procéder à la mise à niveau des machines virtuelles existantes en version 6, cette fois-ci à l’aide de la commande Windows PowerShell Update-VmConfigurationVersion. A ce stade, toutes les nouvelles fonctionnalités liées à Hyper-V vNext sont disponibles et le retour arrière ne sera plus possible.

• Storage Replica pour la réplication du stockage

Storage Replica est certainement l’une des plus grandes nouveautés de Windows Server vNext !

En effet, en permettant la réplication du stockage entre des serveurs ou même des configurations de type clusters géographiques, la fonctionnalité SR – Storage Replica, de Windows Server vNext ouvre la voie à de nouveaux scénarios de PRA basés sur une solution agnostique vis-à-vis du stockage et offrant une réplication au niveau bloc en mode synchrone et asynchrone.

Ainsi, la réplication synchrone fonctionnant au niveau du système de fichiers permettra la mise en miroir des données entre différents sites tout en garantissant de ne perdre aucune donnée en cas de sinistre.

Pour les configurations dont les liens réseaux sont plus lents et ne permettent pas l’utilisation du mode synchrone, la réplication asynchrone pourra être utilisée. Dans ce dernier cas, en cas de sinistre, les données non encore acquittées par le volume de destination pourront être perdues.

(((IMG7752)))

Il est certain que cette superbe fonctionnalité 100% agnostique vis-à-vis des matériels de stockage va pousser de nombreux clients à découvrir Windows Server vNext !

Basée sur le protocole Microsoft SMB 3.x, cette fonctionnalité de réplication synchrone et asynchrone au niveau bloc supporte les configurations simples et les configurations géo cluster, utilise les réseaux TCP/IP via le TCP 445 ou 5445, supporte l’utilisation des cartes réseaux RDMA (sur iWarp ou Infiniband), supporte les connexions multi-chemins et multicanaux SMB, les authentifications Kerberos, le cryptage et la signature des paquets, les fonctionnalités de déduplication et BitLocker et l’utilisation des rôles Hyper-V, SQL Server, Serveurs de fichiers ou toute autre application indépendante du stockage.

• Production Checkpoints

Les versions précédentes d’Hyper-V permettaient à l’administrateur de réaliser des snapshots – appelées aussi Points de contrôle ou Checkpoints, avec Hyper-V 2012 R2. Bien utiles avant certaines opérations présentant un risque, l’usage des points de contrôle au niveau des machines virtuelles ne supporte malheureusement pas les applications telles que SQL Server, Oracle, Exchange ou même les rôles avancés tels que les contrôleurs de domaine Active Directory.

Avec Hyper-V vNext, les snapshots de type « Production checkpoints » supportent désormais la restauration d’un état cohérant vis-à-vis de la plupart des applications. Implémentée via l’utilisation des technologies de sauvegarde à chaud basées sur les snapshots VSS, l’opération est directement prise en charge au sein de la machine virtuelle elle-même. Microsoft précise que cette fonctionnalité est aussi supportée au niveau « consistance du système de fichiers » pour les machines virtuelles Linux via un nettoyage des buffers Linux.

(((IMG7753)))

Microsoft précise qu’à ce stade du développement, les nouvelles machines virtuelles créées sous Hyper-V vNext utilisent les nouveaux snapshots de type « Production checkpoints » avec une possibilité de repli automatique sur les points de contrôles, lorsque cela n’est pas possible.

• QoS distribuée sur le Stockage

Les entreprises utilisent aujourd’hui des capacités de stockage de plus en plus volumineuses mais tendent aussi vers une encore plus grande centralisation de ces ressources.

Avec ce type d’environnement, il devient nécessaire de s’assurer que chaque VM puisse disposer du nombre d’IOPS nécessaire. Avec Windows Server 2012 R2, les administrateurs disposaient d’un premier niveau de QoS permettant de limiter le nombre maximum d’IOPS d’une machine virtuelle donnée.

Bien que cette première implémentation puisse être utilisée lorsqu’il est question de fixer un seul d’IOPS maximum / VM, le fait que les règles QoS ne soient pas distribuées entre les différents nœud d’un cluster fait qu’un nœud Hyper-V donné n’a aucune vue du nombre d’IOPS consommées par les autres nœuds Hyper-V connectés au même stockage partagé.

Windows Server vNext permet désormais à l’administrateur de créer des règles de QoS distribuées lorsque le stockage utilisé est de type SOFS – ScaleOut File Server.
Dans ce cas, le cluster SOFS – composé de 2 à 8 membres, crée l’abstraction en présentant les ressources SAN via SMB 3.0 et en gérant la fonctionnalité de QoS distribuée à l’aide du nouveau protocole MS-SQOS directement au sein du cluster SOFS. Cette nouvelle architecture « côté SOFS » offre à la fois l’avantage de centraliser la gestion des stratégies QoS et aussi de présenter une vue unifiée aux machines Hyper-V.

• Hyper-V Replica : Ajout à chaud des disques VHDX et support des disques VHDX partagés

Pour faciliter la mise en œuvre des configurations en cluster basées sur des machines virtuelles, Windows Server 2012 R2 a apporté le support des disques virtuels VHDX partagés.

Malheureusement, bien qu’à l’époque cette possibilité ait été saluée, les fonctionnalités de mobilité et de sauvegarde de ce type de configuration étaient limitées. Désormais, Hyper-V Replica dans Hyper-V vNext supporte la réplication des disques virtuels VHDX partagés ainsi que l’ajout à chaud des disques VHDX au sein des VM utilisant la réplication Hyper-V Replica.

Le support des points de contrôle (snapshots) et des opérations de sauvegarde à chaud sur les disques VHDX partagés utilisés par les machines invitées configurées en cluster sont aussi des améliorations notables apportées par Hyper-V vNext.

• Ajout et Suppression à chaud des cartes réseaux et de la mémoire RAM

Bien qu’il ne s’agisse pas d’une révolution en soit, Hyper-V vNext améliore encore la configuration dynamique à chaud des machines virtuelles de type Génération 2 fonctionnant sous Windows et aussi sous Linux.

Ainsi, il est désormais possible de directement changer la taille de la mémoire RAM de la machine virtuelle – sans pour autant activer la gestion de la mémoire dynamique Hyper-V. Il devient aussi possible d’ajouter ou de supprimer des cartes réseaux synthétiques à chaud.

• Démarrage sécurisé des VM Linux

Avec Windows Server 2012 R2, les machines virtuelles Hyper-V de type Génération 2 supportent un nouveau firmware virtuel UEFI et aussi l’option « Démarrage sécurisé » pour empêcher le code non autorisé à s’exécuter au démarrage. Uniquement utilisable par les machines virtuelles fonctionnant sous Windows Server 2012, 2012 R2 et Windows 8 et 8.1, Hyper-V vNext permet désormais aux machines virtuelles Linux Ubuntu 14.04 et SUSE Linux Enterprise Server 12 de tirer parti de ce niveau de protection.

• Mise à jour des Composants d’intégration Hyper-V via Windows Update

Jusqu’à présent, la mise à jour des Services d’intégration dans les machines virtuelles Hyper-V était réalisée via l’insertion de l’image ISO vmguest.iso. Avec Hyper-V vNext, la mise à jour des composants d’intégration à l’aide de l’option « Insérer le disque d’installation des services d’intégration » a été retirée. Désormais, l’opération devra être directement réalisée par le système d’exploitation invité via Windows Update – KB3004908, les services WSUS ou bien sûr SC Configuration Manager.

Cette méthode déjà utilisée avec la plupart des distributions Linux permettra d’éviter l’utilisation de privilèges d’administration au sein des machines virtuelles tout en facilitant l’administration et le suivi des mises à jour.

En attendant les containers Docker dans la prochaine technical preview…

Et quoi d’autre en perspective dans les prochaines semaines ?

Ce sera, certainement, la 1re implémentation du Docker Engine pour Windows Server vNext. En effet, depuis plusieurs mois, Microsoft et Docker ont annoncé un partenariat stratégique pour l’implémentation native des conteneurs Docker sous Windows Server vNext.

En utilisant cette technologie, Microsoft montre la voie en permettant à ses clients d’accéder aux meilleures technologies de l’écosystème Linux et de l’écosystème Windows Server. Dans le futur, nous aurons donc la possibilité de proposer les applications de manière traditionnelle via des machines virtuelles ou via des containers Docker plus légers. Avec le principe de la « containerisation », il est plus facile de packager, livrer et exécuter les applications qu’avec des VM traditionnelles. C’est pourquoi, les architectes devront se poser la question du choix entre la mise en œuvre d’une machine virtuelle plus étanche mais plus lourde en termes de ressources ou celle d’un container Docker beaucoup plus léger et rapide opérant au niveau du processus !

(((IMG7754)))

Avec toutes ces nouveautés “in-the-windows-box”, et en attendant la prochaine version Technical Preview 2, il est certain que Microsoft compte frapper un grand coup avec Windows Server et Hyper-V vNext !