vInfra.ch

Guillaume LACAILLE's Blog

Partie 1: Introduction à la Networking Fabric de SCVMM 2012

Au cours de cette première partie dédiée aux réseaux, nous allons faire le point sur les objets réseaux de la fabrique Networking de SCVMM 2012.

Avant de rentrer dans le vif du sujet, nous allons faire un petit point, dans cette première partie, sur les différents objets réseau que nous pouvons trouver à travers Hyper-V 2012/R2 et SCVMM 2012 SP1/R2.

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

Fabric management

Dans la console SCVMM, depuis la version 2012 RTM, un nouvel onglet a fait son apparition. Contrairement à l’onglet VMs and Services, qui correspond aux ressources virtuelles mis à disposition du business, l’onglet Fabric correspond aux ressources physiques et à leur configuration dans le datacenter.

Rappel: Dans un environnement Cloud, le business (utilisateurs) sont des consommateurs de l’infrastructure. Ils n’ont pas besoin de savoir quelle est l’infrastructure technique mis en place pour faire fonctionner leur machine virtuelle. Dans un monde un peu plus commun, c’est la même chose que lorsque l’on achète un téléphone portable pour téléphoner ou utiliser le réseau 3G, nous n’avons pas besoin de connaitre la partie technique mis en place par l’opérateur téléphonique (la Fabric) pour utiliser les services offert dans notre abonnement (les VMs).

Figure 1: Fabric Management

Figure 1: Fabric Management

Dans la Fabric, nous allons donc retrouver tous les objets que nous retrouverons dans le Datacenter:

  • Les serveurs: tous les hôtes Hyper-V qui permettent d’avoir accès aux ressources CPU et Mémoire; mais aussi les serveurs liés à l’infrastructure, comme les serveurs VMM, WSUS, la librairie, ou encore le serveur PXE.
  • Le stockage: lorsque votre matériel est compatible avec SCVMM, vous pouvez y ajouter la gestion de votre SAN, Luns ou shares SMB 3.0. Depuis SCVMM 2012 R2, vous y trouverez également la gestion des Fiber Fiber Channel Fabrics permettant de gérer votre infrastructure SAN Fiber channel (pratiquement de bout en bout).
  • Le réseau: c’est ici que nous nous arrêtons, c’est ce qui nous intéresse !

 La Networking Fabric

Afin de ne pas nous mélanger les pinceaux dès le début, faisons un petit point sur les objets de la Networking Fabric, ce qui permettra d’avoir le bon vocabulaire pour les articles suivants.

 Logical Networks

Les Logical Networks ou réseaux logiques, à ne pas confondre avec les logical switches, permettent de représenter la fonction de votre réseau dans votre environnement.

Par exemple, vous pouvez avoir un réseau logique « Production », un autre « Développement », « Management » ou encore « Backup ».

Le réseau logique permet d’ajouter un niveau d’abstraction à votre réseau concernant les sites, subnets et vLan utilisés par votre infrastructure physique.

Un réseau logique est systématiquement associé à un ou plusieurs Network Site(s). Ce dernier permet d’associer un groupe d’hôtes Hyper-V à un ou plusieurs couples de subnet/vLan. Ces Network Sites sont en général associés à un datacenter ou une salle serveur.

Figure 2: Logical Network

Figure 2: Logical Network

Dans l’exemple du diagramme Figure 2, le logical network Management  est associé à deux groupes de serveurs Hyper-V dans 2 sites différents: Genève et Lausanne. Lorsque la VM1 tourne sur le cluster du groupe 1 dans le datacenter de Genève, la carte réseau est associée automatiquement au vLan 0 sur le subnet 10.0.0.0/24. Si la VM est migrée sur le cluster du groupe 2 dans le datacenter de Lausanne, elle sera automatiquement configurée avec le vLan 100 sans intervention de l’Administrateur.

Note: Rien n’interdit d’utiliser des subnets différents sur des sites différents (par exemple 10.0.0.0/24 et 10.0.1.0/24). Cependant, je vous conseille fortement d’utiliser la ou les mêmes plages d’adresses IP pour le même logical network.

L’autre avantage de ces réseaux logiques: vous pouvez à tout moment ajouter des vLan/Subnet pour un même réseau logique. Imaginez que votre réseau de développement arrive à saturation d’adresses IP, il suffit d’ajouter un couple vLan / Subnet sans modifier les habitudes de déploiement de vos VM: elles seront toujours associées au réseau de développement.

Figure 3: Ajout de subnets pour le réseau de production

Figure 3: Ajout de subnets pour le réseau de production

Enfin, il faut savoir qu’un IP Pool peut être associé qu’à un logical network. Un IP Pool peut-être considéré comme un DHCP Statique: on lui donne une plage d’adresses IP à distribuer avec une configuration réseau (Gateway, DNS, DNS Suffix). Lors de la création d’une nouvelle machine virtuelle, VMM attribuera automatiquement une configuration IP Statique à votre machine virtuelle en utilisant une IP disponible dans le pool d’adresses.

Remarque: voir l’article Attribuer des IP fixe dynamiquement à nos VMs

MAC Address Pools

Les MAC Address Pools, comme leur nom l’indique sont des pools d’adresses MAC (une plage d’adresses MAC), qui peuvent être associés à des groupes de serveurs Hyper-V (Host Groups).

Les Pools d’adresses MAC ont peu d’applications dans la vie courante à ma connaissance, mais peuvent être utiles par exemple dans les cas suivants:

  • Configuration de Load-Balancers sur des adresses MAC spécifiques;
  • Configuration d’outils d’OSD qui utilisent les adresses MAC pour le déploiement de systèmes (via PXE);
  • Configuration d’outils de streaming disque type Citrix Provionning Server (via PXE);
  • Configuration de filtrage firewall via adresses MAC (plus utilisé à ma connaissance).

Load Balancers

Depuis SCVMM 2012 (RTM), il est possible de venir piloter les appliances de load-balancing depuis VMM.

Pour rappel, un load-balancer permet de répartir la charge des utilisateurs sur plusieurs serveurs en fonction d’un certain nombre de paramètres: nombre de connexions, réponse du serveur la plus rapide pour les plus simples, règles plus complexes en fonction de l’application pour d’autres. En règle générale, l’utilisateur se connectera à une adresse IP unique ou un nom unique et sera redirigé vers le serveur le moins chargé par le load-balancer.

Figure 4: Load-Balancer

Figure 4: Load-Balancer

Il ne s’agit pas d’ajouter un virtual switch ou une appliance à chacun de vos serveurs Hyper-V mais bien d’utiliser VMM pour configurer automatiquement vos appliances de load-balancing type Citrix Netscaler avec vos machines virtuelles. L’onglet Load Balancer permet de voir quels sont les Load-Balancers Providers que vous avez configuré pour VMM et leur status.

Par défaut, un seul Load-Balancer est configuré: Microsoft Network Load Balancing (NLB).

Ces configurations de load-balancing seront réalisées à partir des VIP Templates.

VIP Templates

Un VIP Template est un ensemble de règles de load-balancing qui peut être réutilisé dans un Service Template. Un VIP Template peut être utilisé par plusieurs services.

Par exemple, vous pouvez créer un VIP Template avec les simples règles suivantes:

  • Port TCP 80
  • Méthode: Round-Robin

Ainsi, chaque nouvelle connexion sur le port TCP 80 (HTTP) de l’adresse attribuée au VIP (Virtual IP) seront réparties de manières égale sur chacun des serveurs du service. S’il y a 3 serveurs comme dans la figure 4, la première connection ira sur le serveur www1, la seconde sur le serveur www2, la troisième sur le serveur www3, la quatrième sur le serveur www1 à nouveau, et ainsi de suite.

Switch Extension (SP1 Uniquement)

Cet onglet permet de voir et de configurer les switch extensions que vous avez ajouté à vos serveurs Hyper-V et votre infrastructure VMM. Tout comme pour les Load-Balancer, il faut avoir configuré le provider de votre switch virtuel avant de pouvoir avoir l’intégration dans VMM. D’une manière générale, la configuration des extensions de switchs sont différentes pour chaque éditeur.

Note: A l’heure ou j’écris, il existe -à ma connaissance- peu d’éditeurs d’extension switch dont entre autres: Cisco avec le 1000v, 5Nine avec la suite Cloud Security, NEC avec ProgrammableFlow PF1000, et il me semble F5.

Logical Switches

Les Logical Switches, à ne pas confondre avec les Logical Networks, permet d’appliquer des un ensemble de configurations sur les Virtual Switches à travers plusieurs hôtes Hyper-V.

Ces configurations peuvent-être:

  • Utilisation de SR-IOV;
  • Activation d’extensions switch;
  • Utilisation ou non de ports physiques en Teaming;
  • Utilisation d’uplink port profiles (voir ci-dessous);
  • Ajout des classification des ports virtuels (Port classification, voir ci-dessous) pouvant utiliser ce switch logique.

Note: l’utilisation d’un Logical switch nécessite obligatoirement d’utiliser un Uplink Port Profile.

Oui mais alors quelle différence avec les Logical Switches, Virtual Switches et les Standard Switches ?

Les Logical Switches et Standard Switches sont tous deux des Virtual Switches.

  • Un Logical Switch peut-être considéré comme un switch distribué avec une configuration homogène à travers les hôtes Hyper-V et permet l’utilisation de plusieurs cartes réseau physique en teaming (nous verrons dans une autre partie).
  • Un Standard Switch est configuré sur chaque hôte Hyper-V de manière indépendante et ne peut utiliser qu’une carte réseau en externe.

Pour ceux qui viennent du monde VMware, un Logical switch s’apparente plus à un Virtual Distributed Switch (vDS), et un Standard switch à un…Standard switch (vSS).

Note: dès que vous montez un cluster Hyper-V avec SCVMM, l’utilisation des Logical Switches est vivement conseillée.

Port Profiles

Il existe deux types de Port Profiles: les Virtual Network Adapter Port Profiles et les Uplink Port Profiles. Un port profile permet d’appliquer un ensemble de configurations à un port virtuel ou physique.

Le Virtual Network Adapter Port Profile s’applique aux cartes réseau virtuelles, plus communément aux cartes des machines virtuelles (mais pas seulement !). Ils permettent de configurer les paramètres suivants:

  • L’utilisation des fonctionnalités d’offload présentes sur les cartes réseau physique du serveur (VMQ, IPSec, SR-IOV);
  • Configuration des paramètres de sécurité (DHCP guard, Router guard, MAC spoofing…);
  • Configuration de Network QoS: débits minimums et maximums, poids attribué à la carte réseau en cas de trafic élevé.

L’Uplink Port Profile s’applique seulement aux cartes physiques. Ils sont utilisés pour lier une ou plusieurs carte physiques à un Logical Switch. De plus, les paramètres suivant peuvent être configurés:

  • Le teaming mode et l’algorithme de load-balancing (nous y reviendrons);
  • Les sites associés à cet uplink port profile, le même site défini dans les logical networks;
  • La possibilité d’utiliser cette carte réseau pour la virtualisation de réseau (HVN – NVGRE) avec des hôtes Hyper-V 2012 uniquement, la stack HVN ayant migré d’un niveau dans Hyper-V 2012 R2 et étant active par défaut.
Figure 5: Port Profiles

Figure 5: Port Profiles

Port Classifications

Les Port classifications sont, comme leur nom l’indique, des étiquettes permettant de classer les cartes réseau virtuelles. Une classification de port peut être associé à un Virtual Adapter Port Profile si vous souhaitez ajouter, par exemple de la QoS.

Gateways (SP1 Uniquement)

Les Gateways sont utilisées pour connecter les VM Networks d’un site à un autre. Par exemple pour connecter deux datacenters entre eux via un VPN Site-to-Site (S2S), ou pour connecter votre datacenter à Windows Azure et utiliser les ressources du cloud publique.

Tout comme pour les Load-Balancers ou les extensions de switchs, il faut configurer le provider des Gateways (passerelles) afin de pouvoir l’ajouter et la configurer dans VMM.

D’autre part, dans SCVMM 2012 SP1, seules les appliances supportés peuvent-être configurées dans VMM. Les fonctionnalités de passerelles offertes dans Windows Server 2012 R2 ne peuvent être utilisées qu’avec SCVMM 2012 R2.

Network services (R2 Uniquement)

Dans SCVMM 2012 R2, les Network Services regroupent les onglets Switch extentions et Gateways présents dans SCVMM 2012 SP1.

A ces services, s’ajoutent la configuration de l’intégration des services IPAM de Windows Server 2012 R2 (IP Address Management) et des services de management des switchs physiques.

Et côté VMs and Services ?

Côté VMs and Services nous allons retrouver du réseau principalement à deux endroits: dans les VM Networks, et dans les machines virtuelles elles-même, au travers des Virtual Network Adapters.

VM Networks

Les VM Networks sont dans leur définition la plus simple, sans Hyper-V Virtual Network (HVN), une vue des logical networks que vous avez configurés.

Si vous utilisez les fonctionnalités d’Hyper-V Virtual Network (nous y reviendrons en détail), un VM network va permettre d’ajouter un niveau de virtualisation de réseau et isoler vos machines virtuelles comme vous le feriez avec des vLan classiques.

Virtual Network Adapters

Les Virtual Network Adapters existent en deux modèles sous Hyper-V: Legacy Network Adapters, principalement utilisés dans les VMs de génération 1 pour utiliser le boot PXE et compatible avec les anciens systèmes d’exploitation mais au détriment d’un débit virtuellement limité à 100MBps; et les Synthetic Network Adapters offrant les meilleurs performances pour les machines virtuelles qui ont leur integration tools à jour.

Note: Vous le verez dans les prochaines parties, les Virtual Network adapters ne sont pas uniquement utilisés par les machines virtuelles, mais également la partition de management d’Hyper-V. Elle est automatiquement créée lorsques vous cliquez sur Allow Management Operating System […] à la création d’un Virtual Switch dans la console Hyper-V Manager.

Next steps

Dans le prochain article, avant de voir en détails la mise en oeuvre de ces différents objets dans « le monde réel », nous ferons rapidement un point sur les infrastructures convergés du point de vue réseau. Ce que cela signifie, les apports de ces concepts en terme d’infrastructure et de manageabilité.

, , , , , ,

3 thoughts on “Partie 1: Introduction à la Networking Fabric de SCVMM 2012

  • […] Partie 1: Introduction à la Fabric Networking de SCVMM 2012 Partie 2: Le réseau et les infrastructures convergés sous Hyper-V Partie 3: Configuration réseau de base d’un serveur Hyper-V d’un Branch-Office Partie 4: Introduction du teaming de cartes réseau sous Hyper-V 2012 et SCVMM 2012 Partie 5: Configuration du teaming sous Hyper-V et SCVMM 2012 Partie 6: Configuration réseau de base de serveurs Hyper-V en cluster Partie 7: Introduction aux Native Virtual Adapter Port Profiles Partie 8: L’accélération matériel du réseau dans Hyper-V 2012 Partie 9: La séparation des réseaux dans Hyper-V et SCVMM 2012 Partie 10: Configuration des vLan dans SCVMM 2012 Partie 11: Configuration des PVLan dans SCVMM 2012 Partie 12: Introduction à la virtualisation de réseau sous Hyper-V (NVGRE) Partie 13: Configuration de NVGRE dans SCVMM 2012 Partie 14: Configuration de Hyper-V Gateway Partie 15: Introduction aux extensions de switchs dans Hyper-V Partie 16: Installation de l’extension Cisco Nexus 1000V sur Hyper-V Partie 17: Quelques scénarios réseau Partie 18: Connexion d’un environnement Hyper-V à Windows Azure […]

  • […] Avant de commencer, si vous n’êtes pas habitué aux objets présents dans la fabric de SCVMM de vous rafraîchir la mémoire en relisant la Partie 1: Introduction à la Networking Fabric de SCVMM 2012. […]

  • […] switchs ToR (Top of Rack) depuis SCVMM. L’idée était de pouvoir gérer la configuration de toute la fabric réseau en SDN, du switch virtuel jusqu’au switch physiques. Avec Windows Server 10, Microsoft va encore […]

Répondre à Partie 6: Configuration du teaming sous SCVMM 2012 SP1/R2 (1/7) | vInfra.ch Annuler la réponse.

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *