Tech-Ed 2005 : Implémentation d'ISA Server 2004 Édition Entreprise Accueil > Articles > Evènements
Auteurs  Matthieu MARTINEAU PI SERVICES (GOLD PARTNER MICROSOFT) Ingénieur systèmes et réseaux  Tous les articles de cet auteur		4,7/5 Très Bien 79992 128/605

6. La mise en cache distribuée à l'aide du protocole CARP

L'édition Entreprise d'ISA Server, reprend exactement les fonctionnalités que la la version standard en terme de mise en cache ! Cependant des problèmes se posent lorsque l'on considère une grappe composée de plusieurs serveurs. Pour bien percevoir les difficultés rencontrées lors de l'activation de la mise en cache sur un groupe de serveurs, le mieux est d'utiliser un petit exemple.

Considérons une grappe composée de 5 serveurs ISA. La mise en cache est activée sur tous les serveurs et un espace de 10 Go est réservé sur chacun d'entre eux. On remarque que les serveurs ISA n°4 et n°5 possèdent un fichier nommé FireFox.exe dans leur mémoire cache. Un ordinateur client envoie une requête au serveur ISA n°2 (car ce client est configuré pour utiliser le serveur ISA n°2) demande la ressource nommée Firefox.exe. Le serveur ISA n°2 commence par vérifier si la ressource est présente dans son cache (que ce soit dans la mémoire vive ou dans le disque dur). Etant donné que sa mémoire cache est vide, le serveur ISA n°2 contacte le serveur Web approprié, télécharge la ressource, la met localement en cache et la renvoie au client. C'est le fonctionnement classique de la mise en cache (toutes les actions réalisées par le serveur de proxy sont totalement transparentes pour le client).

Cependant l'utilisation de ce système pose des inconvénients lorsque l'on considère une grappe de serveurs :

• Pour commencer le serveur n°2 ne contacte pas les autres serveurs de la grappe alors qu'il est tout à fait possible que la ressource soit présente sur l'un d'entre eux  (c'est d'ailleurs le cas puisque les serveurs 4 et 5 possèdent la ressource) ! La bande passante de la connexion WAN est donc gaspillée inutilement !

• De plus avec ce système, un objet (le fichier Firefox.exe par exemple) peut tout à fait être mis en cache par plusieurs serveurs ISA différents suite à des requêtes envoyées par deux clients différents (dans l'exemple ci-dessus le fichier firefox.exe sera mis en cache 3 fois !!!) ! L'espace mémoire réservé à la mise en cache sur les serveurs de la grappe est donc gaspillé inutilement puisque certaines ressources sont dupliquées !

Pour résoudre le problème de la mise en cache dans un groupe de serveurs, Microsoft a choisi d'implémenter un système de mise en cache distribuée. Le protocole utilisé se nommé CARP (pour Cache Array Routing Protocol). Il est uniquement disponible avec la version entreprise d'ISA Server (ce qui est normal étant donné que l'on ne peut pas créer de grappes de serveurs avec la version standard) et offre un grand nombre d'avantages :

• les objets ne sont jamais dupliqués dans la mémoire cache des serveurs de la grappe

• les serveurs de la grappe n'ont pas besoin de communiquer entre eux pour savoir quel serveur possède quelle ressource dans son cache

• l'ajout ou la suppression dynamique de serveurs au sein de la grappe est supportée

• la charge est équilibrée entre les serveurs grâce à un facteur de charge (chiffre qui doit être configuré sur chaque membre de la grappe)

Pour répartir les données mises en cache entre les serveurs de la grappe, CARP utilise un algorithme se basant sur un hash des URLs demandées. Ainsi chaque serveur de la grappe est configuré pour répondre à une certaine plage d'URL hachées. Cette plage est réajustée par l'algorithme CARP lorsqu'une modification est apportée à la configuration de la grappe (ajout d'un serveur, suppression d'un serveur, changement du facteur de charge d'un serveur).

Lorsque les applications clientes supportent le protocole CARP (c'est notamment le cas d'Internet Explorer) elle peuvent être configurées pour télécharger automatiquement un script de configuration. En utilisant ce script l'application cliente sait immédiatement quel serveur ISA de la grappe elle doit joindre en fonction de l'URL demandée. La capture d'écran ci-contre montre comment le support de CARP peut être activé dans Internet Explorer. Pour atteindre cette fenêtre il faut utiliser le menu Outils / Options Internet..., puis cliquer sur le bouton Paramètres réseau... de l'onglet Connexions. On remarque que l'URL permettant de télécharger le script de configuration est de la forme : http://nom_de_l'un_des_serveurs_isa_de_la_grappe:8080/array.dll?Get.Routing.Script

Lorsque les applications clientes ne supportent pas le protocole CARP elles peuvent être configurées pour joindre n'importe quel serveur ISA de la grappe. En effet, lorsqu'un serveur ISA configuré pour utiliser le protocole CARP reçoit une requête pour une URL qu'il n'est pas censé traité, il redirige automatiquement le client vers le bon serveur ISA !

La première chose à faire est bien entendu d'activer la mise en cache et de définir l'espace qui sera dédié à la mise en cache sur chaque serveur ISA de la grappe. Comme pour la version standard, cette opération s'effectue dans la fenêtre Configuration / Cache. Pour rappel, tous les lecteurs de cache doivent être formatés avec le système de fichiers NTFS ! Dans l'exemple ci-dessous, 30 Go sont réservés pour le fichier de cache sur le serveur ISA-ENT-1 et 120 Go sont réservés sur le serveur ISA-ENT-2.

Il est aussi possible de modifier le facteur de charge dans les propriétés de chacun des serveurs de la grappe. Par défaut, le facteur de charge est fixé à 100 pour chacun des serveurs ce qui signifie que les requêtes sont également réparties entre tous les membres de la grappe ! Il peut s'avérer intéressant de modifier ce chiffre pour tenir compte des performances des composants matériels installés sur chacun des serveurs ISA. Dans l'exemple ci-dessous, le facteur de charge du serveur ISA-ENT-1 est fixé à 100 et celui du serveur ISA-ENT-2 à 160. Cela signifie que le serveur ISA-ENT-2 traitera 60% de requêtes supplémentaires par rapport à l'autre serveur.

Enfin la dernière opération a effectuer reste l'activation du protocole CARP sur un réseau donné. Pour cela il suffit d'afficher les propriétés du réseau sur lequel on souhaite activer la mise en cache distribuée, de cliquer sur l'onglet CARP, puis de côcher la case appropriée. Dans l'exemple ci-contre, le protocole CARP a été activé sur le réseau Interne. Cela signifie donc que seul le résultat des requêtes envoyées par les clients du réseau interne seront mises en cache. On parle de mise en cache directe. Ce type de mise en cache permet de réduire l'utilisation de la bande passante de la connexion WAN contrairement à la mise en cache inversée qui permet de réduire l'utilisation de la bande passante du réseau local. Il est recommandé d'utiliser la mise en cache inversée lorsqu'un serveur Web générant beaucoup de trafic (un serveur OWA par exemple) est publié sur Internet. La fenêtre ci-contre permet également de désactiver CARP pour certains sites Web (cela peut être utile dans certains cas).

L'équilibrage de la charge (NLB) et la mise en cache distribuée (CARP) peuvent tout à fait cohabiter au sein du même groupe de serveurs. Cependant, l'administrateur doit bien comprendre les différences entre ces deux systèmes avant des les implémenter. En effet, CARP et NLB ne fournissent pas le même type de service et ne s'appliquent pas non plus au même trafic réseau !

Lorsque la mise en cache distribuée (CARP) est activée sur une interface donnée (par exemple sur le réseau Interne) seul le trafic HTTP et le trafic FTP sont concernés ! Si une tolérance de panne est assurée au niveau du service (si l'un des serveurs tombe en panne, le script de configuration est automatiquement modifiée et les clients n'utilisent plus que les serveurs actifs), en revanche aucune tolérance de panne n'est fournie pour les objets présent en cache puisqu'il n'y a pas de duplication ! L'un des avantages du protocole CARP est aussi la possibilité de configurer la charge en fonction des caractéristiques matérielles des serveurs (grâce au facteur de charge).

Lorsque l'équilibrage de la charge (NLB) est activée sur une interface donnée (par exemple sur le réseau Interne), tout le trafic IP est également réparti entre les serveurs de la grappe et une tolérance de panne est offerte en cas de défaillance de l'un des serveurs. Le tableau ci-dessous résume les différences entre ces deux protocoles :

L'implémentation de l'une de ces deux technologie ou bien de ces deux technologies dépend des scénarios rencontrés. Par exemple si l'on souhaite activer la mise en cache sur un groupe de serveur, il est recommandé d'activer le protocole CARP. En outre, lorsque l'on souhaite activer la répartition de la charge sur une liaison VPN site-à-site ou bien sur un serveur OWA publié, le protocole NLB doit être utilisé.

Sommaire
1. Présentation d'ISA Server Edition Entreprise
     1.1 Le positionnement du produit au sein la politique de sécurité de Microsoft
     1.2 Les nouveautés de la version Entreprise
     1.3 Configuration requise pour exécuter Microsoft ISA Server 2004 EE
     1.4 Quelle version d'ISA choisir ?

2. Implémentation d'un serveur de stockage de configuration (CSS)
     2.1 Évolution du système de stockage depuis ISA Server 2000
     2.2 Le serveur de stockage de configurations (CSS)
     2.3 Recommandations pour le placement du serveur de stockage de configurations
     2.4 Recommandations pour la mise en place d'un serveur CSS dans un site distant
     2.5 Installation du premier serveur de configurations de l'entreprise ISA Server
     2.6 Installation d'un serveur CSS redondant pour assurer la tolérance de panne
     2.7 Configuration de la réplication intrasite sur les serveurs CSS
     2.8 Configuration de la réplication intersites sur les serveurs CSS

3. Mise en place d'une stratégie d'Entreprise
     3.1 Introduction aux stratégies d'entreprise
     3.2 Implémentation et configuration d'une grappe de serveurs
     3.3 Ordre d'application des règles d'entreprise et de grappes
     3.4 Délégation de l'administration au sein d'une entreprise ISA Server

4. Déploiement d'un serveur ISA au sein d'une Entreprise ISA Server
     4.1 Installation manuelle d'un premier serveur ISA dans groupe de serveurs
     4.2 Installation automatique d'un second serveur ISA dans un groupe de serveur

5. Configuration de l'équilibrage de la charge (NLB) sur un groupe de serveurs (Array)
     5.1 Principe du Network Load Balancing (NLB)
     5.2 Intégration du NLB au sein d'ISA Server 2004
     5.3 Configuration d'un réseau permettant la communication à l'intérieur de la grappe
     5.4 Activation du NLB sur l'un des réseaux d'un groupe de serveurs ISA

6. La mise en cache distribuée à l'aide du protocole CARP
     6.1 Problématique de la gestion du cache dans un groupe de serveurs
     6.2 Principe du cache distribué
     6.3 Configuration du protocole CARP sur un groupe de serveur ISA
     6.4 Fonctionnement simultané de l'équilibrage de la charge (NLB) de la mise en cache distribuée (CARP)

7. Conclusion
     7.1 Procédure globale de déploiement
     7.2 Le mot de la fin...

En Savoir Plus

Evaluez cet article  0 1 2 3 4 5 Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft