Architecture Windows Azure Pack WebSites–Introduction

Dans les “Resources Providers » de Windows Azure Pack, s’il y en a un qui mérite qu’on y passe du temps, c’est Web Sites. C’est un univers à part entière, un vrai jeu de Lego. En plus, c’est le Resource Provider qui a le plus évolué dans Windows Azure Pack puisque nous en sommes à la version 2.0 Update 6 et qu’il continue d’évoluer en permanence. On trouve déjà bon nombre d’excellents billets décrivant la mise en œuvre de l’architecture Web Sites. Cependant, la mise en œuvre a bien changé avec le passage à la version 2. C’est pour cette raison que j’ai décidé de blogger sur le sujet.

Le grand changement, c’est sa mise en œuvre qui a été simplifiée avec l’introduction de la console d’administration Windows Azure Pack Web Sites. C’est une bonne vieille console MMC. Les principaux changements apportés par cette version de Web Sites sont :

  • La désactivation de SSL v3 (sécurité oblige)
  • La prise en charge des Web Jobs pour exécuter des tâches sur les Web-Worker (comme son grand frère Microsoft Azure)
  • Intégration du production/staging site slots (comme son grand frère Microsoft Azure)
  • Prise en compte du module IIS HttpPlatformHandler pour permettre à des applications tel que Java d’écouter directement sur HTTP

Vu que l’architecture est un peu compliquée, on va prendre le temps de la détailler avant de rentrer dans le vif du sujet. Commençons par la « Big-Picture ». Ci-dessous une illustration du Technet que l’on va utiliser pour décoder un peu la bête.

clip_image001

 

Première remarque, pas une seule trace de Windows Azure Pack. C’est normal. On y viendra plus tard. Pour commencer, Windows Azure Pack Web Sites, c’est pas un simple serveur web IIS posé dans un coin. C’est une architecture complète pour de l’hébergement de sites Web / Web Services hautement disponible, multi-tenant proposant plusieurs classes d’hébergement partagé ou dédié. Pour le locataires les services proposés sont relativement proches de ceux proposés dans Microsoft Azure (je dis bien relativement proche), le tout en offrant accès à tout ce qu’on peut héberger sur IIS. La liste est longue, trop longue. Ce billet est le premier d’une série à part entière sur cette architecture. Maintenant que les présentations sont faites, entrons dans le vif du sujet. On dénombre les rôles suivants :

  • Controller Server(s)
  • Management Server(s)
  • Runtime DB Server(S)
  • File Server Server(s)
  • Front-End Server(s)
  • Web Worker Server(s)
  • Publisher Server(s)

Première remarque, ça fait du monde à caser sur ma plateforme. Ça tombe bien, en attendant Microsoft Azure Stack, j’avais rien à décortiquer cet été. Seconde remarque, on ne peut pas co-localiser plusieurs rôles sur un même serveur. Il y a des raisons techniques mais aussi des considérations sécurité dont il faut tenir compte. Conclusion, vous pouvez déjà provisionner six nouveaux serveurs sur votre architecture Windows Azure Pack, le double si on veut gérer les domaines de panne et un peu plus si la scalabilité et la performance sont au programme. Tous ces serveurs seront raccordés au domaine pour des raisons de simplicité de mise en œuvre et d’administration. Cependant, il est tout à fait possible de mettre en œuvre une architecture Websites avec des hôtes en workgroup. C’est juste plus compliqué à administrer.

Note : Si on veut pouvoir proposer le mécanisme d’authentification AD dans une infrastructure Web Sites, il est obligatoire que les instances du rôle Web Worker soient installées sur des serveurs membres du même domaine Active Directory : Enable Windows Authentication for Windows Azure Pack: Web Sites.

 

Commençons avec le rôle le plus simple et le premier que nous allons installer : Le rôle Controller. Il va lui jouer le rôle de chef d’orchestre de l’infrastructure Web Sites, organiser le déploiement de tous les rôles et assurer la mise à niveau / réparation de tous les rôles déployés. C’est aussi lui qui sera chargé de réaliser le provisioning des sites web pour le compte des locataires. Une seule instance de ce rôle suffit dans un POC. Par contre, en environnement de production, il faudra au moins en avoir deux, sachant qu’un seul est actif à l’instant T.

Le Management Server. C’est lui qui héberge les Web Services qui vont s’interfacer avec Windows Azure Pack (AdminAPI, Monitoring API, Usage API). La recommandation est d’installer ce rôle sur un / plusieurs serveurs dédiés si on veut la haute disponibilité. Ce rôle est l’interface avec Windows Azure Pack et ses API. Ne pensez même pas co-localiser ce rôle sur votre plateforme Windows Azure Pack, le résultat sera désastreux pour ce dernier.

Le Runtime DB , c’est une instance SQL dédiée qui peut être configurée en « Always On » pour assurer la haute disponibilité du rôle. C’est donc cette base de données qui va contenir toutes les informations à l’architecture Websites ainsi qu’aux sites web hébergés pour les locataires. Dans le contexte de ma maquette, j’ai hébergé cette base de données sur le serveur SQL de mon infrastructure Windows Azure Pack. C’est le seul rôle que l’on puisse mutualiser en fait.

Le rôle File server sert à stocker le contenu des Web Sites qui seront mis en place. Là où cela devient marrant, c’est que ce n’est pas sur ce serveur que les locataires viendront déposer le contenu de leurs futurs sites web. Pour cela on dispose du rôle Publisher.

Le rôle Publisher sera exposé sur Internet et fournira aux locataires plusieurs moyens (FTP, Visual Studio, Web Matrix, … ) pour déposer le contenu qui devra être mis à disposition sur le web Sites du locataire. Lorsque l’architecture Web Sites aura assigné un site IIS à un locataire, le rôle Web-Worker provisionnera le site web avec le package disponible sur le rôle File-Server. C’est WebDeploy qui sera utilisé pour cette tâche.

On parle de Web Sites, pourtant jusqu’à maintenant, on n’en voit pas beaucoup la couleur. Entrons dans le vif du sujet avec le Web Worker Role. C’est lui qui va héberger les sites Webs de nos locataires. On distinguera deux types d’instances proposant chacune plusieurs classes de performance :

  • Dedicated
  • Shared

 

Il ne nous en reste plus qu’un, le rôle Front-End. Nos instances du Web Worker Role ne sont pas directement exposées sur Internet mais au travers du rôle Front-End. C’est lui qui va être chargé de router les requêtes vers la bonne instance du Web Worker Rôle et donc le bon site web. C’est Application Request Routing qui assure cette fonction.

Voilà pour la théorie. Pour la pratique. J’ai déployé mes nouveaux serveurs dans mon infrastructure Windows Azure Pack tel qu’illustré ci-dessous :

clip_image002

 

Pour la répartition, c’est segmenté en deux grandes familles :

  • Les rôles « infrastructure » de l’architecture Web Sites
    • Les instances du rôle Web-Front exposées sur Internet ou via Reverse Proxy
    • Les instances du rôle Web-Publish exposés sur Internet ou via Reverse Proxy
    • Les instances du rôle File-Server qui elles n’ont absolument pas besoin d’être exposées sur Internet
  • Les rôles « Tenant » de l’architecture utilisés par nos futurs locataires
    • Les instances du rôle Web Worker Shared qui n’ont pas besoin d’être exposées sur internet
    • Les instances du rôle Web Worker Dedicated qui n’ont pas besoin d’être exposées sur internet

Normalement, à ce stade, j’ai perdu personne, mais c’est maintenant que cela se complique. L’architecture Web Sites est à la fois complexe et très riche. On ne pourra donc pas tout traiter en un seul billet. Voilà la liste des réjouissances prochaines :

Prêt pour une nouvelle séance de torture? Pour vous mettre dans l’ambiance, un peu de réseau. Les fans de la segmentation réseau à outrance vous pouvoir se faire plaisir ou mal, c’est selon.

clip_image003

 

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.