Architecture et déploiement des Cluster Hyper-V / SCVMM 2012 SP1 - Best practices PDF Imprimer Envoyer
Note des utilisateurs: / 16
MauvaisTrès bien 
Écrit par Cédric Bravo   

Téléchargez notre livre blanc "Guide d'architecture Hyper-V / SCVMM 2012"

SCVMM2012 Best Practices

SCVMM 2008 R2, SCVMM 2012 SP1, un changement de paradigme !

 

Avec Windows Server 2008 R2 et SCVMM 2008 R2, l'intégration d'un cluster Hyper-V se déroulait de la manière suivante:

  1. Définition de l'architecture physique
  2. Construction du cluster Hyper-V 2008 R2
  3. Installation et paramétrage du serveur SCVMM 2008 R2
  4. Intégration du cluster Hyper-V dans SCVMM 2008R2.

Avec SCVMM 2012 SP1 et Hyper-V 2012, la logique d'intégration est totalement différente, SCVMM joue désormais un rôle central.

  1. Définition de l'architecture physique et logique
  2. Installation et paramétrage du serveur SCVMM 2012 SP1.
  3. Intégration des serveurs Hôtes dans SCVMM 2012 SP1.
  4. Création et paramétrage du cluster Hyper-V 2012 entièrement depuis SCVMM 2012 SP1

SCVMM joue non seulement un rôle central, mais aussi très "structurant", il est donc impératif de définir un certain nombre d'éléments avant installation afin de ne pas se retrouver dans une situation obligeant à "tous casser" pour tout refaire.

 

Le petit guide ci-dessous vous aidera dans les différentes étapes de la premiere phase d'intégration d'une infrastructure Hyper-V / SCMM.

Note : La virtualisation du réseau n'est pas traitée dans ce guide.

 

Indentification des réseaux

 

Une des toute premières actions à mener pour la définition de votre architecture est d’identifier précisément tous les réseaux nécessaires à l'intégration SCVMM / Hyper-V 2012.

 

Best practice :

Les réseaux suivants sont nécessaires à une installation «Â classique ».

  • Un Réseau dédié "Cluster / CSV" (Trafic HeartBeat Cluster et mode redirigé des CSV).
  • Un Réseau dédié "Live Migration" (Trafic dédié aux transferts des VM entres les hôtes Hyper-V).
  • Un Réseau dédié "Management" (Trafic dédié à l'accès console, le déploiement des Template et la communication avec les outils de management.
  • Un ou des réseaux de production (Trafic dédié aux VM).
  • En option, un réseau dédié ISCSI (Nécessaire pour l'exposition de stockage partagé aux VM dans le cadre de la réalisation de clusters virtuels)

 

Pour les besoin de notre exemple, nous avons identifié les réseaux suivants :

 

Réseau

Subnet

Gateway

VLAN

Réseau de Management

172.16.0.0/24

172.16.0.254

100

Réseau Dédié Cluster / CSV

10.0.0.0/24

Non routé

101

Réseau Dédié Live Migration

10.0.1.0/24

Non routé

102

Réseau VM Production

172.16.1.0/24

172.16.1.254

200

Réseau VM DMZ

172.16.2.0/24

172.16.2.254

201

Réseau ISCSI 1

10.0.2.0/24

Non routé

103

Réseau ISCSI 1

10.0.3.0/24

Non routé

104

Tableau 1 - Définition des réseaux

 

Note : L’utilisation de différents réseaux routés permet un cloisonnement des différentes zones fonctionnelles.

 VMM2012 Zone 

Figure 1 - Définition des zones de sécurités

Best Practice :

Afin de tirer au mieux parti des fonctionnalités d’attribution automatique des adresses IP de SCVMM, identifiez clairement les plages d’adresses utilisables.

 

Les réseaux logiques

 

Les réseaux logiques sont une nouvelle couche d'abstraction apportée par SCVMM permettant la prise en compte des concepts relatifs à la virtualisation des réseaux. La définition de ces réseaux est très structurante dans l’intégration SCVMM et il est nécessaire de les identifier au plus tôt.

 

Pour simplifier, les réseaux logiques sont des groupes de réseaux qui partagent les mêmes propriétés fonctionnelles et regroupés en «Â sites ».

 

Ainsi un réseau logique "ISCSI" pourra regrouper tous les réseaux (VLAN / Subnet) ISCSI du Datacenter.

 

 logicalNetworks

Figure 2 - Relations entre les réseaux logiques et définition des réseaux

 

Les réseaux logiques contiennent des «Â Networks Sites ». Les «Â Network Sites » son eux même des objets SCVMM qui regroupent les définitions de réseaux (Subnet et VLAN) d’un site particulier (Pas nécessairement géographique). Les «Â Network Sites » permettent d’exposer les définitions de réseaux (VLAN / Subnets) à des groupes serveurs Hyper-V (Par le biais des groupes d’hôtes).

 

En résumé :

  • Les réseaux logiques regroupent tous les réseaux partageant la même fonction.
  • Les réseaux logiques contiennent des «Â Network Sites » permettant d’associer les définitions de réseaux avec des groupes de serveurs Hyper-V.

 

Best practice :

Comme point de départ, vous pouvez définir la création d’un réseau logique par réseau disposant d’une fonction particulière. Vous pouvez vous appuyer sur les VLAN identifiés lors de la phase d’inventaire.

 

Dans notre exemple, nous pouvons définir les réseaux logiques suivants à partir des réseaux identifiés plus haut.

 

Réseau Logiques

Network Site

Network définition

Management

Nanterre

172.16.0.0/24 – VLAN 100

Cluster / CSV

Nanterre

10.0.0.0/24 – VLAN 101

Live Migration

Nanterre

10.0.1.0/24 – VLAN 102

VM Production

Nanterre

172.16.1.0/24 – VLAN 200

VM DMZ

Nanterre

172.16.2.0/24 – VLAN 201

ISCSI

Nanterre

10.0.2.0/24 – VLAN 103
10.0.3.0/24 – VLAN 104

Tableau 2 - Réseaux logiques

 

Une fois les réseaux identifiés, il nous faut définir comment ceux-ci seront configurés sur vos serveurs Hyper-V. Pour bien comprendre les choix qui s'offrent à nous, il est nécessaire de s'attarder un peu sur les nouveautés apportées par Windows Server 2012 et Hyper-V au niveau du réseau et notamment les suivantes :

 

  • Le support natif du teaming des cartes réseaux
  • Les Vswitchs extensibles (apportant des options de configuration supplémentaires comme la QoS)

 

Pour plus de détails sur la QoS avec Hyper-V, cliquez ici. QoS.

 

Grâce à ces améliorations, il est désormais possible de consolider les différents réseaux tout en assurant la segmentation et la qualité de service. Ceci nous ouvre de nouvelles possibilités de design et permet de réduire le nombre de cartes réseaux nécessaires.

 

Dans notre architecture, nous allons distinguer :

Les ports virtuels :

  • Attachés à la partition parent.
  • Attachés à des machines virtuelles.

Les ports physiques :

  • Attachés ...au réseau physique.

 

Ces deux éléments (ports physiques et virtuels) sont totalement pris en compte et gérés depuis SCVMM 2012 SP1. Ceux-ci sont cependant nommés et "conceptualisés" d'une manière un peu différente de ce que l'on trouve sur Hyper-V 2012.

 

Si cette conceptualisation permet d'apporter l'abstraction nécessaire à la gestion de la virtualisation réseau par SCVMM 2012 SP1, celle-ci n'a pas manqué d'apporter une certaine confusion chez les administrateurs habitués à SCVMM 2008 R2.

 

Tentons d'y voir un peu plus clair…

 

Comprendre les Switchs logiques avec SCVMM 2012 SP1

 

SCVMM 2012 apporte le concept de Switch logiques (Logical Switchs). Les switchs logiques sont en réalité des "Templates de Switchs virtuels".

 

Ces templates de switchs virtuels permettent de définir la configuration des ports physiques (Appelés Uplink Port Profiles dans SCVMM), des ports virtuels (Native Virtual Adapter Port Profiles) et d'appliquer cette configuration de manière uniforme à différents serveurs Hyper-V.

 

Vous l'aurez compris, les "Uplink Port Profiles" définissent la façon dont sont configurés les Team des cartes réseaux physiques reliées à nos "Vswitch" et les "Native Virtual Adapter Port Profiles" définissent la configuration des cartes réseaux virtuelles attachées à nos Switchs Virtuels (QoS, optimisation hardware etc.)

 

 Switchs logiques

Figure 3 - Représentation des profils de ports

 

Hyper-V 2012 offre de nombreuses options concernant la QoS au niveau des ports virtuels, cependant, seules certaines options sont disponibles depuis SCVMM. C'est à ces dernières que nous allons nous intéresser dans le cadre de notre exemple.

 

Best Practice :

S’il est tout à fait possible d'obtenir un cluster Hyper-V 2012 fonctionnel avec une seule carte réseau, il est nécessaire d'utiliser 2 cartes pour assurer une haute disponibilité.

Dans une optique d'isolation minimale du trafic de management, 4 cartes constituent un best practice, comme exposé dans l’exemple ci-dessous.

 NetworkExample
Figure 4 - Exemple d'architecture physique et logique

 

 

Dans notre cas, nous devons prendre en compte un réseau ISCSI capable d'exposer du stockage aux serveurs Hyper-V (Cluster Shared Volumes) mais aussi de présenter des LUNS directement aux VM (Clusters Accross Box).

 

Définition des profils de ports

 

Le schéma suivant illustre un design optimisé avec 4 cartes de 1 Gigabit conçu afin d'assurer la meilleure qualité possible au réseau ISCSI.

 

NetworkWithISCSI 

Figure 5 - Architecture réseau physique et logique du host

 

Un Vswitch unique est utilisé pour consolider l'ensemble du trafic (trafic client et trafic de management). La qualité de service est assurée par des paramètres de QoS configurés par VMM par le biais des "ports profiles".

 

On remarquera que les cartes réseaux supportant le ISCSI ne sont pas regroupée au sein d'un Team, c'est parce que la haute disponibilité est "native" au protocole ISCSI et assurée par la couche MPIO implémentée au niveau des cartes virtuelles.

 

Définition des profils de ports virtuels (Converged Vswich)

 

Profil de Ports Virtuels

Management OS

QoS Weight

QoS Limit

Management

Oui

10

1gbit

Cluster / CSV

Oui

10

1gbit

Live Migration

Oui

40

1gbit

VM Gold

Non

5

1gbit

VM Silver

Non

 -

1gbit

VM Bronze

Non

 -

100Mbit

Tableau 3- Profils de ports du switch convergé

 

Ici, les différents paramètres de QoS disponibles permettent non seulement d'assurer la qualité des services (pour les réseaux de management) mais aussi de créer différentes classes de services pour nos VM (ici Gold, Silver et Bronze). Les ports administratifs (Management, cluster, Live Migration) étant mutualisés sur le même team que les machines virtuelle, une limitation de la bande passante est positionnée afin d’assurer que ces fonctions ne consomment pas la totalité de la bande passante pour les VM ne disposant pas de QoS (Par exemple les VM Bronze).

 

Définition des profils de ports virtuels (ISCSI Vswich)

 

Profil de Ports Virtuels

Management OS

QoS Weight

QoS Limit

ISCSI_CSV

Oui

40

 -

ISCSI _VM

Non

5

 -

Tableau 4- Profils de ports des switchs ISCSI

  

Best Practice :

Le paramètre QoS Weight permet de définir un poids relatif au port afin d'assurer une priorisation de la bande passante.

Il faut voir le paramètre "Weight" comme un plancher et le paramètre "QoS Limit" comme un plafond.

Dans notre exemple, nous assurons une qualité de service minimale à tous les réseaux de management, critiques pour le bon fonctionnement du cluster.

Dans la mesure du possible, le total des poids (Weight) alloués aux cartes virtuelles d'un même team ne devrait pas dépasser 100.

En respectant ce best practice, on peut alors concevoir ce paramètre comme un pourcentage de la bande passante totale. Ainsi dans notre exemple, le réseau Live migration est assuré de toujours disposer d'un minimum de 40% de la bande passante en cas de contention.


 

Définition des groupes d’hôtes.

Les groupes d’hôtes (host Group) sont des objets logiques de SCVMM permettant de regrouper des serveurs de virtualisation. Dans SCVMM 2012 SP1, le design des groupes d’hôtes deviennent très structurant car ils sont utilisés pour de nombreuses fonctions.

  • Applications des paramètres concernant l’optimisation et les réserves.
  • Délégation d’administration
  • Association avec les cloud (pools de ressources).
  • Allocation des réseaux
  • Allocation du stockage
  • Gestion des librairies et des objets équivalents.

Best Practice :

Commencez par définir un Groupe d’hôte de premier niveau correspondant au site géographique.

Si nécessaire, séparer ensuite les serveurs de virtualisation Microsoft des serveurs de virualisation Vmware ou Citrix.

Si vous disposez de serveurs dédiés à des environnements spécifiques, (Production, intégration etc.) regroupez ces serveurs, puis séparer les clusters des serveurs «Â standalone ».

 HostGroups

Figure 6 - Définition des groupes d'hôtes

 

Conclustion

Avec ces éléments en main, vous pouvez maintenant assurer le paramétrage de votre infrastructure SCVMM.

  1. Création des groupes d'hôtes
  2. Création des réseaux logiques, des sites et des définitions de réseaux
  3. Création des IP Pools
  4. Création de VM Networks
  5. Création des profils de ports physiques et virtuels
  6. Création des switchs logiques.

 

Ces opérations feront l'objet d'un article ultérieur.

 

Une fois ces étapes réalisées vous pourrez intégrer et configurer vos serveurs Hyper-V et constituer des clusters directement depuis SCVMM.

 

Note : Pour le design de l'infrastructure SCVMM en tant que telle (répartition des rôles, sizing etc.), vous pouvez vous appuyer sur le guide d'architecture Microsoft disponible ici.

 

 

Joomla! is Free Software released under the GNU/GPL License.