ADC

Demander une nouvelle tentative si le serveur principal réinitialise la connexion TCP

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 un équilibrage de recharge, le client enregistre le RTT lorsque l’appliance lance la même demande auprès du service disponible suivant.

Comment fonctionne une nouvelle tentative de demande lorsque le serveur principal réinitialise une connexion TCP

Le schéma suivant montre comment les composants interagissent les uns avec les autres.

Comment fonctionne une nouvelle tentative de demande pour la réinitialisation de la connexion TCP

  1. Le processus commence par l’activation de la fonctionnalité Apqoe 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 « rétentative » est activée dans la configuration appqoe avec le nombre de tentatives souhaité spécifié, le serveur virtuel d’équilibrage de charge utilise l’algorithme d’équilibrage de charge configuré pour transmettre la demande au prochain serveur d’applications disponible.
  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 le nombre de serveurs principaux disponibles est égal ou inférieur au nombre de nouvelles tentatives et si tous les serveurs envoient une réinitialisation, l’appliance répondra à une erreur interne de 500. 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 principaux 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.

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 suivre les étapes suivantes.

  1. Activer AppQoE
  2. Ajouter une action AppQoE
  3. Ajouter une stratégie AppQoE
  4. Liez la politique AppQoE au serveur virtuel d’équilibrage de charge

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éessaie après une réinitialisation TCP et le nombre de tentatives.

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

Exemple :

add appqoe action reset_action –retryOnReset YES –numretries 5

Où, réessayez sur Réinitialiser. Activez une nouvelle tentative si le serveur principal réinitialise une connexion TCP. chiffres. Réessayer le compte.

Ajouter une stratégie AppQoE

Pour implémenter AppQoE, vous devez configurer la politique 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 la stratégie appqoe au serveur virtuel d’équilibrage de charge

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 la nouvelle tentative de demande pour les requêtes POST

Vous devez toujours faire preuve de prudence lorsque vous rechargez des demandes d’équilibrage qui écrivent des données sur 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 charge pour les requêtes POST.

  1. Activer AppQoE
  2. Ajouter une action AppQoE
  3. Ajouter une stratégie AppQoE
  4. Liez la politique AppQoE au serveur virtuel d’équilibrage de charge

Activer AppQoE

À l’invite de commandes, tapez :

enable ns feature appqoe

Ajouter une action Apple

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 politique Apple

Pour implémenter AppQoE, vous devez configurer la politique AppQoE pour définir comment mettre les connexions en file d’attente 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 un contenu d’une longueur inférieure à 2 000.

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

Lorsqu’un serveur principal réinitialise une demande de paquet TCP et si vous souhaitez que le serveur virtuel d’équilibrage de charge transmette la demande au prochain service disponible 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 politique AppQoE pour les nouvelles tentatives de demande à l’aide de l’interface graphique Citrix ADC

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

Configurer l’action AppQoE pour l’équilibrage des nouvelles tentatives de demande à l’aide de l’interface graphique NetScaler ADC

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

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, consultez la section Configurer la demande d’essai pour la méthode GET. lorsque le serveur principal réinitialise une section de connexion.

Demander une nouvelle tentative si le serveur principal réinitialise la connexion TCP