Troubleshooting OCS 2007 R2
Dans cette partie, on essaiera d’énumérer les “best practices” à mettre en place afin d’éviter des problèmes critiques pouvant générer un blocage en environnement de production.
Ces bonnes pratiques peuvent être liées aux différents composants que le produit OCS/Lync utilise de manière intensive tels que: SQL serveur, AD, Réseaux,…
Ces bonnes pratiques ne sont pas exaustives mais représentent un retour d’expérience assez enrichissant. Et à ce titre, nous vous recommandons très fortement de les mettre en place.
1. Problèmes de performance/connection liés à l’instance SQL Serveur
Il arrive que dans certains cas, assez rare tout de même, que l’instance SQL serveur hébergeant les bases de données d’OCS provoque une consommation CPU avoisinant les 100%
Ce problème peut-même empêcher toute nouvelle connection d’un client communicateur.
En regardant de plus près ce qui s’y passe au niveau de l’instance SQL serveur, on constate que la procédure stockée qui consomme le plus de temps est: RTCPublishMultipleCategories
Cette procédure stockée est notamment utilisée pour mettre à jour des informations relatives à la présence des utilisateurs OCS.
Comment procéder pour mettre en evidence que cette procédure stockée qui pose ce problème de consoomation CPU?
Entre autres méthodes, deux façons simples et rapides que l’on peut utiliser.
L’une consiste à utiliser une requête ( ou procédure stockée prédéfinie) SQL Serveur (sp_who2) ou bien utiliser la MMC du Serveur SQL ( Management Studio).
a) Utiliser la requête: sp_who2 ‘Active’
Et regarder le processus ( SPID ) qui consume le plus de temps CPU au niveau de la colonne: CPUTime , comme indiqué ci-dessus.
Et vous trouverez ainsi le processus qui consomme le plus de temps CPU.
b) Utiliser le tableau de bord SQL serveur
Managment Studio –> Click Droit sur le nom de l’instance SQLServeur –> Report –> Satndard Reports –> Performnce – Top Queries by Average CPU
Que faut-il faire dans ce cas précis?
Dès que l’on a bien identifié que c’est bien cette procédure stockée qui est à l’origine de cette consommation CPU ( environ 100 %), il faut procéder à la mise à jour des statistiques de certaines tables de la base de données RTCdyn avec l’option FULLSCAN:
*****
Use RTCdyn
Update Statistics Endpoint with FULLSCAN;
Update Statistics FrontEnd with FULLSCAN;
Update Statistics SelfSubscription with FULLSCAN;
Update Statistics DeliveryContext with FULLSCAN;
*****
Une question évidente vient alors à l’esprit: Faut-il attendre jusqu’à ce que l’on ait ce genre de problème pour mettre à jour les statistiques de la base de données RTC? ou bien faut-il les mettre à jour à interval régulier?
Ou alors, me diriez-vous, à quoi sert la validation par défaut des statistiques de la base de données RTCdyn?
Petit rappel: Les statistiques sont propres à chaque base de données.
et par défaut, elles sont actives pour chacune des bases de données crées au niveau de chaque instance.
Cette validation pédéfinie ne concerne que 10 % des valeurs. Alors que l’option FULLSCAN représente 100% des valeurs
SQL Serveur conserve des satistiques sur chaque index pour décrire son unicité ( ou selectectivité) et la répartition des valeurs de sa clé.
Donc, l’optimiseur de requêtes SQL utilise ces statistiques pour déterminer l’index éventuel pour exécuter au mieux une requête spécifique.
Donc, pour une bonne optimisation des mises à jour des statistisques, seul le developpeur peut recommander une valeur particulière pour optimiser les statistques des index.
Exemple d’obtention des statistiques:
sp_help FrontEnd ==> retourne les index, contraintes,….
dbcc show_statistics (“FrontEnd”,PK_FrontEnd) with Stat_Header
Quand faut-il mettre à jour réellement les statistques de la base de données RTC?
Une solution de contouronnement cosniste à exécuter le script ci-dessus chaque fois qu’un plan d’exécution montre une dégradation de performance des requêtes SQL.
Ce cas de figure peut arriver à la suite d’un:
_ Redémarrage du service front end ( RtcSrv.Exe)
_ “Upgrade” logiciel nécessitant un redémarrage du service front end.
S’il y a plusieurs front ends dans le pool, attendre jusqu’à ce que tous les front end soient actifs pour exécuter le script de mise à jour des statistiques.
2. Déconnexion d’une session “live meeting” initiée par le client communicateur 2007 R2
Lors d’une session “live meeting” initiée par le client communicateur 2007 R2, le simple fait qu’un participant de la conférence passe de l’état “Mute microphone” à ( ou inversement) “unmute microphone” peut provoquer une déconnexion de la conférence
Après analyse des traces internes (SIP stack), on s’aperçoit qu’il y a eu effectivement une perte de connexion comme mentionnée ci-dessous (481 Call leg unavailable) du côté serveur:
*****
TL_INFO [1]1094.10FC::10/12/2010-16:03:37.516 (SIPAdminLog::TraceDiagRecord:SIPAdminLog_cpp144)$$begin_record
LogType: diagnostic
Severity: information
Text: Response successfully routed
SIP-Start-Line: SIP/2.0 481 Call leg unavailable
*****
Et le client termine le dialogue en envoyant la requête SIP BYE mettant ainsi fin à cette session.
*****
TL_INFO [1]1094.0DEC::10/12/2010-16:03:38.157 (SIPAdminLog::TraceProtocolRecord:SIPAdminLog_cpp122)$$begin_record
Instance-Id: 000F5824
Direction: incoming
Peer: 10.4.21.10:53953
Message-Type: request
From: < sip:videoconf@turismodeportugal.pt >;tag=8d9ff754ab;epid=5a509ab2b4
To: < sip:suporte.oni@turismodeportugal.pt;gruu;opaque=app:conf:audio-video:id:F3BA4254AC6D564A962B9743204A2C5A >;tag=3a1fbbc58;epid=1243E696CC
CSeq: 4 BYE
*****
En regardant les spécifications relatives à la présence dans le MSDN, il est indiqué que la requête “481 call leg unavailable” peut être générée suite à une transition d’état de “Subscribed” à l’état “WaitingForRetry”.
L’automate de transition des différents états relatifs à la présence est le suivant ( https://msdn.microsoft.com/en-us/library/dd279776(office.13).aspx )
Pour quelle raison l’état est passé de “Subscribed” à l’état “WaitingForReply”?
L’une des raisons ( parmi tant d’autres) que l’on peut énoncer dans ce cas est que la requête précédente “Subscribe” a echoué.
Cet échec peut être une conséquence liée directement à un problème réseau ou tout simplement à une lenteur du backend car tous les états de présence ou autres sont évidemmment persisté au niveau des bases de données OCS se trouvant au niveau du backend (Instance SQL Serveur).
En revoyant la configuration du client, on s’est apercu que le serveur SQL hébergeant les bases de données OCS présentait une lenteur remarquable et en plus il fonctionnait dans un environnement virtuel alors que les serveurs OCS ( Front end ) fonctionnent sur des serveurs physiques.
Cette configuration n’est pas recommandée et de surcroit non supportée. Ceci est clairement mentionné dans la documentation en ligne d’OCS. Vous pouvez trouver cette information en cherchant par le critère: Virtualization Support
Donc la solution à ce problème consiste à migrer l’instance SQL serveur sur un serveur physique.