Présentation du déploiement d’hébergement partagé à l’aide d’Application Request Routing 2.0

Microsoft Application Request Routing (ARR) 2.0 est un module de routage de type proxy qui transfère les requêtes HTTP vers les serveurs de contenu en fonction des en-têtes HTTP et des variables du serveur, ainsi que des algorithmes d’équilibrage de la charge. Pour plus d’informations, reportez-vous à l’article Utilisation d’Application Request Routing.

Il existe une fonctionnalité appelée affinité de nom d’hôte, conçue spécifiquement pour les hébergeurs partagés. Cet article présente cette fonctionnalité et explique comment elle peut être utilisée pour déployer un environnement hautement disponible et évolutif, facile à gérer et susceptible de créer de nouvelles opportunités commerciales.

Déploiement d’un hébergement partagé commun

Vous trouverez ci-dessous le schéma d’un environnement typique de déploiement d’un hébergement partagé :

1. L’utilisateur interroge www.site2.com.
2. Le DNS est demandé pour www.site2.com.
3. L’adresse IP pour www.site2.com est retournée.
4. Le navigateur envoie des requêtes à l’adresse IP.
5. En fonction du nom d’hôte, les requêtes sont envoyées vers le site correspondant.
6. Les réponses à www.site2.com sont retournées.

Bien que le déploiement présenté ci-dessus fonctionne, il présente les inconvénients suivants :

• Il n’y a aucune redondance entre les sites.
• L’administrateur doit équilibrer la charge du trafic en limitant le nombre de sites par serveur.
• Les ressources du serveur peuvent ne pas être utilisées équitablement entre les serveurs.
• L’administrateur doit gérer plusieurs fichiers de configuration.

Hébergement partagé avec Application Request Routing

La fonctionnalité d’affinité de nom d’hôte dans Application Request Routing permet aux hébergeurs partagés de repenser la façon dont les sites sont déployés. Application Request Routing traite les requêtes, qu’elles proviennent d’un ou de plusieurs clients, auprès d’un seul serveur derrière ARR, ce qui garantit qu’un site donné ne consommera des ressources que sur l’un des serveurs. Le diagramme ci-dessous illustre cet environnement de déploiement :

1. L’utilisateur interroge www.site2.com.
2. Le DNS est demandé pour www.site2.com.
3. L’adresse IP pour www.site2.com est retournée.
4. Le navigateur envoie des requêtes à l’adresse IP.
5. La charge ARR équilibre les requêtes sur un serveur et traite les requêtes pour www.site2.com auprès du même serveur pendant la durée de vie du processus de travail correspondant.
6. Les requêtes sont envoyées à l’un des serveurs.
7. Le contenu pour www.site2.com est demandé à partir d’un fichier partagé.
8. Le contenu de www.site2.com est retourné.
9. Les réponses pour www.site2.com sont retournées.

L’environnement de déploiement ci-dessus avec Application Request Routing offre les avantages suivants pour le déploiement d’un hébergement partagé commun :

• Les requêtes sont équilibrées dynamiquement par Application Request Routing.
• L’administrateur peut mettre à l’échelle l’environnement horizontalement en ajoutant de nouveaux serveurs sans allocations de site prédéfinies.
• Les ressources des serveurs sont plus uniformément distribuées.
• Les sites disposent d’une haute disponibilité.
• Il n’y a qu’une seule configuration partagée à gérer.

Avec ARR version 1, les hébergeurs peuvent spécifier le nombre de serveurs que les sites peuvent utiliser par nom d’hôte. Cette capacité permet aux hébergeurs de positionner chaque serveur d’application comme une unité de capacité que les propriétaires de sites peuvent acheter.

Pour savoir comment utiliser l’affinité de nom d’hôte dans Application Request Routing, reportez-vous à l’article Hébergement partagé à l’aide d’Application Request Routing.