Recommandations relatives aux performances d'ISA Server 2004

Microsoft Internet Security and Acceleration Server 2004

Sur cette page

	Introduction
	Résumé
	Planification de la capacité d'ISA Server
	Instructions de réglage des performances
	Scénarios
	Évolution d'ISA Server
	Dimensionnement du serveur de stockage de configuration
	Référence et exemple de dimensionnement
	Informations complémentaires

Introduction

Microsoft® Internet Security and Acceleration (ISA) Server 2004 offre un contrôle d'accès sécurisé entre les réseaux et sert de proxy de mise en cache Web pour fournir des réponses rapides sur le Web. Il permet également d’alléger la consommation des ressources matérielles sur les serveurs web publiés (fonctions de reverse proxy). Son architecture multicouches associée à une gestion avancée des stratégies permettent le contrôle précis de l'équilibre entre le niveau de sécurité dont vous avez besoin et les ressources nécessaires. En tant que serveur de périmètre connectant plusieurs réseaux, ISA Server gère une grande quantité de trafic comparativement aux autres serveurs de l'entreprise. C'est la raison pour laquelle il a été conçu pour des performances élevées. Cet article fournit des informations vous permettant de dimensionner vos serveurs ISA 2004 afin d’obtenir des performances optimales selon son type d’utilisation.

Haut de page

Résumé

Dans la plupart des cas, la bande passante réseau disponible et particulièrement celle de la liaison Internet peuvent être sécurisées par ISA Server fonctionnant sur un matériel d'entrée de gamme. Un déploiement type par défaut d'ISA Server sécurisant l'accès Web sortant du trafic HTTP (Hypertext Transfer Protocol) nécessite des configurations matérielles spécifiques selon les différentes liaisons Internet. Ces configurations sont indiquées dans le tableau suivant. (Pour plus d'informations, consultez la section Scénarios de proxy Web dans ce document.)

L'utilisation du filtrage avec état de la couche de transport statefull paquet inspection plutôt que le filtrage de proxy Web améliore l'utilisation de l'UC pour les mêmes types de trafic d'un facteur de 10. Le filtrage avec état et le filtrage d'application peuvent être utilisés en parallèle pour améliorer la précision du contrôle des performances.

Haut de page

Planification de la capacité d'ISA Server

Pour déterminer les ressources nécessaires à un déploiement d'ISA Server, vous devez d'abord connaître vos besoins de capacité. Il existe de nombreux cas pour un large éventail de déploiements. En règle générale, vous devriez disposer des mesures suivantes :

La mesure la plus importante de la capacité d'ISA Server concerne les bandes passantes réelles des réseaux, car elles représentent généralement vos besoins exacts de capacité. Dans de nombreux cas, la bande passante réseau, en particulier celle de la liaison Internet, peut déterminer la capacité d'ISA Server.

Le nombre d'utilisateurs est une indication moins précise de vos besoins de capacité. En effet, l'utilisation diffère selon les besoins de chaque utilisateur et la stratégie réseau de votre entreprise. Dans certains cas, le nombre d'utilisateurs et les mesures effectuées au niveau de l'application peuvent s'avérer utiles pour estimer le trafic réseau.

Tous les cas de planification de la capacité d'ISA Server relèvent de l'une des catégories suivantes :

Les sections suivantes décrivent ces cas de façon plus détaillée.

Ordinateur d'entrée de gamme unique

Dans la plupart des cas, un ordinateur unique dispose d'une puissance de traitement suffisante pour sécuriser le trafic des liaisons Internet standard. Selon plusieurs études de marché relatives à l'utilisation d'Internet, la plupart des bandes passantes des liaisons Internet d'entreprise se situent entre 2 et 20 Mbits/s. Ceci indique qu'un ordinateur d'entrée de gamme doté d'un ou de deux processeurs peut satisfaire les besoins de la plupart des déploiements d'ISA Server.

Selon des résultats de test de pare-feu en sortie, ISA Server exécuté sur un seul processeur Pentium 4 à 2,4 GHz peut fournir un débit approximatif de 25 Mbits/s à 75 % d'utilisation de l'UC. Autrement dit, pour chaque liaison Internet T1 (1,5 Mbits/s), le service de pare-feu Microsoft n'utilise que 4,5 % des ressources de l'UC. Deux processeurs Xeon à 2,4 GHz peuvent fournir un débit approximatif de 45 Mbits/s (T3) à 75 % d'utilisation de l'UC, ou 2,5 % d'utilisation de l'UC pour chaque T1.  

Un ordinateur d'entrée de gamme fonctionne également dans les filiales qui se connectent aux ressources de l'entreprise via des liaisons Internet indépendantes du réseau étendu (WAN) dans les limites de bande passante décrites au paragraphe précédent.

Échelle de l'entreprise

Pour les sites importants à l'échelle de l'entreprise qui comptent plus de 500 utilisateurs, la situation est plus complexe. Ce type de cas nécessite une planification plus élaborée, car la bande passante Internet est suffisamment importante pour déplacer les goulets d’étranglement qui pénalisent les performances vers les ressources de l'UC du système.

La bande passante de la connexion Internet impose une limite du nombre d'ordinateurs pouvant utiliser pleinement cette connexion, et ce maximum peut être suffisant pour la plupart des estimations de capacité. Au départ, il peut s'avérer prudent de prévoir la capacité réseau maximale, car il est fréquent que les besoins de capacité augmentent avec le temps. Pour prendre en charge une augmentation future de ces besoins, vous devez également prévoir des mises à niveau de la puissance de traitement. Pour obtenir une description des techniques d'évolution du matériel, de leurs caractéristiques de performances et des autres avantages de ces évolutions, consultez la section Évolution d'ISA Server dans ce document.

Haut de page

Instructions de réglage des performances

Après avoir décidé de la capacité correspondant à vos besoins, vous devez l'adapter pour obtenir des performances optimales. Pour ISA Server à l'échelle de l'entreprise, il convient donc de prévoir des ressources matérielles adéquates pour que le système dépende de la puissance de son UC comme source d'un possible goulet d’étranglement. Pour un ordinateur ISA Server d'entrée de gamme unique, la bande passante Internet, et non pas le processeur que vous choisissez, est la source d'un possible goulet d’étranglement.  

Réglage du matériel pour une utilisation optimale de l'UC

La capacité d'ISA Server dépend de l'UC, de la mémoire, du réseau et des ressources disque matérielles. Chaque ressource a une limite de capacité, et tant que toutes les ressources sont consommées en deçà de leur limite, le système dans son ensemble fonctionne correctement et satisfait aux objectifs de performances. Les performances chutent considérablement lorsqu'une de ces limites est atteinte, provoquant un goulet d’étranglement. Dans ce cas, le système est considéré comme lié à cette ressource. Chaque goulet d’étranglement présente ses propres symptômes en matière de performances globales du système ; ces symptômes peuvent aider à détecter les ressources ayant une capacité inadéquate. Lorsqu'un goulet d’étranglement a été découvert, il est possible de le supprimer en ajoutant davantage de capacité à la ressource concernée.

Du point de vue du coût, il est plus économique de concevoir un système lié aux ressources de l'UC. En effet, l'UC est la ressource la plus coûteuse à mettre à niveau. Les autres pénuries de ressource sont moins coûteuses à pallier : ajout d'un disque, ajout d'une carte réseau ou augmentation de la mémoire. Nous vous recommandons de régler le matériel du système pour optimiser l'utilisation de l'UC. Assurez-vous que le système ne connaît aucun goulet d’étranglement avant d'atteindre la pleine utilisation de l'UC. Si la puissance de l'UC peut supporter la charge prévue, aucun goulet d’étranglement ne se produira. Pour ce faire, toutes les autres ressources doivent avoir la capacité adéquate. Les sections suivantes expliquent comment concevoir un système optimisé en termes d'UC avec une capacité adéquate dans chaque ressource, comment surveiller chaque ressource et comment éliminer un goulet d’étranglement dans chaque ressource.

Détermination du processeur et de la capacité de l'architecture du système

À l'instar de la plupart des applications serveur traitant de nombreuses requêtes des clients, les performances d'ISA Server sont améliorées lorsque la vitesse et la dimension du cache du processeur sont plus élevées, et lorsque l'architecture du système est mieux conçue :

Les goulets d'étranglement de l'UC sont typiques des situations dans lesquelles les valeurs de performances

\Processeur\% Temps processeur

sont élevées tandis que les E/S de la carte réseau et du disque demeurent bien inférieures à la capacité. Dans un tel cas (système idéal optimisé en termes d'UC), pour atteindre 100 %, il faut augmenter la puissance de l'UC, soit en optant pour une UC plus rapide, soit en ajoutant des processeurs. Pour plus d'informations sur les options d'évolution de l'UC, consultez la section Évolution d'ISA Server dans ce document. Si les temps de réponse d'ISA Server restent élevés avec des faibles pourcentages de l'UC, le goulet d'étranglement se trouve ailleurs.

La technologie hyper-threading peut également contribuer à abaisser les niveaux d'utilisation de l'UC lorsque la consommation de l'UC ne dépasse pas 60 %. À des niveaux plus élevés d'utilisation de l'UC, l'hyper-threading activé consommera la même puissance de traitement que l'hyper-threading désactivé.

Détermination de la capacité mémoire

La mémoire d'ISA Server est utilisée pour les éléments suivants :

Dans les scénarios de mise en cache de proxy Web, la mémoire est également utilisée pour les éléments suivants :

Comme ISA Server gère un grand nombre de connexions simultanées nécessitant la mémoire système non paginée, le facteur mémoire limitant est la taille de la réserve non paginée, déterminée par la taille totale de la mémoire. Pour Microsoft Windows Server™ 2003 et Windows® 2000 Server, les valeurs minimum et maximum de la taille de la réserve non paginée sont indiquées dans le tableau suivant.

Lorsque la mise en cache Web n'est pas activée, 512 Mo doivent suffire pour des ordinateurs monoprocesseurs, et 1024 Mo pour des ordinateurs biprocesseurs. Ces quantités peuvent également stocker la capacité totale de la plage de travail.

Le signe le plus évident d'un réglage incorrect de la mémoire apparaît lorsque la valeur \Mémoire\Pages/s (mesurant les défauts de page matériels) est élevée (supérieure à 10) au cours des charges maximales. Si cela se produit, la première mesure à prendre dépend de l'activation ou non de la mise en cache Web :

Si la mise en cache Web est désactivée, vous devez déterminer s'il faut davantage de mémoire physique en surveillant la mémoire utilisée par tous les processus du système. Les compteurs de performances suivants vous y aideront :
\Mémoire\Pages/s
\Mémoire\Octets de réserve non paginés
\Mémoire\Octets de réserve paginés
\Processus(*)\Plage de travail

Si la mise en cache Web est activée, tentez d'abord de réduire la taille du cache mémoire à 10 % de la mémoire physique. Si des défauts de page matériels continuent de se produire, passez à l'étape 1.

Détermination de la capacité réseau

Chaque périphérique réseau d'une connexion a sa limite de capacité. Ces périphériques incluent les cartes réseau client et serveur, les routeurs, les commutateurs et les concentrateurs qui les interconnectent. Une capacité réseau adéquate tient au fait qu'aucun de ces périphériques réseau n'est saturé. La surveillance de l'activité du réseau est essentielle pour s'assurer que les charges réelles de tous les périphériques du réseau sont inférieures à leur capacité maximale.

Il existe deux grands cas dans lesquels la capacité réseau a une incidence sur les performances d'ISA Server :

Pour surveiller l'activité du réseau, utilisez le compteur de performances :
\Interface réseau(*)\Total des octets/s
Si sa valeur est supérieure à 75 % de la bande passante maximale de n'importe quelle interface réseau, envisagez d'augmenter la bande passante de l'infrastructure réseau qui ne convient pas.

Détermination de la capacité de stockage sur disque

ISA Server utilise le stockage sur disque pour les éléments suivants :

Si les deux sont désactivés ou en l'absence de trafic, ISA Server n'exécute aucune activité d'E/S de disque. Dans une configuration type d'ISA Server, la journalisation est activée et configurée pour utiliser la journalisation de Microsoft SQL Server™ 2000 Desktop Engine (MSDE 2000). Pour la plupart des déploiements, un seul disque suffit pour fournir le taux maximum de journalisation. Si la mise en cache Web est activée, la capacité de stockage sur disque doit être planifiée avec soin comme indiqué à la section Mise en cache Web de ce document.

Le facteur limitant de n'importe quel système de stockage sur disque est le nombre d'accès au disque physique par seconde. Ce nombre varie en fonction du caractère aléatoire de ces accès et de la vitesse de rotation du disque physique. Généralement, la limite se situe entre 100 et 200 accès par seconde. Le compteur de performances permettant de surveiller le taux d'accès au disque est le suivant :

\Disque physique(*)\Transferts disque/s

Si cette limite est atteinte sur un disque pendant une période prolongée, il est probable que le système va ralentir, ce qui se traduira par une augmentation de son temps de réponse. Pour supprimer ce goulet d'étranglement, la solution immédiate consiste à réduire les accès disque en ajoutant des disques physiques.

Les défauts de page matériels sont une autre cause du taux élevé d'accès disque. Pour remédier à cette situation, consultez la section Mise en cache Web dans ce document.

Filtres d'application et filtres Web

ISA Server utilise des filtres d'application pour effectuer des inspections de sécurité au niveau de l'application. Un filtre d'application est une bibliothèque de liaison dynamique (DLL) qui s'enregistre auprès d'un port de protocole spécifique. Chaque fois qu'un paquet est envoyé à ce port de protocole, il est transmis au filtre d'application qui l'inspecte en fonction de la logique de l'application et décide ce qu'il convient de faire selon la stratégie. En l'absence de filtre d'application assigné à un protocole, les données sont soumises à un filtrage TCP avec état. À ce niveau, ISA Server ne vérifie que les informations d'en-tête TCP/IP.

En général, le filtrage au niveau de l'application nécessite davantage de traitement que le filtrage TCP avec état pour plusieurs raisons :

Comme les filtres d'application sont des extendeurs de traitement de pare-feu, ils peuvent avoir un impact sur les performances. Tenez compte des recommandations suivantes :

Journalisation

ISA Server offre deux grandes méthodes pour journaliser l'activité du pare-feu :

Si l'on compare ces deux méthodes, il apparaît que MSDE présente plus de fonctions, mais utilise davantage de ressources système. En particulier, vous pouvez prévoir une amélioration globale de 10 à 20 % de l'utilisation du processeur lorsque vous passez de MSDE à la journalisation de fichiers.

La journalisation MSDE consomme en outre davantage de ressources de stockage sur disque. La journalisation MSDE exécute environ deux accès disque par mégabit. La journalisation de fichiers nécessite la même quantité d'accès disque pour 10 mégabits. Un moyen d'améliorer les performances d'ISA Server consiste à passer de la journalisation MSDE à la journalisation de fichiers. Cela n'est recommandé que lorsqu'un problème de performances est provoqué par la saturation du processeur ou des accès disque.

ISA Server 2004 Enterprise Edition permet également la journalisation SQL à distance, qui peut être utilisée pour consigner tous les enregistrements dans une base de données SQL gérée de façon centralisée. La consommation des ressources de l'UC par la journalisation SQL à distance se situe entre celle de la journalisation MSDE et de la journalisation de fichiers. Elle n'utilise presque pas d'E/S de disque. En revanche, la journalisation SQL à distance introduit d'autres besoins de capacité qui doivent être pris en considération, car tous les enregistrements du journal sont écrits dans une base de données distante centralisée :

Haut de page

Scénarios

ISA Server prend en charge plusieurs scénarios de déploiement et d'application. Les sections qui suivent décrivent les principaux scénarios et leurs caractéristiques de performances.

Scénarios de déploiement

Les scénarios de déploiement renvoient à l'emplacement d'un ordinateur ISA Server au sein de l'intranet d'une entreprise. Du fait des critères de sécurité et de performances, plusieurs scénarios courants ont évolué au cours des années et les sections qui suivent décrivent chacun d'entre eux du point de vue des performances et de la capacité.

Pare-feu de périmètre Internet

Les organisations dont les besoins de capacité se mesurent à l'échelle de l'entreprise peuvent envisager de déployer un ordinateur ISA Server comme pare-feu de périmètre Internet dédié faisant office de passerelle sécurisée vers Internet pour l'ensemble des clients de l'entreprise. Pour conserver des niveaux de débit élevés (plusieurs centaines de Mbits/s) entre les réseaux internes et la connexion Internet, ISA Server peut être configuré pour ne fournir que le filtrage au niveau du paquet et avec état de la couche de transport.

Le filtrage plus évolué au niveau de l'application que permet ISA Server sera activé sur la seconde couche de défense, constituée des ordinateurs pare-feu ISA Server principaux.

Pare-feu départemental ou principal

La ligne de défense suivante pour les organisations à l'échelle de l'entreprise inclut plusieurs ordinateurs ISA Server qui sont déployés en tant que pare-feux réseau départementaux ou principaux offrant un contrôle d'accès sortant et entrant sécurisé à destination ou en provenance des réseaux locaux protégés. Les entreprises disposant déjà d'infrastructures de pare-feu peuvent conserver leurs pare-feux à hautes performances sur le périmètre Internet et décharger le filtrage de couche d'application élaboré vers des ordinateurs ISA Server sur le périmètre des réseaux locaux. Cela permet à une entreprise d'utiliser les connexions Internet à haut débit existantes tout en bénéficiant du niveau de protection unique assuré par les fonctionnalités de filtrage de la couche application d'ISA Server 2004.

Du point de vue des performances, un pare-feu départemental est nécessaire pour prendre en charge une partie seulement du trafic global transitant par le pare-feu de périmètre, ce qui permet l'exécution de fonctions de sécurité qui consomment davantage de ressources, telles que les filtres d'application.

Pare-feu de succursales

ISA Server peut être utilisé pour connecter de façon sécurisée des réseaux de succursales à un bureau principal en utilisant des connexions de site à site par réseau privé virtuel (VPN). Dans ce déploiement, ISA Server est placé dans un bureau principal où il fait à la fois office de pare-feu protégeant le réseau des succursales et de passerelle VPN connectant le réseau des succursales à celui du bureau principal.

En général, un VPN de site à site filtré au niveau du transport ne consomme que 25 % de la puissance de traitement par unité de trafic qui est requise pour l'accès Internet filtré au niveau de l'application.

Remarque
Dans un VPN de site à site filtré au niveau du transport, le trafic transitant par le tunnel n'est pas inspecté par les filtres au niveau de l'application. Le filtrage au niveau de l'application pour le trafic VPN de site à site, tout comme n'importe quel autre trafic, est activé en fonction du protocole.

Scénarios de proxy Web

La majeure partie du trafic sur Internet et à l'intérieur des réseaux d'entreprise actuels utilise HTTP. Une analyse du trafic de nombreux protocoles indique que HTTP est exigeant en termes de performances du réseau. C'est la raison pour laquelle les simulations types de charge de trafic Web sont réalistes lorsqu'il s'agit de mesurer les caractéristiques de capacité et de performances de n'importe quel pare-feu.

Remarque
Une mesure type permettant de vérifier les performances du réseau est la quantité de transactions échangées par connexion TCP. Les valeurs types de HTTP (de 3 à 5 en moyenne) sont faibles par rapport à d'autres protocoles.

Le tableau suivant récapitule les recommandations requises en termes de matériel pour prendre en charge le trafic HTTP sur trois déploiements mono-ordinateurs types selon la bande passante de la liaison Internet.

Les valeurs indiquées dans le tableau qui précède correspondent aux paramètres d'installation par défaut d'ISA Server 2004 et à une configuration de stratégie contenant des centaines de règles. Ceci inclut l'ensemble du filtrage d'application et Web par défaut, ainsi que la journalisation MSDE. Les considérations suivantes s'appliquent au tableau qui précède :

ISA Server sécurise le trafic HTTP en utilisant son filtre d'application de proxy Web intégré. Ce filtre d'application prend en charge trois scénarios différents : proxy direct et proxy transparent pour protéger l'accès sortant à Internet pour les utilisateurs de l'entreprise, et proxy inversé pour protéger l'accès entrant des utilisateurs Internet à des sites Web internes. Les sections qui suivent décrivent chacun de ces scénarios du point de vue des performances et expliquent comment la mise en cache permet d'améliorer les performances.  

Scénarios proxy

Cette section décrit des scénarios de proxy direct, de proxy transparent et de proxy inversé.

Proxy direct

En mode proxy direct, les navigateurs Web clients connaissent la présence du proxy. Dans Internet Explorer, par exemple, cela s'effectue en définissant Utiliser un  serveur proxy ou Détecter automatiquement les paramètres de connexion dans Options Internet. Lorsque les clients Web ont connaissance du proxy, ils ouvrent des connexions directement sur ce proxy et lui envoient des requêtes pour connaître les emplacements sur Internet. (Par exemple, Internet Explorer ouvre deux connexions au proxy pour l'envoi des requêtes HTTP 1.1.) Lorsque ISA Server reçoit une requête pour un serveur, il ouvre une connexion à ce serveur et la réutilise pour les requêtes d'autres clients vers le même serveur. Cela conduit à une topologie de connexion en étoile.

En termes de performances, les avantages de ce scénario tiennent au degré élevé de réutilisation des connexions, ce qui réduit le nombre de connexions ouvertes et le taux de connexion.

Proxy transparent

En mode proxy transparent, les navigateurs Web clients ne connaissent pas la présence du proxy. Ils détectent qu'ils sont routés directement vers les serveurs sur Internet sans aucun agent intermédiaire. En particulier, les clients Web accèdent aux serveurs Internet directement en ouvrant des connexions avec les sites Web cibles. Cela augmente considérablement le taux de connexion car, après qu'un utilisateur a demandé une page sur un nouveau serveur, le navigateur Web ferme ses connexions avec le serveur Web en cours et ouvre de nouvelles connexions avec le nouveau serveur Web. Ceci est typique d'un proxy transparent et a une incidence sur les performances d'ISA Server. Généralement, le taux de connexion côté client avec un proxy transparent est environ trois fois supérieur à celui d'un proxy direct, qui consomme approximativement deux fois plus de cycles processeur par requête.

Le mode proxy transparent est un scénario courant car il est facile à déployer, en particulier pour les fournisseurs d'accès Internet (FAI) dont la base de clients est hétérogène. C'est la raison pour laquelle ce scénario présente des améliorations considérables des performances.

En général, ISA Server nécessite deux fois plus de ressources d'UC pour le mode proxy transparent que pour le mode proxy direct.

Proxy inversé

Le mode proxy inversé, ou publication Web, fonctionne de la même manière que le mode proxy direct, mais le sens est entrant et non sortant. Dans ce scénario, ISA Server fait office de site Web accessible aux clients sur Internet. Les clients ne savent pas que le site Web auquel ils accèdent est en réalité un proxy. Comme avec le mode proxy direct, le nombre de connexions et le taux de connexion sont minimes, en raison de la réutilisation efficace des connexions. Le mode proxy inversé s'utilise pour la publication sécurisée de serveurs Web, tels que Microsoft Internet Information Services (IIS), Microsoft Office Outlook® Web Access 2003, Microsoft SharePoint® Portal Server, etc.

Du point de vue des performances, le mode proxy inversé a des caractéristiques semblables à celles du mode proxy direct. La principale différence tient à ce que la majeure partie du trafic circule d'ISA Server vers les utilisateurs Internet, ce qui nécessite une connexion Internet étendue. Comme indiqué dans la section qui suit, les modes proxy direct et proxy inversé ont des impacts différents sur les performances lorsque la mise en cache Web est activée.

Mise en cache Web

La mise en cache Web est une fonction destinée à améliorer les performances d'ISA Server dans tous les scénarios de proxy Web. Toutefois, l'impact sur l'amélioration des performances varie selon que le cache est activé pour les scénarios sortants (proxy direct et transparent) ou pour le scénario de proxy inversé.

La principale différence entre la mise en cache directe (transparente) et la mise en cache inversée est l'objet du cache. La mise en cache directe (transparente) est destinée à réduire les coûts de la bande passante Internet et le temps de réponse en plaçant à proximité des utilisateurs le contenu courant pouvant être mis en cache. La mise en cache inversée sert à décharger les serveurs Web principaux. La mise en cache inversée n'a aucune incidence sur le temps de réponse et à même tendance à augmenter la latence des objets qui ne sont pas mis en cache.

En termes d'économie, la mise en cache directe réduit les tentatives d'accès aux serveurs Web sur Internet en répondant à ces tentatives à partir du cache. Cela permet d'économiser la bande passante requise pour la liaison Internet. Par exemple, si le ratio octet/accès du cache est de 20 % et que le débit maximal sur les liaisons internes est de 10 Mbits/s, le débit maximal sur la liaison Internet ne sera que de 8 Mbits/s.

Remarque
Le ratio objet/accès du cache est le rapport des objets servis à partir du cache sur l'ensemble des objets servis par le proxy. De même, le ratio octet/accès du cache est le rapport des octets servis à partir du cache sur l'ensemble des octets servis par le proxy. Les valeurs moyennes courantes sont d'environ 35 % pour le ratio objet/accès et d'environ 20 % pour le ratio octet/accès.

La mise en cache inversée facilite la consolidation des serveurs Web et permet ainsi de réduire les coûts du matériel et de gestion. Par exemple, si 80 % des données d'un site Web sont statiques et peuvent être mises en cache, et qu'un objet dynamique nécessite quatre fois plus de cycles processeur par rapport à un objet statique, l'utilisation d'un proxy inversé réduit le nombre de serveurs Web de 100 %.

Remarque
Supposons qu'un objet statique nécessite X cycles processeur et qu'un objet dynamique nécessite 4X cycles. Si 80 requêtes sur 100 sont statiques, le nombre total de cycles nécessaires pour 100 requêtes est de 80X + (100-80)4X = 160X, et 50 % de ceux-ci sont utilisés pour le contenu statique qui sera servi par un cache ISA Server.

Une autre différence entre la mise en cache directe et la mise en cache inversée est l'importance de la plage de travail mise en cache. En mode cache inversé, la taille de l'espace du client est illimitée, mais l'espace du serveur ne contient que quelques sites Web et un nombre relativement faible d'objets. Dans la plupart des cas, ISA Server peut être configuré avec une mémoire et un espace disque raisonnables pour stocker dans son cache tout le contenu hébergé pouvant être mis en cache, de sorte que seul le contenu dynamique qui ne peut pas être mis en cache est dirigé vers les serveurs Web hébergés. De préférence, tout le cache peut être conservé et servi en mémoire.

En mode cache direct, l'espace serveur contient un nombre illimité de sites Web et d'objets Web, de sorte que la plage de travail du cache est également sans limite. Pour contenir une plage de travail aussi étendue, vous devez définir des caches disque de grande taille. Les sections qui suivent expliquent comment planifier et régler la capacité du cache Web pour la mise en cache directe et inversée.

Réglage de la mémoire et des disques en mode cache direct

En mode cache direct, le ratio objet/accès et le taux maximal de requêtes HTTP servent à déterminer le nombre de disques nécessaires, selon la formule suivante :

Par exemple, si le taux maximal de requêtes est de 900 requêtes par seconde et si le ratio objet/accès de 35 %, quatre disques sont nécessaires.

Remarque
Le nombre 100 de la formule qui précède est empirique et signifie qu'un disque physique aux performances moyennes (dont la vitesse de rotation peut atteindre 10 000 tours par minute) peut servir 100 opérations d'E/S par seconde. Un disque plus rapide, dont la vitesse de rotation peut atteindre 15000 tours par minute, peut servir 130 à 140 opérations d'E/S par seconde.

Nous recommandons l'utilisation de disques dédiés de type et de capacité identiques. Si un sous-système de stockage RAID est utilisé, il convient de le configurer en RAID 0 (sans tolérance aux pannes). Des disques de petite taille, si possible ne dépassant pas 40 Go, sont recommandés.

Le réglage de la mémoire cache est plus complexe. Dans les scénarios avec cache, la mémoire est utilisée pour les éléments suivants :

Par défaut, le cache mémoire correspond à 10 % de la mémoire physique totale, et il est configurable. En général, nous recommandons d'utiliser le paramètre par défaut, sauf si des défauts de page matériels se produisent. Les défauts de page matériels provoquent une grave dégradation des performances. Le moyen le plus simple de remédier à cette situation lorsque la mise en cache est utilisée consiste à réduire la taille du cache mémoire.

En tenant compte de ces informations, utilisez le processus suivant pour régler la taille de la mémoire cache :

Réglage de la mémoire et des disques en mode cache inversé

En mode cache inversé, la taille de la plage de travail est tellement plus petite, comparée à celle du mode cache direct, qu'il est pertinent de tenter de tout placer en mémoire. La taille de la plage de travail est la quantité totale d'objets pouvant être mis en cache sur le site Web que le cache héberge. Il est recommandé de définir la taille du disque et du cache mémoire à environ deux fois celle de la plage de travail pour contenir tous les objets pouvant être mis en cache, et de tenir compte de la fragmentation dans la stratégie d'allocation de disque et d'actualisation du cache. Par exemple, une plage de travail de 500 Mo nécessite un cache disque de 1 000 Mo et une mémoire de 1 500 Mo avec la taille du cache de la mémoire définie à 66 %.

Comme la plupart des extractions du cache sont servies à partir du cache mémoire, le taux d'E/S sur le disque est faible. Dans la plupart des cas, un seul disque physique suffit, sans constituer un goulet d'étranglement.

Utilisation du commutateur /3GB dans le fichier Boot.ini

Pour les systèmes importants de plus de 2 Go de mémoire, Windows Server 2003 et Windows 2000 Advanced Server offrent la fonction de réglage 4GT RAM. Cette fonction répartit l'espace mémoire d'un processus en 3 Go pour la mémoire d'application et 1 Go pour la mémoire système. Elle permet aux processus de bénéficier de plus de 2 Go de RAM dans l'espace de l'utilisateur ; pour l'activer, ajoutez le commutateur /3GB au fichier Boot.ini. (Pour plus d'informations, consultez l'article Q171793, « Information on Application Use of 4GT RAM Tuning » (en anglais) dans la Base de connaissances Microsoft.)

Cette fonction peut être avantageuse avec ISA Server, en particulier pour la mise en cache inversée hébergeant un grand site Web. Toutefois, son utilisation réduit la taille maximale de la réserve non paginée (à 128 Mo au lieu de 256 Mo), d'où le nombre maximal de connexions TCP simultanées.

Authentification Web

Il existe de nombreuses méthodes d'authentification Web, chacune ayant un impact particulier sur les performances. Le tableau suivant récapitule les avantages et les inconvénients de chacune de ces méthodes.

Du point de vue des performances, un schéma d'authentification fonctionne mieux sans surcharge par requête et avec une faible surcharge par lot. La décision concernant le schéma d'authentification à utiliser dépend de la puissance et de l'infrastructure.

En outre, l'authentification du proxy Web peut être configurée au niveau du port d'écoute du proxy Web ou au niveau de la règle. Ne choisissez le niveau du port d'écoute que si l'authentification est requise pour tous les accès Web. Sinon, choisissez le niveau de la règle, ce qui signifie que l'authentification n'est exécutée que si les règles l'exigent.

Filtres Web

À l'instar des filtres d'application, les filtres Web peuvent également avoir un impact sur les performances, selon leur fonction. ISA Server est doté de plusieurs filtres Web exécutant des tâches spécifiques. Parmi ces filtres, ceux qui consomment le plus de ressources de l'UC sont le filtre HTTP et le filtre de transition de liaison.

Un filtre HTTP inspecte chaque requête Web et la réponse, en vérifiant qu'elles sont conformes à l'utilisation normale du protocole HTTP. Il est activé par défaut et sa configuration par défaut fournit des limites de taille pour les en-têtes HTTP et l'URL. Les autres fonctions disponibles sont le blocage par méthodes, extensions, en-têtes et signatures de charge utile HTTP. Ces fonctions n'ont aucun impact sur les performances lorsqu'elles sont sélectionnées, excepté pour le blocage de signature qui nécessite 10 % de cycles d'UC supplémentaires. Un filtre HTTP est recommandé pour protéger le trafic Web.

La transition de liaison est utilisée spécifiquement dans les scénarios de publication Web. Elle vérifie les corps de réponse HTML pour rechercher des liens hypertexte absolus et les change pour les faire pointer vers l'ordinateur ISA Server. Par défaut, la transition de liaison ne vérifie que les en-têtes HTTP et non les corps de réponse, de sorte qu'elle ne doit avoir aucun impact notable sur les performances. En outre, lorsque l'analyse du corps est activée, elle ne vérifie par défaut que le contenu HTML, ce qui se traduit par une augmentation globale de 5 % de l'utilisation de l'UC.

Publication Web sécurisée

À l'aide de SSL (Secure Sockets Layer), ISA Server améliore la publication sécurisée de différents contenus Web. ISA Server, avec SSL, permet un accès privé aux sites Web publiés et, pour les utilisateurs d'entreprise, un accès plus sécurisé à différentes ressources réseau internes, telles que le courrier électronique, les sites Web partagés, les services Terminal Server, etc.

SSL est un protocole TCP qui utilise le port 443. SSL est également connu sous l'acronyme HTTPS (Secure HTTP), car il définit l'habillage, l'authentification et le cryptage sécurisés du contenu HTTP.

Du point de vue des performances, le cryptage et le décryptage SSL créent une couche supplémentaire de traitement, qui s'ajoute au traitement HTTP normal. Cette couche comprend les deux phases principales suivantes qui sollicitent particulièrement l'UC :

Le ratio entre débit cumulé et taux de connexion détermine le nombre moyen de bits traités pour chaque connexion. Ce ratio se définit en bits par connexion et, dans la pratique, chaque application a une valeur caractéristique pour ce ratio.

Vous en trouverez quelques exemples ci-après.

Outlook Web Access

Lorsqu'un client Web se connecte à un serveur principal Outlook Web Access Exchange Server, il charge la page Web Outlook qui contient les icônes de l'interface utilisateur et les en-têtes des messages qui se trouvent dans la boîte aux lettres. Ensuite, toute opération effectuée par l'utilisateur (Ouvrir, Envoyer ou Déplacer vers un dossier) génère une nouvelle connexion HTTP qui transfère en moyenne 10 à 20 kilo-octets (Ko). En cumulant le comportement d'Outlook Web Access sur un grand nombre d'utilisateurs, le client Web crée généralement un nombre relativement faible de bits par connexion (par exemple 100 kilobits par connexion).

RPC sur HTTP avec le mode Exchange mis en cache d'Outlook 2003

RPC (Remote procedure call) sur HTTP est une fonction de Microsoft Exchange Server 2003 qui permet aux clients d'Outlook 2003 d'accéder à un serveur Exchange du réseau d'entreprise interne depuis Internet. Lorsqu'il se connecte à Exchange Server, un client Outlook 2003 travaillant en mode Exchange mis en cache commence en général par une synchronisation du contenu de la boîte aux lettres avec un fichier de cache local. Lorsque la synchronisation est terminée, il se produit des connexions intermittentes vers lesquelles les nouveaux messages sont transférés. Pour un utilisateur expérimenté employant un profil d'utilisation important, l'opération de synchronisation transfère un grand nombre d'octets de données sur un petit nombre de connexions, de sorte que la valeur caractéristique de bits par connexion est assez élevée (par exemple 500 kilobits par connexion).

Site Web

Il existe de nombreux moyens de concevoir et d'implémenter un site Web. C'est la raison pour laquelle les sites Web n'ont pas de valeur type de bits par connexion. Toutefois, lorsqu'un site Web sert des requêtes, vous pouvez mesurer la valeur cumulée des bits par connexion. Dans la pratique, les sites Web ont une valeur moyenne de bits par connexion (entre 100 et 500 kilobits par connexion).

Pont SSL

Lorsque vous déployez ISA Server avec la publication Web sécurisée, les clients Web sécurisés sur le réseau externe peuvent se connecter au port SSL. Le pont SSL est une fonction d'ISA Server qui vous permet de spécifier comment ISA Server communique avec le serveur Web principal qui est publié. Vous avez le choix entre les deux types de ponts suivants :

Le pont SSL à SSL renforce la sécurité sur le réseau interne, mais ajoute le coût de traitement du double cryptage à chaque paquet transféré entre ISA Server et le serveur principal. Le pont SSL à SSL coûte entre 20 et 30 % de plus que le pont SSL à HTTP.

Détermination de la capacité SSL

Pour déterminer la taille de l'ordinateur ISA Server que vous devez avoir pour prendre en charge les charges maximales de trafic réseau, vous devez d'abord mesurer les kilobits par connexion type de votre trafic réseau, puis le trafic total cumulé. Utilisez la procédure suivante :  

Par exemple, supposons que la valeur des kilobits par connexion calculés à l'étape 2 soit 200, le débit total cumulé 15 mégabits, et que vous demandiez à ISA Server d'exécuter la fonction de pont SSL à SSL. D'après le tableau qui précède, un processeur unique nécessite 96 mégacycles par mégabit ou
96 × 15 = 1 440 mégacycles pour 15 mégabits par seconde. Un processeur Intel Pentium 4 à 2,4 GHz est suffisant pour cette charge et est utilisé à 1 440 / 2 400 = 60 % au débit maximal. Un ordinateur doté de deux processeurs Intel Pentium 4 à 2,4 GHz nécessite 120 mégacycles par mégabit ou 120 × 15 = 1 800 mégacycles pour 15 mégabits par seconde et est utilisé à 1 800 / (2 × 2 400) = 38 % au débit maximal.

Le tableau suivant montre la quantité de trafic en mégabits qu'un processeur à 2,4 GHz peut traiter dans le cadre de l'utilisation maximale recommandée (80 %).

Ce tableau concerne de façon spécifique les déploiements dans lesquels ISA Server n'est utilisé que pour le trafic SSL. Si vous envisagez de déployer ISA Server pour le trafic SSL et le trafic HTTP non crypté, vous pouvez estimer la puissance de traitement dont vous avez besoin en calculant une moyenne pondérée de mégacycles, selon la quantité de trafic pour chaque scénario multipliée par les mégacycles par mégabit, comme indiqué dans le tableau suivant.

Supposons, par exemple, que vous vouliez déployer ISA Server dans un scénario de pare-feu de périmètre dans lequel 40 % du trafic maximal de 20 mégabits par seconde sont en mode proxy transparent, 35 % en mode proxy direct et 25 % en mode SSL à SSL avec 200 kilobits par connexion. Le nombre total de mégacycles requis pour qu'ISA Server traite ce trafic sur un ordinateur monoprocesseur est de :

mégacycles = 20 mégabits par seconde × (74 × 40 % + 37 × 35 % + 96 × 25 %) = 1 331

Un processeur Intel Pentium 4 à 2,4 GHz est suffisant pour traiter cette charge et est utilisé à
1 331 / 2 400 = 55 % au débit maximal. Un ordinateur biprocesseur nécessite
20 × (86 × 40 % + 43 × 35 % + 120 × 25 %) = 1 589 mégacycles, ce qui utilise
1 589 / (2 400 × 2) = 33 % de deux processeurs Intel Pentium 4 à 2,4 GHz au débit maximal.

Filtrage avec état

Le filtrage avec état inspecte les données au niveau du transport et est implémenté dans le pilote en mode noyau du moteur de paquets de pare-feu d'ISA Server. Le filtrage avec état évalue les adresses IP source et de destination, les numéros de port et les options de l'indicateur TCP/UDP, ainsi que les types et codes ICMP (Internet Control Message Protocol). Il utilise ces informations pour déterminer l'état de la connexion, en autorisant les paquets conformes à cet état et en refusant ceux qui ne le sont pas.

Le filtrage avec état ne nécessite qu'une faible quantité des ressources requises par le filtrage au niveau de l'application. La même quantité de trafic HTTP qui utilise 75 % de la puissance de l'UC avec le filtrage de proxy Web n'emploiera que 8 % de la puissance de l'UC avec le filtrage avec état (un facteur d'amélioration des performances de 10).

VPN

Un réseau privé virtuel (VPN) est constitué de deux scénarios de base : VPN d'accès à distance et VPN de site à site. Les deux peuvent utiliser plusieurs protocoles et travailler conjointement avec le filtrage d'application ou le filtrage avec état. Les protocoles IPsec (Internet Protocol security) peuvent également utiliser les fonctions de déchargement du matériel, disponibles dans un grand nombre de cartes réseau, pour améliorer l'utilisation globale du processeur. Certains protocoles peuvent fonctionner avec la compression pour accroître le débit ou économiser la bande passante. Toutes ces fonctions ont un impact sur les performances, comme l'expliquent les sections suivantes.  

VPN d'accès à distance

Les clients à distance se connectant à partir d'Internet utilisent l'accès à distance au VPN pour accéder à leur réseau d'entreprise. Les protocoles utilisés dans l'accès à distance sont PPTP (Point-to-Point Tunneling Protocol) et L2TP (Layer Two Tunneling Protocol) sur IPsec (Internet Protocol security). Ces deux protocoles prennent en charge la compression. Celle-ci est recommandée car elle économise la bande passante et la puissance de traitement nécessaire au cryptage.

Pour déterminer la capacité adéquate d'un serveur VPN ISA Server, vous devez d'abord évaluer le nombre maximal de connexions à distance simultanées que votre ordinateur ISA Server doit prendre en charge. Par exemple, si vous envisagez de n'avoir pas plus de 5 % des employés de votre entreprise qui établissent des connexions à distance simultanément, et si votre entreprise compte 5 000 employés, vous avez besoin d'une capacité de 250 connexions d'accès à distance au VPN.

Le tableau suivant indique le nombre maximal de connexions simultanées d'accès à distance au VPN prises en charge pour chaque plate-forme matérielle. Ces chiffres impliquent l'installation directe d'ISA Server avec le filtrage de proxy Web, la journalisation MSDE et la compression pour les deux protocoles PPTP et L2TP sur IPsec.

Les considérations suivantes s'appliquent au tableau qui précède :

Dans les déploiements où le niveau de fiabilité des clients VPN peuvent être considéré comme supérieur, le filtrage au niveau de l'application peut être désactivé, ce qui améliore la capacité totale et réduit le niveau de sécurité. Le tableau suivant indique les valeurs lorsque le filtrage du proxy Web est désactivé.

Les considérations suivantes s'appliquent au tableau qui précède :

VPN de site à site

Dans un VPN de site à site, il existe deux grands choix du point de vue des performances et de la capacité. L'un des choix consiste à utiliser PPTP ou L2TP sur IPsec. Ces protocoles fournissent la compression du trafic de l'application, qui double le débit pouvant être transféré via la liaison de site à site. Par exemple, l'envoi d'un fichier de 2 Mo par l'intermédiaire d'un tunnel PPTP ou L2TP ne transmet en réalité que 1 Mo. L'autre choix consiste à utiliser le tunnel IPsec, sans la compression. Ainsi, par rapport au tunnel IPsec, PPTP et L2TP sur IPsec économisent 50 % du trafic de site à site.

Lorsque le filtrage de proxy Web est désactivé, L2TP sur IPsec nécessite un processeur Pentium III à 550 MHz pour un trafic d'application de 15 Mbits/s. La transmission d'un tel trafic dans un sens nécessite une capacité de liaison de 7,5 Mbits/s seulement du fait de la compression. Un processeur Pentium 4 à 3 GHz peut gérer un trafic d'application de 90 Mbits/s nécessitant une capacité de liaison T3 (45 Mbits/s). Lorsque le filtrage de proxy Web est activé, un processeur Pentium III à 550 MHz peut gérer un trafic d'application de 7 Mbits/s nécessitant une bande passante de liaison Internet de 3,5 Mbits/s, tandis qu'un Pentium 4 à 3 GHz peut gérer un trafic d'application de 34 Mbits/s correspondant à une bande passante Internet de 17 Mbits/s. Deux processeurs Xeon à 3 GHz peuvent gérer un trafic d'application de 53 Mbits/s nécessitant une bande passante de liaison Internet de 26,5 Mbits/s. PPTP peut gérer entre 15 et 20 % de débit supplémentaire pour la même consommation d'UC.

Le second choix consiste à utiliser le tunnel IPsec, qui ne prend pas en charge la compression. Autrement dit, le trafic de la liaison Internet est identique au trafic d'application. Utilisé conjointement avec le filtrage avec état (le filtre de proxy Web est désactivé), le tunnel IPsec peut gérer 10 Mbits/s sur un processeur Pentium III à 550 MHz et 52 Mbits/s sur un processeur Pentium 4 à 3 GHz. Lorsque le filtrage de proxy Web est activé, les valeurs de débit sont respectivement 4 Mbits/s, 18 Mbits/s et 30 Mbits/s pour les plates-formes à un processeur Pentium III, à un processeur Pentium 4 et à deux processeurs Xeon.

Le tableau suivant récapitule ces résultats, à savoir les mégabits par seconde réellement pris en charge à 75 % d'utilisation de l'UC. (Les valeurs entre parenthèses représentent les volumes de trafic non compressés.)

Le matériel de déchargement IPsec, disponible dans de nombreuses cartes d'interface réseau, peut accroître les valeurs de débit de 20 à 25 %.

Haut de page

Évolution d'ISA Server

Il existe plusieurs manières de faire évoluer un système ISA Server :

Comme ISA Server gère un état pour chaque flux qui le traverse, toutes les méthodes d'évolution doivent prendre en charge l'adhésivité afin que toutes les données transitent par l'ordinateur ISA Server.

L'évolution d'un système consiste à en accroître la capacité. Chaque méthode d'évolution présente des avantages et des inconvénients. Pour ISA Server, elle dépend également du scénario. Pour choisir une méthode d'évolution, tenez compte des points suivants :

Certains compromis sont nécessaires lorsque vous décidez de faire évoluer le système :

Le tableau suivant récapitule les méthodes d'évolution.

Les considérations suivantes s'appliquent au tableau qui précède :

Haut de page

Dimensionnement du serveur de stockage de configuration

L'un des composants de serveur introduits par ISA Server 2004 Enterprise Edition est le composant serveur de stockage de configuration. Le serveur de stockage de configuration est le référentiel de l'agencement de l'entreprise et indique la configuration de chacun de ses ordinateurs ISA Server. Ce référentiel est une instance d'ADAM (Active Directory® Application Mode). Chaque ordinateur ISA Server possède une copie locale de sa configuration qui est une réplique de la configuration du serveur, située sur le serveur de stockage de configuration.

Le nombre recommandé d'ordinateurs ISA Server pouvant se connecter à un seul serveur de stockage de configuration est de 40, le nombre maximal recommandé étant de 60. Ces nombres ont été estimés à partir des mesures de performances de l'opération qui consomme le plus de ressources sur le serveur de stockage de configuration : l'importation d'une stratégie à grande échelle contenant des centaines de règles avec des milliers de références à l'objet stratégie, qui se traduit par un fichier XML (Extensible Markup Language) de 6 Mo environ. Dans ce scénario, le serveur de stockage de configuration importe le fichier XML et crée une nouvelle configuration. Dès que le serveur de stockage de configuration commence à écrire les nouvelles données de configuration sur le disque, tous les ordinateurs ISA Server connectés commencent à extraire cette configuration simultanément, ce qui provoque une charge considérable pour l'UC, le réseau et les E/S de disque sur le serveur de stockage de configuration. Lorsqu'un ordinateur doté de deux processeurs Intel Pentium 4 à 2 GHz avec 512 Mo de mémoire physique pour le serveur de stockage de configuration est utilisé, les mesures font apparaître que le serveur de stockage de configuration peut gérer un niveau de 2 600 requêtes LDAP (Lightweight Directory Access Protocol) par seconde. Le nombre total de requêtes LDAP par ordinateur ISA Server requises pour la synchronisation avec l'importation d'une stratégie à grande échelle est de 7 000. Ces valeurs se traduisent de la façon suivante en temps requis pour la synchronisation complète de tous les ordinateurs ISA Server après que le serveur de stockage de configuration a importé un fichier XML de stratégie à grande échelle :

Temps total d'importation = Temps de l'importation XML + Temps d'écriture de la configuration sur le disque + Temps de synchronisation de la configuration par tous les ordinateurs ISA Server

Où :

Temps de l'importation XML = 120 secondes

Temps d'écriture de la configuration sur le disque = 120 secondes

Temps de synchronisation de la configuration par N ordinateurs ISA Server = N × 7 000 / 2 600 = 2,7 × N secondes

Le tableau suivant récapitule ces résultats.

Au cours des deux premières phases (importation XML et écriture de la configuration sur le disque), le niveau d'utilisation de l'UC était approximativement de 50 %. En effet, cela est effectué par un seul thread qui ne peut pas consommer plus de 50 % de la puissance de traitement d'un ordinateur biprocesseur. Sur les ordinateurs monoprocesseurs, la consommation d'UC sera de 100 % dans ces phases, situation qui doit être évitée. C'est pourquoi, nous recommandons de déployer des ordinateurs biprocesseurs pour le serveur de stockage de configuration ou d'activer l'hyper-threading sur un ordinateur monoprocesseur (avec des processeurs Pentium 4).

Pour plus d'informations sur le déploiement du serveur de stockage de configuration d'ISA Server, consultez le document (en anglais) ISA Server 2004 Enterprise Edition Deployment Guidelines (http://www.microsoft.com).

Haut de page

Référence et exemple de dimensionnement

Cette section fournit une référence centrale et un résumé du dimensionnement d'ISA Server 2004 Standard Edition et Enterprise Edition. Le premier tableau indique les mégacycles par mégabit pour les scénarios de proxy Web, SSL, VPN et de filtrage avec état.

Les considérations suivantes s'appliquent au tableau qui précède :

Les valeurs du tableau qui précède ont été obtenues à partir des hypothèses suivantes :

Le tableau qui suit fournit les facteurs d'échelle NLB à utiliser lorsque l'évolution NLB est appliquée pour accroître la capacité.

Les considérations suivantes s'appliquent au tableau qui précède :

L'exemple qui suit indique comment utiliser les tableaux qui précèdent pour calculer le matériel nécessaire pour prendre en charge des besoins de trafic spécifiques.

Supposons qu'un grand site ait une bande passante de liaison Internet de 80 mégabits par seconde qui soit entièrement employée aux heures d'utilisation maximale. Pendant ce temps, 10 % du trafic câblé sont utilisés pour l'accès VPN distant (L2TP sur IPsec avec le filtre Web activé), 20 % pour Outlook Web Access (avec le pont SSL à HTTP) et 70 % pour la navigation Web sortante (50 % en mode proxy transparent et 50 % en mode proxy direct). Pour calculer les mégacycles nécessaires à ce trafic, calculez d'abord les mégacycles pondérés par mégabit, en supposant le déploiement d'un seul ordinateur à deux processeurs Xeon (sans équilibrage de charge) :

Mégacycles/mégabit = 353 × 10 % + 128 × 20 % + 86 × 35 % + 43 × 35 % = 107

Le nombre total de mégacycles par seconde requis pour 80 mégabits par seconde est de 80 × 107 = 8 560.

Un ordinateur à deux processeurs de 3 GHz n'a que 2 × 3 000 × 75 % = 4 500 mégacycles lorsqu'il est utilisé à 75 %, ce qui est insuffisant. Il est nécessaire d'ajouter des ordinateurs. À ce stade, la quantité nécessaire n'est pas clairement définissable (probablement deux, mais peut-être trois). Pour calculer le nombre pondéré de mégacycles requis par mégabit, multipliez le nombre de mégacycles par mégabit de chaque type de trafic par son facteur d'échelle correspondant et n'oubliez pas d'effectuer une autre pondération de +15 %. Pour un ensemble à deux membres, utilisez 1,143 pour le trafic Web (en supposant une architecture de type Broadcast Driver) et 1,053 pour le trafic VPN et SSL. Le résultat est le suivant :

Mégacycles pondérés/mégabit en supposant un ensemble à deux membres =

115 % × (353 × 10 % × 1,053 +

128 × 20 % × 1,053 +

86   × 35 % × 1,143 +

49   × 35 % × 1,143) = 133

Le résultat total des mégacycles par seconde requis est de 80 × 133 = 10 640. Ce nombre est trop important pour être servi par deux membres. (Deux ordinateurs à deux processeurs à 3 GHz ne prennent en charge que 2 × 4 500 = 9 000 mégacycles par seconde.) Trois ordinateurs auront probablement suffisamment de puissance pour supporter cette charge. Le résultat du calcul est le suivant :

Mégacycles pondérés/mégabit en supposant un système à trois membres =

115 % × (353 × 10 % × 1,085 +

128 × 20 % × 1,085 +

86   × 35 % × 1,236 +

49   × 35 % × 1,236) = 140

Le résultat total des mégacycles par seconde requis est de 80 × 140 = 11 200. Trois ordinateurs à deux processeurs à 3 GHz fournissent 13 500 mégacycles par seconde à 75 % d'utilisation du processeur. Ceci suffit à supporter cette charge et offre même une possibilité de croissance.

Haut de page

Informations complémentaires

Pour plus d'informations, consultez les documents suivants (en anglais) :

Avez-vous des commentaires à formuler à propos de ce document ? Envoyez vos commentaires.

Haut de page