Microsoft est réellement en train de booster son protocole de partage de fichier SMB 2.2. Les  développement  ciblent des améliorations dans les domaines tels que la performance, la montée en charge, et la tolérance de panne.Voici quelques domaines qui permettront d’améliorer considérablement les capacités d’une infrastructure virtualisée basée sur Hyper-V et le partage de fichier en SMB 2.2:

•Remote VSS– les clients avec Volume Shadow Copy Service (VSS) pourront monter les clichés d’instantané localement, comme l’on peut le faire avec des baies de stockage FC, FCoE et iSCSI.

•Cluster client basculement– ce mécanisme permet aux clients de rattacher leur handle sur une « instance ID. » L’objectif est de fournir au client un moyens de basculer sans interruption de service entre plusieurs points d’accès de stockage de manière transparente.

•Copie unifiée SAN/SMB  –  SMB2.2 fournira des capacités de copie “offload”, comme beaucoup connaissent dans vSphere. SMB 2.2 de permet de transférer la charge liée aux copies, directement au sein du serveur SMB 2.2 : ainsi la copie d’un fichier par un client au sein d’un même serveur ne passera plus par le réseau, et la copie d’un fichier d’un serveur vers un autre, ne transitera plus par le client qui la fait, mais se fera directement entre les deux serveurs.

•Multi-channel (MPIO)–  SMB 2.2 est multi-session a contrario de SMB2.1. Il permet d’agréger plusieurs liens Ethernet en un pool logique en fournissant l’agrégation natif de bande passante, le basculement, et les fonctionnalités avancées MPIO. ces améliorations sont analogues à celles disponibles actuellement dans NFSv4.

• Disponibilité continue– Le client permet cela en créant plusieurs connexions qui couvrent tous les chemins entre client et serveur. Si une connexion échoue, ou si le temps de réponse est mauvais, le client choisit le chemin qui reste disponible.

Le prérequis pour prétendre à utiliser live migration a beaucoup changé.

Sur Hyper-V 2.0 il était nécessaire d’avoir un cluster, et donc un stockage partagé via une baie de stockage SAN, ISCSI ou SAS.

Désormais, il suffira d’une simple connexion réseau entre les deux hôtes !

Dans le détail voila comment cela se passe :

Dans notre exemple nous migrerons la VM W8 en sélectionnant la fonction Move…

Nous avons 3 possibilités :

• Migrer la VM sur un nouvel hôte avec lequel il y a un partage de stockage commun
• Migrer la VM et le stockage sur un autre Hyper-V
• Migrer simplement le stockage

Nous sélectionnons l’hôte de destination :

Nous sélectionnons les éléments a migrer :

Nous sélectionnons ensuite la destination unique ou distribuée :

Enfin nous sélectionnons l’emplacement :

Et enfin la migration démarre a chaud et sans coupure de la VM :

La VM est migrée !

conclusions

Les barrières tombent, rendant live migration accessible à tous les serveurs exécutant Hyper-V 3.0.

Il sera toujours nécessaire d’utiliser un cluster pour assurer la haute disponibilité, mais les live migration pourront s’effectuer entre 2 clusters différents, un deux machines autonomes , ou entre un cluster et une machine autonome.

De nombreuses améliorations ont été apportées au niveau réseau:

Protocole:

SMB 2.2

Le protocole SMB 2.1 fait place au protocole 2.2 qui permet non seulement d’accroitre les performance, mais surtout de pouvoir créer des serveur de fichiers distribués qui permettrons d’avoir des performance hors du commun ainsi d’assurer un “Transparent failover” sans aucune perte de donnée et sans aucune rupture de service (et d’utiliser un serveur de fichier pour héberger les VM Hyper-V…).

Bien évidement il faudra que le client sache parler en SMB 2.2 !

multiplexage de cartes réseau:

Désormais Windows 8 sait gérer la répartition de charge sur plusieurs cartes réseau ainsi que la tolérance de panne.

Ce multiplexage pourra se faire soit dans l’hôte (Hyper-v 3.0) ou dans l’invité (Windows

Extensibilité:

VMware fournissait des Virtual Switch  qui répondaient aux  mêmes commande que  les Switch physique CISCO.

Windows 8 et Hyper-V 3.0 permettent cette fonctionnalité au travers d’extension qui viendrons s’installer au sein des Switch virtuels:

Cela veut dire que l’on pourra mettre des extension pour faire de la capture réseau, des firewalls, de la translation d’IP etc..

Dors et déjà des constructeurs comme CISCO, FIVE NINE, ou BROADCOM ont présenté leurs extensions:

Cisco avec son intégration NEXUS, qui permet de gérer les Switch virtuels comme des équipements physique CISCO:

Même chose chez Broadcom:

La version de Windows Developer Preview de Windows Server 2012 ( Windows 8 ) est disponible, apportant un très gros lot de nouveautés.

En voici une tour d’horizon non exhaustif et non définitif :

Live Migration:

Il est désormais possible d’effectuer plusieurs migrations a chaud:

La configuration de Live migration se fait dans le panneau de configuration Hyper-V.

Il est a noter que l’on peut spécifier les adresses IP utilisées par LM, ainsi que l’ordre de préférence.

Storage migration:

Plus besoin de SCVMM pour déplacer le stockage !

un simple glisser déplacer vers le nouvel emplacement, et le tour est joué:

La migration est effectuée à chaud:

Mémoire

HyperV 3.0 se dote d’un deuxième niveau de pagination:

Réplication

C’est  la fonctionnalité qui va vous permettre de mettre en œuvre votre PRA nativement !

Vos VM pourront être répliquées d’un HyperV vers un autre au moyen du protocole http ou https : donc pas de problème particulier avec les firewalls…

Il suffit pour cela, de configurer le réplica comme suit

Choisir les disques a répliquer:

Déterminer le nombre de point de restauration, ainsi que la fréquence des clichés:

Et enfin de planifier ou de lancer la réplication:

Ainsi sur l’hyper-V cible, l’on peut découvrir le réplica en cours de création:

Un moniteur de réplication permet a tout moment de connaitre l’état. Dans notre cas la réplication a été exécutée en moins de 4 minutes:

Test du réplica

Une des fonctionnalité très intéressante est la possibilité de tester la viabilité du réplica :

Un  cliché instantané est alors réalisé pour ne pas toucher à la cible:

Il suffit alors de démarrer la machine test pour vérifier son fonctionnement:

Et enfin pour supprimer ce test il suffit de cliquer sur stop test failover:

Une confirmation est demandée:

Et la VM de test est supprimée:

Planification de Failover

Encore un excellente fonctionnalité. Dans les solutions de PRA il est toujours simple de basculer de l’environnement de production sur celui de secours, mais l’inverse est toujours très très compliqué…

En un seul click  sur “planned failover” la bascule démarre:

Ici tout est simplifié et Hyper-V s’occupe de toute la procédure!!

• Il réplique les derniers blocs manquant
• Il démarre le réplica
• Il recréé une réplication dans l’autre sens
• Et enfin il démarra la VM de secours.

Votre VM est donc opérationnelle sur la plateforme de secours !

Maintenant pour revenir en mode production, il suffira de recommencer la même opération.

Aucune donnée ne sera perdu, puisque il y aura un cliché instantané qui sera fait avant la bascule.

En résumé, il deviendra aussi banal de réaliser un “failover type PRA” , que un “live migration” sur un cluster Hyper-V.

Le PRA et le Cluster…

Et en cas de cluster Hyper-V ?? la réplication est-elle possible ?

Et bien oui, grâce a une autre fonctionnalité:  Hyper-V Replica Broker.

Cela permet de créer un réplica sur une adresse IP virtuelle et donc de ne pas indiquer en destination un serveur physique mais un cluster.

Conclusion

Microsoft nous réserve encore plein de bonnes surprises avec Hyper-V 3.0, mais dorénavant il est enfin un concurrent très sérieux face à VMware avec toutes les fonctionnalité natives et sans surcout optionnels.

A méditer avant de vous engager sur votre plateforme virtualisée…

Beaucoup de choses ont été dites concernant le fonctionnement de Linux sur la plateforme Hyper-V.

Le fait que Microsoft ne « supporte » pas toutes les distributions de Linux ne signifie en aucun cas qu’elles ne fonctionnent pas sur cette plateforme. Microsoft a limité simplement le support ainsi que le développement des services d’intégration à certaines distributions suivantes :

Au travers du pack Linux Intégration Services v2.1 for Windows Serveur 2008 Hyper-V, pour les distributions:

• SUSE Linux Enterprise Serveur 10
• Red Chats Enterprise Linux 5

 Au travers du pack Linux Intégration Services Version 3.1 fors Hyper-V, pour les distibutions:

• Red Chats Enterprise Linux 6.0 ans 6.1 x86 ander x64
• Cent Os 6.0 x86 ander x64

Qu’en est-il au niveau des autres versions?

UBUNTU et Hyper-V

Sur la version 10.4 d’Ubuntu Serveur, les services d’intégration Hyper-v sont partie intégrants de la distribution. Voici l’installation de cette distribution décrite ici :

http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/10/21/installing-ubuntu-server-10-10-on-hyper-v.aspx

DEBIAN et Hyper-V

Pour ce qui est de la distribution 5 et 6, Yusuf Ozturk propose les services d’intégration Linux Debian V ici :

http://www.yusufozturk.info/linux-server/debian-2-6-36-kernel-upgrade-for-hyper-v-client-drivers.html 

Pour ce qui est de la version 6 il faudra se rendre ici :

http://www.yusufozturk.info/linux-server/building-your-own-kernel-packages-for-hyper-v-support.html

Concernant le futur, il est intéressent de rappeler que Microsoft est le cinquième plus gros contributeur au développement du kernel Linux 3.0, avec une grande implication pour une meilleure integration d’hyper-V au sein du noyau.

Après avoir installé votre cluster hyper-v et créé votre première VM, vous avez peut-être été confrontés à un échec lors de migration d’un hôte vers l’autre.
Une des erreurs couramment commise, est de configurer la VM au travers du Snap-in Hyper-V manager et non d’utiliser le Snap-in Fail Over Cluster Manager. Si tel est le cas vous constaterez lors de vos tentatives de migration l’apparition de l’événement ID 32 :

Cela est dû au fait que la configuration n’a pas été propagée sur l’autre noeud la configuration réseau de cette VM.
Voici comment corriger ce problème:
Lancer le Fail Over Cluster Manager, et se positionner sur la VM en question.
Dans le panneau action, cliquez sur settings :

Effectuez vos modifications au sein de la configuration de votre VM:
 

Puis rafraichissez la configuration de la VM au sein du cluster:

Enfin relancez votre migration:

La migration s’effectue maintenant normalement.

Il faut donc retenir que si vous n’utilisez pas SCVMM, il est impératif de modifier les caractéristiques ainsi que les connexions réseau de vos VM au travers de l’interface cluster.
Et en cas de bêtises rafraichissez la configuration au sein du module cluster, tout devrait rentrer dans l’ordre !

Il existe aujourd’hui des applications tierces (Double Take par exemple), qui permettent de répliquer des machines virtuelles d’un site central vers un autre hyperviseur sur un site secondaire au travers du LAN/WAN. En cas de désastre du site principale, l’activité peut redémarrer sur le site secondaire au travers du réplica. Ces solution peuvent être chères et difficile à mettre en œuvre.
Avec l’arrivée d’Hyper-V 3.0 et de Windows 8, Microsoft intègre un système de réplication asynchrone natif à l’hyperviseur. Le nombre de réplications sera illimité, et aucun équipement spécifique ne sera nécessaire. Il n’y aura donc pas de surcout pour mettre en œuvre cette fonctionnalité.
Ce dernier point est important. Avec sa version 5.0, VMware a annoncé  un système de réplication des VM avec leur prochaine version du site Recovery Manager (SRM), mais il faudra s’acquitter de 200$ à 500$ par VM répliquées.

Si par soucis d’optimisation vous supprimez le partage de fichiers et d’imprimantes ainsi que le client pour réseau microsoft sur vos interfaces ISCSI vous serez dans l’impossibilité de faire des migrations dynamiques sous Hyper-V.

Vous retouverez alors une erreur de type système Event ID:5120.

« Cluster Shared Volume ‘Volume1′ (’Cluster Disk 1′) is no longer  available on this
node because of ‘STATUS_BAD_NETWORK_PATH(c00000be)’.  All I/O will temporarily
be queued until a path to the volume is  reestablished. »

Vérifiez si vous avez le partage d’imprimantes de fichiers et le Client pour les réseaux Microsoft activé sur toutes les interfaces iSCSI.

Microsoft ne mentionne pas la raison de ce prérequis.

Les premières infos circulent déjà…
Une des nouvelles fonctionnalités : pouvoir déplacer le stockage de la machine virtuelle sans SCVMM et surement à chaud.

Microsoft se décide enfin de fournir un composant Iscsi target (disponible initialement dans les NAS propulsés par Microsoft Storage Server).

Cela permet de transformer n’importe quel serveur Windows 2008 R2 en baie de stockage ISCSI low coast et donc de pouvoir présenter un disque partagé CSV a deux serveurs Hyper-V.

Bonne nouvelle pour ceux qui voulaient tester le cluster !

A télécharger ici : http://www.microsoft.com/downloads/en/details.aspx?FamilyID=45105d7f-8c6c-4666-a305-c8189062a0d0