Internet Data Center : Conception de l'infrastructure réseau
Sur cette page
.gif){kind=icon}
Microsoft Internet Data Center : Conception de l'infrastructure réseau
Résumé
Introduction
Éléments de réseau : Présentation
Clients Internet
Routeurs périphériques
Équilibrage de charge
Serveurs tournés vers Internet
Commutateurs multicouches (commutateurs de routage)
Pare-feu
Serveurs d'infrastructure
Serveurs de données et de gestion
Connexion d'entreprise
Conception et objectifs de l'architecture de réseau
Capacité de gestion du flux de trafic
Capacité de gestion de la sécurité
Disponibilité du réseau
Évolutivité du réseau
Architecture simple
Conception de routeur
Routeur périphérique Internet
Routeur périphérique VPN
Conception du service DNS
Services DNS externes
Services DNS internes
Conception DNS fractionné-fractionné
Conception de l'Équilibrage de charge réseau
Mécanismes d'Équilibrage de charge
Association de cartes réseaux
Comportement d'équilibrage de charge distribué
Réglage de la vitesse du réseau et du fonctionnement en duplex
Équilibrage de charge réseau en mode monodiffusion
Équilibrage de charge réseau de ISA Server
Utilisation de l'Équilibrage de charge réseau sur les serveurs Web
Équilibrage de charge réseau et ports
Paramètres TCP/IP
Utilisation de l'Équilibrage de charge réseau sur les serveurs de VPN
Règles de port
Paramètres TCP/IP
Considérations supplémentaires
Conception de réseau commuté
Conception de VLAN
Flux du trafic réseau entre les VLAN
Exigences du trafic Internet
Schéma d'adressage TCP/IP
Affectation d'adresses publiques
Réseau d'entreprise
Schéma complet du système
Résumé
Microsoft Internet Data Center : Conception de l'infrastructure réseau
Cet article est tiré du Guide de référence Internet Data Center
Résumé
Ce chapitre décrit la conception du réseau Microsoft® Internet Data Center. Il fournit un aperçu des éléments architecturaux, tels que les routeurs et les commutateurs, et de la conception et des composants d'infrastructure Web. Il discute également de la configuration du système d'exploitation Microsoft Windows® 2000 Server et du trafic entre les réseaux locaux virtuels (VLAN, Virtual Local Area Networks). Vous trouverez dans les chapitres suivants de ce guide des détails supplémentaires concernant la conception de Internet Data Center.
Introduction
Ce chapitre décrit la conception du réseau Microsoft® Internet Data Center. Il fournit un aperçu des éléments architecturaux, tels que les routeurs et les commutateurs, et de la conception et des composants d'infrastructure Web. Il discute également de la configuration du système d'exploitation Microsoft Windows® 2000 Server et du trafic entre les réseaux locaux virtuels (VLAN, Virtual Local Area Networks). Vous trouverez dans les chapitres suivants de ce guide des détails concernant les aspects spécifiques de la conception de Internet Data Center.
Éléments de réseau : Présentation
Les principaux éléments de l'architecture du réseau Internet Data Center sont les clients, les routeurs périphériques, les équilibreurs de charge, les serveurs Web frontaux clonés, les commutateurs multicouches, les pare-feu, les serveurs d'infrastructure et les systèmes de base de données et de gestion principaux. Cette section se concentre sur les composants logiques permettant de disposer d'une infrastructure évolutive, disponible, sécurisée et gérable.
Clients Internet
Dans l'environnement Internet Data Center, les clients émettent des requêtes à un nom de service qui représente l'application délivrée au client. Le système de l'utilisateur final et le logiciel client n'ont aucune connaissance du fonctionnement interne du système délivrant le service. L'utilisateur final tape généralement le premier URL, par exemple, http://www.blueyonderairlines.com, puis clique sur des liens hypertextes ou remplit des formulaires sur des pages Web pour parcourir le site plus en profondeur. Dans les scénarios interentreprises (BtoB, Business-to-Business), le client est un autre ordinateur serveur du site du partenaire qui exécute un processus automatisé et se connecte à des services exposés sur le serveur BtoB Internet Data Center local. Un exemple de ce scénario serait deux serveurs exécutant Microsoft BizTalk™ et échangeant des documents lors du processus de gestion de chaîne d'approvisionnement.
Routeurs périphériques
Les routeurs périphériques relient l'infrastructure aux réseaux du Fournisseur d'accès à Internet (FAI). Pour les environnements Web d'entreprise haut de gamme, une redondance complète doit être envisagée. La redondance complète exige au moins deux routeurs périphériques, chacun connecté à un FAI différent. Cette implémentation fournit une tolérance de pannes et une agrégation du trafic. Les routeurs doivent exécuter le protocole BGP (Border Gateway Protocol), afin de garantir un routage correct et rapide. La plupart des routeurs sont capables d'appliquer des stratégies de trafic qui doivent être utilisées pour aider à sécuriser un réseau périphérique et ajouter un niveau de sécurité supplémentaire pour le réseau interne.
Équilibrage de charge
L'Équilibrage de charge réseau permet de distribuer la charge entre plusieurs serveurs et de bénéficier d'une haute disponibilité. Dans la conception de Internet Data Center, l'équilibrage de charge est utilisé pour les systèmes Web frontaux et les pare-feu périphériques. Cette conception fournit à la fois une résilience et une évolutivité aux éléments de réseau les plus importants.
Serveurs tournés vers Internet
Les serveurs tournés vers Internet (serveurs frontaux) sont ceux qui fournissent les services Web fondamentaux, tels que HTTP et HTPPS, aux serveurs ou clients Internet. Les développeurs regroupent généralement ces systèmes frontaux en ensembles de systèmes identiques nommés clones. Les clones exécutent les mêmes logiciels et ont accès aux mêmes fichiers HTML, contenu Web, pages ASP, scripts et ainsi de suite, soit grâce à une réplication de contenu, soit à partir d'un partage de fichiers hautement disponible. De hauts niveaux d'évolutivité et de disponibilité peuvent être atteints grâce à l'équilibrage de la charge de requêtes sur l'ensemble des clones, et à la détection de tout clone défectueux et sa séparation des autres clones opérationnels. Vous trouverez plus loin dans ce chapitre des détails sur la manière dont la conception de Internet Data Center implémente ces technologies au niveau des systèmes Web frontaux.
Commutateurs multicouches (commutateurs de routage)
La conception peut être implémentée avec plusieurs périphériques physiques ou deux commutateurs multicouches. La configuration de Internet Data Center utilise deux commutateurs multicouches pour conserver une certaine simplicité, une capacité de gestion et une flexibilité. Les commutateurs sont partitionnés comme périphériques logiques multiples de Couche 2. Des VLAN sont créés et chevauchent les deux commutateurs afin de fournir une tolérance de pannes matérielles. Les serveurs sont configurés avec deux cartes réseau travaillant en équipe et connectées au même VLAN sur chaque commutateur physique. Le trafic entre les VLAN est acheminé grâce au routeur interne dans chaque commutateur principal, et contrôlé grâce à l'utilisation de listes de contrôle d'accès (ACL, Access Control Lists). Certains analystes de réseau et de sécurité considéreront peut-être qu'il est imprudent de placer les réseaux interne et externe sur le même périphérique physique. Toutefois, ceci ne constituerait un danger que si ce périphérique physique était mal configuré. La plupart des périphériques multicouches sont très sécurisés et, s'ils sont configurés correctement, ne présentent aucun problème de sécurité. Si cet aspect demeure un sujet d'inquiétude, vous pouvez simplement déplacer les réseaux périphériques des commutateurs principaux vers des périphériques physiques séparés.
Pare-feu
Un pare-feu est un mécanisme de contrôle du flux de données entre deux parties d'un réseau bénéficiant de niveaux d'approbation différents. La conception de la solution de pare-feu dans l'architecture Internet Data Center est décrite dans le Chapitre 3, "Conception de pare-feu".
Serveurs d'infrastructure
Le VLAN d'infrastructure a été créé pour héberger les contrôleurs de domaine exécutant Windows 2000 avec le service d'annuaire Active Directory™ et DNS (Domain Name System). En fonction de la conception de l'application, le VLAN d'infrastructure peut aussi héberger des serveurs exécutant des composants et des objets professionnels (par exemple BizTalk Server 2000 ou Message Queuing). Si l'application est conçue pour prendre en charge trois niveaux, le réseau d'infrastructure peut héberger des services et de la logique d'application. La plupart des applications sont conçues logiquement comme des systèmes à trois niveaux, mais cette conception prend aussi en charge une application à deux niveaux physiques, ce qui permet aux serveurs Web de communiquer directement avec les serveurs exécutant SQL Server.
Serveurs de données et de gestion
Les systèmes principaux sont les banques de données qui assurent la maintenance des données d'application, où ils procurent une connectivité avec d'autres systèmes qui assurent la maintenance des ressources de données. Les données peuvent être stockées dans des fichiers non hiérarchisés ou dans des systèmes de base de données tels que des systèmes principaux SQL Server 2000. Il est plus difficile de rendre les systèmes de base de données évolutifs et hautement disponibles, principalement en raison des données et des états qu'ils doivent maintenir.
Pour une disponibilité accrue, un cluster prend en charge chaque partition.
Ces clusters sont généralement composés de deux nœuds disposant d'un accès au stockage commun, répliqué et protégé par RAID. En cas de défaillance du service sur l'un des nœuds, l'autre nœud assume la responsabilité de la partition et offre le service.
Connexion d'entreprise
La connexion d'entreprise est la liaison entre le centre IDC et le réseau interne utilisé par l'entreprise. Bien que la connexion d'entreprise dépasse la portée de ce chapitre, les exigences de connectivité liées à la gestion et/ou à la génération de rapports peuvent se révéler importantes. La configuration de cette connexion est cruciale car elle ne doit pas avoir d'impact sur la sécurité, la fiabilité ou la disponibilité de l'architecture du centre de données. Vous trouverez plus loin dans ce chapitre des détails sur les options disponibles pour cette connexion et sur la façon dont elles sont implémentées par le centre IDC.
Conception et objectifs de l'architecture de réseau
La flexibilité de la conception de Internet Data Center est due à son utilisation des technologies VLAN pour séparer les serveurs et le trafic de communication. Les principaux VLAN créés en vue de satisfaire aux différentes exigences de trafic des serveurs sont des VLAN de DMZ, d'infrastructure et de données/gestion (illustrés sous la forme de canaux de réseau sur la figure ci-dessous).
.gif)
Figure 1. Aperçu de la conception de base de Internet Data Center
Les VLAN de DMZ, d'infrastructure et de données et de gestion sont les VLAN fondamentaux pour les décisions de conception prises au sein de l'architecture. Le réseau de la DMZ est composé de serveurs Web multiconnectés et des serveurs DNS externes qui peuvent être interrogés directement par les utilisateurs sur Internet à travers les pare-feu Internet périphériques. La DMZ est en fait constituée de trois VLAN. Les raisons en sont expliquées plus loin dans ce document, mais pour le moment nous utiliserons le terme de "VLAN de la DMZ" pour faire référence à ces trois réseaux. Le VLAN de données et de gestion est composé des serveurs de base de données SQL Server 2000 et d'autres serveurs de gestion et de sauvegarde nécessaires. Le VLAN d'infrastructure contient des serveurs qui fournissent des services requis par le VLAN de la DMZ ou le VLAN de données et de gestion, par exemple Active Directory et DNS. Des services supplémentaires seront ici ajoutés au fil du développement de l'application Internet Data Center. Par exemple, des détails sur Microsoft Commerce Server 2000 et BizTalk Server sont fournis plus loin dans ce guide, dans les chapitres portant sur la conception de BizTalk et Commerce Server.
Avant de rentrer dans les détails de chacun des composants des VLAN, il convient de réfléchir sur l'aspect de cette architecture. Les sections suivantes discutent de certains aspects de la conception.
Capacité de gestion du flux de trafic
L'architecture en VLAN permet de gérer de manière efficace le flux de trafic grâce à la création d'une série de périphériques de sécurité protégés sur lesquels des règles et des stratégies de sécurité peuvent être appliquées.
Capacité de gestion de la sécurité
L'architecture actuelle de Internet Data Center verrouille complètement tous les serveurs Web grâce à l'utilisation d'une stratégie de sécurité pour serveurs Web et d'unités d'organisation Active Directory. Pour plus de détails sur l'implémentation des unités d'organisation Active Directory, consultez le Chapitre 4, "Infrastructure de sécurité".
Les serveurs Web de l'architecture Internet Data Center étant multiconnectés (équipés de deux cartes réseaux), les architectes craignaient que des pirates accèdent au réseau de production par le biais de la carte réseau principale. La conception de l'architecture ajoute une couche de sécurité supplémentaire en séparant le VLAN de la DMZ des autres VLAN de production grâce à la mise en place d'un pare-feu directement entre l'interface du réseau interne de tous les serveurs du VLAN de la DMZ et les autres VLAN internes. Tout le trafic circulant du VLAN de la DMZ vers les serveurs qui se trouvent dans les VLAN de production doit d'abord traverser ce pare-feu. Même si des pirates parvenaient à accéder à un serveur Web, ils devraient contourner ou vaincre la configuration de sécurité du pare-feu interne avant de pouvoir endommager des données.
Le fait de disposer d'un VLAN de données et de gestion séparé permet de placer les serveurs les plus importants (généralement les serveurs SQL Server) derrière deux dispositifs de protection. Tout d'abord, l'architecture Internet Data Center utilise une inspection d'état et des listes de contrôle d'accès pour contrôler la communication des ports TCP et UDP entre les serveurs du VLAN de la DMZ et le serveurs du VLAN de données et de gestion. Ensuite, la conception utilise des technologies VLAN et des listes de contrôle d'accès supplémentaires sur le commutateur, qui peut être configuré de façon à contrôler la communication des ports TCP et UDP entre le VLAN d'infrastructure et le VLAN de données et de gestion.
Disponibilité du réseau
La disponibilité du réseau peut être obtenue grâce à la mise en place d'une redondance à tous les niveaux et à l'utilisation du basculement automatique.
Deux périphériques réseau sont implémentés dans chaque couche de l'architecture afin de fournir une haute disponibilité au niveau du réseau. Des routeurs, des commutateurs et des pare-feu en double sont implémentés afin de maintenir la disponibilité sur l'ensemble du réseau. Aucune défaillance du site ne pourrait être due à un seul périphérique. En cas de défaillance du pare-feu, un pare-feu de secours prend le relais. En cas de défaillance d'un commutateur, un autre commutateur assume l'ensemble de la charge jusqu'à la réparation du premier. En cas de panne de la carte réseau d'un serveur Web, une autre carte réseau est automatiquement activée, sans aucun impact sur le flux de trafic. En cas de panne d'un serveur Web, celui-ci peut être mis hors connexion, réparé puis remplacé dans la ferme Web sans impact sur la production. Les partitions de base de données sur les ordinateurs SQL Server sont protégées dans le cadre d'un cluster de base de données SQL Server.
Évolutivité du réseau
Le trafic réseau est de plus en plus imprévisible. L'utilisation accrue des systèmes de commerce électronique fait que la règle des 80/20, qui voulait que 80 pour cent du trafic réseau soit limité au groupe de travail et seulement 20 pour cent implique Internet, est devenue obsolète. Aujourd'hui, le rapport se rapproche plus de 50/50. Si la tendance se poursuit, ce rapport risque de s'inverser et d'atteindre les 20/80, augmentant sensiblement le trafic du segment principal. La bande passante du segment principal Internet augmentant, la demande sur les réseaux des sites de commerce électronique en fera de même.
On assiste aujourd'hui à des développements technologiques importants visant à procurer les moyens de soulager la pression sur les réseaux de commerce électronique et à fournir un itinéraire de mise à niveau vers des exigences de bande passante supérieures. La conception de réseau doit inclure de nouvelles technologies, telles que des périphériques de couche 2 et Couche 3, qui commutent et acheminent le trafic à la vitesse du câble. Les commutateurs empilables et modulaires, qui offrent des densités de port et des vitesses de port allant jusqu'à 100 mégabits par seconde (Mbps), fournissent des solutions pour les centres de données de commerce électronique dans lesquels les commutateurs peuvent être empilés avec des liaisons Ethernet de 1 Gbps et procurer des milliers de ports à haute vitesse.
L'agrégation de bande passante pour les serveurs est disponible grâce aux technologies d'adaptateurs multiples, qui éliminent les goulets d'étranglement de serveur en augmentant de manière incrémentielle la bande passante entre un serveur et un commutateur. Ces technologies permettent de bénéficier de transmissions à haute vitesse qui étendent la capacité du support physique.
Architecture simple
Pour simplifier la conception de Internet Data Center, tous les VLAN non nécessaires ont été supprimés et la multiconnexion n'est utilisée que lorsqu'elle est absolument nécessaire. À noter l'absence d'un VLAN de gestion séparé, car celui-ci nécessiterait la multiconnexion des serveurs de données et d'infrastructure.
Remarque : L'architecture Internet Data Center possède un VLAN distinct configuré spécifiquement pour permettre la gestion sécurisée à distance des serveurs via du matériel de gestion de serveurs dédié.
En plaçant tous les serveurs de gestion là où leur impact est le plus grand, la conception de Internet Data Center élimine la complexité et résout les problèmes de trafic et de sécurité qui seraient posés par la présence d'un réseau de gestion distinct. La conception possède toutefois des serveurs Web multiconnectés, car il est important de segmenter le trafic interne et externe avec des VLAN séparés, et d'éliminer NetBIOS sur TCP/IP sur l'interface externe. En résumé, la conception de Internet Data Center intègre une certaine complexité uniquement lorsqu'elle est justifiée par une augmentation sensible de la disponibilité, de la fiabilité, de la gestion et de la sécurité.
Conception de routeur
Le point de connexion entre le réseau Internet Data Center et le monde extérieur est le routeur. Ces routeurs périphériques doivent favoriser les principaux services de tout conception de réseau : la sécurité, la haute disponibilité et l'évolutivité.
Routeur périphérique Internet
Dans la conception Internet Data Center, les routeurs périphériques assurant les services de sécurité du système constituent la première barrière de protection du réseau. On utilise pour cela, les ACL étendues des routeurs pour sécuriser le trafic réseau autorisé à circuler sur le réseau périphérique.
Pour ce qui est de la fiabilité et de la disponibilité, le réseau utilise un protocole de haute disponibilité afin de garantir la tolérance de pannes de cette configuration de routeur. Le protocole BGP procure une disponibilité de routage et une capacité d'équilibrage de charge. Les routeurs périphériques offrent également un ensemble de fonctions de qualité de service pouvant être utilisées pour améliorer la disponibilité des sessions utilisateur lors des heures de pointe sur le réseau.
La conception de Internet Data Center utilise le routage périphérique pour :
implémenter des routeurs redondants, ce qui permet à l'architecture Internet Data Center d'éliminer les points de défaillance uniques ;
relier chaque routeur à une connexion FAI différente, pour une disponibilité maximale ;
fournir une capacité BGP, afin d'utiliser au maximum les informations de routage du FAI. Ceci est critique dans les scénarios à FAI multiples, dans lesquels l'équilibrage de charge et les stratégies de routage sont importants ; En outre, il est recommandé d'utiliser des routeurs avec capacité BGP, afin de disposer d'une meilleure évolutivité ;
Remarque : Ceci exige la capacité d'obtenir un Numéro de système autonome (ASN, Autonomous System Number)
créer des itinéraires multiples à travers l'infrastructure réseau, pour une plus haute disponibilité. Ces itinéraires autorisent une répartition de la charge et une plus grande évolutivité grâce à l'équilibrage de charge par protocole de routage ;
utiliser des itinéraires BGP externes (EBGP sur les routeurs périphériques) pour la propagation des itinéraires de réseau IP locaux vers les FAI interconnectés. Ceci permet la découverte d'itinéraires vers le site de commerce électronique. En échangeant les itinéraires BGP Internet complets avec tous les FAI, les routeurs périphériques peuvent déterminer le meilleur itinéraire de retour et offrir une rapidité de réponse optimale au client ;
appliquer des ACL étendues et rigoureuses des interfaces entrantes aux routeurs périphériques. Ces ACL ne doivent autoriser que le trafic pertinent au site de commerce électronique ;
refuser tout trafic destiné aux routeurs grâce à l'utilisation d'ACL, mais autoriser le trafic BGP qui utilise TCP/179 si les paquets proviennent de routeurs de FAI adjacents ;
empêcher la transmission des paquets ICMP (Internet Control Message Protocol) à travers le routeur, car la prise en charge de la commande ping et d'autres capacités similaires peuvent mener à des attaques ;
installer des ACL d'usurpation, afin d'interdire l'entrée dans le centre de données à tout trafic structuré comme étant originaire du centre de données. Ceci permet de garantir que tout trafic possédant une adresse source dans le réseau périphérique provient réellement de ce réseau et non de l'extérieur ;
sécuriser l'interface de la console sur les routeurs, grâce à des noms d'utilisateur et des mots de passe. L'une des méthodes envisageables est l'utilisation du service RADIUS (Remote Access Dial-In User Service) pour authentifier et contrôler les administrateurs qui se connectent sur les consoles des routeurs. Utilisez l'authentification Kerberos ou SSH (Secure Shell) pour accéder à la console du routeur ;
autoriser uniquement l'entrée de TCP/80 (HTTP), TCP/443 (SSL), TCP/25 et UDP/53 (DNS) dans le centre de données. Il est possible que certaines applications personnalisées développées pour fonctionner au-dessus de la conception de Internet Data Center exigent des protocoles supplémentaires pour permettre aux clients d'exécuter des actions supplémentaires telles que l'utilisation du protocole FTP (File Transfer Protocol). Dans ce cas, veillez à ce que la stratégie d'entreprise ne soit pas enfreinte, puis apportez les modifications appropriées aux configurations de ports.
Routeur périphérique VPN
La seconde configuration de routeur de la conception de Internet Data Center a été créée pour fournir une connexion sécurisée à l'architecture à partir d'emplacements distants. La fonction première de ces connexions est de permettre au personnel de support technique d'accéder aux systèmes de gestion. Nous recommandons de séparer physiquement ces routeurs des routeurs périphériques Internet, et d'utiliser des connexions FAI différentes. Ceci permet de séparer le trafic de gestion du trafic de production ; les tâches de gestion n'auront alors aucun impact sur la bande passante disponible aux clients du site. Malgré tout, pour simplifier la configuration et limiter la configuration matérielle requise, la conception de cette connexion peut être intégrée à l'architecture de routeurs périphériques existante. C'est cette configuration qui a été testée dans les laboratoires Internet Data Center.
Conception du service DNS
La conception du service DNS est une partie très importante de la conception de Internet Data Center. L'architecture Internet Data Center de base implémente les services DNS de Windows 2000 dans une conception couramment appelée
"DNS fractionné". L'architecture DNS fractionné est composée de serveurs DNS externes qui fournissent la résolution de noms aux clients Internet, et de serveurs DNS internes qui ne desservent que l'espace de noms interne. Le schéma suivant fournit un aperçu du fractionnement des espaces de noms DNS interne et externe.
.gif)
Figure 2. Configuration DNS fractionné
Les sections suivantes fournissent davantage de détails sur les conceptions DNS interne et externe.
Services DNS externes
Le DNS cyclique est implémenté de manière à fournir une haute disponibilité pour les serveurs Web d'Équilibrage de charge mis en clusters. Deux adresses IP externes sont affectées au nom de site Web <mon nom d'hôte>. Deux enregistrements d'hôte (A) pour <mon nom d'hôte> sont créés dans DNS et configurés avec les adresses IP enregistrées. Exemple :
mon nom d'hôte A 192.168.22.20
mon nom d'hôte A 192.168.23.21
Ces adresses sont configurées sur les pare-feu de ISA Server (Internet Security and Acceleration Server), dont l'implémentation est discutée dans la section "Pare-feu périphérique et conception de mise en cache" du Chapitre 3, "Conception de pare-feu".
Les transferts de zone sont configurées de manière à avoir lieu entre les serveurs DNS externes principaux et secondaires du côté interne des serveurs multiconnectés. Ceci empêche toute exposition des données de zone du côté des serveurs faisant face à Internet. Les transferts de zone ne sont pas autorisés entre les serveurs DNS internes et externes. Cette séparation, ou configuration DNS fractionné, permet aux informations d'espace de noms DNS internes de demeurer isolées et indisponibles à Internet. Les requêtes DNS en provenance d'Internet ne doivent en aucun cas être autorisées à traverser la DMZ et pénétrer sur le réseau interne pour la résolution de noms. Les transferts de zone sont également interdits entre les serveurs DNS externes et tout serveur DNS sur Internet. Dans certains cas particuliers, vous jugerez peut-être souhaitable de transférer votre zone DNS externe sur votre serveur DNS de FAI pour bénéficier d'une redondance supplémentaire. Lorsqu'ils sont implémentés, les serveurs DNS doivent être configurés de manière à n'autoriser les transferts de zone qu'entre le serveur DNS de FAI et vos serveurs DNS externes.
Services DNS internes
Des jeux de serveurs DNS internes, situés sur le VLAN d'infrastructure, sont utilisés pour prendre en charge Active Directory et la résolution de noms pour les serveurs des VLAN de DMZ, d'infrastructure et de données et de gestion.
À des fins d'évolutivité et de redondance, des serveurs DNS multiples sont configurés dans l'architecture. Pour des raisons économiques et de simplicité, les serveurs DNS sont installés sur les contrôleurs de domaine Active Directory et sont configurés de façon à intégrer leurs fichiers de zone à la base de données Active Directory. En configurant les serveurs DNS comme intégrés à Active Directory, les fichiers de zone des deux serveurs DNS seront automatiquement répliqués par Active Directory, et les deux serveurs DNS seront en mesure de gérer le même espace de noms en assumant le rôle de serveurs DNS principaux. Tous les serveurs membres du domaine sont configurés pour pointer vers les deux serveurs DNS comme serveurs principaux et secondaires. Tous les serveurs peuvent enregistrer automatiquement leurs noms conviviaux auprès des serveurs DNS grâce à DDNS (Dynamic DNS). Dans la plupart des configurations, y compris l'architecture Internet Data Center, les systèmes internes doivent être capables de communiquer avec les systèmes qui se trouvent en dehors de l'intranet. Pour effectuer la résolution de noms Internet, les services DNS internes sont configurés pour transférer toutes les requêtes DNS vers les serveurs DNS externes.
Conception DNS fractionné-fractionné
Pour une sécurité accrue, une conception DNS fractionné-fractionné peut être implémentée. Cette conception sépare les services de publication et de résolution dans le DNS externe.Les services de publication dans DNS gèrent les requêtes des clients d'Internet pour les zones pour lesquelles le serveur DNS fait autorité. En limitant les requêtes aux zones locales et en désactivant la récursivité, ces services sont protégés contre les attaques. Les services de résolution dans DSN gèrent les requêtes transférées à partir des serveurs DNS internes et résolvent les requêtes pour le compte des serveurs internes.Les serveurs de résolution ne sont pas à l'écoute des requêtes en provenance d'Internet. Ils n'écoutent que les requêtes provenant des serveurs DNS internes. De cette manière, ils sont protégés contre toute attaque en provenance d'Internet.
L'un des types d'attaque qu'une conception DNS fractionné-fractionné permet d'empêcher est l'empoisonnement de cache. L'empoisonnement de cache est l'envoi d'une requête DNS à un serveur DNS sur Internet pour une zone pour laquelle il ne fait pas autorité. Si la récursivité est activée sur le serveur DNS, il tentera de résoudre la requête pour le client en recherchant sur Internet le serveur DNS qui fait autorité pour la zone où résident les données demandées. Le serveur DNS envoie ensuite une requête à ce serveur DNS faisant autorité afin de résoudre la requête du client. Malheureusement, ce serveur faisant autorité est détenu par un individu ou une organisation malveillante qui envoie une réponse valide mais aussi une attaque à la fin de la réponse, qui risque d'empoisonner le cache des serveurs DNS. Dans une conception DNS fractionné-fractionné, ce type d'attaque est impossible car la récursivité est désactivée sur tous les serveurs à l'écoute d'Internet.
Remarque : Microsoft DNS Server propose une fonctionnalité dans ses paramètres avancés nommée "Sécuriser le cache contre la pollution", qui permet de protéger les serveurs contre les empoisonnements de cache. DNS fractionné-fractionné offre une conception architecturale assurant également une défense contre toute attaque de cette nature.
Conception de l'Équilibrage de charge réseau
L'Équilibrage de charge réseau est un service de mise en réseau offert par Windows 2000 Advanced Server, Windows 2000 Datacenter Server et Microsoft Application Center 2000. La conception de Internet Data Center exige que tous les services soient hautement disponibles (par exemple, un serveur redondant pour chaque service) et hautement évolutifs (à la fois verticalement et horizontalement). Pour satisfaire ces exigences, l'architecture utilise deux types de clustering :
Windows Clustering, qui peut être utilisé pour fournir une tolérance de pannes pour les services accessibles en écriture (tels que Microsoft SQL Server 2000) est discuté dans le Chapitre 5, "Conception de bases de données SQL Server".
L'Équilibrage de charge réseau, qui fournit une tolérance de pannes système (pour les services non accessibles en écriture tels que les serveurs Web et ISA Server) et l'équilibrage de la charge (pour différents services). Ceci permet au concepteur système de développer les services réseau horizontalement.
La conception de Internet Data Center utilise l'Équilibrage de charge réseau pour trois services :
évolutivité horizontale et tolérance de pannes pour les serveurs Web ;
évolutivité horizontale et tolérance de pannes pour les serveurs ISA Server ;
tolérance de pannes pour les serveurs du réseau privé virtuel (VPN, Virtual Private Network) de gestion.
Remarque : Pour plus de détails sur la manière dont la conception de l'Équilibrage de charge réseau fournit une tolérance de pannes pour ISA Server, consultez le Chapitre 3, "Conception de pare-feu".
Mécanismes d'Équilibrage de charge
L'Équilibrage de charge est généralement obtenue grâce à l'une des trois méthodes suivantes (ou une combinaison de ces trois méthodes) :
Méthode |
Avantages |
Inconvénients |
DNS cyclique |
|
En cas de défaillance d'un serveur, l'hôte doit être supprimé manuellement de la table DNS. L'adresse échouée risque également d'être mise en cache dans de nombreux serveurs DNS d'Internet, ce qui peut entraîner l'envoi de clients vers un serveur en panne. Cette situation ne sera pas résolue tant que le nœud ne sera pas remis en ligne ou que l'entrée échouée dans les caches des serveurs DNS arrive à expiration. |
Équilibrage de charge réseau matériel |
|
|
Équilibrage de charge réseau logiciel |
|
|
La conception de Internet Data Center utilise plusieurs clusters et un DNS cyclique pour équilibrer la charge parmi ces clusters. De plus, les services Publication Web et Publication de serveur de ISA Server sont utilisés avec cette configuration si ISA Server joue le rôle de pare-feu périphérique (pour plus de détails sur cette configuration, consultez le Chapitre 3, "Conception de pare-feu").
Tout serveur exécutant ISA Server, ainsi que les serveurs Web IIS (Microsoft Internet Information Services Web), peuvent être configurés pour l'équilibrage de charge. En outre, les serveurs IIS internes sont regroupés en deux clusters d'Équilibrage de charge réseau différents, chacun affecté d'une adresse IP virtuelle interne.
Association de cartes réseaux
Les solutions hautement disponibles font généralement appel à l'association de cartes réseaux. Celle-ci permet à deux cartes réseau Ethernet de partager une adresse IP. Le concepteur système bénéficie ainsi d'une tolérance de pannes réseau grâce à la possibilité de relier chaque carte réseau à un commutateur différent, tout en procurant un basculement transparent pour le port Ethernet et le commutateur. L'association de cartes réseau est une combinaison matériel/pilote fournie par le constructeur du matériel et non par le système d'exploitation.
L'Équilibrage de charge réseau fournit une tolérance de pannes et une évolutivité horizontale pour les serveurs. Le fonctionnement de l'Équilibrage de charge réseau avec l'association de cartes réseau n'est pas garanti ; il importe donc de tester sérieusement la combinaison de ces deux fonctionnalités. Des tests sont nécessaires car l'Équilibrage de charge réseau dérive sa propre adresse MAC (Media Access Control) et l'affecte à toutes les cartes Ethernet du cluster. Ces nœuds partagent l'adresse MAC. Le principe de fonctionnement de l'association de cartes réseau est généralement le même ; celle-ci dérive sa propre adresse MAC partagée pour la paire de cartes réseau. Dans certaines circonstances, un conflit peut survenir entre les adresses MAC virtuelles utilisées par l'association de cartes réseau et l'Équilibrage de charge réseau lorsque ces deux fonctionnalités sont utilisées en même temps.
La concurrence entre les pilotes et les services en vue de contrôler l'adresse MAC peut entraîner des résultats mitigés, en fonction du matériel ou de la solution de pilotes utilisé(e). Les Services de support technique Microsoft prennent cette configuration en charge, tant que l'Équilibrage de charge réseau est la source du problème. Dans le cas contraire, la seule option est de désactiver l'association de cartes réseau ou de renvoyer les utilisateurs aux constructeurs du matériel. Pour plus d'informations, consultez l'article Q278431 de la Base de connaissances Microsoft.
Nous vous recommandons de tester rigoureusement l'Équilibrage de charge réseau avec votre combinaison de matériel et de pilotes d'association de cartes réseau. Tant qu'aucune norme industrielle régissant l'affectation et la gestion des adresses MAC virtuelles n'aura été définie et acceptée par Microsoft et les fabricants de matériel, cette prise en charge continuera de varier d'un fabricant à l'autre.
La conception de Internet Data Center utilise l'association de cartes réseau avec l'Équilibrage de charge réseau en mode monodiffusion. Toutefois, les pilotes de cartes réseau tendant à contrôler l'adresse MAC de l'association et ne détectant pas l'adresse MAC configurée par l'Équilibrage de charge réseau pour l'interface du cluster, une modification s'est révélée nécessaire. Dans l'outil de configuration de carte réseau, l'adresse MAC de l'association de cartes réseau a dû être définie manuellement sur l'adresse MAC affectée à l'interface du cluster par l'Équilibrage de charge réseau.
Cette configuration présente certaines limitations. Si un nouveau nœud est ajouté au cluster d'Équilibrage de charge réseau, ce réglage de l'adresse MAC de l'association de cartes réseau devra être effectué sur le nouveau nœud. En cas de modification de l'adresse IP du cluster, l'Équilibrage de charge réseau dérivera une nouvelle adresse MAC pour le cluster, qui devra également être répliquée sur tous les nœuds.
Il importe également de noter l'interaction de ces comportements avec Application Center, lorsque celui-ci est implémenté dans le cadre de la solution de gestion de contenu. En général, les paramètres d'Équilibrage de charge réseau ne sont configurés que sur le contrôleur du cluster Application Center. Ces paramètres sont ensuite répliqués sur les autres nœuds du cluster. Si vous avez configuré l'association de cartes réseau puis ajouté le nœud au cluster Application Center (l'adresse MAC de l'interface d'Équilibrage de charge réseau deviendra alors celle du contrôleur de cluster), l'adresse MAC d'Équilibrage de charge réseau et celle d'association de cartes réseau seront différentes. Ceci entraînera l'échec de l'ajout du nœud. Pour contourner ce problème, dans la conception de Internet Data Center, l'Équilibrage de charge réseau est configuré manuellement sur chaque nœud afin de garantir que l'adresse MAC de l'association de cartes réseaux reflète celle de l'Équilibrage de charge réseau avant l'ajout du nœud au cluster Application Center.
L'association de cartes réseau permet à l'architecture de conserver une disponibilité de 100 % en cas de panne d'un commutateur, car chaque carte réseau de l'association est reliée à un commutateur différent. Une autre solution consisterait à répartir les serveurs Web sur deux commutateurs du même VLAN desservi. Bien que cette solution procure une redondance, l'architecture perdrait la moitié des nœuds de chaque cluster en cas de panne d'un commutateur. On estime donc que la solution d'association de cartes réseau est supérieure.
Comportement d'équilibrage de charge distribué
Contrairement aux équilibreurs de charge matériels qui dirigent le trafic vers les nœuds qui constituent le cluster, tous les nœuds à Équilibrage de charge réseau (logiciel) reçoivent tous les paquets destinés au cluster. En fait, un commutateur assume la fonction de concentrateur, dans le sens où il envoie le trafic vers tous les ports d'un VLAN donné sur le commutateur. En mode monodiffusion, l'Équilibrage de charge réseau envoie une adresse MAC "leurre" qui n'existe pas vraiment. De cette façon, le commutateur ne détecte jamais à quel port l'adresse MAC est associée, et il envoie donc tous les paquets à tous les ports non associés à une adresse MAC (par exemple tous les ports ayant des serveurs membres des clusters d'Équilibrage de charge réseau).
Le commutateur détecte le port associé aux adresses MAC pour les serveurs qui ne sont pas membres d'un cluster d'Équilibrage de charge réseau ; ces ports ne voient donc pas le trafic d'Équilibrage de charge réseau. Si un cluster d'Équilibrage de charge réseau supplémentaire est attaché au commutateur sur le même VLAN qu'un autre cluster, le commutateur envoie des paquets aux ports d'un cluster avec le trafic destiné à l'autre cluster car il est incapable de détecter les ports pour aucun des nœuds des clusters. Sans mesure d'atténuation, ceci serait le cas dans le réseau Internet Data Center, où l'on trouve deux clusters distincts reliés au même commutateur, avec la moitié des serveurs Web associés à un cluster et l'autre moitié associée à l'autre cluster.
Pour optimiser l'utilisation du réseau, les paquets destinés à un cluster doivent être confinés aux ports auxquels les serveurs de ce cluster sont rattachés.
Deux solutions permettent d'empêcher ce comportement (Pour plus d'informations, consultez les articles Q193602, Q238219 et Q261957 de la Base de connaissances Microsoft) :
Reliez tous les nœuds du cluster à un concentrateur, puis reliez celui-ci au port du commutateur. Dans cette configuration, une modification doit aussi être apportée au Registre sur tous les nœuds, de manière à envoyer une adresse MAC valide. Ainsi, le commutateur détecte le port et l'inondation se produit au niveau du concentrateur.
Configurez un VLAN distinct pour chaque cluster d'Équilibrage de charge réseau. De cette façon, seuls les nœuds à l'intérieur du cluster détectent le trafic. Bien que cela ajoute une certaine complexité à l'architecture du point de vue de la gestion du VLAN, il n'est plus nécessaire de recourir à un concentrateur. Les nœuds peuvent ainsi opérer à 100 Mbps et en duplex intégral.
La conception de Internet Data Center utilise la seconde option.
Remarque : Contrairement à Windows Clustering, qui utilise une interface distincte pour les pulsations, la pulsation d'Équilibrage de charge réseau est envoyée et reçue sur l'interface en cluster. Cela signifie que tout le trafic lié au cluster (trafic client entrant et pulsations) a lieu sur la même interface. Cette configuration ne peut être modifiée. Bien qu'une partie des serveurs de Internet Data Center soit multiconnectée, ce n'est qu'à des fins de sécurité et de segmentation du trafic.
Réglage de la vitesse du réseau et du fonctionnement en duplex
En raison du très grand nombre de combinaisons de commutateurs et de cartes réseau, la fonctionnalité de détection automatique de duplex/vitesse de port n'est parfois pas très fiable. Pour éviter ces problèmes de fiabilité, toutes les cartes réseau et tous les ports de commutateur sont forcés sur un fonctionnement en duplex intégral à 100 Mbps grâce au réglage manuel des pilotes logiciels ou matériels.
Équilibrage de charge réseau en mode monodiffusion
L'Équilibrage de charge réseau fonctionne en mode monodiffusion ou multidiffusion. L'utilisation du mode multidiffusion nécessite la présence d'entrée ARP (Address Resolution Protocol) statiques au routeur, et peut entraîner un traitement supplémentaire au niveau du commutateur (pour plus d'informations, consultez l'article Q193602 de la Base de connaissances Microsoft). Tous les nœuds de cluster d'Équilibrage de charge réseau de l'architecture Internet Data Center sont donc configurés pour le mode monodiffusion. Toutefois, lorsque l'on utilise l'Équilibrage de charge réseau en mode monodiffusion, tous les nœuds d'un cluster sont incapables d'exécuter la commande ping sur les autres nœuds du même cluster sur l'interface en cluster (par contre, les nœuds qui se trouvent en dehors du cluster sont toujours en mesure d'exécuter cette commande sur les autres nœuds). Ceci est dû au fait que les membres des interfaces en cluster d'un cluster partagent une adresse MAC. Lorsqu'un nœud utilise le protocole ARP pour rechercher un autre nœud du cluster, TCP/IP renvoie l'adresse MAC du nœud d'origine (qui est partagée par tous les nœuds). La requête ne quitte donc jamais le nœud, car le protocole ARP fait que le nœud d'origine est résolu sur l'adresse MAC. Si les nœuds du cluster sont multiconnectés, ils pourront toujours exécuter des requêtes ping entre eux grâce aux interfaces à non-Équilibrage de charge réseau.
Équilibrage de charge réseau de ISA Server
Vous trouverez des informations sur l'Équilibrage de charge réseau de ISA Server dans le Chapitre 3, "Conception de pare-feu".
Utilisation de l'Équilibrage de charge réseau sur les serveurs Web
Bien que techniquement l'Équilibrage de charge réseau puisse prendre en charge 32 nœuds par cluster, en pratique il est préférable de limiter le nombre de nœuds à 12 ou moins, pour les raisons suivantes :
Application Center 2000 n'autorise que 12 nœuds par cluster.
Les coûts de traitement de l'algorithme d'équilibrage de charge augmentent à chaque ajout d'un nœud au cluster.
Une quantité de nœuds supérieure à 12 peut se révéler ingérable pour la maintenance système ou le déploiement de contenu ordinaire.
Dans la conception de l'architecture Internet Data Center, deux clusters d'Équilibrage de charge réseau sont configurés, chacun pouvant prendre en charge jusqu'à 12 nœuds. Le DNS cyclique est utilisé pour répartir la charge entre ces deux clusters. L'utilisation du DNS cyclique comme solution d'équilibrage de charge unique (sans l'Équilibrage de charge réseau) présente les inconvénients majeurs suivants :
En cas de défaillance d'un nœud, son adresse IP devra être supprimée manuellement de la table DNS. Il n'existe aucune suppression dynamique.
Il se peut que l'entrée du serveur en panne soit présente dans le cache des serveurs DNS sur Internet, qui enverraient alors cette adresse aux clients jusqu'à ce que le paramètre TTL (Time to Live) de cette entrée ait expiré (délai pouvant s'élever à plusieurs heures ou même plusieurs jours).
Il est clair que le DNS cyclique, utilisé tout seul, ne constitue pas une bonne solution d'équilibrage de charge. Par contre, toutes les insuffisances mentionnées ci-dessus sont éliminées lorsqu'on y associe l'Équilibrage de charge réseau.
La conception de Internet Data Center comporte deux adresses IP pour les clusters de serveurs Web (une adresse pour chaque cluster). Ces adresses sont publiques et répertoriées dans les propriétés TCP/IP des configurations réseau des ordinateurs ISA Server. Elles sont fournies aux clients qui en font la demande à l'aide du DNS cyclique, et sont traduites (par la fonctionnalité de Publication Web) en adresses privées utilisées en interne pour les deux clusters d'Équilibrage de charge réseau.
Cette configuration optimise les avantages des deux technologies et élimine les lacunes du DNS cyclique. Cette configuration produit des clusters d'Équilibrage de charge réseau multiples qui utilisent le DNS cyclique entre eux, et permet en théorie une évolutivité illimitée du site.
Chaque carte réseau d'une association étant reliée à un commutateur différent, même une panne de commutateur n'aurait aucun impact sur le site. La seule raison pour qu'une entrée utilisée pour le DNS cyclique soit indisponible étant l'indisponibilité de tout un cluster, cet inconvénient ne constitue plus un problème. (Pour que le cluster, et donc le site, soit indisponible, il faudrait que les deux commutateurs tombent en panne.)
Équilibrage de charge réseau et ports
Les règles de ports d'Équilibrage de charge réseau suivantes sont configurées sur les serveurs Web :
Règle |
Début |
Fin |
Protocole |
Mode |
Charge |
Affinité |
1 |
0 |
79 |
Les deux |
Désactivé |
Sans objet |
Sans objet |
2 |
80 |
80 |
TCP |
Multiple |
Égale |
Aucune |
3 |
81 |
65535 |
Les deux |
Désactivé |
Sans objet |
Sans objet |
Remarque : La règle de port par défaut d'affinité simple pour les ports 0-65535 a été supprimée.
Contrairement à la configuration de ISA Server, les serveurs Web ne doivent traiter les requêtes que sur le port 80 (HTTP). Normalement, le port 443 serait configuré pour une affinité simple avec les serveurs Web. Ce n'est toutefois pas le cas car la connexion HTTPS à partir des clients est terminée au niveau des ordinateurs ISA Server qui constituent les pare-feu périphériques Internet. Les ordinateurs ISA Server demandent les informations aux serveurs Web via HTTP, puis les transfèrent au client sur HTTPS. Cette connexion est terminée au pare-feu pour les raisons suivantes :
Cela permet aux serveurs ISA Server d'inspecter le contenu des transactions, plutôt que de simplement transférer les informations cryptées.
Cela permet l'utilisation de "Aucune affinité" avec l'Équilibrage de charge réseau plutôt que "Affinité simple".
Si HTTPS était autorisé à traverser le pare-feu ISA Server et à accéder aux serveurs Web, l'affinité simple devrait être configurée pour le port 443 sur les serveurs Web. Le service d'Équilibrage de charge réseau répartirait alors la charge uniquement sur l'adresse IP source, plutôt que sur le port et l'adresse IP source (comme c'est le cas lorsque l'affinité est réglée sur "Aucune"). Le service de Publication Web de ISA Server envoie l'adresse IP de l'interface interne des ordinateurs ISA Server comme adresse IP source, et non l'adresse IP source des clients. En mode d'affinité simple, si les adresses IP sources des clients étaient envoyées, l'équilibrage de charge serait quand même satisfaisant car la quantité d'adresses IP sources serait importante. Toutefois, lors de l'utilisation de la Publication Web, la quantité d'adresses IP sources possibles est égale à la quantité d'ordinateurs ISA Server. L'équilibrage de charge du trafic HTTPS serait alors grandement réduit, car la plupart des requêtes ne seraient desservies que par un petit nombre de serveurs Web.
Le trafic HTTPS étant terminé au niveau du pare-feu périphérique, l'option "Forcer HTTPS" ne doit pas être activée dans les propriétés du site Web ou du serveur. Pour que le client utilise HTTPS, les pages Web doivent être codées de manière à référencer une page comme https:// plutôt que simplement établir un lien vers une page. En outre, une fois la partie sécurisée de la transaction terminée, des liens http:// codés en dur doivent être fournis afin de forcer le navigateur du client à revenir en mode HTTP standard. Même si les concepteurs d'application Web préfèrent généralement ne pas coder les liens de cette façon, cette procédure et nécessaire afin de faire entrer et sortir l'utilisateur du mode HTTPS.
Si l'application Web utilisait HTTP exclusivement mais maintenait également l'état au serveur Web en utilisant par exemple l'état de session ASP, le HTTP devrait aussi être réglé sur "Affinité simple", ce qui aurait les mêmes conséquences que l'utilisation de l'affinité simple sur les serveurs Web pour HTTPS. La fonctionnalité Transfert de requêtes de Application Center permet de contourner ce problème, mais malheureusement elle exige des ressources supplémentaires des serveurs Web. Le maintien de l'état de session sur le serveur Web n'est donc pas recommandé, ni utilisé, dans la conception de Internet Data Center.
Paramètres TCP/IP
Une adresse IP de cluster et une adresse IP dédiée sont configurées sur l'interface qui fait face à Internet. Ceci permet d'utiliser des outils de surveillance afin de tester directement les temps de réponse pour chaque nœud du cluster. De cette façon, si un nœud cesse de répondre, la solution de surveillance peut le supprimer du service. Sans adresse IP dédiée sur ces interfaces, seul le temps de réponse du cluster pourrait être mesuré, ce qui ne procurerait pas les informations nécessaires.
Utilisation de l'Équilibrage de charge réseau sur les serveurs de VPN
Les serveurs de VPN de l'architecture Internet Data Center de base utilisent l'Équilibrage de charge réseau comme mécanisme de haute disponibilité. Dans cette conception, les serveurs de VPN sont utilisés pour la gestion à distance, ce qui signifie qu'il est peu probable qu'ils aient à gérer plus de 20 connexions simultanées. Chacun des serveurs ISA utilisés est parfaitement capable de gérer ce trafic ; les fonctionnalités d'évolutivité et d'équilibrage de charge de ISA Server ne sont donc pas prioritaires. Toutefois, si vous envisagez d'étendre l'architecture et d'utiliser ces serveurs comme passerelles pour votre logique d'application (par exemple dans le cadre d'une solution BtoB), l'équilibrage de charge et l'évolutivité peuvent assumer une réelle importance.
Remarque : Le protocole PPTP (Point-to-Point Tunneling Protocol) nécessite le réglage "Affinité simple" en raison de l'orientation de session des connexions VPN.
Règles de port
L'utilisation de ISA Server comme solution de VPN dans l'architecture Internet Data Center signifie que ISA Server gère la sécurité de filtrage de port supplémentaire. Dans le cas présent, la règle de port par défaut a été laissée intacte. Bien qu'il ne soit pas obligatoire de configurer tous les ports, ceux-ci sont laissés intacts pour raison de simplicité. Le serveur ISA Server n'écoute encore que sur les ports VPN appropriés, ce qui permet d'éviter la complexité accrue qu'implique la gestion de règles de port granulaires en deux emplacements :
Paramètre |
Valeur |
Plage de ports |
1-65535 |
Affinité |
Simple |
Mode de filtrage |
Hôtes multiples |
Charge |
Égale |
Protocoles |
Les deux |
On utilise l'affinité simple car les utilisateurs de la solution VPN travaillent généralement depuis leur domicile, et se connectent donc le plus souvent à leur FAI via des serveurs proxy.
L'affinité de Classe C serait inutile, car elle concerne les clients qui traversent plusieurs serveurs proxy pour atteindre leur FAI. Les connexions VPN exigeant une session, si un utilisateur traverse plusieurs serveurs proxy pour atteindre son FAI, la session est rompue au niveau du serveur proxy du FAI avant d'atteindre l'Équilibrage de charge réseau sur les serveurs Web.
Paramètres TCP/IP
La conception du VPN Internet Data Center n'utilise pas d'adresse IP dédiée sur les interfaces en cluster. Elle n'utilise qu'une adresse IP de cluster, principalement pour des raisons de sécurité mais également à des fins de simplicité. Sans adresse IP dédiée configurée, ces serveurs ne sont pas adressables individuellement par Internet. Ils ne peuvent être interrogés que comme cluster ; un client ne sait donc jamais quel serveur a répondu à sa requête. Ainsi, en supposant qu'un pirate parvienne à pénétrer sur l'un des serveurs et à y placer un Cheval de Troie ou autre logiciel malveillant, il ne saurait pas sur quel nœud celui-ci se trouverait et serait donc incapable d'adresser directement le Cheval de Troie pour le lancer. Bien qu'il ne soit pas impossible que le pirate accède finalement à ce nœud grâce à l'équilibrage de charge, cela implique tout de même une persistance supplémentaire de sa part.
Considérations supplémentaires
Il est important de comprendre le comportement des protocoles de VPN lors de leur utilisation avec un cluster de cette conception :
Ajout de nœuds
En cas d'ajout d'un serveur comme nouveau nœud d'un cluster (à des fins d'évolutivité horizontale), les connexions existantes aux autres nœuds ne subiront aucune perturbation de service durant le processus d'ajout.
Défaillance d'un nœud
En cas de défaillance de l'un des nœuds du cluster, toute connexion existante à ce nœud subira également une défaillance. Toutefois, les autres connexions sur les autres nœuds du cluster ne seront pas affectées.
Une perturbation du service peut survenir lorsque ce nœud est réparé rapidement puis replacé dans le cluster. Ceci est dû au fait que l'Équilibrage de charge réseau ne détecte que les sessions qui utilisent TCP (qui sont associées à un port). Le protocole PPTP utilisant GRE, qui est essentiellement TCP sans association de port, des anomalies de connectivité client et de reconvergence d'Équilibrage de charge réseau peuvent survenir. On peut cependant éviter ces anomalies en attendant une trentaine de minutes avant de replacer le nœud dans le cluster. Ceci n'a pas un impact négatif sur l'architecture, car un nœud défaillant n'est pas très courant. Il suffira de définir une procédure opérationnelle spécifiant qu'un nœud défaillant ne doit pas être replacé dans le cluster avant que 30 minutes ne se soient écoulées.
Conception de réseau commuté
La compréhension du flux de trafic réseau dans la conception du centre de données est essentielle si l'on souhaite obtenir une évolutivité du réseau. La conception de Internet Data Center utilise des technologies VLAN et des commutateurs réseau multicouches à haute vitesse pour fournir l'interconnexion entre les différents réseaux de serveurs créés dans le cadre de la conception. L'architecture est composée de deux commutateurs, qui offrent un niveau élevé de services réseau intelligents tels que la sécurité, la haute disponibilité et l'évolutivité.
Ces périphériques doivent être équipés de ventilateurs, de moteurs de supervision et d'alimentations en double afin de procurer une disponibilité améliorée. De plus, le commutateur doit offrir des services intelligents à la vitesse du câble, tels que des ACL pour la sécurité, la Qualité de service pour une haute disponibilité de session, un équilibrage de charge de serveurs intégré et des VLAN privés pour une sécurité accrue. La disponibilité est encore améliorée grâce à l'utilisation de plusieurs protocoles de Couche 2 et Couche 3 optimisés, qui procurent une récupération de panne en moins de deux secondes dans la plupart des scénarios de défaillance.
Le VLAN privé est une fonctionnalité avancée de Couche 2 qui procure une sécurité basée sur les ports entre les ports adjacents au sein d'un VLAN. Un VLAN privé est un VLAN dans lequel les ports désignés comme ports d'accès sont autorisés à communiquer uniquement avec les ports désignés comme banalisés. Ceci permet d'interdire l'accès aux autres serveurs Web du réseau dans le cas où un pirate compromettrait la sécurité d'un serveur sur un port. Ainsi, les ports adjacents ne peuvent pas être utilisés comme plate-forme de lancement pour les attaques ultérieures.
Il est important de comprendre les services et applications installés sur chaque serveur, et les exigences de communication qu'ils entretiennent entre eux et avec d'autres serveurs placés dans d'autres sections du réseau. Par exemple, les applications installées sur les serveurs Web doivent communiquer avec les contrôleurs de domaine et éventuellement les serveurs composants dans le VLAN d'infrastructure, ainsi qu'avec les ordinateurs SQL Server du VLAN de données et de gestion.
Conception de VLAN
Cette section décrit la fonction de chaque VLAN et le flux de trafic entre ces VLAN. Le tableau suivant présente les VLAN créés pour l'architecture Internet Data Center et mappe les noms de VLAN aux numéros de VLAN :
Nom du VLAN |
Numéro du VLAN |
Interfaces frontales de pare-feu périphérique |
VLAN 16 |
Interface principale de pare-feu périphérique, DNS |
VLAN 21 |
Cluster Web frontal 1 |
VLAN 22 |
Cluster Web frontal 2 |
VLAN 23 |
Web principal, DNS, interface frontale du pare-feu interne |
VLAN 11 |
Réseau de données et de gestion |
VLAN 12 |
Réseau d'infrastructure |
VLAN 13 |
Utilisé pour les cartes de gestion de serveurs |
VLAN 14 |
Interface principale du pare-feu interne |
VLAN 15 |
Cette conception de VLAN optimise l'isolement des différents segments pour accroître la sécurité et gérer le flux des données entre les composants d'application, par exemple pour permettre aux clients du Web d'accéder directement aux composants Web frontaux, mais fournir un accès uniquement aux composants d'application du VLAN d'infrastructure.
Grâce à l'utilisation de l'inspection de paquet d'état sur les pare-feu pour contrôler le flux de trafic entre les VLAN, il est possible de déployer une conception hautement sécurisée autorisant uniquement des machines ou composants internes à accéder aux données critiques ou hautement sensibles.Parmi les aspects clés de la conception de VLAN Internet Data Center, citons :
des règles créées pour garantir que seuls les ensembles de machines autorisés communiquent à partir du VLAN de la DMZ vers le VLAN de l'infrastructure et vers les VLAN de données et de gestion à travers le pare-feu interne ;
un VLAN dédié créé comme VLAN isolé et privé, uniquement destinés aux cartes de gestion de serveurs ;
les serveurs frontaux multiconnectés doivent être configurés pour désactiver le transfert IP ;
des ACL appliquées sur les routeurs d'accès et routeurs de commutateurs ;
le pare-feu interne doit prendre en charge l'inspection d'état entre le VLAN de la DMZ et les VLAN d'infrastructure et de données et de gestion.
Remarque : L'inspection d'état est un type de filtrage de paquets avancé qui effectue le suivi de l'état des connexions traversant un pare-feu.
Les meilleures pratiques suivantes sont appliquées à la conception de commutateur dans l'architecture Internet Data Center
Implémentation de commutateurs pour éliminer les points de défaillance uniques.
Utilisation d'alimentations doubles dans le commutateur, à des fins de résilience.
Utilisation de topologies maillées entre les périphériques réseau, routeurs et commutateurs, afin de procurer une récupération des Couches 2 et 3 en cas de panne d'un périphérique ou d'une liaison.
Utilisation de protocoles de Couche 3, tels que OSPF (Open Shortest Path First) ou IGRP (Interior Gateway Routing Protocol) à des fins de récupération de routage.
Utilisation de VLAN privés afin de renforcer la sécurité.
Sécurisation de l'accès aux commutateurs via la console grâce à l'authentification RADIUS. Les contrôleurs de domaine Active Directory peuvent être configurés comme ordinateurs ISA Server.
Flux du trafic réseau entre les VLAN
Pour raisons de sécurité, tout le trafic superflu sur les ports TCP est bloqué ou désactivé sur les serveurs, les périphériques réseau et les pare-feu. La section suivante décrit la configuration des ports TCP et UDP pour l'architecture Internet Data Center.
Exigences du trafic Internet
Les serveurs faisant face à Internet ont été répartis sur différents VLAN pour différentes exigences de trafic. Les ports TCP 80 et 443 sont redirigés du pare-feu périphérique aux deux fermes de serveurs ISS en cluster sur VLAN 22 et VLAN 23. Le trafic DNS UDP 53 et tous les autres protocoles Internet, s'ils existent dans l'environnement, sont dirigés vers VLAN 21.
Toutes les autres exigences de port, y compris les exigences du trafic Internet, sont décrites dans le Chapitre 3, "Conception de pare-feu" et concernent les VLAN suivants de l'architecture Internet Data Center :
VLAN 22 et 23 : Interface frontale de ferme Web IIS à charge équilibrée
VLAN 21 : Interface principale de pare-feu périphérique Internet, DNS
VLAN 11 : Interface principale de ferme Web IIS, interface frontale du pare-feu interne
VLAN 12 : Base de données-gestion
VLAN 13 : Application-infrastructure-Active Directory-contrôleurs de domaine
VLAN 15 : Interface principale de pare-feu interne
Schéma d'adressage TCP/IP
Le schéma d'adressage IP interne affecté à l'infrastructure est basé sur la norme d'adressage privé RFC 1597. N'importe quel schéma d'adressage privé fonctionne avec cette architecture, mais pour des raisons de simplicité des adresses privées de Classe C ont été sélectionnées et affectées à chaque VLAN. Les plages de sous-réseau de Classe C disponibles sont 192.168.0.0 à 192.168.255.0, ce qui procure suffisamment de sous-réseaux (256) pour cette conception. Les sous-réseaux du tableau suivant sont affectés aux VLAN (le masque standard de Classe C 255.255.255.0 sera affecté à chaque périphérique du sous-réseau) :
Affectation de sous-réseau |
VLAN |
Fonction |
192.168.11.0 |
VLAN 11 |
Réseau interne pour les serveurs IIS et DNS |
192.168.12.0 |
VLAN 12 |
Réseau de données et de gestion |
192.168.13.0 |
VLAN 13 |
Réseau d'infrastructure |
192.168.14.0 |
VLAN 14 |
Réseau des cartes de gestion de serveurs |
192.168.15.0 |
VLAN 15 |
Réseau de pare-feu interne |
192.168.21.0 |
VLAN 21 |
Interface principale de pare-feu périphérique et DNS |
192.168.22.0 |
VLAN 22 |
Interface frontale de Cluster Web 1 |
192.168.23.0 |
VLAN 23 |
Interface frontale de Cluster Web 2 |
Le schéma d'adressage pour l'architecture Internet Data Center est défini comme suit :
**Réseau ** : 192.168.x.0
Masque de sous-réseau : 255.255.255.0
Passerelle par défaut : 192.168.x.253
Adresse de diffusion : 192.168.x.255
DNS principal : 192.168.13.20
DNS secondaire : 192.168.13.21
Où X dénote chaque réseau VLAN listé dans le tableau précédent.
Dans cette configuration, chaque VLAN peut contenir jusqu'à 254 nœuds. Si plus de 254 nœuds sont requis par VLAN, un masque de sous-réseau différent peut
être utilisé.
À des fins de sécurité, les cartes de gestion de serveurs qui se trouvent sur le réseau VLAN 14 sont configurées sans serveur DNS ni passerelle par défaut.
Ces cartes sont ainsi incapables d'accéder à des périphériques en dehors de leur sous-réseau.
Affectation d'adresses publiques
Les affectations d'adresses publiques procurent une connectivité à Internet. Seuls certains périphériques réseau externes sont affectés d'adresses publiques, avec les objectifs suivants :
Fournir une sécurité supplémentaire grâce à l'utilisation d'adresses non routées sur Internet pour tous les serveurs. La solution offre une traduction d'adresse réseau (NAT, Network Address Translation) afin de permettre aux serveurs IIS de communiquer avec Internet, tout en utilisant les adresses privées affectées à leurs cartes réseau externes.
Se conformer aux tendances actuelles de conservation de l'espace d'adresses IP dans la communauté Internet.
Permettre aux entreprises d'obtenir des blocs d'adresses publiques inférieurs à un bloc de 24 réseaux, qui correspond à 254 adresses.
Remarque :La configuration IP spécifique aux différents serveurs de l'architecture dépendra du type de solution utilise pour le pare-feu interne.
Réseau d'entreprise
La configuration réseau finale intégrée à l'architecture Internet Data Center est celle de la connexion au réseau d'entreprise interne. Ce réseau fournit l'accès quotidien au système directement à partir de la connexion interne de l'entreprise. Il est extrêmement important que cette connexion soit conçue de la même façon que la connexion Internet externe. L'architecture globale du système exécute des fonctions critiques et doit donc être protégée, non seulement des pirates Internet mais également de tout accès interne non autorisé.
Un réseau de commerce électronique peut être une extension d'un réseau d'entreprise existant, ou peut être constitué d'une infrastructure système et d'un réseau physique complètement indépendants hébergés chez un opérateur. Dans le cas où la nouvelle infrastructure de commerce électronique est créée en tant qu'extension d'un réseau d'entreprise existant, la manière la plus simple et la plus sûre de relier le réseau d'entreprise et le système de commerce électronique est de créer un VLAN dédié sur le commutateur principal de l'infrastructure de commerce électronique. Ce VLAN peut ensuite utiliser un routeur pour limiter le trafic en appliquant des listes de contrôle d'accès. Pour un scénario plus sécurisé, vous pourriez envisager de placer un pare-feu entre le réseau d'entreprise et l'infrastructure de commerce électronique du VLAN d'entreprise.
Dans une implémentation de commerce électronique où l'infrastructure de support se trouve dans un emplacement distant, deux options sont possibles pour la connexion au réseau d'entreprise
Installation d'une connexion point à point privée et dédiée entre les deux sites. Cette option doit être envisagée dans les scénarios où l'on s'attend à ce que le transfert de données entre les deux sites soit important. Des liaisons redondantes doivent également être installées à des fins de résilience.
Implémentation d'un itinéraire de communication sécurisé grâce à l'utilisation d'un VPN entre le réseau de commerce électronique et le réseau d'entreprise reliant les deux réseaux locaux. La connexion entre les deux serveurs de VPN fournit une sécurité de bout en bout sur Internet grâce à l'encapsulation et au cryptage du trafic entre les deux sites. Pour une sécurité maximale, il est recommandé de créer IPSec sur un tunnel VPN L2TP lors de la connexion de ces deux sites. Dans ce scénario, un serveur d'autorité de certification est installé pour l'émission de certificats aux serveurs, afin de s'assurer que les identités des serveurs de VPN restent inchangées.
Cette seconde option présente aussi l'avantage d'être accessible, via Internet, au personnel de support quel que soit le lieu où il se trouve. Du moment qu'ils sont en mesure de fournir le bon certificat pour s'authentifier auprès de la solution VPN, les membres du personnel de support technique pourront obtenir une connexion sécurisée au réseau Internet Data Center.
L'architecture Internet Data Center est capable de prendre en charge ces deux options de connexion à distance, ainsi que la solution de VLAN local dédié.
Remarque : Les tests de la solution Internet Data Center décrits ici n'ont pas encore été achevés. Une analyse plus poussée de cette connexion sera discutée dans une version ultérieure de ce document.
Schéma complet du système
Comme nous l'avons vu plus haut, l'architecture Internet Data Center est composée de plusieurs VLAN qui aident à gérer le trafic réseau entre les différentes fonctions du centre de données. Il est important de pouvoir visualiser la conception dans son ensemble d'une manière à la fois détaillée et compréhensible. C'est pourquoi nous avons créé le schéma d'Architecture de base, qui représente un plan détaillé de l'architecture de base Internet Data Center. Ce schéma est inclus dans cette documentation et peut également être téléchargé ici.
Résumé
La conception de Internet Data Center fournit un modèle pour l'implémentation d'une solution de commerce électronique complète. Ce chapitre a fourni des détails sur la conception de base utilisée pour la partie infrastructure réseau
de l'architecture.
D'autres aspects pertinents de la conception ont également été discutés.
Bien qu'en définitive la conception que vous choisirez sera spécifique aux exigences et au budget de votre entreprise, ce document vous aura présenté des informations sur les technologies disponibles pour chaque aspect de l'infrastructure réseau et vous aura fourni une architecture testée et éprouvée pouvant servir de point de départ.
Dernière mise à jour le vendredi 1 mars 2002
Pour en savoir plus