Les profils d'application sont associés à des serveurs virtuels afin d'améliorer le trafic réseau d'équilibrage de charge et de simplifier les tâches de gestion du trafic.

Les profils d'application définissent le comportement d'un type particulier de trafic réseau. Le serveur virtuel associé traite le trafic réseau conformément aux valeurs spécifiées dans un profil d'application. Les profils d'application pris en charge sont TCP rapide, UDP rapide et HTTP.

Le profil d'application TCP est utilisé par défaut lorsqu'aucun profil d'application n'est associé à un serveur virtuel. Les profils d'application TCP et UDP sont utilisés lorsqu'une application s'exécute sur un protocole TCP ou UDP, et ne nécessite aucun équilibrage de charge au niveau de l'application (par exemple, un équilibrage de charge d'URL HTTP). Ces profils sont également utilisés lorsque vous souhaitez uniquement appliquer un équilibrage de charge de couche 4, qui fournit de meilleures performances et prend en charge la mise en miroir de la connexion.

Le profil d'application HTTP est utilisé pour les applications HTTP et HTTPS lorsque l'équilibreur de charge doit effectuer des actions basées sur la couche 7, telles que l'équilibrage de charge de toutes les demandes d'images envoyées à un membre du pool de serveurs spécifique ou l'arrêt d'une connexion HTTPS pour décharger les connexions SSL des membres du pool. Contrairement au profil d'application TCP, le profil d'application HTTP met fin à la connexion TCP client avant la sélection du membre du pool de serveurs.

Figure 1. Profil d'application TCP et UDP de couche 4
Figure 2. Profil d'application HTTPS de couche 7

Procédure

  1. Dans le navigateur, connectez-vous avec des privilèges d'administrateur à un dispositif NSX Manager sur https://<nsx-manager-ip-address>.
  2. Sélectionnez Mise en réseau > Équilibrage de charge > Profils > Application > Ajouter des profils d'application.
  3. Sélectionnez un profil d'application TCP rapide et entrez ses détails.
    Vous pouvez également accepter les paramètres du profil TCP rapide par défaut.
    Option Description
    Nom et description Entrez un nom et une description pour le profil d'application TCP rapide.
    Délai d'inactivité Entrez la durée en secondes pendant laquelle le serveur peut rester inactif après l'établissement d'une connexion TCP.

    Définissez un délai qui comprend le délai d'inactivité de l'application plus quelques secondes afin que l'application puisse fermer les connexions avant que l'équilibreur de charge ne le fasse.

    Mise en miroir de flux HA Faites basculer ce bouton pour mettre en miroir tous les flux du serveur virtuel associé sur le nœud de secours HA.
    Délai de fermeture de la connexion Entrez la durée en secondes pendant laquelle les FIN ou RST de la connexion TCP doivent être conservés pour une application avant la fermeture de la connexion.

    Définissez un délai de fermeture court pour permettre des vitesses de connexion rapides.

    Balises Entrez des balises pour faciliter la recherche.

    Vous pouvez spécifier une balise pour définir son étendue.

  4. Sélectionnez un profil d'application UDP rapide et entrez ses détails.
    Vous pouvez également accepter les paramètres du profil UDP par défaut.
    Option Description
    Nom et description Entrez un nom et une description pour le profil d'application UDP rapide.
    Délai d'inactivité Entrez la durée en secondes pendant laquelle le serveur peut rester inactif après l'établissement d'une connexion UDP.

    UDP est un protocole sans connexion. Dans le cadre de l'équilibrage de charge, tous les paquets UDP avec la même signature de flux, c'est-à-dire avec les mêmes adresses IP ou ports source et de destination, et le protocole IP reçus pendant la période d'inactivité, sont considérés comme appartenant à la même connexion et envoyés vers le même serveur.

    Si aucun paquet n'est reçu pendant la période d'inactivité, la connexion, qui est une association entre la signature de flux et le serveur sélectionné, est fermée.

    Mise en miroir de flux HA Faites basculer ce bouton pour mettre en miroir tous les flux du serveur virtuel associé sur le nœud de secours HA.
    Balises Entrez des balises pour faciliter la recherche.

    Vous pouvez spécifier une balise pour définir son étendue.

  5. Sélectionnez un profil d'application HTTP et entrez ses détails.
    Vous pouvez également accepter les paramètres du profil HTTP par défaut.

    Le profil d'application HTTP est utilisé pour les applications HTTP et HTTPS.

    Option Description
    Nom et description Entrez un nom et une description pour le profil d'application HTTP.
    Délai d'inactivité Entrez la durée en secondes pendant laquelle une application HTTP peut rester inactive, au lieu du paramètre de socket TCP qui doit être configuré dans le profil d'application TCP.
    Taille de l'en-tête de la demande Spécifiez la taille maximale de tampon en octets utilisée pour stocker les en-têtes de demande HTTP.
    Taille d'en-tête de réponse

    Spécifiez la taille maximale de tampon en octets utilisée pour stocker les en-têtes de réponse HTTP. La valeur par défaut est 4 096 et la valeur maximale est 65 536.

    X-Forwarded-For (XFF)
    • Insert : si l'en-tête HTTP XFF ne figure pas dans la demande entrante, l'équilibreur de charge insère un nouvel en-tête XFF comprenant l'adresse IP du client. Si l'en-tête HTTP XFF figure dans la demande entrante, l'équilibreur de charge insère l'en-tête XFF comprenant l'adresse IP du client.
    • Remplacer : si l'en-tête HTTP XFF est présent dans la demande entrante, l'équilibreur de charge remplace l'en-tête.

    Les serveurs Web enregistrent dans des journaux chaque demande qu'ils gèrent avec l'adresse IP du client demandeur. Ces journaux sont utilisés à des fins de débogage et d'analyse. Si la topologie de déploiement nécessite le mode SNAT sur l'équilibreur de charge, le serveur utilise l'adresse IP SNAT et la journalisation n'a plus lieu d'être.

    Pour résoudre ce problème, l'équilibreur de charge peut être configuré pour insérer un en-tête HTTP XFF avec l'adresse IP du client d'origine. Les serveurs peuvent être configurés pour enregistrer l'adresse IP dans l'en-tête XFF au lieu de l'adresse IP source de la connexion.

    Taille du corps de la demande Entrez une valeur pour la taille maximale de la mémoire tampon utilisée pour stocker le corps de la demande HTTP.

    Si celle-ci n'est pas spécifiée, la taille du corps de la demande est illimitée.

    Redirection
    • Aucun : si un site Web est temporairement hors service, l'utilisateur reçoit un message d'erreur indiquant que la page est introuvable.
    • Redirection HTTP : si un site Web est temporairement hors service ou a été déplacé, les demandes entrantes pour le serveur virtuel peuvent être redirigées temporairement vers l'URL spécifiée par cette option. Une seule redirection statique est prise en charge.

      Par exemple, si la redirection HTTP est définie sur http://sitedown.abc.com/sorry.html et qu'une demande http://original_app.site.com/home.html ou http://original_app.site.com/somepage.html est effectuée, celle-ci est redirigée vers l'URL spécifiée lorsque le site Web d'origine est hors service.

    • Redirection HTTP vers HTTPS : certaines applications sécurisées peuvent appliquer une connexion SSL, mais au lieu de refuser les connexions non-SSL, elles peuvent rediriger la demande client afin d'utiliser une connexion SSL. La redirection HTTP vers HTTPS vous permet de conserver les chemins d'hôte et d'URI, et de rediriger la demande client afin d'utiliser une connexion SSL.

      Pour la redirection HTTP vers HTTPS, le serveur virtuel HTTPS doit avoir le port 443 et la même adresse IP de serveur virtuel doit être configurée sur le même équilibreur de charge.

      Par exemple, une demande client pour http://app.com/path/page.html est redirigée vers https://app.com/path/page.html. Si le nom d'hôte ou l'URI doit être modifié lors de la redirection, par exemple, vers https://secure.app.com/path/page.html, des règles d'équilibrage de charge doivent être utilisées.

    Authentification NTLM Faites basculer ce bouton pour que l'équilibreur de charge désactive le multiplexage TCP et active les connexions HTTP persistantes.

    NTLM est un protocole d'authentification qui peut être utilisé sur HTTP. Pour l'équilibrage de charge avec l'authentification NTLM, le multiplexage TCP doit être désactivé pour les pools de serveurs hébergeant des applications NTLM. Dans le cas contraire, une connexion côté serveur établie avec les informations d'identification d'un client peut être potentiellement utilisée afin de servir les demandes d'un autre client.

    Si l'authentification NTLM est activée dans le profil et associée à un serveur virtuel, et que le multiplexage TCP est activé dans le pool de serveurs, l'authentification NTLM est prioritaire. Le multiplexage TCP n'est pas effectué pour ce serveur virtuel. Toutefois, si le même pool est associé à un autre serveur virtuel non-NTLM, le multiplexage TCP est disponible pour les connexions vers ce serveur.

    Si le client utilise des connexions HTTP/1.0, l'équilibreur de charge les met à niveau vers le protocole HTTP/1.1 et les connexions HTTP persistantes sont définies. Toutes les demandes HTTP reçues sur la même connexion TCP côté client sont envoyées vers le même serveur via une seule connexion TCP afin de s'assurer qu'aucune nouvelle autorisation n'est requise.

    Balises Entrez des balises pour faciliter la recherche.

    Vous pouvez spécifier une balise pour définir son étendue.