Associez vos fermes de serveurs Lync !

Réservées aux versions Entreprise etclusterisées dans l’environnement 2010, ces nouvelles versions améliorent les fonctions de reprise d’activité notamment dans le cas de bascule de sites de production. Je vous propose donc de passer en revue les points clefs que vous devrez retenir si vous décidez de planifier un déploiement Lync incluant une reprise d’activité sur un site de secours.

La mise en place d’une solution de haute disponibilité sur Lync peut être diverse selon le cas envisagé. Nous présenterons par conséquent les infrastructures à mettre en oeuvre pour assurer, nous l’espérons tout du moins, une architecture sans faille. Pour commencer, nous allons prendre l’exemple d’une solution de haute disponibilité que nous allons petit à petit complexifier.

La mise en place d’un environnement Lync 2010 ou 2013 est souvent associée à la fourniture d’infrastructures permettant une haute disponibilité mono site et / ou une solution de reprise d’activité sur un site distant. Dans la plupart des PME, la solution qui consiste à s’appuyer sur les solutions de redondance des infrastructures virtuelles donne d’excellents résultats et quelques projets qui ont maintenant plus de deux années d’existence d’exploitation et qui m’ont été permis de suivre, n’ont pas connu de pannes sérieuses. Cette solution, basée sur le déploiement d’une solution Lync Standard Edition, a pour double avantage, la réduction des coûts, et le fait de fournir une solution simple, dont les mécanismes de basculement sont normalement maîtrisés par les équipes internes.

Cependant, ces solutions ont des limites qui résident notamment sur le fait qu’une panne d’un service Lync n’entraînera pas la bascule automatique des services et qu’il est possible que le basculement de la machine virtuelle ne règle pas le problème lié aux services Lync en question. D’autre part, le fait de ne bénéficier que d’une seule machine virtuelle assurant le rôle de serveur frontal rend difficiles les opérations de maintenance. Si l’on veut améliorer les choses, la planification d’un environnement hautement disponible va par conséquent s’imposer.

Dans l’environnement Lync, la redondance des services est principalement axée sur la duplication des services nommés Pool ou ferme de serveurs. Sont principalement concernés, les rôles frontaux, Edge, serveurs de médiation et directeurs.

La première chose à prendre en compte lors de la planification des services Lync en haute disponibilité est la mise en place obligatoire d’un répartiteur de charge. Un des avantages de Lync et je vous invite plutôt à vous orienter sur ce mode de répartition est l’utilisation de la technologie Dns Load Balancing (ne pas confondre avec la technique de DNS Round Robin). Dans le cas de l’utilisation DNS Load Balacing, et pour faire court, c’est le client Lync qui va, au vue de la publication multiple d’un service, se connecter sur l’un ou l’autre des membres d’une ferme. C’est le cas pour un client Lync vers une ferme de serveurs frontaux et vers une ferme de serveur Edge, mais c’est également le cas d’un serveur frontal qui souhaite se connecter vers une ferme de serveur Edge. L’avantage de cette solution est qu’elle est simple efficace et ne nécessite pas de configuration élaborée sur des solutions de répartiteurs matériels.

L’inconvénient c’est qu’elle ne couvre pas la totalité de la problématique dans certains cas précis. C’est notamment le cas de la répartition des accès aux services Web, la redondance de service pour certaines messageries publiques et pour les anciennes fédérations OCS. Pour ces points précis, la répartition de charge matérielle est nécessaire. Aussi, pour vous en convaincre voici un schéma Microsoft bien connu des architectes Lync précisant l’utilisation des fonctions DNSLB dans le cadre d’une solution redondante. En y cherchant bien vous y trouverez l’indispensable répartiteur matériel. (Hlb). Voir figure ci-dessous.