Stefan Plizga - Skype for Business

Partage d'expérience autour de Lync & Skype for Business

Optimiser les performances de SQL Server Express sur les serveurs Front-End

Microsoft ne donne pas de bonnes pratiques particulières concernant les bases de données existantes dans SQL Server Express sur les serveurs Front-End. On dit toujours qu'il n'y a rien de particulier à faire, et ce n'est pas faux. Par contre, dans certains cas, on peut observer des temps de réponse de Lync Server / Skype for Business Server qui deviennent plus long sans raison apparente.

Dans SQL Server, on retrouve des indexes sur les tables, qui permettent à SQL d'accéder à l'information plus vite, et on observe que l'ajout de plan de maintenance qui gère les indexes et met à jour les statistiques peut améliorer les performances des serveurs Front-End.

Voici une petite procédure pour mettre en place ce type de plan de maintenance. Il existe d'autres méthodes pour arriver à la même opération mais celle-ci est simple compte-tenu du fait que l'Agent SQL ne fonctionne pas par défaut sur les serveurs Front-End, et que je cherche à éviter de faires des modifications qui pourraient disparaître lors d'une mise à jour.


Les étapes sont relativement simples :

SET @CreateJobs = 'N'
SET @LogToTable = 'N'

  • Se connecter depuis une machine distante qui a SQL Server Management Studio à l'instance RTCLOCAL de chaque Front-End. Si nécessaire pour cette opération temporaire, désactiver le pare-feu Windows ou créer une exception pour SQL Server Express
  • Lancer un New Query editor et exécuter le contenu du fichier MaintenanceSolution.sql
  • Faire la même opération avec l'instance LYNCLOCAL de chaque Front-End


A partir de ce moment, l'outillage est en place. Puisque l'Agent SQL n'est pas fonctionnel par défaut, on va utiliser une tâche planifiée sur chaque Front-End pour exécuter le plan de maintenance :

  • Créer un fichier IndexOptimize.sql avec le contenu suivant et le place dans le répertoire C:\Tools\IndexOptimize de chaque Front-End :

EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y',
@PageCountLevel = 10

  • A l'aide du Task Scheduler de Windows, créer une tâche planifiée avec les paramètres suivants :
    • Tâche exécutée par : NT AUTHORITY\SYSTEM
    • Planification : Journalière, à 5h00
    • Action 1 :
      • Programme : osql.exe
      • Arguments : -E -S .\RTCLOCAL -i IndexOptimize.sql
      • Répertoire : C:\Tools\IndexOptimize
    • Action 2 :
      • Programme : osql.exe
      • Arguments : -E -S .\LYNCLOCAL -i IndexOptimize.sql
      • Répertoire : C:\Tools\IndexOptimize


Quelques notes :

  • Pour la simplicité, l'exemple ci-dessus utilise le compte NT AUTHORITY\SYSTEM mais il est possible d'utiliser un autre compte qui fait partie des administrateurs locaux (c'est le seul groupe qui a le role "sysadmin" dans les deux instances RTCLOCAL et LYNCLOCAL)
  • J'ai choisi 5h pour l'exécution de la tâche planifiée mais ça peut être à un autre moment en fonction de l'occupation des serveurs et des autres traitements.
  • Pour vérifier que le script fonctionne bien, il est possible d'ajouter la ligne @LogToTable = 'Y' (sans oublier une virgule à la fin de la ligne précédente) dans le fichier IndexOptimize.sql et ainsi voir le contenu de la table LogCommand de la base master de chaque instance. S'il y a des lignes,c'est que ça fonctionne, sinon il y a probablement un problème dans le fichier IndexOptimize.sql ou dans la ligne de commande exécutée par la tâche planifiée. Ne pas oublier de supprimer le @LogToTable après le test et de vider la table LogCommand car celle-ci ne se vide jamais automatiquement


Aussi, il ne faut pas oublier d'appliquer les Service Packs et les CU sur les instances SQL Express des serveurs Front-End !

-- Stefan

Focus sur la Haute Disponibilité SQL

L'arrivée de Skype for Business Server amène des nouveaux au niveau des mécanismes de haute disponibilité SQL supportés. Globalement, ce qui ne change pas :

  • Le cluster SQL "traditionnel" est toujours supporté.
  • Le Database Mirroring est toujours supporté.

Ce qui change, c'est que la solution AlwaysOn Availability Groups de SQL Server est dorénavant supportée et devient celle qui est recommandée par Microsoft car :

  • Cette technologie va être pérenne tandis que le Database Mirroring va être amené à disparaître dans une future version de SQL Server.
  • AlwaysOn permet d'avoir un réplica primaire et jusqu'à 2 réplicas secondaires synchrones.
  • Grâce aux Availability Groups de AlwaysOn, toutes les bases de données basculent en même temps, ce qui évite de se retrouver avec quelques bases actives sur un nœud et les autres bases restantes sur un autre nœud.

Je ne vais pas entrer dans le détail concernant le cluster SQL traditionnel ou le Database Mirroring car il n'y a rien de neuf. Par contre il convient de s'attarder un peu sur AlwaysOn.


Versions SQL et Licensing

  • Un serveur SQL seul peut être version Standard ou Enterprise mais ce scénario ne fournit aucune haute disponibilité.
  • Le Database Mirroring requiert la version Standard ou Enterprise de SQL Server.
  • Le mode AlwaysOn Availability Groups nécessite une licence Enterprise de SQL Server.


Support de AlwaysOn Availability Groups

  • Ce mode n'est possible qu'avec Skype for Business Server 2015, aucunement avec Lync Server.
  • Tous les réplicas doivent être dans le même sous-réseau.
  • Les réplicas doivent être en mode de réplication synchrone.
  • Tous les nœuds SQL doivent faire partie du même domaine Active Directory.
  • Le mode de bascule doit être automatique.
  • Skype for Business ne supporte pas la lecture sur le réplica secondaire ni l'accès à un réplica dans Azure.


Mise en place de AlwaysOn Availability Groups pour Skype for Business Server 2015

Dans le cas d'un nouveau pool à installer, la configuration de Skype for Business Server 2015 se passe, de manière macroscopique, de la manière suivante :

  1. L'infrastructure SQL doit être fonctionnelle mais AlwaysOn Availability Groups n'est pas encore installé
  2. Dans la topologie Skype for Business, ajouter un SQL Store avec une configuration particulière qui permettra de pointer vers le listener AlwaysOn Availability Group tout en référençant dans un premier temps le nœud primaire du futur Availability Group, et indiquer que le mode de haute disponibilité est AlwaysOn Availability Groups.
  3. Terminer la configuration du nouveau pool Skype for Business et publier la topologie. Cette dernière operation va créer les bases de données Skype for Business Server sur le nœud primaire du futur Availability Group.
  4. Ensuite, réaliser les operations de preparation de AlwaysOn sur SQL Server, à savoir ajouter le composant Windows Server Failover Clustering sur les différents nœuds SQL, valider la configuration, créer le cluster, configure les paramètres du quorum et activer la fonctionnailté AlwaysOn Availability Groups.
  5. Créer un Availability Group pour Skype for Business et réaliser les operations de sauvegarde/restauration nécessaires à la mise en place des replicas de bases de données sur les serveurs secondaires à partir des bases existantes sur le serveur primaire.
  6. Mettre à jour la topologie Skype for Business Server en remplaçant la reference au nœud primaire de l'Availability Group par le nom du listener en place, puis publier la topologie.


Mise à jour de l'environnement existant

Etant donné qu'il est possible de mettre à jour ses pools Lync Server 2013 vers Skype for Business Server 2015 simplement, Microsoft documente aussi la méthode pour passer de SQL Server seul ou avec Database Mirroring vers AlwaysOn Availability Groups.

Le principe de passage de SQL Server seul vers AlwaysOn Availability Group est simple :

  • Pour un serveur SQL seul :
    • Installer un 2e serveur SQL permettant de créer un cluster et un AlwaysOn Availability Group.
    • Suivre la même procedure que celle décrite plus haut.
  • Pour une infrastructure Database Mirroring :
    • Vérifier que toutes les bases de données sont sur le serveur SQL primaire.
    • Supprimer les bases sur le serveur secondaire et modifier la topologie en consequence.
    • Suivre la même procedure que celle décrite plus haut pour créer un AlwaysOn Availability Group et mettre à jour la topologie.


Voici un aperçu approfondi de la partie infrastructure SQL pour Skype for Business.

-- Stefan