7 05 2014

Après un petit break, voyons quels sont les réseaux de base à ajouter à votre serveur Hyper-V pour le mettre en cluster avec ses copains.

Dans le précédent article, je vous détaillais étape par étape la configuration du teaming de carte à partir de SCVMM, et plus globalement, la configuration réseau d’un hôte Hyper-V depuis SCVMM.

Le teaming de carte est utile autant d’un point de vue des performances que d’un point de vue de la haute-disponibilité du réseau. Lorsqu’il s’agit de rendre le serveur physique hautement disponible, la solution la plus courante est d’ajouter un ou plusieurs hôtes Hyper-V et de mettre ces serveurs en cluster.

Hors, ceux qui ont travaillé avec VMware et qui par la suite créent un cluster Hyper-V se sont tous au moins 1 fois cassé les dents…souvent à cause de configuration réseau des serveurs Hyper-V.

Voyons en détails ce qu’il est nécessaire d’ajouter pour éviter tout problèmes.

Note: cet article est le septième article de la série Introduction aux réseaux sur Hyper-V et SCVMM 2012

De quoi nécessite un cluster ?

Faisons le point sur les différents flux réseaux que l’on retrouve dans un cluster Hyper-V:

Management:

Il s’agit du réseau permettant de gérer les serveurs Hyper-V par l’administrateur ou par SCVMM. Ce réseau permet entre autre aux serveurs Hyper-V de communiquer entre eux, et de communiquer avec le reste de l’infrastructure: Active Directory, DNS, etc.

Cluster (souvent appelé Hearbeat):

Ce réseau permet la communication inter-noeux Hyper-V. Souvent oublié des administrateurs ayant travaillé précédemment avec VMware, ce réseau est ESSENTIEL au bon fonctionnement du cluster Hyper-V.

Il est utilisé par le cluster Hyper-V pour:

• Le Heartbeat: pour vulgariser, les noeux Hyper-V s’envoient des « ping » réguliers pour savoir si les autres serveurs Hyper-V sont toujours en bonne santé.
• Multi-path: lorsque le réseau de management n’est pas accessible par l’un des noeuds du cluster, les communications inter-cluster passent par le réseau de cluster. 
• CSV: lors de l’utilisation de CSVFS, le réseau Cluster est utilisé dans deux cas:
  • Metadata: lorsqu’un noeud Hyper-V réaliser certaines opérations d’écritures/modifications sur les fichiers, il transmet les metadata au serveur Hyper-V qui est owner de la LUN.
  • Redirected-IO: lorsqu’un serveur Hyper-V ne peux pas accéder au stockage, mais a toujours accès au réseau de cluster, les données sont redirigées vers le serveur qui est owner de la LUN pour écrire les données de manière transparente pour les machines virtuelles.

Note: Pour aller plus loin sur le réseau de cluster, je vous invite à lire les articles suivants: http://blogs.technet.com/b/askcore/archive/2010/02/12/windows-server-2008-failover-clusters-networking-part-1.aspx

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/WSV430

Live-Migration:

Nous en avons déjà discuté dans les articles précédents, ce réseau permet de réaliser un Live-Migration de machines virtuelles entre les serveurs Hyper-V du cluster.

Replica:

C’est nouveau avec Hyper-V et hautement recommandé lorsque vous mettez en place Hyper-V Replica, c’est d’utiliser un réseau dédié à la réplication entre les serveurs Hyper-V des différents datacenters (mais pas obligatoire !).

Machines virtuelles:

Bien entendu, des VMs qui n’ont pas d’accès au réseau ont un intérêt limité…

Stockage:

Le stockage est un peu particulier car deux types d’accès sont aujourd’hui disponibles avec Hyper-V 2012:

• Block access: on parle de block access lorsque les machines virtuelles sont stockées sur un SAN et accédées via les protocoles suivants: FC, FCoE, shared SAS ou iSCSI. En général, si les 3 premiers protocoles nécessite un matériel dédié (HBA), l’iSCSI a l’avantage d’utiliser le réseau classique pour ses communications.
• File access: on parle de file access lorsque les machines virtuelles sont stockées sur un serveur de fichier ou un NAS et accédées via un simple partage réseau SMBv3. Ce mode d’accès, nouveau avec Hyper-V 2012 va certainement devenir un standard très rapidement, comme c’est le cas de NFS avec VMware.

Communication cluster uniquement ou cluster et clients ?

Une fois que vous avez créé les réseaux et créé votre cluster Hyper-V, vous avez la possibilité de configurer l’isolation des trafiques réseau utilisé par le cluster:

• Ne pas autoriser la communication réseau de cluster sur ce réseau
• Autoriser la communication réseau du cluster sur ce réseau
• Autoriser la communication réseau du cluster sur ce réseau et Autoriser des clients à se connecter via ce réseau

Les  recommandations de Microsoft:

Management:  Autoriser la communication réseau du cluster sur ce réseau et Autoriser des clients à se connecter via ce réseau

Cluster: Autoriser la communication réseau du cluster sur ce réseau

Live-Migration: Autoriser la communication réseau du cluster sur ce réseau

Replica: Autoriser la communication réseau du cluster sur ce réseau et Autoriser des clients à se connecter via ce réseau

Machines virtuelles: Autoriser la communication réseau du cluster sur ce réseau et Autoriser des clients à se connecter via ce réseau

Stockage: Ne pas autoriser la communication réseau de cluster sur ce réseau

Figure 1: Configuration du réseau de cluster

Note: pour plus de détails, je vous invite à lire l’article suivant: http://technet.microsoft.com/en-us/library/dn550728.aspx

Configuration de la QoS

Lorsque vous utilisez des réseaux convergés pour faire passer tous ces flux, je vous recommande vivement d’utiliser la QoS pour la gestion du trafique et éviter le blocage de tout trafique en cas de contention.

Comme nous le verrons dans un prochain article, Windows Server 2012 et Hyper-V 2012 permet l’utilisation de QoS permettant l’orchestration des flux sur les cartes réseaux partagées.

Ainsi, il est possible de définir, pour chaque carte virtuelle (chaque réseau logique) d’attribuer un poids, allant de 1 à 100, sur 100.

Si vous faites passer tous vos flux sur un seul teaming de cartes, la somme des poids de chaque réseau logique ne devra pas dépasser 100.

Afin d’avoir un ordre d’idée du poids nécessaire pour chaque réseau logique, voici les conseils de Microsoft:

Figure 2: Recommandations Microsoft pour la QoS

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

 Exemple de configuration

L’exemple suivant reprend les réseaux nécessaires aux serveurs Hyper-V en cluster.

Les réseaux de Replica et de Stockage sont optionnels selon la configuration de vos Hyper-V (utilisation de la fibre optique et HBAs par exemple pour accéder au SAN).

Figure 3: Configuration d’un serveur Hyper-V en cluster

Pour la configuration dans Hyper-V et SCVMM, je vous invite à revenir sur les articles précédents.

Next step

Après cet article, vous devriez avoir les bases pour configurer le réseau sur un serveur Hyper-V en mode Standalone, puis en cluster, qu’ils soient intégrés à SCVMM ou non.

Dans le prochain article, nous parlerons un peu plus en détail des Native Virtual Adapter Port profiles, partie importante de SCVMM lors de la configuration des réseaux, avec notamment la possibilité d’ajouter des sécurités et de la QoS aux réseaux des machines virtuelles.

Partager

Carte virtuelle, Cluster, Hyper-V, ManagementOS, QoS, Standalone, Trunking, Virtual Network, vLan

Automatiser la mise à jour des firmware des HP BladeSystem TechEd 2014: l’Hybrid-cloud en force !