Haute disponibilite des serveurs frontaux en Skype 2015

Les répliques sont réparties à travers la ferme sur l’ensemble des serveurs. Leurs données sont répliquées de façon à ne pas perdre d’informations si l’un des serveurs de la ferme venait à tomber. C’est ce qu’illustre la figure 2 dans le cas d’une ferme de 6 serveurs et deux groupes d’utilisateurs.

La figure 3 montre comment connaître le positionnement des répliques pour un utilisateur déterminé via la commande : Get-CsuserpoolInfo.

Lors de la modification de la topologie (ajout ou suppression de serveurs au sein de la ferme) sachez que la configuration de ses répliques est redistribuée à travers la ferme.

Dans notre configuration (figure 4) qui comprend quatre serveurs, comme précisé ci-dessous, que se passe-t-il si l’on arrête de faire fonctionner la réplique primaire ?

Dans ce cas, rien d’extraordinaire. Le client reste connecté et continue sur la réplique secondaire. La couche Windows Fabric va ensuite attendre 15 à 20 minutes et refaire une réplique sur un autre serveur.

Ce délai a été défini pour prendre en compte l’éventuel arrêt redémarrage d’un serveur. Par contre, si le serveur qui contient la réplique primaire s’arrête ainsi qu’une autre réplique vient à tomber alors Windows

Fabric va attendre indéfiniment que la situation soit « réparée ». Cette situation est nommée : Quorum lost replica Set. D’après les tests qu’il m’a été donné de faire sur une plateforme de validation contenant une ferme à quatre serveurs frontaux, si deux répliques viennent à tomber l’une après l’autre alors le client Skype reste connecté quelque temps mais perd la connexion au bout de quelques minutes (voir le résultat des tests en figures 5, 6 et 7).

Il faut donc lors de vos planifications d’architecture prendre en compte ces deux notions que sont la notion de Quorum de serveur et la notion

de Quorum de réplica qui sont deux choses légèrement différentes et qui vont affecter ou non les connexions de vos utilisateurs. Le plus simple est donc de prendre un exemple.

Un client désire mettre en place une solution de redondance au sein d’une ferme de serveurs Skype dont la moitié sera hébergée dans une salle serveur nommée

Salle 1 et l’autre moitié dans la Salle 2, plusieurs scénarios sont envisageables :

Le premier scénario consiste à positionner 3 serveurs dans chaque salle serveurs et à faire en sorte que la base de données SQL qui va automatiquement rentrer en ligne de compte pour l’obtention du Quorum de la ferme, soit clustérisée sur les deux salles. Le second scénario consiste И ne mettre en place que 2 serveurs dans chaque salle serveur et à positionner de la même faНon une base de données clusterisée sur les deux salles.

Une des questions que l’on peut se poser : obtiendra-ton une meilleure disponibilité en cas d’arrêt d’une salle si l’on positionne 3 serveurs par salle plutôt que deux ?

Dans le cas du scenario 1, si la salle 1 vient à s’éteindre, la base de données SQL va basculer automatiquement et restera disponible pour le vote. 3 serveurs frontaux ne seront plus disponibles mais le Quorum de serveurs restera présent car plus de la moitié des votants seront présents. Est-ce que cela signifie que les clients pourront rester connectés ? Rien n’est moins sûr ! Du moins cela dépend de la façon dont les routingsgroup ont été positionnés. Si dans le cas d’un routing group, l’ensemble des réplicas (Primaire, Secondaire et Secondaire de secours) se trouvaient dans la salle 1, alors les utilisateurs de ce groupe de routage perdront leurs connexions et seront incapables de se connecter de nouveaux. A l’inverse, si deux des trois réplicas de ce groupe en question étaient positionnés sur un des serveurs de la salle 2, alors les utilisateurs de ce groupe de routage restent connectés.

Dans le cas du scenario 2 où seulement deux serveurs sont positionnés dans chaque salle serveur alors l’impact de l’arrêt d’une salle peut être différent. Du côté du Quorum de la ferme, pas de souci à l’horizon, car le serveur SQL est toujours présent et participera au vote. Comme dans la salle 2, le nombre de serveurs restant en fonctionnement est deux et que le serveur SQL est présent, le Quorum est atteint. Du côté du Quorum de réplica, au pire deux répliques sont perdues. Les utilisateurs positionnés sur ce groupe de routage ne peuvent plus se connecter et ceux qui étaient connectés, perdent la connexion au bout de quelques minutes. Par contre, si par un heureux hasard deux répliques se trouvent dans la salle 2 alors les utilisateurs continueront d’utiliser Skype pour entreprise.

Dans cet exemple précis, 3 serveurs dans chaque salle ne donnent pas automatiquement plus de disponibilité que le fait d’en positionner deux. Tout dépend en réalité de la répartition des répliques des groupes de routage. Nous voyons donc que la prise en considération de ces deux notions de Quorum et du nombre de serveurs frontaux mis en place, peut selon le scénario dépanne, avoir des impacts utilisateurs différents. Leurs prises en compte dans les documents de reprise d’activité devraient à mon humble avis y figurer en bonne place.