Architecture de référence
Dernière rubrique modifiée : 2012-10-15
Trois architectures de référence proposées permettent de mettre en valeur les topologies du logiciels de communicationMicrosoft Lync Server 2010 qui ont été testées et sont donc prises en charge. Il existe deux topologies Edge principales et une topologie secondaire :
Topologie principale – Architecture de référence 1 : topologie Edge unique consolidée utilisant la traduction d’adresses réseau (NAT) ;
Pour plus d’informations, voir Architecture de référence 1 : Topologie Edge consolidée unique.
Topologie principale – Architecture de référence 2 : topologie consolidée mise à l’échelle utilisant NAT et l’équilibrage de la charge DNS (Domain Name System) ;
Pour plus d’informations, voir Architecture de référence 2 : Topologie Edge consolidée mise à l’échelle (avec charge DNS équilibrée).
Topologie secondaire – Architecture de référence 3 : topologie Edge consolidée mise à l’échelle utilisant des adresses IP publiques et l’équilibrage de charge matérielle.
Pour plus d’informations, voir Architecture de référence 3 : topologie Edge consolidée mise à l’échelle (avec charge matérielle équilibrée).
L’approche recommandée pour le déploiement d’un serveur Edge Lync Server 2010 est d’utiliser l’outil de planification pour générer un fichier d’entrée pour le Générateur de topologies. Les architectures de référence présentées dans cette section n’ont pas pour vocation de remplacer ce processus ; elles offrent un ensemble de dessins et de tableaux conçus pour aider ce même processus.
Pour des résultats optimaux, utilisez le graphique de topologie de la rubrique Définition de la configuration requise pour l’accès des utilisateurs externes pour sélectionner une topologie, puis examinez la section de l’architecture de référence qui y correspond. Les hypothèses émises dans la section suivante s’appliquent aux trois topologies et doivent d’abord être examinées.
Hypothèses
Plusieurs facteurs réseau et environnementaux sont susceptibles de nuire aux performances des serveurs Edge. Les architectures de référence sont conçues selon les meilleures pratiques dans le but de prévenir des problèmes de configuration courants et sont fondées sur les hypothèses définies dans la liste suivante. Si vous optez pour une configuration différente (par exemple, un réseau de périmètre à interface triple), il vous sera toujours possible de la faire fonctionner mais cette configuration ne sera ni testée, ni prise en charge.
Réseau de périmètre dédié (également appelé « zone DMZ », « zone démilitarisée » et « sous-réseau filtré ») avec pare-feu interne et externe.
Lync Server 2010 prend en charge la virtualisation des serveurs Edge mais les architectures de référence partent du principe que des serveurs physiques sont utilisés.
Deux cartes d’interface réseau configurées comme suit :
L’interface interne du serveur Edge se trouve sur un réseau différent de celui de l’interface externe du serveur Edge.
La carte d’interface réseau de l’interface externe du serveur Edge est dotée de trois adresses IP qui lui sont inhérentes (à savoir accès, conférence web et A/V, l’adresse IP d’accès étant définie comme adresse principale et les deux autres adresses IP comme adresses secondaires).
Une seule et unique passerelle par défaut est configurée ; elle est affectée à l’interface externe du serveur Edge d’accès et pointe sur l’adresse IP du pare-feu externe.
La carte d’interface réseau de l’interface externe du serveur Edge et celle de l’interface interne du serveur Edge se trouvent sur deux réseaux distincts entre lesquels aucun routage n’est configuré.
Le modèle d’hôte fort de Windows Server 2008 est employé sur tous les serveurs Edge. Pour plus d’informations, voir « Le petit câbleur : Modèles d’hôte fort et faible » à l’adresse https://go.microsoft.com/fwlink/?linkid=178004&clcid=0x40C.
Aucun directeur n’apparaît pour simplifier les choses mais le déploiement d’un directeur est généralement pratiqué pour réduire les risques d’attaque par déni de service.
Un itinéraire partant du réseau qui abrite l’interface interne du serveur Edge mène à tous les réseaux contenant des clients ou des serveurs Lync 2010 dotés de Lync Server 2010.
Aucune configuration DNS « split-brain » (même domaine hébergé sur les serveurs DNS interne et externe) n’est employée dans les exemples afin de mettre précisément en valeur les solutions requises dans le cadre de cette configuration mais elle est traditionnellement déployée.
Les serveurs Edge pointent sur un serveur DNS dans le périmètre car les fichiers d’hôtes peuvent s’avérer difficiles à maintenir.
Toutes les interfaces externes de serveur Edge ont recours à la traduction d’adresses réseau (NAT) (avec les adresses IP de destination redéfinies en entrée et les adresses IP source redéfinies en sortie) associée à un équilibrage de la charge DNS. Ou bien elles utilisent des adresses IP publiquement routables avec un équilibrage de la charge matérielle.
Une configuration hybride associant un service Edge d’accès et un service Edge de conférence web derrière NAT avec un service Edge A/V configuré avec une adresse IP publiquement routable n’est pas prise en charge dans Lync Server 2010.
Les fonctions du routeur et du pare-feu sont intégrées dans un seul périphérique et, à des fins de référence, le ou les serveurs Edge et proxy inverses se trouvent dans un réseau de périmètre situé entre un routeur/pare-feu intégré externe et interne.
Un seul serveur proxy inverse est affiché mais, en cas de déploiement d’un pool de serveurs proxy inverses déployés dans le réseau de périmètre, leur charge serait équilibrée au moyen d’un programme d’équilibrage de la charge matérielle puisque l’équilibrage de la charge DNS ne fonctionne pas dans le cadre d’un trafic web entre client et serveur.
Après avoir choisi une topologie et déterminé vos exigences en matière de certificat, de port et de DNS, vous pouvez utiliser l’une des trois architectures de référence pour voir à quoi ressemble un déploiement classique. Vous devriez alors être en mesure de modifier les tables existantes à l’aide de vos noms de domaine complet (FQDN) et adresses IP de production, puis les utiliser pour faciliter votre déploiement de production.