Architecture Skype for Business Server

Pour continuer le détail de Skype for Business, je vais maintenant m’attarder sur les considérations d’architecture de Skype for Business Server.

Microsoft identifie les infrastructures en 5 catégories :

1. Topologie standardisée : il s’agit des infrastructures Office 365, qui sont totalement standardisées et sur lesquelles les clients n’ont pas la main sur les serveurs.
2. Topologie structurée : Microsoft parle ici des architectures de référence, qu’on peut voir sur TechNet et qui présentent l’architecture la plus standardisée possible pour un déploiement en entreprise.
3. Topologie recommandée : il s’agit des topologies qui ne sont pas des architectures de référence mais qui suivent les recommandations de Microsoft.
4. Topologie supportée : il s’agit des topologies qui répondent aux critères de supportabilité mais qui ne sont pas forcément les architectures les meilleures à déployer.
5. Topologie non supportée : il faut absolument proscrire cela pour éviter de se retrouver dans une situation où le support Microsoft ne pourra pas vous aider tant que l’infrastructure ne sera pas modifiée pour être supportée.

Je vais m’attacher ici à présenter les points importants des topologies recommandées.

Avant d’entrer dans le détail, voici un petit point que ce que les infrastructures Skype for Business offrent comme possibilité :

• Online
• Hybrid
• Server

On se retrouve dans le même modèle que celui existant entre Lync Server et Lync Online.

Skype for Business Online

Dans un scénario Skype for Business Online, il n’y a pas de serveurs Skype for Business déployés en interne. Mais cela ne signifie pas pour autant qu’il n’y a pas de serveur du tout ! Dans la plupart des cas, les entreprises mettront en place la synchronisation d’Active Directory vers Azure Active Directory, cela nécessitera un serveur de synchronisation avec Microsoft DirSync ou Microsoft Azure AD Sync. Au niveau des bonnes pratiques, il faudra :

• Utiliser un seul tenant Office 365, c’est-à-dire un seul environnement Office 365 pour toute l’entreprise.
• Ne pas avoir de forêt de ressources et avoir une seule forêt de comptes si on synchronise Active Directory avec Azure Active Directory.

Cela ne signifie pas que les autres possibilités, notamment au niveau du nombre de forêts Active Directory, sont impossibles ou non supportées, mais ça n’est pas la recommandation de Microsoft.

Avec Skype for Business Online, pour avoir toutes les fonctionnalités, il faut utiliser Exchange Online.

Au niveau de l’authentification, la brique AD FS (Active Directory Federation Services) pourra être mise en œuvre. Je parlerai de ce point en particulier dans un futur article.

Skype for Business Hybrid

Le scénario Skype for Business Hybrid est globalement similaire au scénario Lync Hybrid qui existe déjà. Globalement, il s’agit d’avoir une partie des utilisateurs déployés sur Skype for Business Server et une autre partie sur Skype for Business Online.

Dans ce scénario, les entreprises auront une infrastructure Skype for Business Server, la synchronisation d’annuaire Active Directory (cette fois-ci elle est obligatoire) et la configuration faite pour utiliser Skype for Business Online avec le même domaine SIP.

Les mêmes recommandations existent dans ce scénario qu’avec le scénario pur Online. On ajoute aussi ces points :

• L’infrastructure Skype for Business Server est déployée dans la forêt de comptes.
• La fédération et l’authentification initiale des utilisateurs se fait via Skype for Business Server, cela rend donc l’infrastructure interne critique et il est donc important de s’assurer qu’elle est redondante.

Dans le mode Hybrid, la connectivité entre Skype for Business et Exchange est possible ainsi :

• Les utilisateurs Skype for Business Online utilisent Exchange Online.
• Les utilisateurs Skype for Business Server utilisent Exchange Server ou Exchange Online.

L’authentification des utilisateurs hébergés sur Office 365 est possible avec AD FS.

Skype for Business Server

Ce type de scénario est le plus courant à mon avis : déployer une infrastructure Skype for Business en interne de l’entreprise. Toujours dans le registre des bonnes pratiques, il faut :

• Déployer Skype for Business Server dans la forêt de comptes.
• Déployer Exchange Server, ou alors utiliser Exchange Online ou Exchange Hybrid.

Ce scénario donne la possibilité de passer en mode Hybrid par la suite si nécessaire.

Architectures avec 3 forêts

Les architectures avec 3 forêts, typiquement les scénarios avec une forêt AD avec les comptes utilisateurs, une forêt AD pour Lync Server hébergée chez un opérateur pour fournir de la téléphonie Lync dans un mode « managé » et un tenant Office 365 pour Exchange Online, sont des architectures qui sont supportées avec Lync Server 2013 depuis septembre 2014.

Ce type d’architecture est très complexe à mettre en œuvre et ne semble pas disponible dans Skype for Business. Cela signifie que les entreprises qui souhaitent externaliser leur infrastructure Skype for Business Server devront étendre leur forêt Active Directory pour qu’elle puisse être utilisée pour héberger l’infrastructure Skype for Business Server gérée par un opérateur.

Composants Skype for Business Server

Fondamentalement, les principes de Lync Server 2013 restent valable dans Skype for Business Server. On retrouve tous les points importants tels que :

• Pool Standard
• Pool Entreprise :
  • La recommandation reste d’avoir 3 serveurs Front End minimum par pool, même si c’est supporté avec 2 serveurs Front End.
  • Concevoir le pool pour subvenir à la perte d’un serveur Front End
• Pool Quorum :
  • Le Pool Quorum est le concept qui nécessite d’avoir au moins 50% des serveurs Front End disponibles, sinon le pool entier s’arrête.
  • Tout comme dans Lync Server, si exactement 50% des serveurs Front End sont disponibles mais que le Back End SQL est indisponible, le pool entier s’arrête.
• Skype for Business & Streched Datacenter :
  • Ce n’est pas supporté dans Lync Server 2013 et ça ne l’est pas non plus dans Skype for Business Server : il ne faut pas déployer un pool Skype for Business sur deux datacenters.
  • Cette architecture, bien que potentiellement séduisante sur le papier, pose des problèmes et peut au final s’avérer moins fiable qu’une architecture avec 2 datacenters qui hébergent chacun un pool.
  • Il faut privilégier le Pool Pairing.
• Disaster Recovery :
  • Pour rappel, le Disaster Recovery requiert en général une intervention manuelle de l’administrateur, on cherche à éviter une bascule automatique en cas d’un problème annexe.
  • La méthodologie supporté est d’utiliser le Pool Pairing.
  • Pour garantir la disponibilité des Simple URLs nécessaires au bon fonctionnement, il faut utiliser si possible du GeoDNS.
• Bases de données :
  • L’infrastructure SQL pour Skype for Business doit être dans le même datacenter que les serveurs Front End.
  • Les mécanismes de haute disponibilité sont :
    • SQL Failover Cluster : il s’agit du cluster traditionnel SQL, peu utilisé pour les infrastructures Lync et probablement encore moins utilisé pour Skype for Business.
    • DB Mirroring : ce mécanisme n’est pas à privilégier car il va disparaître dans une future version de SQL Server.
    • SQL AlwaysOn : ce mécanisme doit être privilégié car permet une meilleure gestion de bascule des bases de données SQL et va être pérenne.
• Partages de fichiers :
  • Leur utilisation reste la même que pour Lync Server.
  • Ils doivent être localisés dans le même datacenter que les serveurs Front End.
  • DFS et DFS-R permettent d’assurer la disponibilité des données.
• Office Web Apps :
  • Ce composant est toujours nécessaire pour afficher des présentations PowerPoint.
  • Les serveurs Office Web Apps nécessitent toujours un load balancer.
• Base de Monitoring :
  • Il est recommandé d’avoir une seule base de données centralisée plutôt qu’une base de donnée par pool ou par datacenter.
  • Cela permet d’avoir une vue globale sur les données CDR et QoE plutôt que d’avoir à recouper les informations de plusieurs bases.
• Serveurs Edge :
  • Le principe et les rôles sont les mêmes que dans Lync Server.
  • DNS Load Balancing est recommandé dans les cas généraux.
• Reverse Proxy :
  • Le principe est le même que dans Lync Server.
• Video Interoperabiltiy Server (VIS) :
  • Ce rôle permet l’intégration de Lync avec les équipes de visio conférence tiers tels que Cisco/Tandberg.
  • Ce rôle n’est pas mutualisable avec les autres rôles.
  • Il est possible de créer un pool VIS pour de la haute disponibilité

Voici les premiers détails en ce qui concerne l’architecture Skype for Business Server. On remarque globalement que beaucoup de concepts de Lync Server 2013 sont conservés, cela explique donc pourquoi la mise à jour de Lync Server 2013 vers Skype for Business Server sera simple.

— Stefan