Citrix ADC

Nouvelle tentative de demande

Lorsqu’un serveur principal réinitialise une connexion TCP, la fonction de nouvelle tentative de demande transmet la demande au serveur disponible suivant, au lieu d’envoyer la réinitialisation au client. En effectuant l’équilibrage de rechargement, le client enregistre RTT lorsque l’appliance lance la même demande au service disponible suivant.

La fonction de nouvelle tentative de demande est applicable pour le scénario d’erreur suivant :

  • Le serveur principal réinitialise une connexion TCP lorsque l’appliance envoie un paquet de données de demande.
  • Si le serveur principal réinitialise une connexion TCP sur l’établissement SYN

Fonctionnement de la nouvelle tentative de demande lorsque le serveur principal réinitialise une connexion TCP lors de la réception d’un paquet de données de demande

Le diagramme suivant montre comment les composants interagissent les uns avec les autres.

Fonctionnement de la nouvelle tentative de demande

  1. Le processus commence par activer la fonctionnalité appqoe sur votre appliance.
  2. Lorsque le client envoie une requête HTTP ou HTTPS, le serveur virtuel d’équilibrage de charge envoie la demande au serveur principal.
  3. Si le service demandé n’est pas disponible, le serveur principal réinitialise la connexion TCP.
  4. Si la configuration appqoe est activée avec le nombre souhaité de tentatives de nouvelle tentative spécifié, le serveur virtuel d’équilibrage de charge utilise l’algorithme d’équilibrage de charge configuré pour transférer la demande au serveur d’applications disponible suivant.
  5. Une fois que le serveur virtuel d’équilibrage de charge a reçu la réponse, l’appliance transmet la réponse au client.
  6. Si les serveurs back-end disponibles sont égaux ou inférieurs au nombre de tentatives et si tous les serveurs envoient une réinitialisation, l’appliance répondra à une erreur interne de 500 serveurs. Considérez un scénario avec cinq serveurs disponibles et le nombre de tentatives est défini sur six. Si les cinq serveurs réinitialisent la connexion, l’appliance renvoie une erreur de serveur interne 500 au client.
  7. De même, si le nombre de serveurs principaux est supérieur au nombre de nouvelles tentatives et si les serveurs back-end réinitialisent la connexion, l’appliance transmet la réinitialisation au client. Considérez un scénario avec trois serveurs back-end et le nombre de tentatives est défini comme deux. Si les trois serveurs réinitialisent la connexion, l’appliance envoie une réponse de réinitialisation au client.

Fonctionnement de la nouvelle tentative de demande lorsque le serveur principal réinitialise une connexion TCP sur l’établissement SYN

Le diagramme suivant montre les composants interagissent les uns avec les autres :

Fonctionnement de la nouvelle tentative de demande

  1. Le processus commence par activer la fonctionnalité appqoe sur votre appliance.
  2. Lorsque le client envoie une requête HTTP ou HTTPS, le serveur virtuel d’équilibrage de charge initie la connexion au serveur principal.
  3. Si le service demandé n’est pas disponible sur l’établissement TCP SYN, le serveur principal réinitialise la connexion TCP.
  4. Si la configuration appqoe est activée avec le nombre souhaité de tentatives de nouvelle tentative spécifié, le serveur virtuel d’équilibrage de charge utilise l’algorithme d’équilibrage de charge configuré pour transférer la demande au serveur d’applications disponible suivant.
  5. Une fois que le serveur virtuel d’équilibrage de charge a reçu la réponse, l’appliance transmet la réponse au client.
  6. Si les serveurs back-end disponibles sont égaux ou inférieurs au nombre de tentatives et si tous les serveurs envoient une réinitialisation, l’appliance répondra à une erreur interne de 500 serveurs. Considérez un scénario avec cinq serveurs disponibles et le nombre de tentatives est défini sur six. Si les cinq serveurs réinitialisent la connexion, l’appliance renvoie une erreur de serveur interne 500 au client
  7. De même, si le nombre de serveurs principaux est supérieur au nombre de nouvelles tentatives et si les serveurs back-end réinitialisent la connexion sur l’établissement TCP SYN, l’appliance transmet la réinitialisation au client. Considérez un scénario avec trois serveurs back-end et le nombre de tentatives est défini comme deux. Si les trois serveurs réinitialisent la connexion, l’appliance envoie un paquet de réinitialisation au client.

Configurer une nouvelle tentative de demande pour la méthode GET

Pour configurer la fonctionnalité de nouvelle tentative pour la méthode GET, vous devez effectuer les étapes suivantes.

  1. Activer AppQoE
  2. Ajouter une action AppQoE
  3. Ajouter une stratégie AppQoE
  4. Lier le serveur virtuel d’équilibrage de charge à la stratégie AppQoE

Activer AppQoE

À l’invite de commandes, tapez : enable ns feature appqoe

Ajouter une action AppQoE

Vous devez configurer une action AppQoE pour spécifier si vous souhaitez que l’appliance réessaye après une réinitialisation TCP et le nombre de tentatives de nouvelle tentative.

add appqoe action reset_action -retryOnReset ( YES | NO ) -numretries <positive_integer>]

Exemple :

add appqoe action reset_action –retryOnReset YES –numretries 5

Où, retryOnReset. Activez une nouvelle tentative si le serveur principal réinitialise une connexion TCP. numretries. Réessayer le compte.

Ajouter une stratégie AppQoE

Pour implémenter AppQoE, vous devez configurer la stratégie AppQoE pour hiérarchiser les requêtes HTTP ou SSL entrantes dans une file d’attente spécifique.

À l’invite de commandes, tapez :

add appqoe policy <name> -rule <expression> -action <string>

Exemple :

add appqoe policy reset_policy -rule http.req.method.eq(get) -action reset_action

Lier le serveur virtuel d’équilibrage de charge à la stratégie Appqoe

Lorsqu’un serveur principal réinitialise une demande de paquets TCP et si vous souhaitez que le serveur virtuel d’équilibrage de charge transmette la demande au service disponible suivant, vous devez lier le serveur virtuel d’équilibrage de charge à la stratégie AppQoE.

À l’invite de commandes, tapez :

bind lb vserver <name> ((<serviceName> (-policyName <string> [-priority <positive_integer>] [-gotoPriorityExpression <expression>] [-type ( REQUEST | RESPONSE )]

Exemple :

bind lb vserver v1 -policyName reset_policy -type REQUEST -priority 1

Configurer une nouvelle tentative de demande pour les demandes POST

Vous devez toujours faire preuve de prudence lorsque vous rechargez les demandes d’équilibrage qui écrivent des données dans le serveur principal. Pour de telles demandes, assurez-vous que la longueur du contenu est courte. Si la longueur du contenu est longue, cela peut entraîner une consommation de ressources. Suivez les étapes ci-dessous pour configurer l’équilibrage de rechargement pour les requêtes POST.

  1. Activer AppQoE
  2. Ajouter une action AppQoE
  3. Ajouter une stratégie AppQoE
  4. Lier le serveur virtuel d’équilibrage de charge à la stratégie AppQoE

Activer AppQoE

À l’invite de commandes, tapez :

enable ns feature appqoe

Ajouter une action Appqoe

Vous devez ajouter une action AppQoE pour réessayer après une réinitialisation TCP et le nombre de tentatives de nouvelle tentative.

add appqoe action reset_action -retryOnReset ( YES | NO ) -numretries <positive_integer>]

Exemple :

add appqoe action reset_action –retryOnReset YES –numretries 5

Ajouter une stratégie Appqoe

Pour implémenter AppQoE, vous devez configurer la stratégie AppQoE pour définir comment mettre en file d’attente les connexions dans une file d’attente spécifique.

À l’invite de commandes, tapez :

add appqoe policy <name> -rule <expression> -action <string>

Exemple :

add appqoe policy reset_policy -rule HTTP.REQ.CONTENT_LENGTH.le(2000) -action reset_action

Remarque :

Vous pouvez utiliser cette configuration si vous préférez restreindre la fonctionnalité de nouvelle tentative de demande pour une longueur de contenu inférieure à 2000.

Lier le serveur virtuel d’équilibrage de charge à la stratégie AppQoE

Lorsqu’un serveur principal réinitialise une demande de paquets TCP et si vous souhaitez que le serveur virtuel d’équilibrage de charge transmette la demande au service disponible suivant via une file d’attente spécifique, vous devez lier le serveur virtuel d’équilibrage de charge à la stratégie AppQoE.

À l’invite de commandes, tapez :

bind lb vserver <name> ((<serviceName> (-policyName <string> [-priority <positive_integer>] [-gotoPriorityExpression <expression>] [-type ( REQUEST | RESPONSE )]

Exemple : bind lb vserver v1 -policyName reset_policy -type REQUEST -priority 1

Configurer la stratégie AppQoE pour une nouvelle tentative de demande à l’aide de l’interface graphique Citrix ADC

  1. Accédez à AppExpert > AppQoE > Stratégies.
  2. Dans la page Stratégies AppQoE, cliquez sur Ajouter.
  3. Dans la page Créer une stratégie AppQoE, définissez les paramètres suivants : a. Nom. AppQoE policy name b. Action. Ajoutez ou modifiez une action. Pour créer une action, reportez-vous à Créer une action AppQoE la section. c. Expression. Sélectionnez ou entrez une expression HTTP.REQ.CONTENT_LENGTH.le (2000) de stratégie.
  4. Cliquez sur Créer et Fermer.

    Stratégie AppQoE pour la retentative de demande ou l'équilibrage de recharge

Configurer l’action AppQoE pour l’équilibrage de nouvelle tentative de demande à l’aide de l’interface graphique Citrix ADC

  1. Accédez à AppExpert > AppQoE > Action.
  2. Dans la page AppQoE Actions, cliquez sur Ajouter.
  3. Dans la page Créer une action AppQoE, définissez les paramètres suivants pour réessayer lors de la réinitialisation TCP : a. Réessayez lors de la réinitialisation TCP. Activez la case à cocher pour activer l’action de nouvelle tentative pour la réinitialisation TCP. b. Retry Count. Saisissez le nombre de tentatives.
  4. Cliquez sur Créer et Fermer.

    Configurer l'action AppQoE pour l'équilibrage de la nouvelle tentative de demande

Configurer une nouvelle tentative de demande pour la méthode GET lorsque le serveur principal se réinitialise sur l’établissement TCP SYN

La configuration CLI et GUI est similaire aux étapes suivies pour la méthode GET. Pour plus d’informations, reportez-vous à Configurer l’essai de requête pour la méthode GET la section. lorsque le serveur principal réinitialise une section de connexion.