Haute disponibilite des serveurs frontaux en Skype 2015

Compte tenu de l’importance que prend la solution Skype pour Entreprise dans le fonctionnement quotidien des sociétés, la mise en place d’un environnement Skype 2015 en haute disponibilité est de plus en plus une nécessité

La planification des environnements de haute disponibilité sous Skype 2015 répond à des exigences particulières qui sont notamment liées à l’utilisation d’une solution logicielle (Windows Fabric) généralement mal connue par les administrateurs de ces plateformes. Nous allons donc détailler les quelques informations clés que vous devez prendre en compte pour comprendre comment fonctionne la haute disponibilité…

Principes de Base Haute disponibilite des serveurs frontaux en Skype 2015

La haute fonctionnalité des services Skype For Business se base comme bien souvent chez Microsoft sur la multiplication des rôles pour chaque service clé. Dans l’environnement Skype pour Entreprise nous allons donc trouver les 4 grands rôles fondamentaux que sont :

• Les services frontaux

• Les services Office Web APP

• Les services Edge

• Les services de base de données

Dans cet article, nous allons nous concentrer exclusivement sur les services frontaux qui globalement accueillent les connexions de vos utilisateurs internes. Pour informations, vos serveurs frontaux sont responsables des fonctions suivantes (Sources MicrosoftTechnet) :

• Enregistrement et authentification des utilisateurs.

• Informations de présence et échange de cartes de visite.

• Services de carnet d’adresses et développement de listes de distribution.

• Fonctionnalités de messagerie instantanée, dont les conférences de messagerie instantanée à plusieurs.

• Conférence web, conférence rendez-vous PSTN et conférence A/V (si déployée).

• Hébergement d’applications, à la fois pour les applications incluses dans Skype Entreprise Server (par exemple, Intendant Conférence et application Résponse Group) et pour les applications tierces.

• Surveillance éventuelle permettant de collecter des informations d’utilisation sous forme d’enregistrements des détails des appels et d’enregistrements des erreurs des appels (CER). Ces informations fournissent des mesures sur la qualité des médias (audio et vidéo) qui traversent votre réseau à la fois pour les appels Voix Entreprise et les conférences A/V.

• Composants web pour des tâches web prises en charge tels que le planificateur web et le lanceur de participation.

• Archivage éventuel permettant d’archiver les communications de messagerie instantanée et le contenu des réunions pour des raisons de conformité.

• Services web de conversation permanente, si celle-ci est activée, pour la gestion des salles de conversation et le téléchargement de fichiers. Si vous souhaitez assurer une haute disponibilité pour vos utilisateurs, plusieurs serveurs doivent donc former une ferme (Pool). Notez-le dés à présent, l’éclatement de cette ferme qui peut être constituée de 2, 4 voire d’une dizaine de serveurs n’est pas supportée par Microsoft dans le cadre d’un réseau dit « Métropolitain ». Autrement dit, votre ferme de serveurs devra impérativement, si vous souhaitez rester dans un cadre supporté par l’éditeur, résider au sein d’un même réseau local. La solution alternative mais qui n’est pas à proprement parler de la haute disponibilité reste l’association de ferme (Pool Pairing). Pour plus d’information sur cette fonctionnalité, merci de vous reporter à l’article suivant : https://technet.microsoft.com/fr-fr/library/jj204697.aspx

Concernant les fonctions de haute disponibilité qui nous préoccupent, elles sont donc basées sur la mise en place de la version dite ‘Entreprise ‘ de Skype pour Entreprise qui consiste à mettre en place une base de données SQL à des fins de stockage de la configuration et plusieurs serveurs frontaux. Cette configuration nécessitera dans tous les cas, la mise à disposition d’un service de répartition de charge pour les flux Web hébergés sur ces derniers. En ce qui concerne la répartition des flux Web, merci de vous reporter à cette adresse : https://technet.microsoft.com/fr-fr/library/gg615011.aspx. Concernant plus précisément ce qui nous intéresse à savoir le fonctionnement de la haute disponibilité des serveurs frontaux, il faut prendre en considération le fait que les serveurs vont procéder comme tout environnement clustérisé à un vote pour déterminer si le quorum (la majorité) est atteinte. La chose la plus importante est alors de savoir qui va compter pour établir ce vote. Pour cela, il suffit d’examiner les données contenues dans le fichier suivant :

(((IMG8406)))

• C:\ProgramData\Windows Fabric\FabricHostSettings. xml pour SkypeForBusiness et

• C:\ProgramData\Windows Fabric\settings.xml pour Lync 2013.

Voici un exemple de cas que vous pouvez rencontrer en figure 1.

Comme vous pouvez le voir, la configuration est changeante compte tenu de la présence ou pas de la parité du nombre de serveurs. Dans le cas d’une ferme paire, le serveur SQL va entrer en ligne de compte dans le vote et l’obtention du Quorum, dans le cas contraire où le nombre de serveurs est impair le serveur SQL est ignoré. L’obtention du Quorum est importante car il permet de faire fonctionner correctement la ferme. Autrement dit, pour que la ferme fonctionne la présence du Quorum est impérative mais vous verrez par la suite que cela n’est pas complètement suffisant. Concernant le Quorum et sa présence, voici un tableau qui permet d’y voir un peut plus clair.

(((IMG8407)))

On notera par conséquent deux états concernant le Quorum qui sont les suivants :

• Quorum Lost : cet état se produisant quand le nombre de serveurs est insuffisant pour obtenir le Quorum. Ce qui notamment est le cas quand tous les serveurs de la ferme démarrent

• Operating Pool : Lorsque tous les serveurs de la ferme en question sont présents et en ligne Ceci étant posé, intéressons-nous maintenant à la répartition des utilisateurs au sein d’une ferme. Tous vos utilisateurs au sein d’un pool vont être affectés à ce que l’on appelle un groupe de routage (Routing Group). Ce groupe de routage va contenir trois copies qui seront réparties sur les serveurs de la ferme. On notera donc que chaque utilisateur qui appartient à un seul groupe de routage, est lié à 3 répliques de ce dernier.

Répliques qui seront notées comme ceci :

• Réplique principale

• Réplique secondaire

• Réplique secondaire de secours