ADC

Surveillance des services RTSP

L’appliance NetScaler possède un moniteur intégré qui peut être utilisé pour surveiller les services RTSP : le moniteur RTSP. Il vérifie régulièrement le service RTSP auquel il est lié en ouvrant une connexion avec le serveur RTSP à charge équilibrée. Le type de connexion qu’il ouvre et la réponse qu’il attend varient en fonction de la configuration réseau. Si le service RTSP répond comme prévu dans le délai configuré, il marque le service comme étant activé. Si le service ne répond pas ou ne répond pas correctement, il marque le service comme étant inactif.

L’appliance NetScaler peut être configurée pour équilibrer la charge des serveurs RTSP à l’aide de deux topologies : NAT-off et NAT-on. Les serveurs RTSP envoient leurs réponses directement au client, en contournant l’appliance. L’appliance doit être configurée pour surveiller les services RTSP différemment selon la topologie utilisée par votre réseau. L’appliance peut être déployée en mode en ligne ou non en mode NAT-off et NAT-on.

En mode NAT-off, l’appliance fonctionne comme un routeur : elle reçoit les requêtes RTSP du client et les achemine vers le service qu’elle sélectionne à l’aide de la méthode d’équilibrage de charge configurée. Si vos serveurs RTSP à équilibrage de charge se voient attribuer des FQDN accessibles au public dans le DNS, les serveurs d’équilibrage de charge envoient leurs réponses directement au client, en contournant l’appliance. La figure suivante montre cette configuration.

Figure 1. RTSP en mode NAT-off

RTSP-NAT

Le flux de demandes et de réponses dans ce scénario est le suivant :

  1. Le client envoie une demande DESCRIBE à l’appliance. L’appliance utilise la méthode d’équilibrage de charge configurée pour choisir un service et achemine la demande vers Media Server-1.

  2. Le client envoie une demande de configuration à l’appliance. Si l’ID de session RTSP est échangé dans la requête DESCRIBE, l’appliance, à l’aide de la persistance RTSPSID, achemine la demande vers Media Server-1. Si l’ID de session RTSP est échangé dans la demande SETUP, l’appliance effectue l’une des opérations suivantes :

    • Si la requête RTSP provient de la même connexion TCP, elle achemine la demande vers Media Server-1, préservant ainsi la persistance.
    • Si la demande arrive sur une connexion TCP différente, elle utilise la méthode d’équilibrage de charge configurée pour choisir un service et envoie la demande à ce service, sans maintenir la persistance. Cela signifie que la demande peut être envoyée à un autre service.
  3. Media Server-1 reçoit la demande SETUP de l’appliance, alloue des ressources pour traiter la demande RTSP et envoie l’ID de session approprié au client.

    Remarque : L’appliance n’effectue pas de NAT pour identifier la connexion RTSP, car les connexions RTSP la contournent.

  4. Pour les demandes suivantes, le client utilise ensuite l’ID de session pour identifier la session et envoyer des messages de contrôle au serveur multimédia. Media Server-1 exécute les actions demandées, telles que la lecture, le transfert ou le retour en arrière.

En mode NAT-on, l’appliance reçoit les demandes RTSP du client et achemine ces demandes vers le serveur multimédia approprié à l’aide de la méthode d’équilibrage de charge configurée. Le serveur multimédia envoie ensuite ses réponses au client via l’appliance, comme illustré dans le schéma suivant.

Figure 2. RTSP en mode NAT-on

RTSP-NAT-on-Mode

Le flux de demandes et de réponses dans ce scénario est le suivant :

  1. Le client envoie une demande DESCRIBE à l’appliance. L’appliance utilise la méthode d’équilibrage de charge configurée pour choisir un service et achemine la demande vers Media Server-1.

  2. Le client envoie une demande de configuration à l’appliance. Si l’ID de session RTSP est échangé dans la requête DESCRIBE, l’appliance, à l’aide de la persistance RTSPSID, achemine la demande vers Media Server-1. Si l’ID de session RTSP est échangé dans la demande SETUP, l’appliance effectue l’une des opérations suivantes :

    • Si la requête RTSP provient de la même connexion TCP, elle achemine la demande vers Media Server-1, préservant ainsi la persistance.
    • Si la demande arrive sur une connexion TCP différente, elle utilise la méthode d’équilibrage de charge configurée pour choisir un service et envoie la demande à ce service, sans maintenir la persistance. Cela signifie que la demande peut être envoyée à un autre service.
  3. Media Server-1 reçoit la demande SETUP de l’appliance, alloue des ressources pour traiter la demande RTSP et envoie l’ID de session approprié au client.

  4. L’appliance exécute un protocole NAT pour identifier le client pour les connexions de données RTSP. Les connexions RTSP passent par l’appliance et sont routées vers le client approprié.

  5. Pour les demandes suivantes, le client utilise ensuite l’ID de session pour identifier la session et envoyer des messages de contrôle à l’appliance. L’appliance utilise la persistance RTSPSID pour identifier le service approprié et achemine la demande vers Media Server-1. Media Server-1 exécute l’action demandée, telle que lire, transférer ou revenir en arrière.

Le moniteur RTSP utilise le protocole RTSP pour évaluer l’état des services RTSP. Le moniteur RTSP se connecte au serveur RTSP et exécute une série de contacts pour s’assurer que le serveur fonctionne correctement.

Paramètre Spécifie
Requête RTSP Chaîne de requête RTSP envoyée au serveur RTSP (par exemple, OPTIONS *). La valeur par défaut est 07. La longueur de la demande ne doit pas dépasser 163 caractères.
Code REP Ensemble de codes de réponse attendus du service.

Pour obtenir des instructions sur la configuration d’un moniteur RTSP, reportez-vous à la section Configuration des moniteurs dans une configuration d’équilibrage de charge.

Surveillance des services RTSP

Dans cet article