ADC

Comprendre les moniteurs utilisateur

Les moniteurs utilisateur étendent la portée des moniteurs personnalisés. Vous pouvez créer des moniteurs utilisateur pour suivre l’état des applications et des protocoles personnalisés que l’appliance NetScaler ne prend pas en charge. Le diagramme suivant illustre le fonctionnement d’un moniteur utilisateur.

Figure 1. Moniteurs utilisateur

User-monitor

Un moniteur utilisateur nécessite les composants suivants.

Dispatcher. Un processus, sur la solution matérielle-logicielle, qui écoute les demandes de surveillance. Un répartiteur peut se trouver sur l’adresse IP de bouclage (127.0.0.1) et sur le port 3013. Les répartiteurs sont également appelés répartiteurs internes. Un répartiteur peut également être un serveur Web prenant en charge l’interface CGI (Common Gateway Interface). Ces répartiteurs sont également connus sous le nom de répartiteurs externes. Ils sont utilisés pour les scripts personnalisés qui ne s’exécutent pas dans l’environnement FreeBSD, tels que les scripts .NET.

Remarque :

Vous pouvez configurer le moniteur et le répartiteur pour qu’ils utilisent HTTPS au lieu de HTTP en activant l’option « sécurisé » sur le moniteur et en le configurant en tant que répartiteur externe. Toutefois, un répartiteur interne ne comprend que le protocole HTTP et ne peut pas utiliser le protocole HTTPS.

Dans une configuration HA, le répartiteur s’exécute à la fois sur les appliances NetScaler principales et secondaires. Le répartiteur reste inactif sur la solution matérielle-logicielle secondaire.

script. Le script est un programme qui envoie des sondes personnalisées au serveur à charge équilibrée et renvoie le code de réponse au répartiteur. Le script peut renvoyer n’importe quelle valeur au répartiteur, mais si une sonde réussit, le script doit renvoyer la valeur zéro (0). Le répartiteur considère toute autre valeur comme une défaillance de la sonde.

L’appliance NetScaler est fournie avec des exemples de scripts pour les protocoles couramment utilisés. Les scripts se trouvent dans le répertoire /nsconfig/moniteurs/. Si vous souhaitez ajouter un script, ajoutez-le ici. Pour personnaliser un script existant, créez une copie portant un nouveau nom et modifiez-la.

Important :

  • À partir de NetScaler version 13.0 build 41.20, vous pouvez utiliser le nsntlm-lwp.pl script pour créer un moniteur afin de surveiller un serveur NTLM sécurisé.

  • À partir de la version 10.1 122.17, les fichiers de script des moniteurs utilisateur se trouvent dans un nouvel emplacement.

    Si vous mettez à niveau un dispositif virtuel MPX ou VPX vers la version 10.1 build 122.17 ou ultérieure, les modifications sont les suivantes :

    • Un nouveau répertoire nommé conflicts est créé dans /nsconfig/monitors/ et tous les scripts intégrés des versions précédentes sont déplacés vers ce répertoire.
    • Tous les nouveaux scripts intégrés sont disponibles dans le répertoire /netscaler/monitors/. Tous les scripts personnalisés sont disponibles dans le répertoire /nsconfig/monitors/.
    • Enregistrez un nouveau script personnalisé dans le répertoire /nsconfig/monitors/.
    • Une fois la mise à niveau terminée, si un script personnalisé est créé et enregistré dans le répertoire /nsconfig/monitors/, avec le même nom que le script intégré, le script du répertoire /netscaler/monitors/ est prioritaire. Le script personnalisé n’est pas exécuté.

    Si vous provisionnez un dispositif virtuel avec la version 10.1 version 122.17 ou ultérieure, les modifications sont les suivantes :

    • Tous les scripts intégrés sont disponibles dans le répertoire /netscaler/monitors/.
    • Le répertoire /nsconfig/monitors/ est vide.
    • Si vous créez un script personnalisé, vous devez l’enregistrer dans le répertoire /nsconfig/monitors/.

Pour que les scripts fonctionnent correctement :

  • Le nombre maximal de caractères dans le nom du script ne doit pas dépasser 63.
  • Le nombre maximal d’arguments de script pouvant être fournis à un script ne doit pas dépasser 512.
  • Le nombre maximal de caractères pouvant être fournis dans les arguments du script de paramètre ne doit pas dépasser 639.

Pour déboguer le script, vous devez l’exécuter à l’aide du script nsumon-debug.pl de l’interface de ligne de commande. Vous utilisez le nom du script (avec ses arguments), l’adresse IP et le port comme arguments du script nsumon-debug.pl. Les utilisateurs doivent utiliser le nom du script, l’adresse IP, le port, le délai d’expiration et les arguments de script pour le script nsumon-debug.pl.

À l’interface de ligne de commande, tapez :

nsumon-debug.pl <scriptname> <IP> <port> <timeout> <partitionID> [scriptarguments][is_secure]
<!--NeedCopy-->

Important : à partir de la version 10.5 build 57.x, les fichiers de script 11.0 pour les moniteurs utilisateur prennent en charge les adresses IPv6 et incluent les modifications suivantes :

  • Pour les protocoles suivants, de nouveaux protocoles pm files ont été inclus pour la prise en charge d’IPv6.

    • RADIUS
    • NNTP
    • POP3
    • SMTP
  • Les exemples de scripts suivants dans /netscaler/monitors/ ont été mis à jour pour la prise en charge d’IPv6 :

    • nsbmradius.pl

    • nsldap.pl

    • nsnntp.pl

    • nspop3 nssf.pl

    • nssnmp.pl

    • nswi.pl

    • nstftp.pl

    • nssmtp.pl

    • nsrdp.pl

    • nsntlm-lwp.pl

    • nsftp.pl

    • nsappc.pl

    Après la mise à niveau vers la version 10.5 build 57.x ou 11.0, si vous souhaitez utiliser vos scripts personnalisés existants avec les services IPv6, assurez-vous de mettre à jour les scripts personnalisés existants avec les modifications fournies dans les exemples de scripts mis à jour dans /netscaler/monitors/.

Remarque :

L’exemple de script nsmysql.pl ne prend pas en charge l’adresse IPv6. Si un service IPv6 est lié à un moniteur utilisateur qui utilise nsmysql.pl, la sonde échoue.

  • Les types de moniteurs LB suivants ont été mis à jour pour prendre en charge les adresses IPv6 :

    • USER

    • SMTP

    • NNTP

    • LDAP

    • SNMP

    • POP3

    • FTP_EXTENDED

    • StoreFront

    • APPC

    • CITRIX_WI_EXTENDED

    Si vous créez un script personnalisé qui utilise l’un de ces types de moniteurs LB, veillez à inclure la prise en charge IPv6 dans le script personnalisé. Reportez-vous à l’exemple de script associé dans /netscaler/monitors/ pour connaître les modifications que vous devez apporter au script personnalisé pour la prise en charge d’IPv6.

Pour suivre l’état du serveur, le moniteur envoie une requête HTTP POST au répartiteur configuré. Cette demande POST contient l’adresse IP et le port du serveur, ainsi que le script à exécuter. Le répartiteur exécute le script en tant que processus enfant, avec des paramètres définis par l’utilisateur (le cas échéant). Ensuite, le script envoie une sonde au serveur. Le script envoie l’état de la sonde (code de réponse) au répartiteur. Le répartiteur convertit le code de réponse en réponse HTTP et l’envoie au moniteur. En fonction de la réponse HTTP, le moniteur marque le service comme étant en hausse ou en panne.

L’appliance NetScaler enregistre les messages d’erreur dans le fichier /var/nslog/nsumond.log lorsque les sondes du moniteur utilisateur échouent. Ces messages d’erreur détaillés sont affichés dans l’interface graphique et dans l’interface de ligne de commande pour les show service/service group commandes.

Le tableau suivant répertorie les moniteurs utilisateur et les raisons possibles de l’échec.

Type de moniteur utilisateur Raisons de défaillance
SMTP Le moniteur ne parvient pas à établir une connexion au serveur.
NNTP Le moniteur ne parvient pas à établir une connexion au serveur.
  Arguments de script manquants ou non valides, qui peuvent inclure un nombre d’arguments ou un format d’argument non valide.
  Le moniteur ne parvient pas à trouver le groupe NNTP.
LDAP Le moniteur ne parvient pas à établir une connexion au serveur.
  Arguments de script manquants ou non valides, qui peuvent inclure un nombre d’arguments ou un format d’argument non valide.
  Le moniteur ne parvient pas à se lier au serveur LDAP.
  Le moniteur ne parvient pas à localiser une entrée pour l’entité cible sur le serveur LDAP.
FTP La connexion au serveur est dépassé.
  Arguments de script manquants ou non valides, qui peuvent inclure un nombre d’arguments ou un format d’argument non valide.
  L’ouverture de session échoue.
  Le moniteur ne parvient pas à trouver le fichier sur le serveur.
POP3 Le moniteur ne parvient pas à établir une connexion à la base de données.
  Arguments de script manquants ou non valides, qui peuvent inclure un nombre d’arguments ou un format d’argument non valide.
  L’ouverture de session échoue.
  La préparation de la requête SQL échoue.
  L’exécution de la requête SQL échoue.
SNMP Le moniteur ne parvient pas à établir une connexion à la base de données.
  Arguments de script manquants ou non valides, qui peuvent inclure un nombre d’arguments ou un format d’argument non valide.
  L’ouverture de session échoue.
  Le moniteur ne parvient pas à créer la session SNMP.
  Le moniteur ne parvient pas à trouver l’identifiant d’objet.
  Le paramètre de valeur de seuil du moniteur est supérieur ou égal au seuil réel du moniteur.
RDP (Windows Terminal Server) Arguments de script manquants ou non valides, qui peuvent inclure un nombre d’arguments ou un format d’argument non valide.
  Le moniteur ne parvient pas à créer un socket.
  Les versions ne correspondent pas.
  Le moniteur n’arrive pas à confirmer la connexion.

Vous pouvez consulter le fichier journal à partir de l’interface de ligne de commande à l’aide des commandes suivantes :

> shell
root@ns# cat /var/nslog/nsumond.log
root@ns# exit
>
<!--NeedCopy-->

La commande ouvre un shell BSD, affiche le fichier journal à l’écran, ferme le shell BSD et vous renvoie à l’interface de ligne de commande.

Avant la version 13.0 build 52.X de NetScaler, la show service/service group commande affichait un message d’erreur générique indiquant que « la sonde a échoué » comme cause de l’échec de la sonde du moniteur utilisateur.

Exemple :

show service ftp

Monitor Name: mon2
State: UNKNOWN  Weight: 1   Passive: 0
Probes: 3    Failed [Total: 0 Current: 0]
Last response: Failure - Probe failed.
Response Time: 1071.838 millisec
<!--NeedCopy-->

À partir de la version 13.0 build 52.X de NetScaler, la show service/service group commande affiche la cause réelle de l’échec de la sonde du moniteur utilisateur.

Exemple :

show service ftp

Monitor Name: mon2
State: DOWN   Weight: 1   Passive: 0
Probes: 729   Failed [Total: 726 Current: 726]
Last response: Failure - Login failed.
Response Time: 8000.0 millisec
<!--NeedCopy-->

Les moniteurs utilisateur ont également une valeur de délai d’expiration et un nombre de relances pour les échecs de sonde. Vous pouvez utiliser des moniteurs utilisateur avec des moniteurs non utilisateurs. En cas d’utilisation élevée du processeur, un moniteur non utilisateur permet de détecter plus rapidement une panne de serveur.

Si la sonde du moniteur de l’utilisateur expire en cas d’utilisation élevée du processeur, l’état du service reste inchangé.

Example1:

add lb monitor <name> USER –scriptname <script-name> -resptimeout 5 seconds
<!--NeedCopy-->

Remarque

Pour les moniteurs scriptables, le délai d’attente de réponse doit être configuré à une valeur égale au délai d’expiration attendu de 1 seconde. Par exemple, si vous vous attendez à ce que le délai d’attente soit de 4 secondes, configurez le délai d’attente de réponse sur 5 secondes.

Example2:

add lb monitor <name> USER –scriptname <script-name> -scriptargs <Arguments> -secureargs <Arguments>
<!--NeedCopy-->

Remarque :

Nous vous recommandons d’utiliser le secureargs paramètre plutôt que le scriptargs paramètre pour toutes les données sensibles liées aux scripts.

Comprendre les moniteurs utilisateur

Dans cet article