Obtention d’une haute disponibilité et d’une scalabilité - ARR et NLB

par Won Yoo

Obtention d’une haute disponibilité et d’une scalabilité :
Microsoft Application Request Routing (ARR) pour IIS 7.0 et versions ultérieures et Network Load Balancing (NLB).

Microsoft Corporation
Auteurs : Ahmed Bisht, Won Yoo
Date de publication : 13 novembre 2008

Abstract

Ce document fournit des conseils prescriptifs sur la façon dont Application Request Routing (ARR) peut être utilisé avec Network Load Balancing (NLB) pour obtenir une haute disponibilité et une scalabilité.

Vue d’ensemble

Microsoft Application Request Routing (ARR) pour IIS 7.0 et versions ultérieures est un module de routage basé sur proxy qui transfère les requêtes HTTP aux serveurs de contenu en fonction des en-têtes HTTP, des variables de serveur et des algorithmes d’équilibrage de charge. Un déploiement ARR classique est illustré dans le diagramme ci-dessous :

Bien que ARR offre une haute disponibilité et une scalabilité pour les serveurs de contenu, le déploiement global n’est pas hautement disponible ou évolutif, car :

• ARR est le point de défaillance unique.
• L’extensibilité des serveurs de contenu est limitée par la capacité maximale d’un serveur ARR.

Pour surmonter ces défis, les administrateurs peuvent envisager d’utiliser plusieurs serveurs ARR avec l’équilibrage de charge réseau (Network Load Balancing - NLB). ARR peut être déployé en mode actif/passif pour atteindre uniquement la haute disponibilité ou en mode actif/actif pour atteindre la haute disponibilité et la scalabilité. Ce livre blanc décrit comment ARR et NLB peuvent être déployés ensemble pour activer les scénarios ARR principaux tout en obtenant une haute disponibilité et une scalabilité globales. NLB est disponible sur toutes les références SKU de Windows Server 2008.

Utilisation de Application Request Routing et de Network Load Balancing

ARR est créé en tant que module sur IIS et est conçu pour prendre les décisions de routage au niveau de la couche 7 (application). Plus précisément, ARR s’appuie sur un autre module IIS, réécriture d’URL, pour inspecter les en-têtes de requête HTTP entrants et les variables de serveur pour prendre les décisions de routage. Étant donné cette conception, les administrateurs peuvent écrire des règles d’acheminement intelligentes en fonction des informations au niveau de l’application, telles que :

• Nom d’hôte (HTTP_HOST) : routez le trafic vers différents serveurs de contenu en fonction du nom d’hôte.
• Ressource demandée (URL) : en fonction des extensions de fichier, déterminez si les ressources demandées sont destinées au contenu statique ou au contenu dynamique et routez les requêtes en conséquence.
• Informations client (HTTP_USER_AGENT) : en fonction du type et de la version du navigateur, routez les requêtes vers les serveurs de contenu appropriés.
• En-têtes personnalisés (définir en tant que cookie par applications) : routez le trafic en fonction des informations de cookie définies par les applications, telles que la préférence utilisateur ou l’ID utilisateur.

Voici quelques-uns des exemples ci-dessus. Pour obtenir la liste complète des en-têtes HTTP et des variables de serveur, reportez-vous à l’Annexe A.

Étant donné que NLB prend les décisions de routage au niveau de la couche 3, les informations spécifiques à l’application, telles que les en-têtes HTTP et les variables de serveur, ne peuvent pas être utilisées pour fournir un routage basé sur l’application. En même temps, ARR ne fournit pas de fonctionnalités de déploiement à tolérance de panne pour elle-même et doit s’appuyer sur d’autres technologies et solutions complémentaires pour obtenir une haute disponibilité pour le niveau ARR. NLB fonctionne à un niveau différent sur la pile réseau et est activé sur les mêmes serveurs que l’emplacement où ARR est déployé :

Scénario 1 : routage basé sur HTTP et équilibrage de charge

Le scénario d’équilibrage de charge et de routage basé sur HTTP active une architecture de déploiement à 3 niveaux qui implique :

• Niveau 1 (Web) : fournit deux objectifs de traitement du contenu statique et du routage et de l’équilibrage de charge des requêtes dynamiques restantes sur les serveurs de niveau 2.
• Niveau 2 (Application) : traite le contenu dynamique qui s’appuie sur la logique métier.
• Niveau 3 (Données) : stocke les données.

Le diagramme suivant illustre le déploiement à 3 niveaux :

Bien que l’exemple ci-dessus montre une règle d’acheminement qui différencie le contenu statique du contenu dynamique, un autre scénario courant consiste à différencier les requêtes de présentation des requêtes de service web.

Option1 : Actif/passif

En mode actif/passif, il existe généralement deux serveurs ARR dans lesquels un serveur traite les requêtes tandis que l’autre est un serveur de basculement. Comme indiqué ci-dessus, si cette configuration permet d'obtenir une haute disponibilité en supprimant le point de défaillance unique, elle ne constitue pas une solution d'extension puisque la capacité globale des serveurs de contenu est limitée par la capacité maximale d'un serveur ARR.

Dans cette configuration, étant donné que deux serveurs ARR sont configurés de la même façon, une configuration partagée est utilisée. Tout d’abord, installez ARR sur les deux serveurs, puis créez le cluster NLB. Le cluster NLB est configuré pour accepter le trafic sur un seul des nœuds du cluster. Pour ce faire, configurez les règles de port du cluster avec un mode de filtrage d’hôte unique. Le nœud acceptant le trafic est déterminé par le paramètre de priorité de l’hôte des nœuds du cluster NLB. Pour plus d’informations, reportez-vous à la configuration NLB.

À l’exception de la fonctionnalité d’affinité de nom d’hôte dans ARR, il n’existe aucune information d’état d’exécution qui doit être partagée entre les deux serveurs ARR. Par conséquent, pour ce scénario, aucune configuration spéciale n’est nécessaire sur ARR ou NLB. Même si vous utilisez la fonctionnalité d’affinité du serveur dans ARR, les informations d’état affinités sont mises à la disposition du serveur passif via un cookie dans l’en-tête de requête.

Ce scénario est entièrement pris en charge dans la version 1 d’ARR.

Configuration ARR

Étape 1 : Activer la configuration partagée sur deux serveurs ARR.

• Suivez les étapes de ce document pour mettre en place une configuration partagée dans IIS.

Étape 2 : Configurer l’architecture de déploiement à 3 niveaux à l’aide d’ARR.

• Suivez les étapes de ce document pour configurer ARR dans l’architecture de déploiement à 3 niveaux.

• À un niveau élevé, le document ci-dessus décrit :

  • Comment rendre le contenu statique disponible sur le serveur ARR.
  • Comment écrire des règles de réécriture d’URL pour le contenu statique afin qu’elles soient traitées directement à partir du serveur ARR.
  • Comment écrire des règles de réécriture d’URL pour le contenu dynamique afin qu’elles soient transférées aux serveurs d’applications.

Configuration NLB

La configuration NLB est divisée en plusieurs étapes :

1. Installez la fonctionnalité NLB sur tous les serveurs ARR.
2. Créez un cluster NLB pour ARR.
3. Configurez NLB pour le déploiement actif/passif.

Installer la fonctionnalité NLB sur tous les serveurs ARR

1. Ouvrez Gestionnaire de serveur.
   
2. Développez Fonctionnalités.
3. Cliquez sur Ajouter des fonctionnalités.
4. Dans l’Assistant Ajout de fonctionnalités, sélectionnez Network Load Balancing.
   
5. Cliquez sur Installer pour confirmer l’installation de la fonctionnalité NLB.
   
6. Vérifiez que la fonctionnalité NLB est installée correctement.
   
7. Répétez les étapes ci-dessus sur tous les serveurs ARR.

Créer un cluster NLB pour ARR

1. Vérifiez que NLB est installé sur toutes les instances de serveurs ARR.
2. Accédez à Démarrer > Tous les programmes > Outils d’administration, puis ouvrez Network Load Balancing Manager.
   
3. Cliquez avec le bouton droit sur Clusters Network Load Balancing, puis cliquez sur Nouveau cluster.
   
4. Dans la boîte de dialogue Nouveau cluster, dans la zone de texte Hôte, tapez l’adresse du serveur de l’un des serveurs ARR. S’il existe plusieurs interfaces, tapez l’adresse du serveur sur laquelle vous souhaitez créer le cluster NLB.
   
5. En mode actif/passif (mode hôte unique en NLB), la priorité détermine l’ordre dans lequel le basculement a lieu. Par défaut, le serveur avec la priorité 1 est le nœud actif.
   
6. L’adresse IP du cluster, une adresse IP virtuelle, est nécessaire. Cliquez sur Ajouter. Il s’agit de l’adresse IP avec laquelle les clients communiquent.
   
7. Tapez l’adresse IP virtuelle, puis cliquez sur OK.
   
8. Sélectionnez Suivant.
   
9. Acceptez la valeur par défaut. Pour plus d’informations, reportez-vous à l’Annexe.
   
10. Cliquez sur Terminer pour terminer la création du cluster NLB.
    
11. Maintenant que le cluster NLB est créé, vous pouvez ajouter des membres supplémentaires au cluster. Suivez les étapes restantes sur tous les serveurs membres supplémentaires. Dans Network Load Balancing Manager, cliquez avec le bouton droit sur le cluster nouvellement sélectionné, puis sélectionnez Ajouter un hôte au cluster.
    
12. Tapez l’adresse du serveur du membre à ajouter. S’il existe plusieurs interfaces, sélectionnez celle qui doit être utilisée par le cluster NLB.
    
13. Notez que l’attribution de priorité est mutuellement exclusive et unique parmi les serveurs membres du cluster. En mode actif/passif (mode hôte unique dans NLB), la priorité détermine l’ordre de basculement.
    
14. Cliquez sur Terminer pour ajouter le serveur membre au cluster.
    
15. Network Load Balancer Manager doit ressembler à ce qui suit :
    

Configurer NLB pour le déploiement actif/passif

1. Pour configurer NLB pour le déploiement actif/passif, dans Network Load Balancing Manager, cliquez avec le bouton droit sur le cluster, puis sélectionnez Propriétés du cluster. Cliquez sur l’onglet Règles de port. Cliquez sur Modifier.
   
2. Sélectionnez Hôte unique, puis cliquez sur OK.
   

NLB est configuré avec succès pour fonctionner en mode actif/passif avec ARR.

Option2 : Actif/actif

En mode actif/actif, vous pouvez avoir deux serveurs ARR ou plus. Cette configuration obtient à la fois une haute disponibilité et une scalabilité, contrairement au mode actif/passif, qui n’atteint que la haute disponibilité.

Comme indiqué précédemment, étant donné que plusieurs serveurs ARR sont configurés de la même façon, une configuration partagée est utilisée. La principale différence est la façon dont NLB est configuré. Pour utiliser tous les serveurs ARR en même temps, la règle de port du cluster NLB est configurée en mode hôte multiple.

Que la fonctionnalité d’affinité soit activée ou non dans NLB, aucune configuration spéciale n’est nécessaire sur les serveurs ARR. Pour un, les serveurs ARR utilisent une configuration partagée afin qu’ils soient configurés de la même façon. Deuxièmement, étant donné que ARR utilise un cookie client pour stocker les informations d’affinité du serveur pour sa propre utilisation, ces informations sont disponibles par requête et sont donc disponibles sur les serveurs ARR. La recommandation pour NLB consiste à définir l’affinité sur aucune, car elle entraîne une distribution de charge plus uniforme.

Ce scénario est entièrement pris en charge dans la version 1 d’ARR.

Configuration ARR

La configuration ARR pour actif/actif est identique à celle d’actif/passif. La principale différence est la façon dont NLB est configuré.

Étape 1 : Activer la configuration partagée sur deux serveurs ARR.

• Suivez les étapes de ce document pour mettre en place une configuration partagée dans IIS.

Étape 2 : Configurer l’architecture de déploiement à 3 niveaux à l’aide d’ARR.

• Suivez les étapes de ce document pour configurer ARR dans l’architecture de déploiement à 3 niveaux.

• À un niveau élevé, le document ci-dessus décrit :

  • Comment rendre le contenu statique disponible sur le serveur ARR.
  • Comment écrire des règles de réécriture d’URL pour le contenu statique afin qu’elles soient traitées directement à partir du serveur ARR.
  • Comment écrire des règles de réécriture d’URL pour le contenu dynamique afin qu’elles soient transférées aux serveurs d’applications.

Configuration NLB

La configuration NLB est divisée en plusieurs étapes :

1. Installez la fonctionnalité NLB sur tous les serveurs ARR.
2. Créez un cluster NLB pour ARR.
3. Configurez NLB pour le déploiement actif/actif.

Installez la fonctionnalité NLB sur tous les serveurs ARR : Documenté [ici](achieving-high-availability-and-scalability-arr-and-nlb.md#install NLB).

Créer un cluster NLB pour ARR: Documenté [ici](achieving-high-availability-and-scalability-arr-and-nlb.md#create nlb).

Configurez NLB pour le déploiement actif/actif.

1. Pour configurer NLB en vue d'un déploiement actif/actif, dans le Network Load Balancing Manager, cliquez avec le bouton droit de la souris sur le cluster, puis sélectionnez Propriétés du cluster. Cliquez sur l’onglet Règles de port. Cliquez sur Modifier.
   
2. Sélectionnez Hôtes multiples. Pour le paramètre Affinité, sélectionnez Aucune. Comme mentionné ci-dessus, la recommandation est de ne pas utiliser l’affinité dans NLB, car elle entraînera une meilleure distribution de charge.
   

NLB est configuré avec succès pour fonctionner en mode actif/actif avec ARR.

Scénario 2 : Hébergement partagé à l’aide de l’affinité de nom d’hôte

Ce scénario utilise la fonctionnalité d’affinité de nom d’hôte dans ARR pour activer un déploiement d’hébergement partagé pour :

• Réduire la gestion manuelle et la maintenance impliquées dans le déploiement d’hébergement partagé traditionnel.
• Optimiser les ressources de serveur existantes tout en veillant à ce que toutes les ressources du serveur soient utilisées uniformément.
• Effectuer facilement une extension de l’environnement.
• Créer des opportunités commerciales pour vendre une capacité supplémentaire.

Pour plus d’informations sur l’hébergement partagé et ARR, reportez-vous à ce document.

Le diagramme suivant illustre l’environnement d’hébergement partagé à l’aide d’ARR :

Option1 : Actif/passif

Comme indiqué précédemment, en mode actif/passif, il existe généralement deux serveurs ARR dans lesquels un serveur traite les requêtes tandis que l’autre serveur est un serveur de basculement. Bien que cette configuration atteigne une haute disponibilité en supprimant le point de défaillance unique, il ne s’agit pas d’une solution d’extension, car la capacité d’agrégation des serveurs de contenu est limitée par la capacité maximale d’un serveur ARR.

Dans cette configuration, étant donné que deux serveurs ARR sont configurés de la même façon, une configuration partagée est utilisée. Le cluster NLB est configuré pour accepter le trafic uniquement sur l’un des nœuds du cluster. Pour ce faire, configurez les règles de cluster avec un mode de filtrage d’hôte unique. Le nœud acceptant le trafic est déterminé par le paramètre de priorité de l’hôte des nœuds du cluster NLB. Pour plus d’informations, reportez-vous à la configuration NLB.

La fonction d'affinité de nom d'hôte dans ARR affine les demandes vers un serveur particulier (ou un groupe de serveurs dans RC) en fonction du nom d'hôte. Les informations relatives à l'état d'exécution du mappage affinitaire entre les noms d'hôtes et les serveurs de contenu sont stockées en mémoire dans une instance d'un serveur ARR. Dans la version 1 d’ARR, ARR tire parti de la version 1 de Microsoft External Cache pour IIS afin de partager et de gérer cet état d’exécution entre plusieurs serveurs ARR. Vous trouverez plus d’informations sur ce scénario dans ce document.

Ce scénario est entièrement pris en charge dans la version 1 d’ARR.

Configuration ARR

Étape 1 : Configurer ARR pour l’hébergement partagé avec l’affinité de nom d’hôte.

• Suivez les étapes décrites dans ce document pour configurer la fonctionnalité d’affinité de nom d’hôte dans ARR pour l’hébergement partagé.

Étape 2 : Activer et configurer External Cache.

• Suivez les étapes décrites dans ce document pour activer et configurer External Cache.

Configuration NLB

La configuration NLB est divisée en plusieurs étapes :

1. Installez la fonctionnalité NLB.
2. Créez un cluster NLB pour ARR.
3. Configurez NLB pour le déploiement actif/passif.

Installez la fonctionnalité NLB : Documenté [ici](achieving-high-availability-and-scalability-arr-and-nlb.md#Install NLB features).

Créer un cluster NLB pour ARR: Documenté [ici](achieving-high-availability-and-scalability-arr-and-nlb.md#Create NLB cluster for ARR).

Configurer NLB pour le déploiement actif/passif : Documenté [ici](achieving-high-availability-and-scalability-arr-and-nlb.md#Configure NLB for active/passive).

Option 2 : Actif/actif dans ARR

En mode actif/actif, vous pouvez avoir deux serveurs ARR ou plus. Cette configuration obtient à la fois une haute disponibilité et une scalabilité, contrairement au mode actif/passif, qui n’atteint que la haute disponibilité. Étant donné que plusieurs serveurs ARR sont configurés de la même façon, une configuration partagée est utilisée. Pour utiliser tous les serveurs ARR en même temps, NLB est configuré en mode hôte multiple. Comme indiqué précédemment, les informations relatives à l'état d'exécution du mappage affinitaire entre les noms d'hôtes et les serveurs de contenu sont stockées dans la mémoire d'une instance d'un serveur ARR. Pour partager ces informations entre plusieurs serveurs ARR, Microsoft External Cache pour IIS est utilisé. Pour plus d’informations sur External Cache, reportez-vous à ce document.

Configuration ARR

La configuration ARR pour actif/actif est identique à celle d’actif/passif. La principale différence est la façon dont NLB est configuré.

Étape 1 : Configurer ARR pour l’hébergement partagé avec l’affinité de nom d’hôte.

• Suivez les étapes décrites dans ce document pour configurer la fonctionnalité d’affinité de nom d’hôte dans ARR pour l’hébergement partagé.

Étape 2 : Activer et configurer External Cache.

• Suivez les étapes décrites dans ce document pour activer et configurer External Cache.

Configuration NLB

La configuration NLB est divisée en plusieurs étapes :

1. Installez la fonctionnalité NLB.
2. Créez un cluster NLB pour ARR.
3. Configurez NLB pour le déploiement actif/actif.

Installez la fonctionnalité NLB : Documenté [ici](achieving-high-availability-and-scalability-arr-and-nlb.md#Install NLB features).

Créer un cluster NLB pour ARR: Documenté [ici](achieving-high-availability-and-scalability-arr-and-nlb.md#Create NLB cluster for ARR).

Configurer NLB pour le déploiement actif/actif : Documenté [ici](achieving-high-availability-and-scalability-arr-and-nlb.md#Configure NLB for active/active). Il est recommandé de ne pas utiliser l’affinité dans NLB pour ce scénario ARR.

Résumé

Dans ce livre blanc, deux scénarios principaux d'ARR ont été examinés pour obtenir une haute disponibilité et une scalabilité en déployant plusieurs serveurs ARR et en utilisant NLB.

Annexe

Annexe A : Tous les en-têtes HTTP et variables serveur disponibles pour écrire des règles de décision de routage

ALL_HTTP	ALL_RAW	APPL_MD_PATH
APPL_PHYSICAL_PATH	CERT_COOKIE	CERT_FLAGS
CERT_ISSUER	CERT_KEYSIZE	CERT_SECRETKEYSIZE
CERT_SERIALNUMBER	CERT_SERVER_ISSUER	CERT_SERVER_SUBJECT
CERT_SUBJECT	CONTENT_LENGTH	CONTENT_TYPE
DOCUMENT_ROOT	GATEWAY_INTERFACE	HTTP_ACCEPT
HTTP_ACCEPT_ENCODING	HTTP_ACCEPT_LANGUAGE	HTTP_CONNECTION
HTTP_CONTENT_LENGTH	HTTP_HOST	HTTP_IF_MODIFIED_SINCE
HTTP_IF_NONE_MATCH	HTTP_REFERER	HTTP_UA_CPU
HTTP_USER_AGENT	HTTPS	HTTPS_KEYSIZE
HTTPS_SECRETKEYSIZE	HTTPS_SERVER_ISSUER	HTTPS_SERVER_SUBJECT
INSTANCE_ID	INSTANCE_META_PATH	LOCAL_ADDR
PATH_INFO	PATH_TRANSLATED	QUERY_STRING
REMOTE_ADDR	REMOTE_HOST	REMOTE_PORT
REMOTE_USER	REQUEST_FILENAME	REQUEST_METHOD
REQUEST_URI	SCRIPT_FILENAME	SCRIPT_NAME
SERVER_ADDR	SERVER_NAME	SERVER_PORT
SERVER_PORT_SECURE	SERVER_PROTOCOL	SERVER_SOFTWARE
URL

Annexe B : Documentation supplémentaire sur l’équilibrage de charge réseau (NLB)

• Instructions de NLB Server Core :

  • Installer la fonctionnalité NLB : https://download.microsoft.com/download/6/3/5/6350896f-1e08-440b-9f24-d50f5e9b2390/ServerCoredeepdive.ppt

• NLB et SSL :

  • https://support.microsoft.com/?id=313299

• Autres liens NLB :

  • https://technet.microsoft.com/library/cc782694.aspx
  • https://technet.microsoft.com/library/cc778263.aspx
  • https://support.microsoft.com/kb/323437
  • https://support.microsoft.com/kb/890159
  • https://blogs.msdn.com/clustering