Des messages d'erreur HTTP 504 s'affichent dans les journaux d'accès d'un Classic Load Balancer, dans les métriques CloudWatch ou lorsque je me connecte au service par le biais d'un Classic Load Balancer. Comment puis-je résoudre le problème ?

Une erreur HTTP 504 est un code de statut HTTP qui indique l'expiration du délai d'inactivité d'une passerelle ou d'un proxy. Lors de la résolution du problème, vérifiez les points suivants :

Vérifier le délai d'inactivité de l'équilibreur de charge et le modifier, si nécessaire

La raison principale pour laquelle un équilibreur de charge renvoie des erreurs HTTP 504 est due au fait qu'une instance principale correspondante n'a pas répondu à la demande durant le délai d'inactivité configuré (par défaut, le délai d'inactivité d'un Classic Load Balancer est de 60 secondes).

Si les métriques CloudWatch sont activées, vérifiez-les métriques pour votre équilibreur de charge. Si les points de données de latence correspondent à la valeur du délai d'inactivité actuellement configuré pour l'équilibreur de charge et que la métrique HTTPCode_ELB_5XX contient des points de données de latence, cela signifie qu'au moins une demande a dépassé le délai d'inactivité.

Pour résoudre ce problème, modifiez le délai d'inactivité de l'équilibreur de charge afin de permettre l'achèvement d'une demande HTTP pendant la période spécifiée pour le délai d'inactivité, ou configurez votre application afin qu'elle traite plus rapidement les demandes.

Vérifier que les instances principales gardent les connexions ouvertes

Si une instance principale ferme une connexion TCP à l'équilibreur de charge avant que ce dernier n'ait atteint le délai d'inactivité configuré, l'équilibreur de charge risque de ne pas pouvoir répondre à la demande, ce qui entraînera une erreur HTTP 504.

Pour résoudre ce problème, activez les paramètres keep-alive sur vos instances principales et définissez le délai d'attente keep-alive sur une valeur supérieure au délai d'inactivité de l'équilibreur de charge.

(Apache uniquement) Désactiver TCP_DEFER_ACCEPT

Lorsque TCP_DEFER_ACCEPT est activé pour les instances principales Apache, l'équilibreur de charge établit une connexion en envoyant un SYN à l'instance principale ; l'instance principale répond à l'aide d'un SYN-ACK et l'équilibreur de charge envoie un ACK vide à l'instance principale.

L'instance principale n'accepte pas le dernier ACK, car il est vide et elle renvoie un SYN-ACK à l'équilibreur de charge à la place. Cela peut entraîner un délai de dépassement de la nouvelle tentative SYN ultérieurement. Lorsque l'instance principale ferme la connexion sans envoyer de FIN ou RST à l'équilibreur de charge, ce dernier considère que la connexion est établie, ce qui n'est pas le cas. Ensuite, lorsque l'équilibreur de charge envoie des demandes via cette connexion TCP, l'instance principale répond à l'aide d'un RST, ce qui génère une erreur HTTP 504.

Pour résoudre ce problème, définissez la valeur de AcceptFilter http et AcceptFilter https sur none.

(Apache uniquement) Désactiver le module multi-processus Event et configurer de manière optimale les modules multi-processus Prefork et Worker

Le module multi-processus Event ne doit pas être utilisé sur les instances principales enregistrées sur un équilibreur de charge, car il met fin de manière dynamique aux connexions, ce qui entraîne l'envoi de messages d'erreur HTTP 504 aux clients.

Pour obtenir des performances optimales lors de l'utilisation des modules multi-processus Prefork et Worker, utilisez les valeurs suivantes, en partant du principe que le délai d'inactivité de l'équilibreur de charge est de 60 secondes :

 

mod_prefork MPM

mod_worker MPM

 

Expiration

65

65

 

KeepAliveTimeout

65

65

 

KeepAlive

Activé

Activé

 

MaxKeepAliveRequests

10 000

0

 

AcceptFilter http

aucun

aucun

 

AcceptFilter https

aucun

aucun

 

maintenance, réseau, VPN, tunnel


Cette page vous a-t-elle été utile ? Oui | Non

Retour au Centre de connaissances AWS Support

Vous avez besoin d'aide ? Consultez le site du Centre AWS Support

Date de publication : 15/09/2016