Architecture Edge sans redondance

Elle se base sur la mise en place d’un seul serveur EDGE sans redondance, mais elle va permettre de comprendre les différents éléments requis, quelle que soit l’architecture déployée. Les éléments requis pour la mise en place du rôle EDGE sont relativement nombreux et nous allons les passer en revue.

Les éléments de base à prendre en compte pour le serveur Edge sont le réseau, les services DNS et les certificats.

Infrastructure réseau

En premier lieu, il faut disposer d’un serveur en DMZ avec au minimum deux cartes réseau dont une connectée au réseau de l’entreprise (en direct ou au travers d’un pare-feu) et une carte réseau connectée au réseau public (en direct ou au travers d’un pare-feu). Il ne faut en aucun cas de routage entre les deux réseaux utilisés. Les deux interfaces réseaux doivent être sur des réseaux distincts. L’interface publique nécessite de préférence trois IP publiques (une IP par rôle Edge), mais il est possible de faire fonctionner le rôle Edge avec une seule IP publique. La gestion des adresses IP publiques peut s’effectuer de deux manières : soit directement, soit au travers de translation d’adresse IP (NAT). L’utilisation d’adresses IP publiques est généralement la plus simple mais cette approche n’est pas toujours autorisée par les responsables de la sécurité informatique.

La plupart des entreprises impose le passage des flux publics par un routeur/pare-feu qui effectue alors une transformation des adresses IP publiques en adresses IP privées (Network Address Translation ou NAT). Avec Lync 2010, il est possible d’utiliser des adresses IP publiques au travers de NAT, ce qui n’était pas possible avec les versions précédentes OCS 2007 et OCS 2007 R2. Mais l’utilisation de NAT impose le respect de certaines contraintes et particulièrement la modification des adresses IP contenues dans les paquets de messages (SNAT et DNAT). Il faut, en effet, que les paquets IP qui circulent en externe contiennent les adresses IP publiques uniquement et que les paquets entre l’équipement NAT et le serveur Edge contiennent les adresse IP du serveur Edge et du serveur NAT uniquement.

Les services DNS

En complément des adresses IP publiques, il convient aussi de définir différents enregistrements DNS au niveau du réseau public Internet. Plusieurs enregistrements DNS de type A et SRV sont requis pour la configuration automatique du client Lync Server 2010 (enregistrements optionnels), des enregistrements DNS A ou CNAME pour la découverte automatique des services Web Lync Server, des enregistrements DNS A et SRV pour l’interface externe du serveur Edge Lync Server 2010 et des enregistrements DNS A et SRV pour l’interface externe du proxy inverse. En complément de ces enregistrements DNS, il faut aussi prévoir des enregistrements DNS pour la mise en place de la solution de mobilité Lync. Avant de passer à l’installation et configuration du serveur Edge, nous allons voir dans ce dossier les architectures redondées.

Les certificats

Lync 2010 utilise par défaut des communications sécurisées et cela nécessite la mise en place de certificats de type serveur. Pour les communications internes (clients et serveurs internes au réseau local, serveurs entre eux), des certificats issus d’une autorité de certification interne peuvent convenir, mais sur les réseaux publics, il est préférable, voire indispensable de disposer de certificats publics. L’usage de certificats publics est obligatoire pour la mise en place de fédération, d’interconnexion avec les messageries instantanées publiques (MSN, Yahoo ou AOL) ou encore pour les utilisateurs mobiles. Le choix de l’autorité de certification est relativement libre, à condition de pouvoir disposer de certificats à noms multiples (Subject Alternate Name ou SAN) dont l’autorité de certification est reconnue par les serveurs, les clients et les périphériques utilisés. Il faudra aussi prévoir le certificat nécessaire pour les publications Web au travers du serveur reverse proxy.

Architecture Edge avec redondance

Lorsque l’on aborde le sujet de la haute disponibilité, les prérequis sont extrêmement importants pour répondre aux exigences de basculement automatique de services en cas de défaillance d’une machine. La solution de redondance au sein de Lync se base sur le principe de la mise en place de plusieurs serveurs ayant les mêmes rôles et d’équilibrer la charge sur ces serveurs en mode opérationnel. Le regroupement logique de ces serveurs ayant le même rôle se nomme pool. En cas de défaillance d’un serveur au sein du pool, les autres serveurs du pool assurent alors la continuité du service. Microsoft Lync supporte deux solutions pour la gestion de l’équilibrage de charge au sein d’un pool qui sont, soit les dispositifs matériels ou Hardware Load Balancing (HLB), soit un équilibrage à l’aide des enregistrements DNS grâce à un mécanisme connu sous le nom de DNS Load Balancing (DNSLB).

Le choix de l’une ou l’autre des architectures est conditionné par les environnements réseau de l’entreprise. Une première règle simple se base sur l’existence ou non d’environnements OCS 2007/2007 R2 au sein de l’entreprise ou de ces partenaires. Les versions précédentes de Lync (OCS 2007 et OCS 2007R2) ne supportent que les équipements matériels et en aucun cas l’équilibrage de type DNS. Si une phase de cohabitation, migration ou fédération avec des environnements OCS 2007 ou  OCS 2007 R2 est envisagée, alors l’usage d’équipements matériels d’équilibrage de charge est requis pour le déploiement d’une solution redondée. Pour le choix d’une solution DNS LB ou HLB, voir le Tableau 1. (Tableau Choix DNSLB ou HLB.)