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 Fast TCP, Fast UDP 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.

Figure 1. Profil d'application TCP et UDP de couche 4
""

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 au niveau de l'équilibreur de charge et attend la demande HTTP ou HTTPS des clients avant de sélectionner le membre du pool de serveurs.

Figure 2. Profil d'application HTTPS de couche 7
""

Procédure

  1. Avec des privilèges d'administrateur, connectez-vous à NSX Manager.
  2. Sélectionnez Mise en réseau > Équilibrage de charge > Profils > Application > Ajouter des profils d'application.
  3. Sélectionnez un profil d'application Fast TCP et entrez ses détails.
    Vous pouvez également accepter les paramètres du profil Fast TCP par défaut.
    Option Description
    Nom et description Entrez un nom et une description pour le profil d'application Fast TCP.
    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 Fast UDP 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 Fast UDP.
    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.

    Pour détecter une communication client ou serveur inactive, l'équilibreur de charge utilise la fonctionnalité de délai d'attente de réponse du profil d'application HTTP définie sur 60 secondes. Si le serveur n'envoie pas de trafic pendant l'intervalle de 60 secondes, NSX-T Data Center met fin à la connexion côté client et serveur. Les profils d'application par défaut ne peuvent pas être modifiés. Pour modifier les paramètres d'un profil d'application HTTP, créez un profil personnalisé.

    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 les connexions inactives du client restent avant que l'équilibreur de charge ne les ferme (FIN).
    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.

    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.

    Balises Entrez des balises pour faciliter la recherche.

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

    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.

    Délai d'expiration de la réponse (s) Entrez la durée en secondes pendant laquelle l'équilibreur de charge attend la réponse HTTP du serveur avant de l'arrêter et de fermer la connexion au membre du pool et retente la demande sur un autre serveur.
    Serveur persistant Faites basculer ce bouton pour que l'équilibreur de charge désactive le multiplexage TCP et active les connexions HTTP persistantes.

    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.

    Lorsque les connexions HTTP persistantes sont activées et que des règles de transfert sont configurées dans l'équilibreur de charge, le paramètre de survie du serveur est prioritaire. Par conséquent, les demandes HTTP sont envoyées aux serveurs déjà connectés avec une connexion de survie.

    Si vous souhaitez toujours accorder la priorité aux règles de transfert lorsque les conditions de la règle d'équilibreur de charge sont satisfaites, désactivez le paramètre de survie.

    Notez que le paramètre de survie est prioritaire sur le paramètre de persistance.

    Le traitement est effectué dans l'ordre suivant : Persistance > Survie > Règles d'équilibreur de charge.