> Tech > Le DNS Load Balancing

Le DNS Load Balancing

Tech - Par iTPro - Publié le 09 janvier 2013
email

Le DNS Load Balancing ou DNS LB n’est pas exactement une fonction des serveurs DNS, mais plutôt une fonctionnalité supportée par Lync 2010.

Le principe proposé par Microsoft repose sur la définition et la création de plusieurs enregistrements DNS avec un seul nom de ‘serveur’ou ‘host’ associé à plusieurs adresses IP. C’est donc une configuration DNS similaire au DNS Round Robin (DNS RR), ce qui est supporté par les serveurs DNS. Attention, le mécanisme DNS RR n’est pas une solution de haute disponibilité à la base. Lync 2010 utilise l’ensemble des entrées DNS définies pour le serveur recherché (DNS LB) et équilibre les flux de type SIP et MEDIA entre les clients Lync et les serveurs Lync Front End.

Ce mécanisme est donc supporté uniquement par Lync (client et serveur) pour les protocoles spécifiques. Il sera donc nécessaire de recourir à des Hardware Load Balancing pour les ports 80 (HTTP) et 443 (HTTPS) car ces protocoles sont orientés ‘State-Session’. Une requête établie avec un serveur particulier doit se poursuivre avec le même serveur. La mise en place du DNS LB ne permet pas le support de ce type de fonctionnement alors qu’un équipement HLB le permet. On constate donc ainsi les limitations de cette solution qui ne permet pas la cohabitation avec OCS 2007 ou 2007 R2 et qui ne permet pas non plus la haute disponibilité sur les services Web. Voir tableau 2.

Tableau 2  – Exemples d’enregistrements DNS pour le DNS LB

FQDN

IP/FQDN

Notes

_sip._tls.creusot.com

Pool.creusot.com

Enregistrement SRV pour authentification automatique.

FE1.creusot.com

192.168.1.1

Serveur frontal 1

FE2.creusot.com

192.168.1.2

Serveur frontal 1

FE3.creusot.com

192.168.1.3

Serveur frontal 1

Pool.creusot.com

192.168.1.1

Le pool possède donc plusieurs adresses IP (celles des différents serveurs Front-End)

192.168.1.2

192.168.1.3

 

Dans la suite et la fin de ce dossier, certaines particularités sont mises en avant en fonction du rôle de serveur à mettre en haute disponibilité.

Redondance du serveur Lync Edge

Le serveur Lync Edge est un rôle important pour permettre l’accès aux différentes fonctionnalités Lync pour les utilisateurs situés à l’extérieur de l’entreprise. Pour assurer une continuité de service pour ces utilisateurs externes, il est nécessaire de disposer d’au minimum deux serveurs Edge qui seront regroupés au sein d’un pool Edge. Les différents utilisateurs gérés par les serveurs Edge peuvent être pleinement redondés en utilisant un Load Balancer matériel (HLB) en amont et en aval (réseau interne et réseau externe). La solution de haute disponibilité en utilisant le DNS LB implique certaines incompatibilités, surtout dans des environnements avec de la fédération publique, des interconnexions PIC ou OCS ou encore dans des environnements connectés via XMPP.

Redondance du Reverse Proxy

La redondance du Reverse Proxy est un point crucial quant à l’accès aux ressources Lync. Lors de la tentative de connexion, le client Lync envoie une requête par le biais du protocole HTTP. Dans ce scénario, il est impossible de mettre en place un DNS Load Balancer. En effet, pour rappel, l’utilisation d’un DNS Load Balancer sur le protocole HTTP ne permet pas de garder la persistance de  session. La seule solution de mise en haute disponibilité du rôle de reverse proxy repose sur la mise en place d’un Load balancer matériel (HLB).

Redondance du serveur Lync Front-End

Le serveur Lync Front-End est le rôle le plus important dans une infrastructure Lync. Il est responsable de la plupart des fonctionnalités présentes dans le produit Lync. Pour mettre une redondance au niveau de ce rôle, il est nécessaire de disposer de plusieurs serveurs Front-End qui permettront aux utilisateurs de s’authentifier et bénéficier des fonctionnalités Lync. La redondance des serveurs Front-End, peut se faire en utilisant un équipement Load Balancer matériel (HLD) qui va permettre de détecter les serveurs actifs du pool et ainsi établir les communications entre le client et les serveurs opérationnels de Lync. Pour ce rôle de Front-End,  il est également possible de mettre en place un mécanisme de DNS Load Balancer entre les différents serveurs Front-End du pool. Mais dans tous les cas, un HLB sera requis pour les publications des services et publications Web interne et externes ainsi que les services de mobilité (ports 80, 443, 8080 et 4443).

Redondance du serveur Back-End

Le rôle de back end pour Lync repose sur un serveur SQL. Lync ne supporte pas toutes les versions de SQL (SQL 2012 n’est actuellement pas supporté par exemple) et  pas toutes les solutions de redondance de SQL. Seuls les clusters SQL Actif/Passif sont supportés en tant que serveurs Back End de Lync. Lync 2010 ne prend pas en charge la mise en miroir native des bases de données. Il conviendra aussi de s’assurer que la version SQL mise en cluster est supportée par Lync 2010.

Conclusion

En conclusion, la redondance logique des serveurs au sein des différents pools doit être mise en place au niveau de l’architecture logique de Lync 2010 (Topology Builder)  et un dispositif matériel HLB ou dans certains cas, la mise en place du DNS Load Balancing, est requis pour assurer la gestion des flux (équilibrage de charge et gestion des défaillances) vers les différents serveurs des pools. Voir tableau 3.

Tableau 3 – Récapitulatif des options de haute disponibilité Lync 2010 par rôle

Role

Haute disponibilité

Load Balancer

DNS Load Balancing

Standard Edition Server

Not Available

NA

NA

Enterprise Edition Front End server.

Deploy Multiple Server in a Pool and use Load Balancing

Oui

Oui

Back End Server

SQL Server uses Windows Clustering for High Availability

Non

Non

A/V Conferencing Server

Deploy Multiple Servers in a Pool. Load Balancing not required

NA

NA

Edge Server

Deploy Multiple Servers in a Pool and use Load Balancing

Oui

Oui

Mediation Server

Deploy Multiple Servers in a Pool and use Load Balancing

Oui

Oui

Monitoring

Standby Server

(MSMQ on the Front-End queues messages in the event of a failure)

Non

Non

Archiving

Standby Server

(MSMQ on the Front-End queues messages in the event of a failure)

Non

Non

Director

Deploy Multiple Servers in a Pool and use Load Balancing

Oui

Oui

File Server

Use Windows Clustering or Distributed File System  (

Non

Non

 

 

Téléchargez gratuitement cette ressource

Guide de Cloud Privé Hébergé

Guide de Cloud Privé Hébergé

Comment permettre aux entreprises de se focaliser sur leur cœur de métier, de gagner en agilité, réactivité et résilience en s’appuyant sur un socle informatique performant, évolutif et sécurisé ? Découvrez les avantages des solutions de Cloud Privé hébergé de la CPEM.

Tech - Par iTPro - Publié le 09 janvier 2013