IIS 6.0 : Une nouvelle génération de serveur Web
par Sami Jaber (jaber@ifrance.com)
Introduction
Lors de la dernière conférence Fusion2002 réunissant
Microsoft et ses partenaires à Los Angeles (Californie), le voile a été levé sur
la nouvelle mouture du désormais célèbre serveur Web de Microsoft : Internet
Information Server 6.0. A cette occasion, les brèves démonstrations
réalisées par les ingénieurs de Redmond nous ont permis de découvrir les
multiples améliorations apportées au noyau d'IIS associé au futur système
d'exploitation maison : .NET Server Standard Edition.
Ces améliorations touchent principalement :
- Les performances et la robustesse avec une
architecture basée sur les Processus d'écoutes ou Workers Processes
- L'Administration : simplifiée à l'aide d'XML
- La Sécurité et la fiabilité
- L'intégration native du Framework .NET
Cet article se propose donc de vous présenter ces différentes
caractéristiques en insistant particulièrement sur les plus importantes d'entre
elles. Cet article a été réalisé à l'aide de la version Release Candidate 1 de
.NET Server Standard Edition, il est donc probable qu'à l'avenir certaines des
fonctionnalités énumérées ici soient amenées à évoluer.
L'architecture IIS 6.0
Les défauts du mode d'isolation de IIS 5.0
IIS 5.0 comporte un inconvénient majeure lié à son mode de
fonctionnement. En effet, la totalité de l'environnement d'exécution ou Runtime
du serveur Http est situé dans un seul et même processus : inetinfo.exe.
Le rôle de inetinfo.exe consiste à traiter les requêtes clientes et à les
renvoyer vers un autre processus chargé d'encapsuler une application Web donnée
: dllhost.exe. A l'heure actuelle, il existe trois modes de fonctionnement
proposés par l'interface graphique d'IIS lorsque vous créez une Application Web.
-
Protection basse : Signifie que les applications Web
et le serveur HTTP partagent le même processus, en l'occurrence, inetinfo.exe.
Avantages : Aucun changement de contexte n'est nécessaire, très
performant.
Inconvénients : En cas de défaillance d'une application donnée, le
serveur HTTP subit l'avarie lui aussi.
-
Protection haute : Signifie que les applications Web
sont totalement isolées du serveur HTTP par le biais d'un processus externe
DllHost.exe associé à chaque Application.
Avantages : Séparation claire entre applications Web et serveur HTTP.
Inconvénients : Peu performant car nécessite constamment de réaliser un
changement de contexte inter-processus (swap). Très gourmand en mémoire.
-
Protection moyenne : C'est le mode par défaut. Un
seul processus DllHost.exe est chargé d'encapsuler l'ensemble des WebApps.
Cela signifie que l'isolation entre applications n'est pas assurée. Si ce mode
constitue aujourd'hui le meilleur rapport performances/coût, il présente un
inconvénient certain pour un fournisseur d'accès dont les serveurs hébergent
de multiples Application Web. En effet, la stabilité de chaque application est
liée à celle des autres.
En mode Protection moyenne toutes les applications Web
demeure isolées l'une de l'autre. Malgré tout, il est difficile, voire
impossible pour le service d'administration inetinfo.exe de garder un oeil sur
le cycle de vie de chaque application. En cas de défaillance d'une WebApp, le
serveur ne peut relancer de manière ciblée l'application en défaut car DLLHost.exe
(appelé aussi surrogate) est un processus vu de manière totalement externe pour
inetinfo.exe.
Microsoft ayant intégré les limites de ces différents mode de
fonctionnement, IIS6 propose donc une nouvelle orientation en terme
d'architecture se rapprochant plus du mode "protection haute", mais sans ces
inconvénients. Quoi de neuf dans IIS 6.0 ?
L'un des changements les plus importants concerne la
sécurité. Afin de se prémunir contre les attaques malveillantes, IIS est
installé par défaut en mode Lockdown. Cela signifie que lors de la première
installation, tous les services dynamiques sont inhibés à l'instar du
filtre ASP.NET autorisant l'exécution de requêtes aspx. Il faudra explicitement
que l'utilisateur active ces options pour être en mesure d'utiliser pleinement
les fonctionnalités dynamiques d'IIS 6.0.
L'autre changements concerne la mise en place d'une
architecture à base de processus d'écoutes ou workers processes destinés
à résoudre un certain nombre de problèmes liés aux performances mais aussi à
l'isolation des applications Web. Il est dorénavant possible d'arrêter et de
relancer certaines applications sans interférer sur les autres.
Enfin, la dernière nouveauté concerne l'administration et la
métabase d'IIS. Il est désormais possible de sauvegarder l'ensemble des
métadonnées et informations de configurations du serveur Web dans des fichiers
au format XML. Ces opérations peuvent être spécifiées soit de manière
programmatique, soit directement à partir de l'interface d'administration (MMC).
Séparation des rôles
IIS 6 sépare clairement les différentes
attributions en terme d'exécution. Le serveur HTTP, par le biais du processus
Http.sys s'exécute en mode noyau lui permettant de bénéficier des
ressources du système d'exploitation. Toutefois, l'ensemble des applications Web
s'exécuteront comme des processus utilisateur classiques possédant des droits
restreint. Ainsi, la séparation des rôles devient beaucoup plus clair et si par
mésaventure, une WebApp venait à effectuer une opération non conforme (Buffer
overflow par exemple), non seulement le serveur HTTP resterait actif, mais une
simple réallocation de Worker Process suffirait à lui redonner la main.
Inversement, avec un tel système, si le processus
HTTP.sys venait à subir une défaillance quelconque, le système d'exploitation
prendrait aussitôt soin de le relancer sans produire d'effet de bord sur les
Applications Web existantes. Seules les requêtes situées dans la file d'attente
seraient perdues. Il faut avouer que ces caractéristiques constituent des
avancées majeures par rapport à l'architecture existante d'IIS 5.0.
Les processus d'écoutes ou Workers Process
Qu'est-ce que c'est ?
Les processus d'écoutes ne constituent pas en soi une réelle
nouveauté au sein des architectures de serveur Web. Ainsi, Apache dans sa
dernière version utilise déjà une forme de Worker Process. Dans l'approche de
Microsoft, l'originalité provient des conditions dans lesquelles ces processus
d'écoutes peuvent être configurés. Mais avant d'aller plus loin, attardons nous
sur le principe même des Worker Process d'IIS.
Lorsqu'une requête HTTP est reçue par le listener HTTP.sys,
après s'être assuré de sa validité, il vérifie si d'éventuelles données en cache
sont susceptibles de répondre à la demande en question. Si la demande est
valide, la réponse est envoyée par le serveur en se basant sur les données en
cache. Le cas échéant, le processus HTTP.sys associe à la requête la file
correspondante à chaque Processus d'écoute ou Worker Process pour l'application
donnée. Si le processus d'écoute n'est pas disponible ou simplement
n'est pas lancée, HTTP.sys le signale directement au service d'administration (WAS)
qui prend l'initiative de le démarrer sur la base des paramètres de
configuration situés dans la métabase d'IIS.
Les groupes de processus ou "Web Garden" (Jardin Web :-))
permettent de répartir des Applications Web par affinité de Processeur dans le
cadre d'architectures SMP. Un processeur donné sera chargé de répondre aux
requêtes à destination d'une même application.
Revenons à notre scénario d'exécution, lorsqu'un Worker
Process est disponible pour répondre à la demande, il récupère la requête
cliente de la file et la traite via le filtre ISAPI ou l'extension Web
correspondante. La réponse est ensuite redirigée vers HTTP.sys qui se charge de
la renvoyer au client en ayant préalablement pris soin de l'insérer en cache.
Le but du module d'administration d'IIS est aussi de
monitorer les workers processes afin de vérifier s'ils sont toujours actifs.
Ainsi, lorsqu'un processus n'a pas répondu dans un temps bien déterminé, la
requête est re-émise et re-attribuée en accord avec HTTP.sys.
Voici l'architecture globale d'IIS 6.0 telle qu'illustrée précédemment.
Configurer les processus d'écoute en fonction de ses besoins
Les processus d'écoutes sont non seulement une manière élégante de traiter le
problème de l'isolation des applications, mais ils permettent aussi d'assurer la
fiabilité d'un site. A cet égard, IIS propose plusieurs paramètres de
configuration permettant de prendre des mesures spécifiques, par exemple :
- Relancer une WebApp lorsqu'elle atteint un niveau de saturation CPU
donné (100%, 90%, ...). Cette option est l'une des plus intéressantes car
elle permet de soulager une machine lorsqu'un ou plusieurs traitements
sollicitent de manière exagérée le processeur. Cela permet en outre de déceler
un comportement anormal dans une application donnée.
- D'attribuer par Application Web une bande passante réseau déterminée.
Cette option ouvre la voie à la mise en place d'une facturation par service.
De nouveaux modèles économiques sont peut-être en train de voir le jour.
- De relancer une WebApp au delà d'un certain nombre de requêtes.
Cette option nous paraît quelque peu douteuse. Se baser sur un nombre précis
de requêtes pour relancer un site ne peut-être qu'aléatoire à moins de
disposer de certaines limitations en terme de pool de connexion ou d'accès à
des ressources quelconques. Il est fort probable que cette option soit l'une
des moins utilisées.
- De relancer une WebApp à une date ou une heure bien précise dans la
journée. Certains sites imposent une maintenance journalière programmées à
certaines heures de la journée. Dans ce cas, cette option sera d'un grand
secours. Rappelez-vous, il est désormais possible d'arrêter un site sans
perturber le fonctionnement des autres. De cette manière, lorsque seule une
application donnée requiert d'être arrêtée pour une opération de maintenance,
les autres continueront à fonctionner sans problème.
- De relancer une WebApp lorsque le processus consomme énormément de
mémoire vive ou virtuelle. Qui n'est jamais tombé sur ce cas d'école, un
processus aspnet_wp.exe consommant de plus en plus de mémoire jusqu'à arriver
à saturation. En règle général, dans ce genre de situation, l'administrateur
prie très fort en espérant que les WebApps concernées libèreront à un moment
ou à un autre la mémoire allouée. Désormais, il sera possible d'automatiser
cette tâche en activant simplement cette option.
- De restreindre l'utilisation des ressources du serveur par une WebApp
donnée. Cette option permet d'attribuer un certain nombre de workers
processes à une Application donnée. Ce paramètre est donc lié à la
fréquentation de votre site. A vous de trouver le bon rapport entre mémoire
utilisée et réactivité attendue pour la réponse. Les personnes ayant déjà eu
l'habitude de paramétrer des pools de connexion destinées à des bases de
données devront adopter la même démarche dans ce cas précis.
- De pinger régulièrement une WebApp et la relancer automatiquement en
cas de défaillance. Ce mécanisme est aussi appelé "Watch Dog Process", les
systèmes d'exploitation tels que Windows 2000 ou XP fournissaient déjà ce type
de service mais uniquement dans le cas de services (IIS, Ftp, ...). Dorénavant
ce mécanisme s'appliquera aussi dans le cas d'applications Web.
Toutes ces options réunies permettent de contrôler très
finement le cycle d'exécution des Applications situées sur un même serveur HTTP.
Non seulement il est possible d'assurer une certaine qualité de service par
WebApp, mais l'administrateur a aussi la possibilité de prendre des mesures
rapides lors de défaillances. A noter que le Framework ASP.NET installé
aujourd'hui sur l'ensemble des OS Windows propose déjà dans la section
ProcessModel du fichier Machine.config la plupart de ces options.
Malheureusement, le mode de fonctionnement actuel d'IIS 5.0 avec un seul Worker
Process (wp_aspnet.exe) ne permet par de tirer pleinement partie des
caractéristiques de ce modèle. A l'avenir, la vigilance est de mise car la
configuration de IIS 6.0 prévaudra sur celle du Framework.
Pour résumer, jusqu'alors les systèmes d'exploitation se
chargeaient simplement de d'arrêter et de relancer le processus IIS en cas de
défaillance. Dorénavant, il ne sera plus question d'arrêter entièrement un
serveur mais plutôt d'agir directement sur les applications Web concernées. Les
fournisseurs d'accès verront assurément d'un bon oeil ces améliorations
permettant enfin à IIS de rivaliser avec son grand rival de toujours : Apache.
Les Sessions ASP.NET doivent être persistantes
La plupart des applications ASP.NET destinées à tourner sous
IIS 6.0 devront prendre certaines mesures particulières car ils peuvent
désormais prétendre à subir un arrêt de Worker Process. Bien entendu, il
appartient à l'administrateur système de prendre des mesures adaptées afin
d'éviter ce genre de situation car l'arrêt des Processus d'écoute provoquera
fatalement la perte de toutes les informations contenues dans les Sessions HTTP
des utilisateurs.
Prenons un exemple, imaginez un site de vente en ligne pour
des voitures de luxe. Monsieur GIL, après s'être authentifié à partir de la page
de connexion s'apprête à passer commande de la dernière Ferrari DTI 110 Ch dont
il rêve depuis toujours. Alors qu'il s'apprête à valider son achat s'élevant à
200 K€, il reçoit un message du serveur lui indiquant qu'il vient subitement
d'être déconnecté. Le Worker Process atteignant 90%, la limite configurée par
l'administrateur pour son Application Web vient d'être atteinte, il est donc
recyclé.
Si pour certains sites, le dommage est insignifiant car la
Session ne contient aucune information capitale, pour d'autres, le prix à payer
pourra être considérable. C'est pourquoi, pour ceux là, il convient de prendre
certaines précautions afin de rendre la Session persistante dans une base de
données ou en utilisant simplement le service ASP_State.
Il est à noter que ce type d'architecture faisant appel à des
workers processes seront amenés à se généraliser à l'avenir. C'est pourquoi il
apparaît plus que jamais nécessaire de bâtir des applications Web utilisant des
Sessions persistantes. Non seulement ils permettent de s'affranchir des arrêts
intempestifs du serveur mais ils constituent un socle parfait pour la mise en
place de WebFarms ou Cluster de serveurs.
L'administration de la métabase
L'administration a été totalement revisitée. IIS propose ainsi une métabase
au format XML configurable via l'interface graphique ou directement au niveau du
fichier Metabase.xml. Par ailleurs, l'utilisateur peut à tout moment revenir
sur une ancienne configuration et effectuer un Rollback des paramètres courants
suite à une panne ou lors d'une restauration. Toutes ces opérations peuvent être
réalisées de manière programmatique à l'aide des API Admin Base Objects (ABO),
WMI et ADSI ou directement via la console MMC.
Le code suivant illustre en JScript la manière d'agir sur la configuration d'IIS
:
var vdirObj = GetObject("IIS://localhost/W3svc/1/Root");
// Print out the current value of some properties:
WScript.Echo("Before: " + vdirObj.property_name_1 + ", " + vdirObj.property_name_2);
// Set some properties:
vdirObj.Put("property_name_1", numeric_or_boolean_value);
vdirObj.Put("property_name_2", "string_value");
// Save the property changes in the metabase:
vdirObj.SetInfo();
WScript.Echo("After: " + vdirObj.property_name_1 + ", " + vdirObj.property_name_2);
Modifier la configuration "à chaud"
Le fichier Metabase.xml d'IIS peut-être modifié alors que l'ensemble des
applications sont en cours d'exécution. Ce système est appelé "Edit-While-Running"
et peut-être activé ou désactivé par l'administrateur.
De plus, IIS garde un historique de toutes les modifications effectuées sur
les paramètres de la métabase. A ce titre, comme n'importe quel autre outil de
gestion de configuration, il est possible d'annuler ou d'intervertir certains
changements de configuration.
Microsoft a énormément travaillé sur les aspects d'administration car ils
représentent le tendon d'Achille de la plupart des serveur Web. Lorsque le
nombre de sites à héberger est supérieur à une dizaine ou une vingtaine avec
chacun possédant des spécificités particulières (sécurité, répertoires
racine,..), il est difficilement envisageable d'effectuer ces opérations de
manière manuelle. Là encore, nul doute que les fournisseurs d'accès apprécieront
ce type de fonctionnalité destinées à faire d'IIS 6.0 un vrai serveur de
production. Identité IIS 6.0 vs. Identité IIS 5.0
Les Workers processes utilisent une identité différente de celle d'IIS 5.0.
Les applications actuelles qui attendent une identité de type
IWAM_ComputerName seront impactées par ces changements. IIS 6.0 utilise
l'identité des Workers processes représentée par le compte NetWork Service
directement à partir de la console IIS. Groupe IIS_WPG et Comptes prédéfinis
Le groupe prédéfinit IIS_WPG fait dorénavant partie de la sécurité d'IIS
6.0. Ce groupe fournit un ensemble de privilèges minimum requis par l'ensemble
des Processus d'écoute. Il évite ainsi d'avoir à assigner manuellement des
droits pour chaque compte. Par ailleurs, IIS 6.0 vous autorise à utiliser les comptes prédéfinis
Network Service, System et Local comme identité des Pools
d'applications. Par défaut, ces comptes sont intégrés dans le groupe IIS_WPG
possédant les droits du compte le plus faible en terme de sécurité.
Autres fonctionnalités ...
Diverses améliorations font aussi leur apparition telles que le vérificateur
d'URL : URLScan permet ainsi de filtrer les tentatives d'intrusion type Buffer
Overflow. La nouveauté réside dans la possibilité d'activer et désactiver une
extensions Web particulière.
Conclusion
Pour une fois, Microsoft a innové beaucoup plus sur le fond
et moins sur la forme. Si IIS 6.0 possèdent exactement la même interface
graphique que son prédécesseur, l'environnement d'exécution, lui, a
considérablement évolué avec une architecture entièrement basée sur les
Processus d'écoutes permettant de mettre en place une séparation claire entre
Applications Web et noyau du serveur HTTP. Il va sans dire qu'IIS 6.0 marque un
tournant dans l'histoire des serveurs Web de Microsoft. IIS 6.0 est plus
robuste, plus fiable et notamment plus sécurisé. Tous les ingrédients sont
désormais réunis pour lui permettre d'affronter l'ennemi juré de toujours :
Apache. Enfin, si le multi-threads a marqué une génération entière de
serveur Web, il semble aujourd'hui acquit à la lueur des évènements que la
plupart des produits du marché semblent s'orienter vers un chemin inverse :
celui du multi-processus. Dans cette optique, Microsoft apparaît plus armé que
jamais avec sa notion de domaine d'application. Ceux-ci permettent de
s'affranchir des limites des processus tout en proposant un modèle efficace pour
la montée en charge. Reste une dernière lacune à combler, celle de la
crédibilité de l'éditeur de Redmond face à un marché ayant vu ressurgir
récemment les fantômes du passé. De multiples failles de sécurité ont été
découvertes ces derniers temps affectant aussi bien Apache que IIS.
Auteur : Sami JABER
Copyright : DotNetGuru Aout 2002 ©
Pour en savoir plus ...
IIS 6 Administration
Auteur : Mitch Tulloch
Binding: Hardcover
Editeur: McGraw-Hill Osborne
Prix : Environ 50€
ISBN: 0072194855
IIS 6.0 Pocket Consultant
Auteur: William R. Stanek
Pages : 400
Niveau : Tout niveaux
Date de publication : 04/02/2003 (et oui)
ISBN 0-7356-1560-8
http://www.dotnetguru.org/articles/Previews/IIS6Preview.htm
| 
SharePoint
au
Quotidien
avec
EROL
