NetApp Tech OnTap
     

Étude de cas : les leçons apprises avec
Hyper-V et NetApp

Le succès d'Avanade repose sur l'aptitude de ses consultants à répondre aux besoins des entreprises clientes du monde entier. Pour aider ses collaborateurs, Avanade a beaucoup investi dans des applications et services informatiques qui offrent aux consultants tous les outils numériques dont ils peuvent avoir besoin pour atteindre leurs objectifs. Les possibilités de reprise après sinistre et de disponibilité offertes par la solution Microsoft® Hyper-V™ sont l'une des principales raisons qui nous ont amenés à virtualiser nos serveurs. Une fois associée à un stockage interne partagé, nous espérons qu'une architecture de ce type permettra à nos applications et services de basculer en douceur sur un autre noeud local et de répliquer en va-et-vient sur un centre de données distant, ce dans le but de limiter la propagation des sinistres.

Bien que nous ayons d'autres raisons de passer à Hyper-V, c'est la flexibilité de restauration et de récupération des environnements de serveurs virtuels pour la reprise après sinistre qui a décidé notre PDG à réaliser cet important investissement. Les autres raisons qui nous ont amenés à choisir Hyper-V sont les suivantes :

  • Réduction des coûts des data centers (encombrement, puissance et refroidissement réduits) sans retombées sur la qualité du service
  • Meilleure exploitation des ressources de serveurs
  • Déploiement plus rapide des nouveaux environnements de serveurs d'applications

Nous espérions évoluer dans tous ces domaines. C'est dans cette optique que nous nous sommes engagés à utiliser la version bêta de Windows Server® 2008 avec Hyper-V. Là, le travail a vraiment commencé.

Notre déploiement Hyper-V

Avant de décrire notre environnement Hyper-V actuel, je voudrais vous en dire plus sur la nature de notre infrastructure informatique avant l'implémentation de Hyper-V. Notre environnement est constitué de trois data centers (un aux États-Unis, un en Europe et un en Asie) et la plupart des services applicatifs utilisés par nos consultants proviennent de notre data center américain de Seattle. Quand nous avons commencé à déployer Hyper-V, les quelques 8 000 professionnels d'Avanade utilisaient plus de 200 serveurs distribués.

Comme Avanade est une coentreprise de Microsoft et d'Accenture, notre environnement informatique s'appuie principalement sur des applications Microsoft pour les besoins du personnel sur le terrain et les activités générales de l'entreprise. Ces applications comprennent notamment de nombreuses installations de Microsoft Office SharePoint® Server, de Microsoft Exchange, de Microsoft SQL Server®, de Microsoft Team Foundation Server, de Microsoft Terminal Services, ainsi que de nombreuses applications sectorielles line 120 supportées par des applications Web frontales.

Pour tirer le meilleur parti du nouvel environnement de serveurs virtuels, nous avons décidé de coupler Microsoft Hyper-V avec une infrastructure de stockage partagée. Nous utilisions déjà le stockage NetApp® en iSCSI pour notre infrastructure SQL Server. Le choix de NetApp s'est donc naturellement imposé comme solution pour la prise en charge du nouveau déploiement Hyper-V. Nous avions particulièrement apprécié la flexibilité et l'efficacité des technologies NetApp de protection et de réplication des données Snapshot™ et SnapMirror®. Il nous était devenu habituel de provisionner rapidement du stockage pour les nouvelles applications et nous envisagions de gagner en capacité sur le stockage primaire grâce à la déduplication NetApp.

Nous espérions que NetApp s'avèrerait aussi efficace pour Hyper-V qu'il l'avait été pour nos autres environnements. Les tests de performances réalisés avec Hyper-V et NetApp en iSCSI ont confirmé que la combinaison NetApp/Hyper-V nous permettrait de bénéficier des hautes performances qu'il nous fallait.

Comme nous avons décidé de continuer sur cette voie, notre implémentation Hyper-V a été déployée dans deux domaines : la production et l'environnement de test et de développement. Voici les principaux points à retenir concernant notre déploiement actuel.

Environnement de production

  • Microsoft Hyper-V pour Windows Server 2008, Core Installation, Enterprise Edition
  • Configuré en tant que cluster Hyper-V à quatre noeuds
  • 27 partitions enfant (machines virtuelles)
  • Les applications virtualisées s'exécutent sous le système d'exploitation invité Windows Server 2003 ou sous Windows Server 2008
    Applications virtualisées
  • Team Foundation Server
  • Systems Center Operations Manager 2007
  • Microsoft Windows Server 2008 Terminal Services (TS Farm et TS Gateway)
    Serveurs et stockage
  • Serveurs Sun Fire X4150, chacun doté de deux processeurs quadri-coeur, 32 Go de RAM
  • Système de stockage NetApp FAS3040 configuré avec le protocole iSCSI

Environnement de test et de développement

  • Microsoft Hyper-V pour Windows Server 2008, installation complète, Enterprise Edition
  • Un cluster à quatre noeuds
  • Un cluster à deux noeuds
  • Trois serveurs autonomes
  • Plus de 150 partitions enfant (machines virtuelles) pour les hôtes Hyper-V de test et de développement
    Applications virtualisées
  • Variées, mais intègrent des applications de production
    Serveurs et stockage
  • Serveurs Dell 2950, chacun doté de deux processeurs quadri-coeur, 32 Go de RAM
  • Système de stockage NetApp FAS3020 configuré avec le protocole iSCSI

VMware DRS

Figure 1) NetApp supporte le cluster Hyper-V à quatre noeuds d'Avanade.

Décisions à prendre lors d'un déploiement Hyper-V

Au vu du déroulement de nos déploiements, il semble que les choix effectués dans certains domaines particuliers aient joué un rôle déterminant dans la réussite de ce projet. Ces choix sont les suivants :

  • Quelle édition de Microsoft Windows Server 2008 déployer, l'édition complète ou l'édition Core plus légère de Windows Server
  • Comment configurer le système NetApp pour qu'il prenne en charge les fichiers du disque dur virtuel (ou VHD pour « Virtual Hard Disk ») des partitions enfant Hyper-V
  • Quel processus développer pour pouvoir provisionner et relier rapidement un nouveau VHD à un noeud Hyper-V existant

Choix de Microsoft Windows Server 2008 Core Edition
Il nous a fallu un certain temps pour déterminer si nous devions utiliser Server Core ou l'édition complète de Windows Server 2008. Nous savions que Server Core était bien moins lourd du point de vue de la sécurité et qu'il nous faudrait donc installer beaucoup moins de correctifs. Ce point était important car chaque hôte devrait au final héberger 10, 15, voire 20 machines virtuelles. Pour que les machines virtuelles restent disponibles au maximum, nous souhaitions réduire tant que possible le nombre de redémarrages nécessaires sur les serveurs hôte.

Cependant, Server Core est doté d'une interface de ligne de commande et nous craignions que cela effraie notre personnel de premier niveau. Les employés s'inquiétaient : « Est-ce que cet outil sera difficile à utiliser et serai-je capable de le dépanner au besoin ? » À l'issue de quelques négociations, nous avons décidé de continuer avec Server Core. Il s'est avéré que c'était le bon choix. Une fois la solution conçue, elle a très bien fonctionné et offert une infrastructure très solide. Notre équipe de support technique a pu continuer à utiliser les outils standards pour Windows Server 2008, notamment les applications intégrables MMC et les outils d'administration de serveurs distants. Au bout du compte, tout le monde a fini par vraiment apprécier Server Core.

Configuration du stockage NetApp pour une utilisation avec des partitions enfant Hyper-V et des VHD

Nous savions que la déduplication et la technologie Snapshot de NetApp fonctionnaient bien au niveau des volumes, alors nous avons décidé de structurer le stockage de nos partitions enfant Hyper-V de sorte à tirer le meilleur parti de ces fonctionnalités.
Comme le volume des données dupliquées entre les instances d'un même système d'exploitation invité est très important, nous nous attendions à réaliser des économies substantielles en lançant la déduplication NetApp sur les volumes de développement et de test dotés de disques durs virtuels Hyper-V. À notre grande satisfaction, nous avons obtenu une économie d'espace de plus de 50 %. Il n'en fallait pas plus pour nous encourager à déployer la déduplication dans notre environnement de production. Étant donnés les avantages obtenus avec les volumes, nous avons adopté les pratiques suivantes :

  • Groupement des partitions enfant exploitant le même système invité sur le même volume flexible NetApp (FlexVol®).
    Dans notre environnement de production, les partitions enfant Windows Server 2003 seraient donc toutes regroupées sur un seul et même volume, tandis que nos partitions Windows Server 2008 se trouveraient sur un autre volume. (Dans notre environnement de développement et de test, cette règle est moins scrupuleusement suivie car nous pouvons utiliser NetApp Snapshot pour sauvegarder ou restaurer rapidement tout un environnement à des fins de test. Le cas échéant, l'environnement peut comprendre plus d'un système d'exploitation invité.)
  • Mappage en 1:1 des disques durs virtuels sur les LUN.
    À chaque partition enfant correspond un LUN qui stocke les fichiers et données du disque dur virtuel de cette partition enfant. Pour renforcer l'indépendance entre partitions enfant, ce mappage 1:1 garantit qu'aucune partition enfant ne partagera le même LUN qu'une autre partition enfant. Toutefois, de nombreux LUN (et disques durs virtuels) se trouvent toujours sur le même volume NetApp.
  • Utilisation des GUID de volumes Microsoft en tant qu'identifiants uniques des partitions enfant.
    Comme nous avons de nombreuses machines virtuelles sur nos clusters Hyper-V, les lettres ne suffisent plus pour identifier les lecteurs. Il n'a pas été possible d'utiliser des points de montage car cela aurait engendré des dépendances indésirables entre les disques. Nous avons donc choisi d'utiliser les GUID des volumes pour identifier les disques sur nos clusters. Plutôt que de stocker un LUN sur un lecteur identifié par une lettre (lecteur E:, par exemple), nous avons décidé de ne pas attribuer de lettres aux lecteurs. Voici à quoi ressemble une assignation GUID quand on n'utilise pas de lettres :  \\?\Volume{c9612f6f-702e-11dc-b79a-00123f769676}\.

Les sections suivantes décrivent la configuration actuelle du stockage de nos environnements de production, de développement et de test.

Configuration du stockage pour l'environnement de production Hyper-V
Deux volumes flexibles NetApp (FlexVol) stockent les données associées à chaque partition enfant. Les fichiers des VHD des partitions enfant sont configurés dans Hyper-V en tant que fichiers « VHD fixes », ce afin d'optimiser les performances. Nous savions que nous pourrions encore gagner de l'espace grâce à la technologie de déduplication NetApp. C'est ce qu'attendent les clients quand ils utilisent des VHD dynamiques.

Volume 1 :

  • Stocke les données de sept partitions enfant (machines virtuelles) Windows Server 2003, les données de chacune des partitions enfant étant stockées sur des LUN iSCSI distincts
  • Le volume bénéficie en tout de 500 Go de capacité de stockage
  • 48 % de l'espace du volume sont actuellement utilisés

Volume 2 :

  • Stocke les données de 20 partitions enfant Windows Server 2008, les données de chacune des partitions enfant étant stockées sur des LUN iSCSI distincts
  • Le volume bénéficie en tout de 1,25 To de capacité de stockage
  • 76 % de l'espace du volume sont actuellement utilisés

Configuration du stockage pour l'environnement de développement et de test
Plus de 30 volumes flexibles NetApp (FlexVol) stockent les données de développement ou de test associées aux partitions enfant. Les fichiers des VHD des partitions enfant sont configurés dans Hyper-V en tant que fichiers « VHD dynamiques », ce qui facilite l'expansion et la diminution de leur taille lors des tests et des développements.

Volume 1 : utilisé pour le développement

  • Stocke les données de 25 partitions enfant Windows Server 2008
  • Les données de chaque partition enfant sont stockées sur des LUN iSCSI distincts
  • Les LUN font entre 40 et 100 Go
  • Le volume bénéficie en tout de 600 Go de capacité de stockage
  • 39 % de l'espace du volume sont actuellement utilisés

~32 volumes : utilisés par les équipes de développement et de test

  • À eux tous, les volumes stockent les données de plus de 100 partitions enfant Hyper-V Windows Server 2008
  • Les données de chaque partition enfant sont stockées sur des LUN iSCSI distincts
  • Les LUN font en moyenne 20 Go
  • Chaque volume occupe en moyenne trois LUN
  • À eux tous, les volumes bénéficient de 2,5 To de capacité de stockage

Provisionnement rapide des nouveaux LUN et VHD
Nous avons particulièrement apprécié la flexibilité de la baie de stockage interne de NetApp. Il nous a été facile de développer un moyen de provisionner les nouveaux LUN et nous avons pu relier un nouveau disque (VHD) sur un noeud Hyper-V en cinq minutes. Nous avons développé un ensemble de scripts basés sur des commandes SSH (Secure Shell). Ce sont ces scripts qui créent le LUN et le relient automatiquement à notre cluster Hyper-V. Par la suite, ce processus nous a permis d'automatiser le provisionnement des LUN. Une fois le processus entièrement documenté, nous espérons passer la main à nos équipes chargées des applications afin qu'elles le documentent elles-mêmes. Il suffit de se rendre sur l'hôte, d'exécuter les commandes nécessaires et le tour est joué. Il n'y a rien d'autre à faire !

Et pour la suite

Au vu des succès obtenus, nous avons l'intention de tout virtualiser à partir de maintenant. Selon moi, l'architecture finale sera constituée de notre cluster Hyper-V et d'un cluster SQL Server relié à du stockage NetApp. Toutes nos applications frontales seront au final hébergées sur le cluster Hyper-V, lequel devrait passer de quatre à huit noeuds. Nous avons également commencé à mettre à niveau le microcode NetApp sur notre système de production de manière à pouvoir lancer la déduplication NetApp et ainsi réduire le volume d'espace nécessaire à mesure que nos machines virtuelles se développent.

Plans de virtualisation
Nous prévoyons de virtualiser notre implémentation SharePoint, voire notre cluster SQL Server. Microsoft apportant un support croissant à Hyper-V, nous envisageons de virtualiser nos serveurs de tête, nos serveurs de pare-feu ISA Servers, ainsi que nos serveurs Web frontaux IIS. Dans les 6 à 9 prochains mois, nous espérons pouvoir virtualiser de nombreux racks de serveurs à application unique car ceux-ci occupent beaucoup de place dans le data center. Ces applications sont utilisées par peut-être 10 à 20 personnes dans un service comme les ressources humaines ou la finance. Il devrait être assez simple et plutôt rentable de transférer ces applications sur des machines virtuelles.

Nous continuons à faire évoluer nos pratiques par rapport à Hyper-V. Cette évolution est en partie rythmée par l'arrivée de nouveaux produits Microsoft bénéficiant d'une intégration de plus en plus étroite avec Hyper-V, comme SCVMM (Service Center Virtual Machine Manager) et Microsoft DPM (Data Protection Manager). En fait, nous avons déjà commencé à tester la fonction P to V (Physical to Virtual) de SCVMM et elle s'annonce prometteuse car elle devrait nous permettre de convertir rapidement de nombreux serveurs physiques en machines virtuelles. Nous cherchons également des moyens d'incorporer au mieux les nouvelles technologies NetApp de protection des données qui valorisent VSS, afin que Microsoft Hyper-V puisse capturer rapidement des snapshots d'une machine virtuelle de base. Nous envisageons d'utiliser une technologie NetApp de ce type pour la gestion et la protection des données, en conjonction avec Data Protection Manager.

Plans de protection des données et de reprise sur incident
Nous développons également des processus pour la protection des données par niveaux.

  • Certaines données Hyper-V seront probablement sauvegardées avec Microsoft Data Protection Manager ou une combinaison de DPM et des technologies de protection des données NetApp valorisant VSS.
  • Nous utilisons actuellement DPM dans notre environnement de production. Celui-ci nécessite l'emploi d'un agent sur chaque partition enfant.
  • Nous prévoyons de sauvegarder certaines données à l'aide de NetApp Snapshot.  (Snapshot est déjà utilisé dans nos environnements de développement et de test.)
  • Certaines données vitales seront répliquées grâce à NetApp SnapMirror entre notre data center de Seattle et un autre site externe de reprise sur incident basé dans nos locaux de l'Est des États-Unis.

Conclusion

Nous sommes pleinement satisfaits du travail accompli avec Microsoft Hyper-V et NetApp. Nous avons gagné beaucoup d'espace disque (grâce à la déduplication NetApp) et sommes désormais à même d'autoprovisionner pas moins de quatre serveurs en moins d'une heure. Nous espérons encore accélérer ce processus grâce à SCVMM. Nos machines virtuelles restent disponibles au maximum. Nous avons également obtenu des performances exceptionnelles avec Hyper-V et NetApp.

© 2008 Avanade Inc. Tous droits réservés. Le nom et le logo Avanade sont des marques déposées aux États-Unis et dans d'autres pays. Les autres noms de marques et de produits sont des marques commerciales de leurs propriétaires respectifs.

Avez-vous des remarques à faire sur cette étude de cas ?

Posez vos questions, échangez des idées et partagez vos points de vue en vous connectant directement sur les communautés NetApp.
Andy Schneider

Andy Schneider
Ingénieur système en chef
Avanades

Après des débuts en tant que consultant sur le terrain chez Avanade il y a trois ans et demi, Schneider a passé les deux dernières années a mettre à profit son expérience au sein de l'équipe chargée de l'infrastructure informatique centrale de l'entreprise. Avec son équipe, il détermine maintenant comment utiliser au mieux les nouvelles technologies dans l'environnement de production d'Avanade.

 
Explorer