Architecture Windows Azure Pack WebSites – Etape n°3 : Mise en place du rôle Web-Worker

Derrière le Font-End, se trouve le Web-Worker. Dans mon architecture, toutes les instances de ce rôle sont localisées dans une zone réseau dédiée. Aucun besoin qu’elles soient exposés sur Internet.

clip_image001

 

Dans une infrastructure Web Sites, nous savons déjà qu’il y a deux types de Web-Worker :

  • Dedicated
  • Shared

La différence tiens au niveau de l’isolation entre les locataires. Avec une instance Shared, plusieurs locataires se partagent une même instance du rôle Web-Worker. L’isolation est assurée par Internet Information Services en isolant chaque locataire dans un site web dédié. Avec une instance Dedicated, c’est beaucoup plus simple puisque le serveur web est dédié à un unique locataire. C’est un choix que nous allons pouvoir proposer à nos locataire.

On va commencer par provisionner une instance Shared depuis la console Windows Azure Pack Web Sites. l’instance Web-Worker reposera sur une machine virtuelle avec les caractéristiques suivantes :

  • Socle : Windows Server 2012 R2 de préférence raccordé au domaine
  • Rôles & Fonctionnalités : Framework Dot.Net 3.5.1 installé (attention, y a un piège)
  • Présence du certificat *.Websites.Windowsazurepack.fr (avec clé privée)
  • UAC : Désactivé
  • Compte WAP\FT-WAP-WEB02 membre du groupe local administrators

Quelques règles de pare-feu entrantes :

  • Protocole « Windows Management Instrumentation (WMI-In) »
  • Protocole WINRM (HTTP TCP 5985)
  • Protocole WINRM (HTTPS TCP 5986)
  • Protocole Web Farm Framework Agent (TCP 8173)
  • Protocole Dynamic WAS Service (TCP 8676)
  • Protocole « Worker Management Endpoint » (TCP 456)
  • Protocole HTTP

 

Note : Selon les informations issues de l’article Capacity Planning for Windows Azure Pack: Web Sites, il faut considérer que :

  • Le système va consommer au minimum 1.2Go de mémoire vive, le reste étant dévolu aux Web Sites
  • La pagination est à proscrire
  • Seulement 5% des sites web sont actifs à l’instant T, seuls eux consomment
  • Le nombre de sites web hébergés ne doit pas dépasser 20 fois le nombre de sites web actifs
  • La consommation moyenne d’un site web est de 70Mo
  • La quantité de mémoire nécessaire pour héberger se calcule selon la formule suivante : Number of Provisioned web sites * 70MB * 5% – (Number of Web-Worker Roles * 1044 MB)
  • La recommandation est d’avoir au minimum deux instances du rôle Web-Worker en mode Shared

 

C’est maintenant que cela commence à se compliquer. Jusqu’à maintenant, on savait que le rôle Web-Worker pouvait être Shared ou Dedicated (Reserved). C’est une question de sizing. On va commencer petit joueur et déclarer une instance Shared. Depuis la console Microsoft Azure Pack Websites nous allons demander le déploiement de notre première instance de Web-Worker.

clip_image002

 

Vu la liste de composants à installer, on comprend que le processus va être relativement long : clip_image003

 

Comme pour les rôles précédents, le contrôleur met à disposition le fichier XML ainsi que le repository préalablement téléchargé. Après avoir installé et configuré tous ces composants, notre instance du rôle Web-Worker va redémarrer et s’annoncer comme opérationnelle (Si au moins une instance du rôle Front-end est opérationnelle). A la fin, la console Windows Azure Web Sites doit ressembler à l’illustration ci-dessous :

clip_image004

 

Note : Si aucune instance du rôle Font-end n’est opérationnelle, l’ajout d’une instance du rôle Web-Worker fonctionne mais elle ne démarre pas. C’est normal, c’est le rôle Font-end qui est chargé de fournir un certain nombre d’informations pour finaliser la configuration.

 

Un peu de PowerShell pour la fin histoire de vérifier que notre rôle est bien provisionné.

Get-WebSitesServer | Where {$_.role -eq « WebWorker » }|Select Name, Status, PlatformVersion | Format-Table -Autosize

clip_image005

 

Ça nous fait une seule instance pour le rôle Web-Worker. Or, il nous faut une seconde instance afin de pouvoir proposer le service en haute disponibilité. j’ai donc préparé un serveur supplémentaire pour notre seconde instance. Un peu de PowerShell et c’est joué.

New-WebSitesServer -Name webworker02.windowsazurepack.lan -ServerType « WebWorker »

clip_image006

 

Note : Ce n’est pas précisé mais c’est bien une instance Shared qui a été mises en œuvre. La variable « IsDedicated » est à False.

 

On peut constater que l’installation est en cours avec la commande PowerShell suivante :

Get-WebSitesServer | Where {$_.Name -eq « webworker02.windowsazurepack.lan »}

clip_image007

 

Après un peu de patience et un reboot, une nouvelle exécution de la commande « Get-WebSitesServer | Where {$_.role -eq « WebWorker » }|Select Name, Status, PlatformVersion | Format-Table -Autosize », nous indique la disponibilité de deux instances deux instances du role WebWorker opérationnelles.

clip_image008

 

Pourquoi avoir deux instances du rôle Web-Worker me direz-vous? Pour le vice? Aussi, mais c’est surtout pour la disponibilité et gérer les domaines de panne de notre infrastructure. En cas d’indisponibilité d’une des deux instances, il est facile de déplacer les sites web sur l’instance restante et de rediriger les requêtes entrantes depuis les instances du rôle Front-end. C’est pratique lorsqu’on va patcher / reconstruire une instance, voire procéder à la mise à niveau de l’architecture Web Sites. On sera en mesure de procéder en Rolling-upgrade sans interrompre le service.

 

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!

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.