Ferme de serveur & Pool Pairing

Là où les choses se complexifient un peu c’est lorsque que l’on va adresser des clients ayant deux sites physiques de production ou deux centres de données. Dans ce cas précis, la version Lync 2013 permet de mettre en place une solution de ferme de serveurs associés ou Pool Pairing. L’avantage de cette solution est qu’il n’existe pas de réelle contrainte de distance et Microsoft ne donne pas d’indication pour le moment sur les prérequis en matière de latence entre les deux sites.

Ferme de serveur & Pool Pairing

Dans le cas d’un scénario comprenant deux centres de production, on y placera deux fermes (Pool) de serveurs frontaux que l’on pourra facilement associer. L’intérêt de cette solution est de permettre une réplication de données à travers un nouveau service nommé (Service de Backup). Cette nouvelle fonction d’association de fermes de serveurs frontaux (Pool Pairing) est possible pour les versions Enterprise mais également pour les serveurs fonctionnant avec la version Standard. La seule condition est que vous devez associer des fermes de même version et de même nature (physiques ou virtuels). Dans ce type de scénario, il est également à prendre en compte le fait que tous les utilisateurs en cas de sinistre du site A basculeront sur le site B et que par conséquent vous devrez estimer le dimensionnement des serveurs mais aussi celui de la bande passante au regard de cette situation. Voir figure ci-dessous.

L’un des intérêts majeurs de cette nouvelle fonction, est qu’elle permet également de répliquer via le service de backup, les informations de la base de données de configuration (CMS). Si dans notre exemple, le site A possède la base de données CMS alors une copie de la base de données CMS sera créée sur le site B et les services CMS seront en place dans les deux fermes. Par contre, dans tous les cas de figure, seul un site est désigné comme maître CMS, le second étant de facto considéré comme secours.

Les fonctions d’association de ferme de serveurs sont de type 1 pour 1 et il n’est pas prévu de pouvoir faire un sorte qu’une ferme de serveurs puisse secourir (Backup registrar) plus de un pool.

Contrairement au fonctionnement de serveurs frontaux au sein d’une ferme, le basculement de fermes associées n’est pas automatique. Ce qui, dans le cas de basculement de site de production n’est souvent pas un réel problème. Ce qui implique aussi, que côté utilisateur, en cas de perte du site A une déconnexion puis une reconnexion est à prévoir.

Dans ce type de scénario, le temps de rétablissement du service est donc à calculer avec un certain nombre de variables, qui sont :

• Le temps d’alerte des équipes en charge de la maintenance en conditions opérationnelles.

• La durée nécessaire à l’estimation de la situation.

• Le temps nécessaire pour conduire correctement les actions de basculement des utilisateurs vers la ferme associée.

Pour cette dernière étape et uniquement cette dernière étape, Microsoft estime que 30 minutes sont nécessaires pour accomplir l’ensemble des opérations (RTO). Nous sommes donc loin d’un basculement automatique mais rappelons- le, il s’agit bien d’un basculement de services suite à la perte complète d’un site de production ce qui, je l’espère pour vous, ne devrait se produire qu’exceptionnellement….

Côté réplication des données, le service de réplication (Backup Service) qui fonctionne sur les serveurs frontaux synchronise ses données toutes les 2 minutes. La réplication s’effectue donc entre les deux services de backup qui s’échangent les données entre les deux fermes de serveurs et qui valident leurs prises en compte par un échange de cookie. L’éditeur précise que compte tenu de la bande passante et de la latence possible entre les deux sites un décalage de 30 minutes de la réplication est possible (RPO) ce qui vis-à-vis de Lync sera plus facilement accepté que dans un environnement Exchange.

Le service de backup dans notre cas de figure va donc principalement s’occuper de :

• Synchroniser les données des utilisateurs (Sip Uris, liste de contacts et les éléments de configuration) ainsi que les données de conférences (conférences, présentation Powerpoint, tableaux blanc).

• Compresser les données avant transfert.

• Décompresser les données sur le pool associé.

• D’importer les données dans le stockage distant.

Le transport de données du service de backup ne procédant à aucune encryption, l’utilisation d’une connexion sécurisée (IpSec) s’impose donc si vous envisagez d’utiliser une connexion Internet entre les deux sites.