On a tous eu des soucis de provisionnement de service de synchronisation de profil utilisateur avec SharePoint 2010 avant le SP1. Service qui ne démarre pas, service bloqué en démarrage, problèmes de permissions…
Avec SharePoint 2013 arrive le service de cache distribué aka AppFabric Cache service. Ce service sert à, comme son nom l’indique, faire de la mise en cache pour améliorer les performances de SharePoint 2013.
Qu’est-ce qui est mise en cache ? Des jetons de sécurité, des contextes de sécurité, des données de session, des objets SharePoint, et le plus important, des données sociales (flux d’information & co).
Plus de détails https://technet.microsoft.com/library/jj219700(office.15).aspx
Vous comprendrez donc que son bon fonctionnement conditionne fortement celui des nouvelles fonctionnalités sociales apportées par SharePoint 2013.
Récemment j’ai procédé à l’installation d’une ferme de production sous SharePoint 2013 et je me suis cassé les dents sur la mise en place des fonctionnalités sociales et du service de cache. En effet c’est nouveau, peu documenté, pas beaucoup de retour d’expérience. J’ai fini par faire appel au support Microsoft, mon ticket et monté jusqu’au niveau 3, le problème n’était donc pas simple à la base. L’objectif de cet article est donc de faire un retour d’expérience afin de vous éviter les écueils et de donner quelques conseils sur comment gérer ce nouveau service, les impacts en termes de topologie.
Nous allons commencer par des questions de topologie, en effet où faut-il disposer ce nouveau service pour obtenir les meilleures performances ? Microsoft répond ceci, nous avons quatre solutions :
Dans le cadre d’une installation complète sur un seul serveur SharePoint (toute la ferme sur une machine), la réponse est assez simple, sur la même machine.
Dans le cadre d’une ferme plus complète, sur tous les serveurs
Dans le cadre d’une ferme importante, sur les serveurs web frontaux
Dans le cadre d’une ferme de grande taille, sur des serveurs dédiés
Voir la vidéo sur le cache ici, très instructive https://technet.microsoft.com/en-us/sharepoint/fp123606.aspx
Note : lors de mon case, j’ai eu aussi des ingénieurs support niveau 2 appfabric, eux recommandent directement un serveur dédié au cache (ou plusieurs), dès le second type de ferme pour des questions de performance.
Mais voilà il y a quelques « détails » à savoir :
Il est très fortement déconseillé d’avoir plus de 5 serveurs de cache par ferme.
Il est très fortement déconseillé d’exécuter le service de cache sur une machine faisant tourner les services de synchronisation de profil utilisateur et/ou de recherche.
La mémoire dynamique est très fortement déconseillée (dans le cadre de machines virtuelles)
La mémoire allouée au service de cache doit être la même sur tous les nœuds du cluster de cache.
La mémoire alloué au service ne doit pas excéder 16Go.
Si à un moment donné l’utilisation mémoire de la machine dépasse les 90%, le service de cache se met en mode de purge, il n’accepte plus aucun objet et essaie d’en vider un maximum jusqu’à atteindre les 70% causant une dégradation importante des performances.
SharePoint 2013 utilise (et embarque) App Fabric 1.1, qui est la seule version supportée même si elle est vieille, il est formellement interdit de procéder à une mise à jour manuelle du composant (ou sinon perte du support Microsoft).
Une liste plus exhaustive de ces détails est disponible ici https://technet.microsoft.com/library/jj219572(office.15).aspx
Le service de cache fonctionne par nature en cluster, en effet son premier rôle est de mettre des objets en mémoire lors du premier accès (ou lors d’une phase de chargement initiale) afin de permettre un accès plus rapide par la suite. Il sert aussi à faire transiter les objets (notamment de session) entre les divers serveurs. De plus il apporte une certaine tolérance à la panne.
Votre cluster est donc constitué d’un ou plusieurs services de cache. Ce service de cache est provisionné et démarré par défaut par le psconfig (assistant de configuration des produits et technologies SharePoint). Vous avez la possibilité d’indiquer au psconfig de ne pas provisionner ce service avec une option. Voir https://sharepointinterview.com/sharepoint-2013-preview-setup-and-configuration-error-with-appfabric-cache/
Si le service est dans l’état arrêté, il est effectivement arrêté mais il fait toujours partie du cluster de cache et peut éventuellement perturber son bon fonctionnement.
Pour l’arrêter et le dé provisionner correctement, il faut utiliser les commandes powershell suivantes :
Stop-SPDistributedCacheServiceInstance -Graceful
Remove-SPDistributedCacheServiceInstance
Il est très important de faire le stop graceful avant le remove, car sinon votre cluster se retrouvera dans un état inconsistant et bloqué.
Plus de documentation sur comment gérer le service de cache ici https://technet.microsoft.com/library/jj219613(office.15).aspx
Quelques autres commandes très utiles :
(Lancer la console SharePoint en mode admin avant et entrer use-cachecluter)
get-cacheclusterhealth qui vous permet de connaitre la santé du cluster de cache (s’il y a des fragments, ce n’est pas bon signe) https://msdn.microsoft.com/en-us/library/ff428190(v=azure.10).aspx
Restart-cachecluster qui redémarre tous les services de cache composant le cluster et force une reconstruction complète du cache https://msdn.microsoft.com/en-us/library/ff428182(v=azure.10).aspx
Pour ce qui est des droits, ce service n’a pas besoin de droits particuliers sur la machine, il suffit que le compte de service qui le provisionne soit admin de la machine, son compte de service doit aussi avoir le contrôle total de l’application de service profil utilisateur.
Pour que votre newsfeed fonctionne correctement, car c’est quand même le but recherché, il faut que :
Votre recherche soit configurée avec la recherche continue (continous crawl), merci au user group sharepoint Montréal pour l’information.
Votre service profil utilisateur soit correctement configuré.
Compte de service du cache ayant le contrôle total sur l’application de service profil utilisateur.
Compte de service de l’application web qui héberge la collection de site « mon site » ait le contrôle total de l’application se service profil utilisateur.
Les comptes suivants aient le droit d’accéder au service de cache :
Compte de service de recherche
Compte de service profil utilisateur
Compte de la ferme
Compte de l’application web qui héberge le mysite
Vous pouvez donner ces permissions sur le cluster de cache grâce à la commande Grant-CacheAllowedClientAccount https://msdn.microsoft.com/en-us/library/ff428172(v=azure.10).aspx
Enfin la commande Export-CacheClusterConfig vous permettra de savoir quelle est la configuration actuelle du cluster de cache https://msdn.microsoft.com/en-us/library/ff428173(v=azure.10).aspx
Dernière précision, ce service ne vient pas remplacer les mécanismes déjà connus de cache de sortie, cache objet, et blobcache.
Voilà c’est globalement tout ce que j’avais à dire sur ce service de cache, sur les impacts aux topologies, les écueils à éviter etc. J’espère que cela vous aura aidé à mieux apprivoiser ce nouveau service et vous aura fait gagner du temps.
Merci aux membres des communautés, staff AlphaMosaïk et ingénieurs de support Microsoft sui m’ont aidé sur ce problème.