Redondance des services de bases de données

Chère et complexe, utilisant un seul et unique espace de stockage, cette solution n’était pas adaptée aux problématiques de duplication des données sur plusieurs sites de production.

Dans l’environnement Lync 2013, Microsoft change la donne en utilisant les fonctions de miroir de base de données SQL ce qui va effectivement rendre possible la duplication synchrone des données à moyens coûts sur deux sites de production.

On aura tendance à mettre en place pour cette solution un serveur SQL témoin qui permettra un basculement automatique des services de base de données en cas de problème. Si vous souhaitez un basculement manuel conforme au mode de basculement des services frontaux associés, alors le serveur SQL témoin ne sera pas nécessaire.

Redondance des services Edge

La mise en haute disponibilité des serveurs Edge se base dans un premier temps sur l’installation de fermes de serveur Edge pour assurer la redondance des services externes. Si vous possédez deux centres de données, il conviendra de déployer simplement plusieurs fermes de serveur Edge sur les deux centres de données concernées.

Dans le cas d’une panne de serveur Edge au sein de la ferme d’un centre de données, l’équilibrage de charge matérielle ou les fonctions de DNSLB assureront la redirection vers les autres membres disponibles. C’est entièrement automatique et cela fonctionne déjà comme cela dans l’environnement Lync 2010.

Dans le cas où une ferme de serveur (Edge et Frontaux) ne serait plus disponible grâce à l’utilisation des fonctions de DNSLB à l’extérieur, les clients Lync externes seront capables d’être acheminés vers les serveurs restant en fonction sur l’autre site de production si et seulement si tous vos serveurs Edge possèdent le même nom externe de domaine pleinement qualifié (FQDN).

Pensez également à faire en sorte que les connexions réseaux internes des serveurs Edge des deux sites soient joignables par tous les utilisateurs Lync des deux centres de données (udp/3478) et cela, de façon routée. (Pas de Nat)

Voici pour rappel les flux A/V et Web Conférence sur Lync 2010

En cas de bascule du site A vers le site B les accès externes vont continuer de fonctionner via le pool Edge du site B, cependant la fédération, elle ne fonctionnera plus en raison du fait qu’elle est déclarée comme étant attachée dans la configuration Lync à un pool en question (celui qui ne fonctionne plus… pas de chance). De ce fait, vous devez modifier par le Topology Builder la configuration de fédération pour qu’elle soit enregistrée sur le pool Edge du site B. Pas vraiment très long à effectuer mais à positionner dans le document des actions à réaliser en cas de basculement de site.

L’utilisation du Topology Builder

sera également nécessaire si seule votre ferme de serveurs Edge du site A est hors service, mais que vos serveurs Lync Frontaux du site en question sont encore opérationnels. Dans ce cas, il faudra modifier la configuration pour indiquer à votre ferme de serveurs frontaux du site A d’utiliser le pool Edge du site B. Là aussi, c’est rapide mais c’est à documenter.

Toutes ces fonctions permettent donc désormais d’envisager plus sereinement les bascules de sites en simplifiant les opérations de remise en production. Reste aux administrateurs de les paramétrer de les jouer, et de les documenter et de les faire rejouer par des néophytes.

La sagesse voudrait également que ces procédures soient utilisées régulièrement pour vérifier qu’elles sont toujours opérationnelles. Mais là… On frise la perfection !