Archives mensuelles : janvier 2016

Architecture WAP–Design SCVMM

On parle enfin virtualisation, SCVMM et Hyper-V. Si on connait un peu son SCVMM, on connait ses limites de sizing :

  • Nombre de hosts Hyper-V : 1000
  • Nombre de machines virtuelles : 25000
  • Nombre de User Roles : 1000

Source : Overview of System Center 2012 – Virtual Machine Manager

 

Après, il y aura les limites d’Hyper-V (2012 R2) à prendre en considération :

  • Nombre maximum de nœuds dans un cluster : 64
  • Nombre de machines virtuelles maximum dans un cluster : 8000

Source : Hyper-V scalability in Windows Server 2012 and Windows Server 2012 R2

 

Première conclusion, la véritable limitation viendra de SCVMM mais pas ou on pourrait l’attendre, ce sera celle du nombre de user-roles dans SCVMM, donc le nombre maximum de locataires que l’on pourra avoir sur une seule infrastructure SCVMM. Est-ce un problème de n’avoir que mille locataires? Le Business répondra invariablement oui. Il faut pouvoir outre passer cette limite technique ? Les grands fournisseurs de services Cloud se sont déjà heurtés à ce type de problème. Si leurs infrastructures n’étaient pas assez scalable, on le saurait depuis longtemps. Leur astuce c’est que l’infrastructure présentée au client n’est qu’une partie de l’infrastructure globale. Derrière Azure, il y a certes des services globalisés tel que le portail mais après, les services sont localisés et même découpés en instances de plus petite tailles, plus faciles à manager. A l’échelle de Windows Azure Pack, on peut faire la même chose avec SCVMM. Individuellement chacun de nos locataires à peu de chances de nous faire atteindre les limites d’une seule instance de SCVMM. Rien n’empêche alors d’avoir plusieurs instances de SCVMM présentées à Windows Azure Pack via le Service provider Foundation. De son point de vue, on publie effectivement plusieurs Clouds SCVMM. Pour nos locataires, ce ne sont que des offres d’abonnement différents. Pour commencer, une seule instance suffira.

Haute disponibilité avec SCVMM

Le nombre d’instances étant réglé, passons à sa disponibilité. Avec SCVMM, on est limité car on ne peut avoir qu’une seule instance du rôle que l’on peut seulement configurer pour opérer au sein d’un cluster. Si le cluster ne fait pas partie de vos choix, l’utilisation d’Hyper-V Replica est vivement recommandée. Personnellement, j’essaie de limiter le nombre d’instances de SCVMM. Même si Windows Azure Pack permet de référencer autant de Service provider Foundation pour lesquelles on peut référencer jusqu’à cinq instances SCVMM distinctes, il n’en reste pas moins que cela reste des instances distinctes du point de vue Gallery et VM Roles. Donc nos choix se limitent à :

  1. Rester dans les limites de support de SCVMM pour n’avoir qu’une seule instance indépendamment du nombre de Datacenters
  2. Placer une instance SCVMM par Datacenter et raccorder les hôtes de virtualisation en conséquence
  3. Placer une instance SCVMM par Datacenter et raccorder les hôtes de virtualisation en répartissant entre les Management group

 

Le choix numéro n°1 est le choix le plus rationnel pour commencer. Du point de vue architecture rien n’empêche d’ajouter d’autres instances en cours de route pour faire face aux besoins / contraintes. La seule limitation concerne la fonctionnalité Gallery de Windows Azure Pack qui est liée à la librairie SCVMM. Le contenu de la Gallery présenté à l’utilisateur référence toutes les VM Roles disponibles, indépendamment des SCVMM. Pour éviter de présenter plusieurs fois la même ressource à nos futurs locataires, il faut reconfigurer les VM Roles avant importation pour les rendre unique. Dans le contexte que nous allons développer, nous resterons sur le scénario n°1. Ci-dessous l’architecture pressentie pour SCVMM.

clip_image001

 

On reste donc dans le simple avec pourtant une subtilité. J’ai bien de l’Hyper-V Replica mais entre deux clusters qui sont dédiés au Fabric Management. On reviendra sur ce point plus tard. Pour finir avec le design d’infrastructure, un petit rappel : Par Défaut, SCVMM est un produit qui vous veut du bien. Pensez donc à sauvegarder les clés dans l’Active Directory ?

clip_image002

 

Haute disponibilité des librairies

Avec SCVMM, il ne faut pas oublier de penser à la librairie SCVMM, ou plutôt aux librairies SCVMM. C’est un peu plus qu’un agent installé sur un serveur qui joue le rôle de serveurs de fichiers. Il en faut au moins une par Datacenter, histoire d’éviter de déployer des VDHX via le WAN. Pour répliquer le contenu, DFS-R peut paraitre le candidat idéal, mais attention à la taille du Staging Folder qui va nécessiter beaucoup d’espace disque pour préparer la réplication. Rien qu’un VHDX pour un système d’exploitation de type Windows Server 2012 R2, il faudra compter entre 15 et 17Go (en disque dynamique). Selon les guidelines de sizing DFS-R, chaque partenaire de réplication doit être en mesure de traiter la réplication de 16 fichiers entrants et 16 fichier sortants. La volumétrie disque nécessaire pour le Staging Folder peut donc être évaluée à l’aide de la taille cumulée des 32 plus gros fichiers à répliquer. A ce niveau, les fonctionnalités de réplication de stockage sont certainement plus économes. Et encore, nous ne parlons que d’une seule instance SCVMM. Une bonne raison pour continuer à se limiter à une seule instance SCVMM.

Du point de vue architecture, on va quand même utiliser DFS-R en mettant en place un groupe de réplication comprenant deux nœuds répartis entre nos deux datacenters. Après, il faut comprendre une chose, nous nous sommes assurés de la disponibilité du contenu avec DFS-R, rien de plus. DFS-N ne peut rien faire pour nous puis que c’est une communication de type BITS entre la librairie SCVMM et l’hôte Hyper-V, il n’y a aucun accès en SMB avec un chemin UNC. Donc en cas d’indisponibilité d’une librairie, tous les objets y faisant référence sont inutilisables depuis SCVMM. Travailler avec plusieurs librairies implique de travailler avec les objets équivalents. C’est un processus qui permet de déclarer manuellement des associations entre plusieurs objets que l’on va déclarer comme équivalent. Là où ça coince, c’est que c’est une fonctionnalité qui ne semble accessible que depuis la console d’administration de SCVMM, fonctionnalité pour laquelle on a pas de commande PowerShell. A ma connaissance, il n’y a qu’un seul cas ou les objets sont automatiquement déclarés comme équivalents, s’ils sont tous tagués avec les mêmes familles, versions et namespaces.

clip_image003

 

Design des Clouds SCVMM

L’infrastructure posé, rentrons dans SCVMM. Sous la notion de cloud, on va pouvoir regrouper plusieurs types de ressources (Host Groups, Logical Networks, accessoirement des Load Balancers et des VIP, du stockage, des librairies SCVMM, des politiques de capacités, …). Commençons avec les Host groups. La première chose à faire est d’isoler les ressources utilisées par le Fabric Management de celles qui seront utilisées par nos futurs locataires. Dédier un Cloud SCVMM pour le Fabric Management n’est pas sans conséquences. Certes, plusieurs Clouds SCVMM peuvent partager des ressources comme les librairies mais pour d’autres, cela pose des problèmes pour les hosts groups

Dédier un host group pour la Fabric Management est obligatoire. C’est un peu un sanctuaire. Sans lui, plus de Windows Azure Pack, donc aucun moyen pour nos locataires de consommer les ressources mises à leur disposition. Il faudra donc associer un Cluster à ce Host-group. Le problème, c’est que cette association est exclusive. Le ou les clusters Hyper-V deviendront donc réservé uniquement pour le Fabric Management. Pour ces clusters, pas la peine d’essayer de le sizer au plus court. Son indisponibilité serait bloquante pour les exploitants mais aussi pour les locataires. Pas la peine de mégoter sur le nœud de cluster pour la réserve. En plus, il faudra bien les patcher un jour ces clusters. S’il n’y a pas les ressources nécessaires pour basculer les workloads du Fabric Management, il faudra donc interrompre le service. C’est moche, surtout quand on vend qu’un cloud est censé être plus disponible que les bonnes vieilles implémentations « On-Premises ».

Plusieurs Cloud SCVMM peuvent partager les mêmes librairies sans problème. Techniquement, c’est vrai. Imaginons que vous voulions proposer à nos locataires la possibilité de faire des checkspoints de leurs machines virtuelles, ou ce contenu serait-il stocké ? Notre locataire est en droit d’attendre que les exploitants de la plateforme Cloud qu’il a retenu ne puissent pas accéder à ce contenu. Pour répondre à cette problématique, il est donc obligatoire de disposer de librairies SCVMM qui seront dédiées au Cloud SCVMM réservé à nos locataires. Si on sépare les librairies en fonction des usages (service et locataires), il faudra donc plusieurs groupes de réplication DFS-R et dédier des serveurs de fichiers pour chaque usage.

Enfin, introduire plusieurs Clouds SCVMM pour nos locataires n’est pas dénué de sens. D’une part cela contribue à proposer plusieurs niveaux de service à nos locataires (Gold, Bronze, Silver, …). Le plus intéressant ici n’est pas la technique mais bien les services proposés à nos locataires. En montant en gamme, on peut proposer de nouveaux services à nos futurs locataires :

  • Le niveau Silver pourrait ne contenir que des host groups référençant des Hyper-V, donc sans haute disponibilité
  • Le niveau Bronze introduirait la haute disponibilité en utilisant des hosts groups contenant des clusters Hyper-V
  • Le niveau Gold lui proposerait carrément la virtualisation réseau avec la NVGRE Gateway ?

 

L’approche est aussi applicable au stockage en proposant une gamme de stockage en fonction :

  • Le niveau Silver ne proposerait que du stockage local de type DAS
  • Le niveau Bronze proposerait du stockage basé sur du Scale-Out File Server
  • Enfin le niveau Gold proposerait lui du stockage géo-répliqué entre les datacenters (par exemple basé sur Storage Replica, inclus dans l’édition Datacenter de Windows Server 2016)

 

Cette approche a cependant une limitation dans Windows Azure Pack. Lorsqu’un utilisateur souscrit à un abonnement IaaS dans son portail, il lui est associé le Cloud SCVMM dans lequel il pourra consommer son service. Si demain cet utilisateur veut bénéficier du niveau de service supérieur, nous devrons migrer la souscription de l’utilisateur vers l’abonnement de niveau supérieur. Le problème, c’est que cela ne migre pas les machines virtuelles entre les clusters.

Synthétisons un peu tout cela dans un diagramme. Donc deux Cloud au sens SCVMM pour distinguer les usages et une organisation des hosts-groups en fonction des Datacenters. Pour commencer, je considère que des clusters Cross-datacenters ne sont pas à l’ordre du jour pour commencer. Il y a beaucoup d’autres choses à monter avant cela. Le modèle a l’avantage d’être simple, avec pour seule réelle limite la scalabilité de SCVMM. Du point de vue de nos locataires, j’ai retenu un seul Cloud, donc un seul niveau de service proposé.

clip_image004

 

Maintenant qu’on l’outil de management en place, peuplons-le avec des clusters Hyper-V.

 

Design des clusters

Coté cluster, on sait déjà qu’il nous faudra au moins deux clusters Hyper-V pour le Fabric Management et d’autres pour les locataires. Il reste dépendant quelques questions en suspens :

  • Combien de clusters pour le Fabric Management ?
  • Doit-on avoir des clusters inter-sites ?
  • Doit-on privilégier les grands clusters ?

 

Combien de clusters pour le Fabric Management ? Facile, tout le monde dans le même cluster ? OK mais s’il tombe, on perd tout. En plus, on est dépendant du stockage. Si on veut pouvoir survivre à la perte d’un Datacenter, c’est du stockage Geo-répliqué qu’il nous faut alors. Difficile de vendre au Business que nous allons claquer un maximum d’argent pour un service qui au final n’est pas consommé par le client final. Il en est dépendant certes mais s’il ne fonctionne pas, le fournisseur reste coupable. C’est entre autre pour cette raison que le diagramme au-dessus référence deux host-group pour le Cloud du Fabric Management. Dans cette configuration, l’impact de la perte du Datacenter n’a aucun impact sur ces clusters. Ce qui manque, c’est d’assurer la haute disponibilité des ressources hébergées. Hyper-V Replica est tout désigné pour cela. En plus, cela simplifiera grandement les opérations de patching.

Doit-on avoir des clusters inter-sites ? Le cluster Hyper-v Inter-site, donc inter-Datacenter implique de disposer d’un stockage partagé entre les datacenters. Technologiquement, c’est possible. Par contre, cela implique d’abandonner l’approche Scale-Out FileServer de Microsoft (génération Windows Server 2012 R2) pour revenir aux baies de disques avec réplication de LUN. D’un point de vue service proposés aux futurs locataires, cela avait un sens pour proposer un mécanisme de failover en cas d’indisponibilité de Datacenter. Le problème, c’est que depuis Hyper-V 2012, on dispose de la fonctionnalité Hyper-V Replica qui permet de maintenir une copie de machine virtuelle sur un autre hôte hyper-V, voire même sur un autre cluster. Au final, on a donc plus besoin de clusters inter-sites.

Doit-on privilégier les grands clusters ? Comme vu précédemment, un cluster peut être composé de 64 nœuds et héberger jusqu’à 8000 machines virtuelles. Mais doit-on aller jusque-là ? Too big to fail ? Personnellement, je vois le cluster comme un domaine de panne. L’indisponibilité d’un nœud va nécessairement avoir des répercussions sur les autres, surtout si on se trouve en situation de surconsommation des ressources (plus de Cluster Reserve). Plus grand sera le cluster, plus important sera l’effet domino en cas de défaillance d’un ou plusieurs nœuds. Autre problème des grands clusters, la maintenance. Avec des grands clusters, le niveau de parallélisation des opérations de maintenance est moins important qu’avec des clusters de taille moins importantes. Cela a donc un impact sur la fenêtre de maintenance dont on disposera pour faire le maintien en condition opérationnel de la plateforme. Pour cette raison, je préfère limiter le nombre de nœuds au sein d’un cluster. Une limite à Seize nœuds me semble un compromis acceptable.

Maintenant, pour le design même des clusters Hyper-V, c’est très dépendant de votre architecture matérielle. D’un point de vue réseau, c’est fortement lié aux capacités d’offloading de vos cartes réseau et des capacités de votre cœur de réseau à accepter du 10Gb ou du 40Gb ou mieux. Du point de vue stockage, Microsoft propose son approche avec le Scale-Out file server mais c’est peut-être du stockage préexistant au sein de votre système d’information que vous voudriez utiliser (SAN). Ou alors êtes-vous prêt à l’hyper-convergence en regroupant compute, storage et network au sein d’une même appliance comme le propose Nutanix ou Windows Server 2016? Bref trop de variables pour proposer quelque chose de générique. Aujourd’hui, il y a une tendance vers l’hyper-convergence. C’est une approche technique intéressante mais elle impliquer de revoir aussi l’organisation. Ce ne sont plus trois équipes qui seront à la manœuvre (stockage, réseau et serveurs) mais bien une seule équipe « Cloud ». Sur ce sujet, quelques lectures intéressantes de collègues MVP qui ont déjà traités ces sujets bien mieux que moi :

 

Prochaine étape SCOM.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)