Architecture WAP – Design infrastructure IAAS

Le service IaaS de Windows Azure Pack est un monde à part. C’est un sujet que j’avais déjà abordé dans la série de billet Windows Azure Pack – IaaS : Introduction. On est à la frontière entre deux mondes. Le problème, c’est que ces deux univers ne parlent pas le même langage. On a donc besoin d’un interprète. D’un côté Windows Azure Pack cause le JSON nativement et de l’autre SCVMM, ben il cause PowerShell. On ne peut pas dire que ça aide. Service Provider Foundation sera notre traducteur universel (Alias C3PO). Du point de vue de Windows Azure Pack, il sera vu comme un ensemble de Resource Provider.

clip_image001

 

Dans le diagramme ci-dessus, on constate que du point de vue de Windows Azure Pack, la seule notion qui l’intéresse, c’est celle de VM Clouds. C’est la ressource que nous allons mettre à disposition de nos futurs locataires, à savoir un Cloud SCVMM. SCOM et SCVMM sont totalement inconnus, pourtant, ils fournisseur des services. Plus précisément, le Service Provider Foundation assure la mise en place des souscriptions de ce service, son statut et son état de santé. Ça match juste avec les Resources Providers au cœur de Windows Azure Pack que nous venons de voir. Dans les faits, c’est un peu plus compliqué que cela mais pour commencer, on va se contenter de cela.

 

Windows Azure Pack n’a aucune idée de ce qu’est SCVMM. Il ne voit que la ressource mise à disposition. Derrière ce terme, il faut y voir une unité de gestion, on y reviendra plus tard. Pour l’instant, on va se concentrer sur les Resources Providers mis à disposition de Windows Azure Pack, ils sont au nombre de trois :

  • SystemCenter
  • CloudServices
  • Gallery

 

Donc on doit installer Service Provider Foundation. Le comment a déjà été traité ici : Windows Azure Pack – IaaS : Installation du Service Provider Foundation. Les questions qui nous intéressent ici c’est :

  • Ou l’installer ?
  • Comment le rendre hautement disponible?
  • Comment être sûr que ce sera scalable dans le temps ?

 

La réponse la plus évidente à la première question peut sembler facile. On peut l’installer sur l’unique instance de notre infrastructure SCVMM, c’est la solution la plus simple. Problème, adieu la haute disponibilité, idem pour la scalabilité. On n’y coupera pas, il faudra lui dédier un serveur pour notre première instance. Vu que ce sont des Web Services, pour la haute disponibilité, c’est juste une histoire de load-Balancers, voilà pour la seconde question.

clip_image003

 

Dernier point, la scalabilité. Au niveau du Service Provider Foundation, c’est une histoire de configuration matérielle. Selon le Capacity Planning for Service Provider Foundation, avec le bonne configuration on est prêt à tout :

Nombre de VM

CPU

RAM

Moins de 5000 4 cœurs 8 Go RAM
Entre 5 000 et 12 000 VM 8 cœurs 8 Go RAM
Entre 12 000 et 25 000 VM 16 cœurs 8 Go RAM

25 000 machines virtuelles, c’est aussi la limite de notre infrastructure SCVMM. Ça tombe bien. Revenons à nos Resources Providers. Pour les deux premiers (Gallery et CloudServices), il faut comprendre que le Resource Provider se limite à fournir des services au portail des locataires. Pour le dernier, c’est lui qui porte les fonctions principales du Service Provider Foundation. Si on regarde sur le serveur en question, cela correspond aux Web Services exposés, à savoir :

 

Nous avons l’interface entre Windows Azure Pack et Service Provider Foundation. La suite est assez simple puisqu’il nous reste plus qu’à déclarer notre instance SCVMM voire jusqu’qu’à cinq instances. Ce sont des sujets que j’avais déjà abordé dans cet article : Windows Azure Pack – IaaS : Intégration de Service Provider Foundation ainsi que celui-ci Windows Azure Pack – IaaS : Déclaration du VM Cloud.

Pour l’architecture IaaS, il ne nous reste plus qu’un sujet à traiter, à savoir l’accès aux machines virtuelles via RDP. Ce service est mis à disposition par la Remote Desktop Gateway. Le service repose sur la fonctionnalité « Enhanced session mode » de Windows Server 2012 R2. La fonctionnalité est intéressante car elle propose un accès RDS à la machine virtuelle via l’hôte Hyper-V. Cela signifie que même si la machine virtuelle ne dispose pas de connectivité Internet, c’est le mode console. Sous la moquette, cela ressemble à cela :

clip_image005

 

Techniquement, on utilise un certificat (avec un FQDN public) qui est présent sur :

  • La Remote Desktop Gateway
  • Virtual Machine Manager

 

Il est aussi présent sur tous les hôtes Hyper-V mais c’est SCVMM qui se charge de le mettre à disposition de tous les hôtes Hyper-V. Lorsque l’utilisateur va demander l’accès RDP à une de ses machines virtuelles, un fichier RDP sera généré et mis à disposition de l’utilisateur. Il va ensuite le présenter à la Remote Access Gateway. Normalement, le rôle de la RDS Gateway est d’authentifier les utilisateurs avant qu’ils n’accèdent aux sessions RDS. Problème, dans le contexte de Windows Azure Pack, notre RDS Gateway n’a aucune idée du fournisseur d’identité à solliciter. Le package va donc modifier le mode de fonctionnement de la RDS Gateway pour réaliser une authentification à base de certificat.

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

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Les derniers articles par Benoit (tout voir)

Laisser un commentaire

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

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.