Exporter (0) Imprimer
Développer tout

Déployer une infrastructure System Center Virtual Machine Manager / Hyper-V 2012, Guide D’architecture.

A propos de l’auteur

Dn386801.1AC72BD7ECD7030D9DFEA7547D2C1E8B(fr-fr,TechNet.10).png

Architecte infrastructure pour le compte de Nware, Cédric Bravo totalise plus de 15 années d’expériences dans les technologies de l’information.

MVP virtualisation depuis 2009, Speaker aux techday’s sur les technologies de scripting et de virtualisation, Cédric est aussi co-auteur de « Scripting Windows » (un ouvrage didactique sur l’automatisation en environnement Microsoft aux éditions Eyrolles) et président du groupe francophone des utilisateurs de la virtualisation (http://www.guvirt.org/ ).

Opérant en tant que consultant, Cédric accompagne les grands comptes Français et internationaux dans la construction et le développement des infrastructures orientées services.

Septembre, 2013


Contexte

System Center Virtual Machine Manager 2012 est le composant de la gamme System Center qui va vous permettre de créer et de gérer les pools de ressources nécessaires à l’exécution de vos services au sein de votre Cloud privé.

Ce document s’adresse aux administrateurs et architectes ayant déjà une bonne connaissance de la virtualisation Microsoft et de SCVMM.

Le but de ce guide est de vous aider dans les phases d’architecture d’une infrastructure Hyper-V SCVMM 2012 au travers d’un scénario didactique.


  • Ce document ne traite pas les aspects relatifs à la virtualisation du réseau avec Hyper-V et SCVMM.
  • Ce document ne s’intéresse pas non plus aux aspects « infrastructure » d’une intégration SCVMM, c’est-à-dire aux aspects relatifs à l’architecture des différents tiers SCVMM (Sizing, Haute disponibilité, répartition des rôles etc.). Pour ces points, reportez-vous au « Solution Accelerator » disponible ici

SCVMM 2008, SCVMM 2012, un changement de paradigme.

SCVMM 2012 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 vous obligeant à "tous casser" pour tout refaire.


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

Définir l’architecture

Inventaire

 

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.

 

Dn386801.note(fr-fr,TechNet.10).gifBest 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

0

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 2

10.0.3.0/24

Non routé

104

Tableau 2 - Définition des réseaux

 

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

Dn386801.D3F7A271EC9631D6E19CEA381A00E558(fr-fr,TechNet.10).png

Figure 1 - Définition des zones de sécurités
Dn386801.note(fr-fr,TechNet.10).gifBest 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.
Si vous utilisez des réseaux tagués (802.1.Q), veillez à configurer correctement les interfaces de vos switch physiques (Trunk).

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 partageant les mêmes propriétés fonctionnelles et regroupés en « sites ».


Ainsi un réseau logique Management pourra regrouper tous les réseaux (VLAN / Subnet) de management du Datacenter.

Dn386801.048943DD7DB4DDD1077E76A2FF71D577(fr-fr,TechNet.10).png

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.

Dn386801.note(fr-fr,TechNet.10).gifBest 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 0

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 3 - 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. Pour plus de détails sur le teaming, reportez-vous au document suivant disponible ici.

 

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.)

 

Dn386801.17F2923521C3E656E4195C0806F73D54(fr-fr,TechNet.10).png

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.

 



Dn386801.note(fr-fr,TechNet.10).gifBest 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 tu trafic de management, 4 cartes constituent un best practice, comme exposé dans l’exemple ci-dessous.


Dn386801.3B8671705E9008989C68D55442375BF1(fr-fr,TechNet.10).png

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.

Dn386801.A0F944B123B796310EF200A21D900100(fr-fr,TechNet.10).png

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 depuis 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 est 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

Host Management

Oui

10

1gbit

Host Cluster / CSV

Oui

10

1gbit

Host Live Migration

Oui

40

1gbit

VM Gold

Non

5

1gbit

VM Silver

Non

 -

1gbit

VM Bronze

Non

 -

100Mbit

Tableau 4- 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 5- Profils de ports des switchs ISCSI

  

Dn386801.note(fr-fr,TechNet.10).gifBest Practice:

Définissez avec une grande attention vos profils de ports. La bonne configuration de ceux-ci est particulièrement critique avec l’utilisation d’un réseau convergé.
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 chacun 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.

Dn386801.note(fr-fr,TechNet.10).gifBest 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 ».

Dn386801.2E1046FD979C313346EA2AA258164AD4(fr-fr,TechNet.10).png

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

Paramétrage initial de SCVMM 2012

Après une phase d’architecture dédiée(*), vous disposer maintenant d’un serveur SCVMM prêt à l’emploi. Avant même d’ajouter des serveurs de virtualisation vous devez néanmoins réaliser le paramétrage en conformité avec les éléments définis pendant la phase d’architecture.

Dn386801.note(fr-fr,TechNet.10).gifNote (*):

Ce guide ne décrit pas les étapes nécessaires à l’intégration d’une infrastructure SCVMM (Sizing, haute disponibilité, répartition des rôles etc.)

 

Ce chapitre se concentre sur les étapes nécessaires à la mise en œuvre des choix d’architecture décrit dans les chapitres précédents.

Création des groupes d’hôtes

Les Groupes d’hôtes (Host Group) de SCVMM 2012 jouent un rôle beaucoup plus structurant que dans les précédentes versions. En effet, ceux-ci seront utilisés pour « mapper » les objets sites, il est donc nécessaire de disposer de ces objets dès qui possible pour poursuivre la configuration.


Dn386801.35ADE2EB6FEFAFB1B5DDAD2A42282E1E(fr-fr,TechNet.10).png

Figure 7 - Création des Host Groups

Vous pouvez aussi créer vos groupes d’hôte par le biais de commande powershell.


New-VMHostGroup [NOM_HOSTGROUP] –ParentHostGroup [NOM_HOSTGROUP_PARENT]

Création des réseaux logiques

Les réseaux logiques définit pendant la phase d’architecture sont les seconds objets à déclarer dans SCVMM 2012.


Dn386801.note(fr-fr,TechNet.10).gifBest Practice:

Utilisez des préfixes normalisés pour nommer vos objets (ex : LGNET pour Logical Nework). Ceci permet d’identifier plus clairement les objets et facilite la réalisation de scripts d’automatisation.


Dn386801.464D96343D96F659E521CFEEC3E950D8(fr-fr,TechNet.10).png

Figure 8 - Création des réseaux logiques
Dn386801.note(fr-fr,TechNet.10).gifBest Practice:

Après son installation, SCVMM est configuré par défaut pour créer automatiquement les réseaux logiques (Logical Networks, VM Networks) de serveurs ou de clusters Hyper-V déjà configurés. Afin de garder un contrôle total sur la nomenclature et l’organisation de ces objets, il est recommandé de désactiver cette fonction et de créer les objets manuellement.


Dn386801.B6D6F47D77FB548629FC4C6899E4C4C3(fr-fr,TechNet.10).png

Figure 9 - Désactivation de la création automatique des réseaux logiques

Création des sites et des « Network definition »

Comme décrit dans la Figure 2 (Relations entre les réseaux logiques et définition des réseaux1

(C’est la raison pour laquelle il est conseillé de créer un « Host group » par site).


Chaque « Network Site » contient ensuite une ou plusieurs définitions de réseau « Network Definition » correspondant aux Subnet et VLAN utilisés. Dans notre exemple ci-dessous, le Logical Network ISCSI contient un site unique « Nanterre » et deux vlan (103 et 104).


Dn386801.4999CFADCC06B7D97B4C9BE49E4DA858(fr-fr,TechNet.10).png

Figure 10 - Création des "Network definition"

Dn386801.note(fr-fr,TechNet.10).gifBest Practice:

Appliquer une convention de nommage claire à vos objets « Network Site » afin de faciliter leur repérage et l’automatisation Powershell. (Ex : NSITE_[FONCTION]_[SITE]



Création des IP Pool associés

Une fois les réseaux logiques créés, vous pouvez créer des Pool d’adresses IP associés pour chaque réseau déclarés. Les pools d’adresses IP fonctionnent comme des étendues DHCP. Grâce aux IP Pools, SCVMM est capable de configurer automatiquement les IP des interfaces virtuelles associées.

Note : Les adresses IP attribuées par SCVMM aux interfaces virtuelles sont configurées en tant que IP fixes.


Dn386801.F603AED82996BB57788AB53491CFB3C8(fr-fr,TechNet.10).png

Figure 11 - Création des IP Pools

Dn386801.note(fr-fr,TechNet.10).gifBest Practice:

Appliquer une convention de nommage claire à vos objets « IP POOL » afin de faciliter leur repérage et l’automatisation Powershell. (Ex : IP_POOL_[FONCTION]).


Les IP Pools permettent de configurer les paramètres suivants :

  • IP Range
    • Exclusions d’IP réservées aux VIP (Load Balancer)
  • Gateway
  • Dns
  • Wins

Une fois terminée, nous disposons d’environ un réseau IP par réseau logique (à l’exception du réseau logique « SCSCI » qui utilise deux subnets).


Dn386801.84CECF06FC829316E7D7E0A9C42B6FDF(fr-fr,TechNet.10).png

Figure 12 - Exemple de réseaux logiques et IP Pool

Création des VM Networks

Les « VM Networks » sont une nouvelle abstraction de la couche réseau apportée par SCVMM 2012 SP1. Les VM Network permettent de configurer des réseaux « virtuels » sur lesquels viendrons se connecter les ports des machines virtuelles et les ports de management. Dans l’optique on nous n’utilisons pas la virtualisation du réseau dans notre scénario, il existe une relation de 1 pour 1 entre les « VM Networks » et les « Logical Networks ».


Dn386801.D7DBFC3F5904EA0BEDB0B624B4F8238E(fr-fr,TechNet.10).png

Figure 13 - Création des VM Networks


Création des profils de ports

Comme expliqué dans le chapitre « Comprendre les Switches Logiques avec SCVMM 2012 SP11

Comme décrit dans le chapitre « Définition des profils de ports1


Profils de ports physiques

  • Uplink port profile des membres du team « switch convergé »
  • Uplink port profile des switch ISCSI

Profils de port virtuels « management »

  • Management
  • Live Migration
  • Cluster / CSV
  • ISCSI_HOST

Profils de ports viruels « VM »

  • VM Gold
  • VM Silver
  • VMBronze
  • ISCSI_VM


Note : SCVMM propose par défaut un certain nombre de profils de ports préconfigurés (ISCSI, Management, Cluster etc.)


Depuis la console SCVMM, dans le contexte « Fabric », créer un nouveau profil de port et sélectionner «  Uplink Port Profile ».


Dn386801.1E68240BD1FA78A1719A394DE11397C4(fr-fr,TechNet.10).png

Figure 14 - Création des Uplink port profiles

Note : Dans notre exemple, les ports physiques utilisés pour les connections ISCSI ne sont pas configurées en Team, les paramètres relatifs au teaming sont donc inutiles.


Il faut ensuite associer le profil de port avec un « Network Site ». Lors de la configuration des interfaces liée à ce profil de port physique, nous aurons alors accès aux réseaux et pools d’IP associé au site. Les ports utilisés pour le ISCSI n’ont besoin d’accéder qu’aux réseaux « ISCSI ».


Dn386801.AAF86B936B78807DFD46CE8FC5B47B58(fr-fr,TechNet.10).png

Figure 15 - Uplink Port profile pour le réseau ISCSI

A l’inverse, le profil de port physique pour notre réseau convergé (partageant les flux administratif et VM) doit être mappé avec les réseaux de site Cluster, Management, Live Migration, PROD et DMZ

Dn386801.760E6067AF0A6C031A5F85173CBB656C(fr-fr,TechNet.10).png

Figure 16 – Uplink port profile pour le réseau convergé

Une fois les profils de ports physiques créés, il faut créer les profils de ports virtuels. Nous avons défini les caractéristiques de ces ports dans la phase d’architecture dans le Tableau 1- "Profils de ports du switch convergé".

De nombreux profils sont déjà présents dans SCVMM, vous pouvez le modifier pour vos besoins ou en recréer pour vous conformer à vos spécifications.

Les ports virtuels disposent de plus de paramètres que les ports physiques, notamment concernant l’activation de fonction d’accélération matérielle.

Note : Pour fonctionner, ces fonctions doivent être supportées par vos cartes réseaux physiques.


Dn386801.A1EFB17C583FA459D6F6D8D2312A61CA(fr-fr,TechNet.10).png

Figure 17 - Fonctions d'accélération matérielles

Les nouveaux Switches extensibles disponibles avec Hyper-V 2012 autorisent la configuration d’option de sécurité au niveau de chaque port. Ces options sont surtout nécessaires pour les ports réseaux destinés aux machines virtuelles. L’activation ou non de ces fonctions doit être évaluée pendant la phase d’architecture.


Dn386801.F5ACD009CA46834625CC882914103280(fr-fr,TechNet.10).png

Figure 18 - Configuration des paramètres d'accélération matérielle

Les Switches extensibles permettent aussi la configuration d’option de qualité de service. Il est ainsi possible d’indiquer un planché minimal disponible exprimé en Mbps ou en poids relatif.

Configurer les valeurs définies pendant la phase d’architecture et consignées dans les tableaux  « 31 » et  « 41 switches ISCSI » (Attention à ne pas confondre Mbps et Mo/s).

Note : définir une bande passante minimale pour un port ne signifie pas qu’une portion de la bande passante lui est « réservée », mais plutôt que le port est prioritaire à hauteur de la valeur configurée en cas de besoin.


Dn386801.BE6B9C041B64936F78094E0A89702127(fr-fr,TechNet.10).png

Figure 19 - Configuration des paramètres de QoS

Dn386801.note(fr-fr,TechNet.10).gifBest Practice:

Utilisez les paramètres de QoS pour créer différentes classes de port réseau correspondant à plusieurs niveaux de services. Dans le cas de réseaux convergés impliquant une cohabitation des flux techniques (Management, cluster, CSV etc.) et des flux client (VM) assurez-vous que les flux techniques sont prioritaires.

Utilisez de préférence la limitation de bande passante (Maximum Bandwidth) pour les ports de VM. Ce paramètre permet d’apporter une sécurité supplémentaire en s’assurant qu’une machine virtuelle ne vient pas s’accaparer toute la bande passante disponible.



Les  « Virtual port profiles » doivent être associés avec des « Port Classification ». En effet, les « Port Profiles » ne sont pas exposés directement aux utilisateurs, seul les « Port Classification » sont visibles.


Ces « Classes de ports » sont tout simplement des étiquettes apportant une abstraction entre le profil de port et l’utilisateur. Cette abstraction peut être utilisée par des extensions de Vswitch spécifiques (Ex : Cisco Nexus 1000v).



Dn386801.AE9594FC604BE025F677FE07EC38DA8F(fr-fr,TechNet.10).png

Figure 20 - Relation entre le port profiles et les classes de ports

Dn386801.note(fr-fr,TechNet.10).gifBest Practice:

Utilisez une convention de nommage claire pour identifier vos différentes classes de ports.
Ex : Utilisez le préfixe « HOST_ » pour les classes associées avec des profils de ports de management et le préfixe « VM_ » pour les classes associées avec des profils de ports VM.

Création des switches logiques

Les switch logiques viennent assembler les profils de ports définis à l’étape précédente.

Ce sont ces définitions de switches qui seront ensuite déployés sur les serveurs Hyper-V 2012.

Conformément à notre architecture, nous allons créer 3 switches logiques.


  • ISCSI_1
  • ISCSI_2
  • Convergé

Dn386801.DE2BB329C4E79C3154DE0AB6DC5333E6(fr-fr,TechNet.10).png

Figure 21 - Création des switch logiques

Note : L’activation des options d’accélération SR-IOV (si votre carte le supporte) permet d’obtenir des performances quasi identiques à l’utilisation de ports réseaux physiques. Cependant, en créant un accès direct des ports virtuels au matériel, cette fonction contourne les switch Hyper-V, rendant notamment les options de QoS configurées inopérantes.



Le nouveau modèle de VSwitches extensible de Hyper-V 2012 permet d’ajouter de nouvelles fonctionnalités. Deux extension sont disponibles par défaut, le « Filterring » permettant de configurer des ACL aux niveaux des ports et le « monitoring » permettant de configurer des compteurs aux niveaux des ports.

De nouvelles extension peuvent être déclarées dans SCVMM afin d’être déployées.


Dn386801.4E0B225280C76FCE86FCAE098127D147(fr-fr,TechNet.10).png

Figure 22 - Activation des extentions de vswitch

Une fois les extensions choisies, il faut définir quel type de port physiques seront utilisé par notre « Logical Switch »

C’est à ce niveau que vous pouvez décider si les « Uplink Port Profiles » sont configuré en team ou non. Dans notre exemple, décrit dans la Figure 1 - "Architecture réseau physique et logique du host", les ports ISCSI n’utilisent pas de team, la haute disponibilité étant assurée par la couche MPIO.


Dn386801.ACF4F3C7012D1269DDA5892F4A23A28A(fr-fr,TechNet.10).png

Figure 23 - Configuration des Uplink Port Profile

Une fois les ports physiques associés avec le « Virtual Switch », passons ensuite au « Ports virtuels ». Comme expliqué sur la figure Figure 1 - "Relation entre le port profiles et les classes de ports", les Vswitchs sont associés avec des « classes de ports ». Les classes de ports sont-elles même associées avec les « virtual ports profiles ». Dans notre exemple, pour la connexion ISCSI le seul type de profil nécessaire est ISCSI.


Dn386801.83E43C871F84C087DA118A6AD28ACB94(fr-fr,TechNet.10).png

Figure 24 - Association classes de ports et des Vswitch

Le second type de Logical Switch nécessaire est celui utilisé pour le réseau convergé.


Dn386801.2DB6026172800CDCDFE68CA691ECB315(fr-fr,TechNet.10).png

Figure 25 - Association classes de ports management et des Vswitchs


Le profil de port associé est le « UPLINK_CONVERGED » créé précédemment. Celui-ci est cette fois ci configuré en team.

Dn386801.ABCEE5E320C4595EAE9EB4A5964C3A48(fr-fr,TechNet.10).png

Figure 26 - Logical Switch convergé, configuration des ports physiques

Les ports virtuels associés sont ceux créés précédemment (Ports de management et ports VM).

Dn386801.8883218851C9EF675F65FC6BF7AE6743(fr-fr,TechNet.10).png

Figure 27 - Association des profils de ports vituels avec les Logical Switches

Une fois la configuration terminée, nous obtenons 3 Switch logiques tel que représenté ci-dessous.

Dn386801.06137FB4A310024E3023A07684C3D7DA(fr-fr,TechNet.10).png

Déploiement des clusters Hyper-V 2012 avec SCVMM 2012

Comme expliqué dans notre introduction, SCVMM joue désormais un rôle central dans le déploiement de l’infrastructure de virtualisation Hyper-V 2012. L’ensemble des opérations relatives à la configuration d’un cluster Hyper-V 2012 sont désormais effectuées depuis SCVMM. Pour cette raison, le paramétrage de SCVMM est un prérequis au déploiement de serveurs et clusters Hyper-V.

Ajout des serveurs Hyper-V 2012 dans VMM

En s’appuyant sur WDS et WAIK (Windows Automation and Installation Kit) SCVMM 2012 est capable de déployer des serveurs physiques pour y installer Windows et Hyper-V automatiquement. Ce guide ne décrit pas ces fonctions avancées.


Dn386801.note(fr-fr,TechNet.10).gifBest Practices:

Si la configuration du déploiement de serveurs physique est une fonctionnalité intéressante, vous devez évaluer le coût de sa mise en œuvre versus le nombre de serveurs Hyper-V que vous allez déployer par an.
En effet, si la mise en œuvre peut s’avérer plus ou moins complexe, elle nécessite la maintenance d’un master et d’une infrastructure de déploiement spécifique. Cette fonctionnalité s’adresse principalement aux grands Datacenter composés de serveurs en lame très standardisés et subissant de nombreuses opérations d’installation et de recyclage de serveurs physiques.


Les prérequis pour l’ajout d’un serveur sont les suivants :

  • OS installé et patché en version « full » ou « core »
  • MPIO installé (ISCSI initiator activé si nécessaire)
  • Interface de management configurée avec son IP définitive et joignable depuis SCVMM
  • Toutes les cartes réseaux connectées et correctement brassées.

Note : Selon le matériel utilisé, vous devrez avoir installé différents pilotes et outils (ex : Pilotes cartes FC, Initiateur ISCSI, DSM Constructeurs, MPIO Propriétaire etc.).


Il n’est pas nécessaire de :

  • D’avoir le rôle Hyper-V d’installé.
  • D’avoir configuré les teams
  • D’avoir installé un cluster.

Ces opérations seront effectuées directement depuis SCVMM.


Pour ajouter les serveurs, utiliser simplement l’assistant VMM. Les serveurs membre d’un cluster doivent obligatoirement faire partis du même domaine Active Directory.

Dn386801.A0001F050102C70B578A677A87A3C22A(fr-fr,TechNet.10).png

Figure 28 - Ajout de serveurs Hyper-V

Rappel : Il n’est pas nécessaire d’avoir configuré le rôle Hyper-V sur les serveurs, celui-ci sera automatiquement installé par SCVMM lors de l’intégration des Hosts. Celui-ci n’installe pas cependant la MMC « Hyper-V Manager ».

Dn386801.5CEF1515064E13031AC8773B81687CEC(fr-fr,TechNet.10).png

Figure 29 - Installation de Hyper-V par SCVMM


Déploiement des Switch logiques

Avant de pouvoir mettre nos serveurs en cluster, il est nécessaire d’y déployer les Switches logique précédemment créé. La configuration réseau de chaque serveur membres du cluster doit être strictement identique.

Le déploiement des switches logiques est effectué depuis les propriétés du serveur Hyper-V dans l’onglet « Virtual Switches ».

Les profils de ports physiques configurés précédemment (Uplink Port Profile) sont alors associés aux cartes physiques (afin de configurer le teaming le cas échéant).


Dn386801.023CE34ACBE6E3FB6782563FA07549EE(fr-fr,TechNet.10).png

Figure 30 - Configuration des switchs logiques

L’identification des cartes est particulièrement sensible lors de cette étape, en effet, les cartes sont identifiées dans VMM non pas par leur nom, mais par leur « Device Name ». Assurez-vous d’avoir correctement réalisé le brassage des cartes avant d’effectuer cette opération.


Note : Dans le cadre de réseaux convergés, ou plusieurs VLAN sont concentrés sur plusieurs ports, vous devez avoir convenablement configuré vos « Trunk » sur les ports concernés des équipements réseaux.


Dn386801.note(fr-fr,TechNet.10).gifNote:
Best practices :
Lors de la création de vos Switches logiques, ajoutez les cartes physiques une par une, puis configurer les interfaces virtuelles dans un second temps (sauf carte de management si nécessaire). Ceci pour éviter d’éventuels problèmes de perte de connexion pendant l’opération de configuration.

Afin d’assurer la haute disponibilité dans le cas de cartes réseaux multiports, veillez à utiliser au sein d’un même team des ports réseaux situé sur différentes cartes physiques.

*** Attention ***
Si la carte de management du serveur Hyper-V est reliée au switch logique, il faut impérativement mapper un port virtuel héritant de la configuration IP de la carte physique, vous risquez sinon de perdre la connexion à votre serveur. La carte de management du serveur Hyper-V doit être capable de communiquer avec VMM (Même Subnet, même VLAN).

Dn386801.32145FC38C41BA01077657A0A7D67FE9(fr-fr,TechNet.10).png


Veillez à assigner les bons paramètres à l’interface de management (ici le VM Network de Management et la classe de port « Host Management ».

Utilisez une convention de nommage claire pour nommer les interfaces virtuelles, ceci afin de faciliter l’administration et l’automatisation.


Une fois les ports physiques configurés et l’interface de management (VNIC_MGMT) configurée pour hériter des paramètres réseaux de la carte physique, vous pouvez passer à la configuration des autres cartes liée à notre partition parent. Pour chaque carte de (Live migration, Cluster…) indiquer le VMNetwork, le VLAN (si nécessaire), le profil de port, ainsi que le Pool d’ip à utiliser.

En sélectionnant un Pool d’IP pour la configuration de la carte, celle-ci sera automatiquement configurée avec les paramètres définit dans l’objet « IP_POOL » de SCVMM. Il n’y a donc pas besoin de se connecter au serveur Hyper-V pour y paramétrer les cartes réseau.


Dn386801.86E8262871D586D7B703E7137DA8FD96(fr-fr,TechNet.10).png

Figure 31 - Configuration cartes de management


Dn386801.B5AA5D3AB558FBB576723EA0B2436BA4(fr-fr,TechNet.10).png

Figure 32 – Configuration réseau des hosts

Une fois déployée depuis SCVMM, notre configuration se représente de la manière suivante sur nos serveurs Hyper-V.

Dn386801.6A8A2DB9D13790A1DC8424498A529946(fr-fr,TechNet.10).png

Figure 33 - Résultat de la configuration des ports réseaux sur le serveur

Dn386801.note(fr-fr,TechNet.10).gifBest Practice:

Dans le cas où vous avez de nombreux serveurs à configurer et afin d’éviter les erreurs de saisie, aidez-vous de SCVMM pour créer un script de configuration automatique. De cette manière, il devient facile d’ajouter ou retirer des nœuds d’un cluster ou d’associer un orchestrateur pour faire évoluer la capacité d’hébergement de manière dynamique. L’utilisation d’une convention de nommage claire des objets SCVMM prend alors tout son sens.


Création du cluster

La création du cluster Hyper-V s’effectue directement depuis SCVMM. Une fois les équipements correctement configurés, il est très facile de déléguer l’extension de cluster en ajoutant des nœuds à un cluster existant.

L’ensemble des nœuds doivent partager une configuration réseau identique, veillez donc à ce que les switches logiques aient été correctement configurés sur chaque nœuds.


Considération relative à l’intégration du stockage

Si un stockage partagé est nécessaire au déploiement de VM hautement disponibles, sa présence n’est pas obligatoire lors de la création du cluster.

SCVMM permet désormais de piloter votre stockage évitant ainsi l’utilisation d’une console spécifique pour créer et publier le stockage consommé par vos machines virtuelles.


Les différentes étapes de l’intégration du stockage sont les suivantes :

  1. Découverte de vos pools de stockage
  2. Création des classes de stockages en fonction des différents pools de disques
  3. Création des LUNs
  4. Allocation des LUNs ou des classes de stockage à des clusters ou à des pools de ressource (cloud).

Vous trouverez ici une liste des constructeurs supportant l’intégration avec SCVMM.


Pour créer un cluster, il suffit d’utiliser l’assistant VMM et de sélectionner des serveurs Hyper-V configurés de manière identique.


Dn386801.A63DCC8264079D4B597EA8ACE0BBC847(fr-fr,TechNet.10).png


Note : Lors de la création initiale d’un cluster, vous pouvez ignorer la phase de validation afin d’accélérer l’opération. La validation peut être effectuée à n’importe quel moment sur un cluster. Le succès de la validation est un prérequis impératif au support d’un cluster en production.


Dn386801.note(fr-fr,TechNet.10).gifBest Practice:

Chaque modification de la configuration du cluster doit être accompagnée d’une nouvelle validation.


Une fois le cluster constitué, il est possible d’y ajouter un nouveau nœud à n’importe quel moment (dans la limite de 64).

Dn386801.0B685119AFC73DF04E6F38A68BE70596(fr-fr,TechNet.10).png

Figure 34 - Ajout de nœuds à un cluster existant

Dn386801.note(fr-fr,TechNet.10).gifBest Practice:

Lors de la configuration initiale d’un cluster, les disques locaux conservent le statut de « disponible pour le placement ». Pour éviter de se retrouver avec des machines virtuelles déployées sur ces disques il est conseillé de retirer les disques locaux des nœuds du cluster comme disponibles pour l’hébergement des machines virtuelles.

Dn386801.6FC809650B30E2F31BC609A7AB856D86(fr-fr,TechNet.10).png

Dn386801.note(fr-fr,TechNet.10).gifNote:

Un script fournis en annexe vous permettra d’automatiser cette opération (Attention cependant, il faudra la répéter à chaque ajout de nœud dans le cluster).




Annexe

Script de retrait des disques locaux d’un cluster pour le placement


################################################################################
#
#  Dé mappage des disques locaux d'un cluster.
#  Guvirt.org - 28.06.2013
#  Auteur : Cedric.bravo@gmail.com
#
################################################################################

Param ([STRING]$ClusterName)
Function USAGE {
    if (($ClusterName -eq ""))
       {
       Write-Host "###############################################################" -ForegroundColor yellow
       Write-Host "Démappage des disques locaux d'un cluster V1.0                 " -ForegroundColor yellow
       Write-host "                                                               " -ForegroundColor yellow
       Write-host "www.guvirt.org                                                 " -ForegroundColor yellow
       Write-host "cedric.bravo@gmail.com                                         " -ForegroundColor yellow
       Write-Host "###############################################################" -ForegroundColor yellow
       Write-host
       Write-Host "Syntaxe: Set-ClusterLocalVolumes -ClusterName <NOM_CLUSTER>    " -ForegroundColor yellow
       Write-Host
       Write-Host "<NOM_CLUSTER>      : Nom du cluster                   " -ForegroundColor yellow
       Write-Host
       Write-Host "<--------EXEMPLE---------->" -ForegroundColor yellow
       Write-Host
       Write-Host "Set-ClusterLocalVolumes -ClusterName 2012_HV_CLUS "-ForegroundColor yellow
       Write-Host
       Write-Host "Démappe tous les disques locaux des noeuds du cluster comme disponibles pour le placement." -ForegroundColor yellow
       Exit
}
}

USAGE
(Get-VMHostCluster $ClusterName).nodes|%{$_.diskvolumes}|?{$_.Classification.name -eq "Local Storage"}|Set-SCStorageVolume -AvailableForPlacement $false




Par Cédric Bravo – Microsoft (MVP)




Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft