504 Gateway Timeout - Deux instances EC2 avec équilibreur de charge
Cela pourrait être le problème impossible. J'ai tout essayé. J'ai l'impression qu'il y a un gars au standard quelque part qui fait tournoyer sa moustache.
Le problème:
Amazon EC2 exécute une application. Il fonctionne sans problème lorsqu'il n'y a qu'une seule instance et pas d'équilibreur de charge.
Mais dans mon environnement de production, deux instances identiques fonctionnent derrière un même équilibreur de charge et lors de certaines tâches, comme une fonctionnalité qui génère un PDF et l'attache à un e-mail, rien ne se produit, et lors de l'utilisation de Google Developer. outils avec l'onglet Réseau j'obtiens l'erreur "504 Gateway Timeout" une fois que le délai d'attente est atteint (je l'ai réglé à 30 secondes).
Ma base de données est externe, sur Amazon RDS.
Je pense… Si je pouvais forcer un client à rester connecté au serveur initial auquel il s'était connecté, ce problème serait résolu car je comprends que le délai d'attente de la passerelle 504 se produit lorsque l'instance-1 tente de contacter instance-2 pour effectuer la tâche.
Cela se produit UNIQUEMENT lors de l'utilisation de l'équilibrage de charge, mais jamais lors d'une connexion directe à l'un de mes deux serveurs.
Paramètres de l'équilibreur de charge:
- L’équilibreur de charge a un CRECORD sur mon registraire de sorte que app.myapplication.com pointe vers myloadbalancerDNSname.elb.amazonaws.com
- L'équilibreur de charge a 2 instances saines, chacune dans la même région, mais elles se trouvent dans des zones de disponibilité différentes.
- L'équilibreur de charge utilise les mêmes groupes de sécurité que les instances (autoriser TOUTES les adresses IP sur les ports 22, 80 et 443).
- L'équilibrage de charge a activé l'équilibrage de charge entre zones.
- CORS (dans Amazon S3) est activé pour GET, POST, PUT, DELETE de * à * (je ne sais pas comment cela est associé à mes instances, mais je l’ai fait comme les instructions le disaient)
- L'équilibreur de charge a des écouteurs configurés comme tels:
- Protocole de l'équilibreur de charge: Port d'équilibreur de charge HTTP: 80 Protocole d'instance: Port d'instance HTTP: 80
- Protocole d'équilibrage de la charge: Port d'équilibrage de la charge HTTPS: 443 Protocole d'instance: Port d'instance HTTP: 80 (le chiffrement est sélectionné correctement par mon fournisseur de certificat et les champs SSL sont sûrement corrects à 100%)
Quelques idées supplémentaires:
Cela étant dit, je ne teste pas avec HTTPS, mais plutôt avec HTTP normal. Je ne suis pas convaincu que SSL est correctement configuré même si mon fournisseur de certificat l'a dit. La raison de ma suspicion est que lorsque j'essaie de saisir https://app.myapplication.com j'obtiens l'erreur "(échec) net :: ERR_CONNECTION_CLOSED" dans les outils de développement de Google, dans l'onglet Réseau. Mais cela ne devrait pas être applicable, car le problème persiste, même avec HTTP. Je peux dépanner SSL plus tard.
Donc, pour réitérer, mon problème est d'avoir le problème "504 Gateway Timeout" lors de l'utilisation de certaines fonctions, mais aussi parfois de manière aléatoire au lieu de charger la page (mais rarement). Ce problème 504 ne survient que lors de l'utilisation de l'équilibrage de charge, mais jamais lors d'une connexion directe à l'une de mes deux instances.
Je ne sais pas quelle question poser, car j'ai suivi chaque document jusqu'au T, vérifié deux ou trois fois toutes les suggestions sur le Web et RIEN.
Quel serveur utilisez-vous? J'ai eu un problème très similaire avec l'équilibrage de charge nginx et AWS. J'ai ajouté keepalive_timeout 75s; au bloc http dans mon fichier de configuration nginx et je n'ai pas vu le problème depuis.
Assurez-vous de redémarrer nginx après avoir ajouté et enregistré cette ligne (sous ubuntu Sudo service nginx restart. Sous redhat, arrêtez nginx /path/to/nginx/executable -s stop puis /path/to/nginx/executable pour démarrer nginx)
AWS a recommandé ce correctif sur leur page d'aide Dépannage d'AWS Load Balancer
Premièrement, quel est le délai d'inactivité défini pour votre ELB? Vous le trouverez tout en bas de l'onglet "Description" de votre équilibreur de charge. Vous pouvez en savoir plus sur le délai d'inactivité ici dans la documentation ELB . La valeur par défaut est 60 secondes. Vous devez également envisager de définir ou d'augmenter le maintien en activité sur votre serveur Web. Cela dépend du serveur Web que vous utilisez.
Deuxièmement, si vous pensez que cela est dû au fait que le client est passé d’une instance à l’autre, vous devez activer la persistance de la session dans l’ELB. Cela garantira qu'un client est toujours dirigé vers la même instance dorsale par l'équilibreur de charge. Pour l'activer, cliquez à nouveau sur l'onglet "Description", puis cliquez sur le lien Modifier en regard de chaque entrée de la section Configuration du port. Vous voudrez probablement choisir l’option «Activer l’adhésivité des cookies générés par Load Balancer», car elle indiquera à l’ELB de gérer tous les aspects de l’adhésivité.
Dans mon cas, il s'avère que l'équilibreur de charge ne posait aucun problème. La solution finale est finalement le fichier hosts d'Ubuntu dans lequel se trouve une entrée inexplicable pour acheminer le trafic depuis une adresse IP mystère vers le nom d'hôte de mon application. Ainsi, au cours du processus de création du fichier PDF, le générateur PDF a réécrit les chemins afin de pointer vers le serveur de mystère, d'où les problèmes de délai d'attente de la passerelle. Je ne sais pas pourquoi cela fonctionnait occasionnellement et n'échouait pas.
127.0.0.1 localhost
127.0.1.1 ubuntu-server
42.139.126.191 app.myapp.com
Voici à quoi cela ressemblait. J'ai donc supprimé cette troisième ligne et tous les engrenages ont recommencé à tourner. : P
Nous utilisons des instances Amazon EC2 derrière un Amazon ELB et nous obtenions des erreurs 504 GATEWAY_TIMEOUT. Nous utilisons Apache et PHP sur les serveurs Web Ubuntu.
Dans notre cas, l'erreur était due au manque de mémoire des serveurs. Nous n'avons pas vu le "manque de mémoire" dans nos journaux d'erreurs Apache. Il y avait une entrée de ligne 504 dans les journaux d'accès Apache. Nous avons confirmé le "manque de mémoire" en consultant le fichier syslog (/ var/log/syslog) et en résolvant le problème de mémoire.
Cela a résolu l'erreur 504 pour nous.
Le délai d’inactivité est probablement le coupable et la valeur par défaut est 60 secondes . AWS ALB
Vérifiez les paramètres des groupes de sécurité. Le port 80 peut être limité à l'accès.