par Tao Zhou
Pour lancer un site Web majeur, la question de sa disponibilité et de ses performances
est une considération essentielle à prendre en compte. La mise à l'échelle (ou
scaling) matérielle ou logicielle sont des stratégies possibles pour traiter les
problèmes de disponibilité et de performances. La première consiste à installer
un système multiprocesseur robuste et évolutif, par exemple un serveur à 8 voies
avec des composants matériels redondants, comme serveur Web. La seconde permet
de mettre en miroir le contenu Web sur plusieurs serveurs Web formant un cluster.
Les serveurs en cluster peuvent avoir des configurations matérielles différentes
: combinaison de systèmes anciens et nouveaux, de systèmes lents et rapides.
Au fur et à mesure que le trafic augmente sur le site, il est possible d'ajouter
des machines au cluster. Pour mettre en oeuvre le scaling logiciel, vous pouvez
utiliser un équilibreur de charge de serveur Web (également baptisé équilibreur
de charge IP), logiciel qui dirige un client vers le serveur Web le moins occupé
ou le plus approprié parmi plusieurs serveurs prenant en charge un contenu en
miroir. Par exemple, pour équilibrer et basculer le trafic du client vers un serveur
Web en cas d'incident, vous pouvez utiliser des produits comme le service NLB
(Network Load Balancing) pour Windows 2000 ou WLBS (Windows NT Load Balancing
Service) de Microsoft, le commutateur Web de Cisco Systems, ou celui de Nortel.
Bien que la mise à l'échelle logicielle soit plus facile à adopter et donne plus
de flexibilité aux applications Web, que celle matérielle, il n'est pas facile
de gérer le contenu et les applications Web entre plusieurs serveurs. Tous les
changements apportés au contenu et aux composants applicatifs doivent être déployés
sur tous les serveurs. Si le contenu des serveurs n'est pas en miroir, les utilisateurs
obtiendront des résultats différents des serveurs d'un même site Web. En cas de
panne des serveurs d'un cluster, un équilibreur de charge de serveur Web peut
rediriger les requêtes des clients vers des serveurs en bonne santé. Mais il faut
tout de même un outil pour surveiller la santé et les performances des serveurs
Pour faciliter la gestion des sites Web et des applications, Microsoft a développé
Application Center (AppCenter) 2000, qui peut synchroniser le contenu du Web et
déployer des applications COM+ entre plusieurs serveurs d'un cluster. AppCenter
peut surveiller et communiquer l'état de santé et les performances des serveurs
et du cluster. Outre l'utilisation de NLB pour équilibrer la charge des serveurs
Web, AppCenter supporte le service CLB (Component Load Balancing), que Microsoft
a retiré de Windows 2000 après la RC1 (Release Candidate 1) de la beta 3. Le service
CLB peut équilibrer la charge du niveau médian (c'est-à -dire le niveau logique
d'entreprise) des applications Windows à plusieurs niveaux. Nous allons voir comment
installer et tirer parti de la capacité d'AppCenter à mettre en cluster, équilibrer
la charge, et surveiller l'état de santé et les performances des serveurs Web.
Application Center 2000 peut synchroniser le contenu du Web et déployer
des applications COM+ entre plusieurs serveurs d'un cluster
Microsoft Application Center 2000
AppCenter tourne sous Windows 2000 Server avec le SP1 (Service Pack 1), Windows
2000 Advanced Server SP1, et Windows 2000 Datacenter SP1. Il permet de grouper
deux ou plusieurs serveurs exécutant AppCenter pour former un cluster AppCenter.
Le premier serveur configuré pour un cluster est le contrôleur du cluster. Les
serveurs ajoutés à ce cluster sont les membres du cluster. Bien que la documentation
de Microsoft ne spécifie pas de limite du nombre de membres pouvant être supportés
par un cluster AppCenter, le nombre maximum de serveurs supportés par NLB dans
un cluster est de 32. Les relations entre un contrôleur de cluster et ses membres
sont identiques à celles d’un PDC NT avec ses BDC. Tout changement effectué sur
le contrôleur du cluster (par exemple publication de contenu Web), est dupliqué
par le contrôleur sur les membres du cluster. Lorsqu’un changement intervient,
AppCenter peut automatiquement synchroniser la configuration de Microsoft IIS,
y compris celle de sites et de répertoires virtuels, des racines Web, du contenu,
des certificats de serveurs, des clés du registre, des paramètres du réseau, des
paramètres NLB et des SDN (Data Source Names) entre le contrôleur et les membres
du cluster.
En revanche, les composants COM+ et les filtres ISAPI (Internet Server API) doivent
être dupliqués manuellement d’un serveur à l’autre ou dans tout le cluster. Microsoft
appelle ce processus le déploiement. Le déploiement manuel de ces composants permet
de garder le contrôle sur les mises à jour des applications COM+ et l’intégrité
du cluster, puisque ces changements exigent de relancer le service Web sur le
serveur. Un membre du cluster peut être promu contrôleur, en cas de défaillance
du contrôleur original, et un contrôleur de cluster peut être rétrogradé au niveau
de simple membre du cluster.
Le clustering AppCenter diffère de celui de MSCS (Microsoft Cluster Service),
inclus dans NT Server 4.0 Enterprise Edition (NTS/E), et des services de clustering
inclus dans Windows 2000 Adcanced Server et Datacenter. Dans MSCS, deux noeuds
d’un cluster (jusqu’à 4 noeuds dans Datacenter) utilisent un système de stockage
partagé pour fonctionner en mode bascule en cas d’incident ou actif-passif (également
baptisé actif-sauvegarde). Un seul serveur actif répond aux requêtes des clients
et le serveur de sauvegarde n’y répond pas, sauf en cas de défaillance du serveur
primaire.
Dans AppCenter, les serveurs mis en miroir dans un cluster sont tous des serveurs
actifs traitant les requêtes des clients, distribuées par le service d’équilibre
des charges. Pour une même application (par exemple IIS) exécutée sur un cluster
MSCS à deux noeuds et un cluster AppCenter à deux noeuds, ce dernier traitera presque
deux fois plus de requêtes que le cluster MSCS. AppCenter ne remplace toutefois
pas MSCS ; il ne fournit, en effet, le clustering qu’aux serveurs Web et aux applications
COM+. Pour le clustering des applications BackOffice, il faut utiliser MSCS.
Il existe trois types de clusters AppCenter : les clusters Web, les clusters d’applications
COM+ et les clusters de routage COM+. Un cluster Web héberge des sites Web IIS
mis en miroir entre plusieurs serveurs d’un cluster. Il peut aussi héberger des
applications COM+ locales. Ce type de cluster utilise NLB pour l’équilibrage de
charge des serveurs Web IIS (on peut également utiliser un équilibreur de charge
tiers à la place) et CLB pour l’équilibrage de charge des applications COM+. Dans
un cluster Web AppCenter simple, que montre la Figure 1, ce sont les interfaces
réseaux frontales du cluster (c’est-à -dire celles qui font face à l’Internet)
qui supportent l’équilibrage de charge pour l’accès des utilisateurs externes.
Les interfaces réseau dorsales (c’est-à -dire faisant face à l’intranet) réalisent
la synchronisation du cluster et fournissent l’accès des utilisateurs internes
pour des tâches telles que la maintenance et la gestion du cluster.
Le cluster d’applications COM+ d’AppCenter n’héberge que des applications COM+
auxquelles renvoient d’autres sites Web, comme les clusters Web AppCenter, ou
les applications Windows. Par exemple, sur la Figure 2, une application COM+ est
placée au milieu d’une application multi-niveau et met en oeuvre la logique d’entreprise,
ce qui permet de décharger le traitement des objets COM+ des serveurs Web et d’améliorer
les performances. Le niveau supérieur est dédié à un cluster Web AppCenter qui
héberge les serveurs Web recevant les requêtes des clients. Le niveau inférieur
est un cluster d’applications BackOffice (par exemple Microsoft SQL Server sur
MSCS) chargées de la maintenance des données de l’entreprise.
AppCenter fournit également un cluster de routage COM+, qui achemine simplement
les requêtes vers une application COM+ dans le cluster d’applications COM+.
Téléchargez cette ressource
Microsoft 365 : 5 erreurs de sécurité
A l’heure où les données des solutions Microsoft 365 sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités ? Découvrez le Top 5 des erreurs à ne pas commettre et les meilleures pratiques recommandées par les Experts DIB France.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Le spatial dans le viseur des cyberattaquants
- Connaître son client : exploiter les API des réseaux pour offrir des services personnalisés et sur mesure
- Architecte cloud : applications de chatbot & Azure OpenAI Service
- Le LLMjacking : quand les cyberattaques utilisent illicitement des comptes LLM
- Les identités des développeurs doivent être prises en compte !