Considérations des performances et meilleures pratiques avec l'appliance KACE SMA. (4210034)

Admin UI: https://kacesma.domain.loc/adminui

System UI: https://kacesma.domain.loc/systemui

Remarque: Tenter d'accéder à l'interface utilisateur du système sur un SMA simple-org redirigera simplement vers l'interface d'administration. Pour les systèmes multi-org, les paramètres existent à la fois dans l'interface d'administration (par organisation) et dans l'interface système (globalement).

Lors du dépannage de problèmes de performances sur un appliance KACE, il est extrêmement important de comprendre les symptômes du problème. En contactant KACE Support, plus nous pouvons identifier le problème avec précision, plus vite nous pouvons le résoudre.

Tout d'abord, assurez-vous que les exigences minimales sont respectées pour les appliances virtuelles et que le matériel physique est actuellement pris en charge.

Appliance Virtuelle

https://www.quest.com/fr-fr/products/kace-systems-management-appliance

Spécifications | Spécifications techniques de l'appliance virtuelle | Configuration système requise pour la machine virtuelle

Appliance Physique

https://www.quest.com/fr-fr/products/kace-systems-management-appliance

Spécifications | Spécifications techniques des appareils physiques | Spécifications matérielles

Multi-org: System UI | Organisations | [Nom de l'ORG]

Single-org: Admin UI | Settings/Paramètres > Provisioning | Paramètres de communication

• Le nombre maximum de connexions recommandées par heure est de 500 (y compris les agents de TOUS les Orgs).
• Idéalement, réglez chaque intervalle de façon aussi prudente que possible. Exemple : S'il n'est pas nécessaire que les résultats d'inventaire soient mis à jour plus d'une fois par jour, réglez l'inventaire de l'agent sur 1 jour. Régler cette valeur à 4 heures, dans ce cas, mettrait un stress supplémentaire inutile sur le serveur - ce qui aurait un impact négatif sur les performances.

• Accès à l'interface utilisateur - Les utilisateurs et les administrateurs du service d'assistance ont un impact sur ce seuil par l'utilisation constante de l'interface utilisateur Web.
• Intervalle d'agent - Avoir trop fréquemment des paramètres pour les intervalles d'agent peut amener Apache à maximiser sa limite de connexion.
  
• Scripts - Les scripts en ligne et leur charge utile sont tirés par des agents au moment de l'exécution programmée. Avoir trop de scripts en ligne programmés trop fréquemment peut avoir un impact négatif sur la performance de l'interface utilisateur, arrêter ou retarder l'activité de l'agent, et généralement affecter la performance globale du serveur.
• Horaires de mise à jour - Les horaires de mise à jour s'exécutent de la même manière que les scripts en ligne, donc les informations précédemment mentionnées sur le Scripting s'appliquent ici.

Recours et prévention

• Partage de réplication - Les partages de réplication sont la meilleure option pour réduire le trafic de l'agent de/vers le SMA. En déchargeant le travail de service des fichiers aux agents sur les partages de réplication, tout le trafic qui aurait été acheminé vers le SMA pour les téléchargements de scripts, les charges utiles, les fichiers patch, etc. sera retiré du partage de réplication pour chaque agent configuré pour en utiliser un.
• Intervalle des agents - L'allongement de l'intervalle des agents peut réduire le nombre de connexions par heure pour réduire l'impact sur le serveur Apache pour le SMA.

Les programmes de découverte n'ont pas d'impact direct sur la communication des agents ou les performances de l'interface utilisateur Web, car ils n'impliquent pas Apache. Cependant, des calendriers de découverte agressifs peuvent avoir un impact notable sur les performances globales du serveur.

Les calendriers de scripts et de correctifs peuvent avoir un impact direct sur la communication des agents et les performances de l'interface utilisateur Web, car ils impliquent Apache. Le fait d'avoir des calendriers de scripts ou de correctifs agressifs peut avoir un impact notable sur les performances globales du serveur ainsi que causer des problèmes de communication avec les agents et d'accès à l'interface utilisateur. La meilleure option pour éliminer la plus grande partie de cet impact est l'utilisation des partages de réplication. Une planification agressive peut encore causer des problèmes avec les partages de réplication, mais le seuil est beaucoup plus élevé. Lors de l'utilisation des partages de réplication, le coupable le plus probable de tout problème de débit (par exemple, si les programmes ne sont pas terminés) sera le réglage du débit de la tâche.

Les scripts hors ligne ont une présence moins visible sur le serveur, par nature. Gardez à l'esprit que les scripts hors ligne peuvent avoir un impact sur les performances en raison du téléchargement des résultats (par exemple, si un script hors ligne s'exécute très fréquemment, les téléchargements de résultats composés dans de grands environnements peuvent en fait maximiser les flux Appache).

Multi-org: System UI | Settings/Paramètres | Paramètres généraux

Single-org: Admin UI | Settings/Paramètres | Provisioning | Paramètres de communication

Task Throughput/ Débit des tâches est un multiplicateur utilisé par le service Konductor (le'cerveau' pour les tâches des agents) sur le SMA. La valeur par défaut de 3 peut être augmentée d'un niveau toutes les 15 minutes, mais ne doit être augmentée que si la moyenne de charge sur le serveur reste inférieure à 10 et que la quantité de tâches " prêtes à fonctionner " ne peut être maintenue. Si le serveur envoie des tâches assez rapidement pour maintenir une file d'attente vide, cette valeur ne doit pas être augmentée. Le réglage le plus bas qui fonctionne dans l'environnement devrait être utilisé.

Le nombre total de tâches dépend du nombre de programmes de correctifs et de scripts en fonction du nombre d'agents en production. L'intervalle d'agent affecte également la fréquence à laquelle plusieurs de ces tâches sont planifiées et envoyées à tous les agents - ce qui aura également un impact sur le nombre total de tâches que le serveur doit envoyer aux agents et la quantité de débit nécessaire pour les accomplir.

Konductor Log/journaux

Multi-org: System UI | Settings | Logs

Single-org: Admin UI | Settings | Logs

[2017-10-23 17:21:57 -0500] Konductor[1384] [main] stats [s:21874 t:8 tc:8 c:8 cc:738 sl:30 tpl:40 at:399 rt:400 lt:3 lv:0.31]

• s = secondes que le konducteur a été actif
• t = tâches lancées
• tc = tâches accomplies
• c = tâches accomplies (même chose que tc)
• cc = appels effectués (le Konductor actualise la liste des tâches)
• sl = intervalle de sommeil en secondes (délai entre les boucles)
• tpl = tâches réparties par konducteur par boucle
• at = threads actifs (400 maxi, le nombre diminue au fur et à mesure que les threads sont utilisés)
• rt = fils réservés (400 maxi, le nombre diminue au fur et à mesure que les fils sont utilisés)
• lt = la charge cible (elle correspondra au paramètre de débit de la tâche en cours)
• lv = charge réelle pendant 1 minute (ne devrait jamais dépasser 10, plus la charge est faible, mieux c'est)

Statut des tâches de l'agent

Multi-org: System UI | Settings/Paramètres | Support | Affichage de l'état des tâches de l'agent

Single-org: Admin UI | Settings/Paramètres | Support | Affichage de l'état des tâches de l'agent

• Toutes les tâches - affiche toutes les tâches dans la file d'attente des tâches de l'agent.
• En cours - affiche toutes les tâches envoyées aux agents qui n'ont pas terminé.
• Prêt à fonctionner (connecté) - affiche les tâches prêtes à fonctionner avec les agents actifs connectés et en attente.
• Prêt à Exécuter - affiche les tâches prêtes à être exécutées mais les agents non connectés.
• Plus de 10 minutes - affiche les tâches exécutées depuis plus de 10 minutes.
• Type de tâche - permet de filtrer en fonction du type de tâche (par exemple, inventaire, script spécifique, etc.)
  
• Organisation - permet de filtrer par organisation

Exemple 1:

Problème : Les agents ne reçoivent pas les tâches, les inventaires prennent beaucoup de temps, etc. Les tâches lancées (t) et les tâches terminées (tc et/ou c) sont égales ou presque égales, mais les threads actifs (at) et/ou les threads réservés (rt) sont bien inférieurs au niveau standard de 400 chacun.

Parce que : Les scripts hors ligne s'exécutent trop fréquemment, et les threads actifs sont consommés par les agents qui téléchargent les résultats des scripts hors ligne.

Exemple 2:

Problème : Les tâches de l'agent ne sont pas envoyées assez rapidement et elles sont sauvegardées dans la liste des tâches de l'agent. De nombreuses tâches sont en état "Prêt à Exécuter (connecté)", et les threads actifs/réservés (at/rt) semblent avoir de nombreux threads disponibles.

Parce que : Le débit des tâches peut avoir besoin d'être augmenté, car le serveur suit la charge mais ne peut pas distribuer les tâches assez rapidement pour répondre à la demande.

L'impact des rapports planifiés sur la performance du serveur dépendra du nombre et de la fréquence des rapports planifiés ainsi que de la taille de l'ensemble de données interrogé.

Astuces:

• L'assistant de création de rapports devrait produire des requêtes efficaces, mais il est possible de créer un très grand ensemble de données qui peut prendre plusieurs minutes à exécuter.
• Déclarer l'ensemble de données le plus petit possible. Exemple : Besoin de voir les machines Windows sans titre de logiciel exécutant une version spécifique de Windows ? Filtrez le rapport pour n'afficher que les systèmes Windows exécutant cette version spécifique de Windows qui répondent aux critères.
• Planifiez des rapports similaires aux intervalles de tâches de l'agent. Ne les programmer que pour qu'ils fonctionnent aussi souvent que le besoin l'exige. Exemple : Si un rapport quotidien est suffisant, ne le planifiez pas à l'heure.

L'impact des étiquettes intelligentes sur les performances du serveur peut être assez important. Les étiquettes intelligentes d'appareil et d'utilisateur (y compris les étiquettes LDAP) sont traitées lorsqu'un appareil télécharge des données d'inventaire ou qu'un utilisateur se connecte, respectivement. Cela signifie que chaque étiquette intelligente de périphérique activée sur le serveur fonctionne avec chaque téléchargement d'inventaire. Par exemple, 100 étiquettes intelligentes activées dans un environnement de 15 000 appareils entraîneraient 150 000 demandes d'étiquettes intelligentes à chaque cycle d'inventaire. De même, 100 étiquettes intelligentes utilisateur seraient évaluées à chaque connexion d'un utilisateur.

Astuces:

• Les étiquettes intelligente (y compris les étiquettes LDAP) doivent être aussi précis que possible.
  
• Chaque étiquette doit être testée pour s'assurer qu'elle ne cause pas de retard sur le serveur. Il est tout à fait possible qu'une seule étiquette inefficace retourne les requêtes sur le serveur, ce qui entraîne un retard, voire, dans certains cas, arrête le flux des données d'inventaire dans la base de données.
• Les étiquettes LDAP doivent être aussi restrictives que possible dans LDAP. Le DN de base doit être le plus profond possible dans l'arbre et le filtre de recherche avancée doit être très précis pour ne renvoyer que les données requises.

Même si les règles relatives aux tickets s'appliquent généralement au service d'assistance, il est possible d'accéder aux données dans d'autres parties de la base de données, ce qui peut avoir un impact sur les performances dans d'autres parties.

Astuces:

• Les règles de tickets devraient toujours être testées avant la mise en œuvre complète.
• Les règles de tickets sont appliquées à chaque ticket dans une file d'attente lorsque le ticket est sauvegardé ou modifié par e-mail.
• Chaque règle affichera la dernière exécution au bas de la page et le temps qu'il a fallu pour l'exécuter. Gardez à l'esprit le temps nécessaire à l'exécution de chacune d'elles, car le temps total de toutes les règles d'une file d'attente déterminera le temps nécessaire au traitement d'un ticket enregistré.

Dans la mesure du possible, les assistants de l'interface utilisateur doivent être utilisés. Custom SQL est une option de niveau expert que nous offrons au client, et elle est extrêmement puissante mais aussi très dangereuse.

• Tout SQL personnalisé doit être testé avant l'implémentation (MySQL Workbench, etc.).
• Ne sélectionnez que les champs obligatoires, car l'utilisation d'une sélection * entraînera le retour d'un ensemble de données plus volumineux.
• En raison de la nature du SQL personnalisé, il est possible d'écrire une requête qui a un impact majeur sur les performances du serveur.
  
• Le support n'offre pas d'assistance avec SQL personnalisé, mais KACE Professional Services est disponible en tant qu'offre payante pour tous les besoins SQL personnalisés.
  

Lorsque vous contactez KACE Support, il est important d'identifier le plus précisément possible les symptômes du problème de performance. Il est également possible de gagner du temps en extrayant de manière préventive les journaux du serveur de l'appliance, car ceux-ci sont généralement nécessaires pour diagnostiquer le problème. Pour extraire les journaux du serveur :

Sur une appliance multi-org:

System UI | Settings/paramètre | Support | Récupérer les journaux d'activité de l'appliance

Sur une appliance mono-org:

Admin UI | Settings/paramètre | Support | Récupérer les journaux d'activité de l'appliance