White Paper Hyper-V / SCVMM 2012 SP1 · virtualisation et des technologie Cloud White Paper Hyper-V / SCVMM 2012 SP1 Document Guvirt – ... Avec Windows Server 2008 R2 et SCVMM 2008

Groupe Francophone des utilisateurs de la

virtualisation et des technologie Cloud

White Paper Hyper-V / SCVMM 2012 SP1

Document Guvirt – Reproduction interdite sans accord

Guvirt

[email protected]

http://www.guvirt.org

Guvirt

White Paper Hyper-V / SCVMM 2012 SP1

System Center Virtual Machine Manager 2012 - Hyper-V 2012 Clustering Best practices Page 1/42

Sommaire

1 Introduction ............................................................................................................... 4

1.1 A propos de l’auteur .............................................................................................................................. 4

1.2 Contexte ................................................................................................................................................ 4

1.3 SCVMM 2008, SCVMM 2012, un changement de paradigme. .............................................................. 4

2 Définir l’architecture................................................................................................... 5

2.1 Inventaire des réseaux .......................................................................................................................... 5

2.1 Les réseaux logiques .............................................................................................................................. 6

2.2 Comprendre les Switchs Logiques avec SCVMM 2012 SP1 ................................................................... 8

2.3 Définition des profils de ports ............................................................................................................. 10

2.4 Définition des groupes d’hôtes. .......................................................................................................... 12

3 Paramétrage initial de SCVMM 2012 ......................................................................... 13

3.1 Création des groupes d’hôtes .............................................................................................................. 13

3.2 Création des réseaux logiques ............................................................................................................. 14

3.2.1 Création des sites et des « Network definition » ................................................................................ 15

3.2.2 Création des IP Pool associés............................................................................................................... 16

3.3 Création des VM Networks .................................................................................................................. 17

3.4 Création des profils de ports ............................................................................................................... 18

3.5 Création des switches logiques ........................................................................................................... 23

4 Déploiement des clusters Hyper-V 2012 avec SCVMM 2012 SP1 ................................ 27

4.1 Ajout des serveurs Hyper-V 2012 dans VMM ...................................................................................... 27

4.2 Déploiement des Switch logiques........................................................................................................ 29

4.3 Création du cluster .............................................................................................................................. 32

4.4 Ajout du stockage ................................................................................................................................ 34

5 Création des pools de ressources (Cloud) .................................................................. 36

5.1 Comprendre la notion de Cloud dans SCVMM .................................................................................... 36

5.2 Création d’un Cloud dans SCVMM ...................................................................................................... 36

5.3 Délégation d’administration ................................................................................................................ 39

6 Annexe ..................................................................................................................... 42

6.1 Script de désactivation des disques locaux d’un cluster pour le placement ....................................... 42


Table des illustrations

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

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

Figure 3 - Représentation des profils de ports ........................................................................................................ 8

Figure 4 - Exemple d'architecture physique et logique ........................................................................................... 9

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

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

Figure 7 - Création des Host Groups ..................................................................................................................... 13

Figure 8 - Création des réseaux logiques .............................................................................................................. 14

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

Figure 10 - Création des "Network definition" ...................................................................................................... 15

Figure 11 - Création des IP Pools........................................................................................................................... 16

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

Figure 13 - Création des VM Networks ................................................................................................................. 17

Figure 14 - Création des Uplink port profiles ........................................................................................................ 18

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

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

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

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

Figure 19 - Configuration des paramètres de QoS ................................................................................................ 21

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

Figure 21 - Création des switch logiques .............................................................................................................. 23

Figure 22 - Activation des extentions de vswitch .................................................................................................. 24

Figure 23 - Configuration des Uplink Port Profile ................................................................................................. 24

Figure 24 - Association classes de ports et des Vswitch ....................................................................................... 25

Figure 25 - Association classes de ports management et des Vswitchs ................................................................ 25

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

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

Figure 28 - Ajout de serveurs Hyper-V .................................................................................................................. 28

Figure 29 - Installation de Hyper-V par SCVMM ................................................................................................... 28

Figure 30 - Configuration des switchs logiques ..................................................................................................... 29

Figure 31 - Configuration cartes de management ................................................................................................ 30

Figure 32 – Configuration réseau des hosts .......................................................................................................... 31

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

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

Figure 35 - Création d'un cloud ............................................................................................................................. 36

Figure 36 - Association des groupes d'hôtes à un cloud ....................................................................................... 36

Figure 37 - Association de réseaux logiques à un Cloud ....................................................................................... 37

Figure 38 - Association des classes de ports avec un Cloud .................................................................................. 37

Figure 39 - Définition des ressources allouée à un Cloud ..................................................................................... 38

Figure 40 - Création d'un rôle Tenant Administrator ............................................................................................ 39

Figure 41 - Profil du rôle........................................................................................................................................ 39

Figure 42 - Définition du scope d'un administrateur de Cloud ............................................................................. 39

Figure 43 - Association des VM Network et d'un rôle. .......................................................................................... 40

Figure 44 - Définition des actions.......................................................................................................................... 40

Figure 45 - Vue d'un administrateur de Cloud ...................................................................................................... 41


Figure 46 - Création d'une VM par un utilisateur ................................................................................................. 41


1 INTRODUCTION

1.1 A propos de l’auteur

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.

1.2 Contexte

Ce document décrit la phase d’architecture d’une solution de virtualisation Microsoft afin de fournir un chemin d’intégration au travers d’un scénario didactique.

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

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

1.3 SCVMM 2008, SCVMM 2012, un changement de paradigme.

Avec Windows Server 2008 R2 et SCVMM 2008 R2, l'intégration d'un cluster Hyper-V se déroule 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 vous obligeant à "tous casser" pour tout refaire. Le petit guide ci-dessous vous aidera dans les différentes étapes du design de votre infrastructure Hyper-V / SCVMM.

http://www.nware.fr/

http://mvp.microsoft.com/en-us/MVP/Cedric%20Bravo-4024467

http://www.guvirt.org/

http://go.microsoft.com/fwlink/?LinkId=245473


2 DEFINIR L’ARCHITECTURE

2.1 Inventaire 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 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 1 - Définition des réseaux

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

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. Si vous utilisez des réseaux tagués (802.1.Q), veillez à configurer correctement les interfaces de vos switch physiques (Trunk).


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

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

http://technet.microsoft.com/fr-fr/library/hh831679.aspx

http://www.microsoft.com/en-us/download/details.aspx?id=30160


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

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 tu trafic de management, 4 cartes constituent un best practice, comme exposé dans l’exemple ci-dessous.

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


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

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


2.4 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 ».

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


3 PARAMETRAGE INITIAL DE SCVMM 2012

Après une phase d’architecture dédiée1, 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. 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.

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

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]

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


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

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

Figure 8 - Création des réseaux logiques

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

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


3.2.1 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éseaux), Les « Network

Sites » sont des « sous objets » des « Logical Networks ». Les « Network sites » sont des objets permettant de regrouper toute les définitions de réseau d’un « site » et de les associer à un groupe d’hôtes en particulier. (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).

Figure 10 - Création des "Network definition"

Best 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]


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

Figure 11 - Création des IP Pools

Best 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

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

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

3.3 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 ».

Figure 13 - Création des VM Networks


3.4 Création des profils de ports

Comme expliqué dans le chapitre « Comprendre les Switchs Logiques avec SCVMM 2012 SP1 » les profils de ports définissent la configuration des ports physiques et virtuels utilisés pour le déploiement des clusters Hyper-V et des machines virtuelles dans SCVMM.

Comme décrit dans le chapitre « Définition des profils de ports », notre scénario comprend 2 types de profils physiques, 4 profils de port virtuels « management » et 4 profils de ports virtuels « VM ».

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

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

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

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

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.

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 « Tableau 3- Profils de ports du switch convergé » et « Tableau 4- Profils de ports des switchs 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.

Figure 19 - Configuration des paramètres de QoS

Best practices : 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).

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

Best practices : 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.


3.5 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é

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.

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

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

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

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.

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

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.


4 DEPLOIEMENT DES CLUSTERS HYPER-V 2012 AVEC

SCVMM 2012 SP1

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.

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

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

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

Figure 29 - Installation de Hyper-V par SCVMM


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

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.

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


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.

Figure 31 - Configuration cartes de management


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.

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

Best practices : 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.


4.3 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 identiques.

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.

http://social.technet.microsoft.com/wiki/contents/articles/16100.supported-storage-arrays-for-system-center-2012-vmm.aspx


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

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

Best practice : Lors de la configuration initiale d’un cluster, les disques locaux conservent le statut de « disponible pour le placement ». Ceci peut provoquer des problèmes lors du déploiement de machines virtuelles. A ce titre il est conseillé de désactiver les disques locaux des nœuds du cluster comme disponibles pour l’hébergement des machines virtuelles.

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


Considération relative au disque de quorum

Windows Server 2012 introduit la notion de “Quorum Dynamique”. Même si il est toujours recommandé de construire des clusters comportant un nombre « impair » de votant, le quorum dynamique permet de maintenir un cluster fonctionnel sous certaines conditions.

Le quorum dynamique recalcule le quorum à la volée et maintiens un cluster fonctionnel même en cas de perte de plus de 50% des votes.

Pour maintenir un cluster fonctionnel même en cas de la perte de plus de 50% des votes il faut que les prérequis suivants soient respectés.

Le cluster a déjà établis un quorum

Le cluster subis des défaillances séquentielles (un nœud après l’autre).

Grâce au quorum dynamique, il est par exemple possible de monter un cluster 2 nœuds sans disque de « quorum ». Le service cluster restera fonctionnel même en cas d’arrêt d’un des deux nœuds. De même un cluster 3 nœuds restera fonctionnel même après la perte d’un second nœud, sous réserve qu’un quorum ai pu être recalculé après la perte du premier nœud.

4.4 Ajout du stockage

Une fois le LUN créé et présenté aux nœuds de votre cluster, celui-ci est visible depuis la console SCVMM.

Note : Dans le cas où le stockage n’est pas intégré à SCVMM par le biais d’un provider spécifique, il est nécessaire de :

Créer manuellement le LUN depuis l’interface SAN.

Présenter les LUNS aux serveurs Hyper-V.

Initialiser le volume depuis un des nœuds et l’ajouter dans le cluster.

Ces opération sont effectuée automatiquement par VMM si un provider SMI-S ou SMP est utilisé.

Une fois le LUN créé et présenté aux nœuds de votre cluster, celui-ci est visible depuis la console SCVMM 2012.


Le volume est alors automatiquement placé et monté dans « Available Storage ». Il faut ensuite le « convertir » en CSV pour pouvoir le rendre disponible pour le placement des machines virtuelles.


5 CREATION DES POOLS DE RESSOURCES (CLOUD)

5.1 Comprendre la notion de Cloud dans SCVMM

Le concept de Cloud utilisé dans SCVMM est une couche d’abstraction entre les ressources consommées et l’environnement physique possédant ces ressources.

Un Cloud SCVMM permet d’associer ensemble des réseaux logiques, des classes de stockage, des classes de ports et des ressources d’hébergement (RAM, CPU etc.) et de les exposer à une population de client (tenants).

Une fois créé, les pools de ressources peuvent être délégués à des administrateurs de Cloud (gestionnaires de ressources). Ces derniers peuvent à leur tour autoriser des utilisateurs à consommer les ressources dont ils ont la charge.

5.2 Création d’un Cloud dans SCVMM

Dans l’exemple ci-dessous, nous allons créer un « Cloud Production », utilisant les ressources des serveurs contenus dans le groupe d’hôtes de production du site de Nanterre.

Figure 35 - Création d'un cloud

Ce « Cloud » ne contient que des « clusters » membres du host group « production ».

Figure 36 - Association des groupes d'hôtes à un cloud

Best practice : Eviter des créer des pools de ressource mélangeant des serveurs « Standalone » et des serveurs en « cluster ».


Les machines virtuelles déployée dans notre pool de ressource n’ont pas besoin d’accéder aux réseaux techniques du cluster (Management, Live Migration et Cluster). Les VM ont cependant besoin d’accéder aux réseaux PROD, DMZ et au réseau ISCSI.

Figure 37 - Association de réseaux logiques à un Cloud

Seules les classes de ports Gold, Silver, Bronze et ISCSI sont nécessaire pour le déploiement de VM.

Figure 38 - Association des classes de ports avec un Cloud

Note : Si votre SAN est intégré à SCVMM par le biais d’un provider, vous pouvez définir les classes de stockages qui seront accessibles dans ce Cloud (Ex : Stockage Gold, Silver etc.).


Il est possible de définir précisément les ressources qui seront allouée au pool de ressource. De cette manière il est possible d’allouer des « morceaux » de la capacité totale de votre environnement à différents services.

Figure 39 - Définition des ressources allouée à un Cloud

Note : Attention à ne pas confondre l’allocation de ressource (Pooling) avec un mécanisme de QoS.


5.3 Délégation d’administration

Une fois le Cloud créé, il faut lui associer un rôle « administrateur ».

Figure 40 - Création d'un rôle Tenant Administrator

Les membres du rôle administrateur du Cloud (Tenant Administrator) pourront à leur tour créer des rôles utilisateurs (Self Service Users) capables de consommer les ressources disponibles dans le Cloud qu’ils administrent.

Figure 41 - Profil du rôle

Un rôle administrateur peut être associé à plusieurs pools de ressources (Cloud)

Figure 42 - Définition du scope d'un administrateur de Cloud


Best practices : Vous pouvez utiliser les pools de ressources pour séparer les clients (environnement multi-tenants) ou pour séparer les environnements (Production / Pré production) en conformité avec l’architecture physique qui sous-tend ce modèle.

Pour accéder au réseau, les machines virtuelles doivent être connectées à des VM Networks. Cette étape permet de définir les VM Network disponibles pour cet administrateur. Il pourra ensuite déléguer l’utilisation de ces VM Network à d’autres utilisateurs.

Figure 43 - Association des VM Network et d'un rôle.

Pour chaque rôle il est nécessaire de définir quelles actions peuvent être exécutée

Figure 44 - Définition des actions


Une fois le rôle configuré, l’administrateur peut accéder à la console SCVMM. Il dispose alors d’une vue filtrée conformément aux éléments configurés. Les administrateurs de Cloud gèrent des ressources, ils n’ont pas de vision de l’infrastructure matérielle, contrairement aux administrateurs SCVMM.

Figure 45 - Vue d'un administrateur de Cloud

Quand un administrateur de ressource ou un utilisateur délégué (Self Service User) crée une machine virtuelle, il ne dispose que des éléments exposés lors de la configuration de Cloud et du rôle.

Ici notre administrateur de Cloud ne peut voir que les VM Network PROD, DMZ et ISCSI. De même il ne peut configurer que les ports profiles associés à notre Cloud (ISCSI, Bronze, Silver, Gold).

Lors de la création de la VM, l’utilisateur n’a pas le choix du serveur de destination, il déploie dans un « Cloud ».

Note : Si aucun profil de ports n’est sélectionné, le profil de port par défaut définit au niveau du switch logique est appliqué (Cf.Figure 27 - Association des profils de ports vituels avec les Logical Switches)

Figure 46 - Création d'une VM par un utilisateur


6 ANNEXE

6.1 Script de désactivation des disques locaux d’un cluster pour le placement

################################################################################

#

# Dé mappage des disques locaux d'un cluster.

# Guvirt.org - 28.06.2013

# Auteur : [email protected]

#

################################################################################

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 "[email protected] " -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

Documents

White Paper Hyper-V / SCVMM 2012 SP1 · virtualisation et des technologie Cloud White Paper Hyper-V / SCVMM 2012 SP1 Document Guvirt – ... Avec Windows Server 2008 R2 et SCVMM 2008