Tl;dr
L'énorme quantité de trafic régional a été causée par une apt-get update au démarrage de la machine.
J'ai d'abord soupçonné le logiciel que j'exécute sur le cluster, car il envoie un nombre impressionnant de requêtes DNS - il n'utilise probablement pas de cache DNS. Et le serveur DNS se trouve dans une autre zone de disponibilité.
Moyen complet de déboguer ce genre de choses
J'ai débogué ce problème avec un ami, voici comment nous sommes arrivés à la solution pour que tous ceux qui ont ce problème puissent suivre :
Tout d'abord, à partir de la gestion de la facturation, vous pouvez voir que le coût est de 0,01 $ par Go. Cela reflète donc les points suivants de la page web de tarification (qui entrent un peu plus dans les détails) :
- Amazon EC2, Amazon RDS, Amazon Redshift et Amazon ElastiCache instances ou Elastic Network Interfaces dans la même zone de disponibilité.
- Utilisation d'une adresse IP publique ou Elastic
- des instances Amazon EC2, Amazon RDS, Amazon Redshift et Amazon ElastiCache ou des interfaces réseau élastiques dans une autre zone de disponibilité ou un VPC "peered" dans la même région AWS.
Ensuite, j'ai vérifié une explication sur AWS concernant Zones et régions de disponibilité . Ce que je dois payer, c'est définitivement le trafic qui vient de la même région ( us-east-1 dans mon cas). Il peut s'agir soit d'un trafic passant d'une AZ à une autre AZ (nous le savions auparavant), soit d'un trafic utilisant une adresse IP publique ou une adresse IP Elastic au sein de la même AZ (nous le savions également par le biais de l'autre question sur le défaut du serveur ). Cependant, il semble maintenant que cette liste soit effectivement exhaustive.
Je le savais :
- 6 machines EC2 dans un cluster
- pas de RDS
- pas de Redshift
- pas d'ElastiCache
- non Adresse IP élastique
VPC piloté
VPC est un produit propre, donc allez à VPC . De là, vous pouvez voir combien de VPC vous avez. Dans mon cas, il n'y en avait qu'un, donc le peering n'est pas possible du tout. Mais vous pouvez toujours aller à Connexions d'échange de trafic et voir si quelque chose y est défini.
Sous-réseaux
Desde el Sous-réseau dans le VPC, nous avons également trouvé des indices importants pour un débogage plus poussé. Les plages IP des différentes zones de disponibilité dans les us-east-1 :
-
172.31.0.0/20 para us-east-1a
-
172.31.16.0/20 para us-east-1b
-
172.31.32.0/20 para us-east-1e
-
172.31.48.0/20 para us-east-1d
Puisque toutes mes machines devraient être dans us-east-1d J'ai vérifié. Et en effet, ils avaient tous des IPs commençant par 172.31.48 , 172.31.51 y 172.31.54 . Jusqu'à présent, tout va bien.
tcpdump
Cela nous a finalement permis de définir les bons filtres pour tcpdump. Maintenant, je sais avec quelles IPs je dois communiquer pour éviter les coûts (réseau, etc.). 172.31.48.0/20 seulement), nous avons mis en place un filtre pour tcpdump . Cela a permis d'éliminer tous les bruits qui m'empêchaient de voir la communication externe. De plus, avant, je ne savais même pas que la communication avec l'extérieur était possible. [something].ec2.internal pourrait être le problème, puisque je ne connaissais pas suffisamment les régions, les ZA et leurs plages d'IP respectives.
On a d'abord créé ce filtre tcpdump :
tcpdump "not src net 172.31.48.0 mask 255.255.240.0" -i eth0
Cela devrait montrer tout le trafic venant de partout sauf us-east-1d . Il a montré beaucoup de trafic de ma connexion SSH, mais j'ai vu quelque chose de bizarre passer - un ec2.internal adresse. Ne devraient-ils pas tous avoir été filtrés, puisque nous ne montrons plus le trafic interne à AZ ?
IP ip-172-31-0-2.ec2.internal.domain > ip-172-31-51-15.ec2.internal.60851
Mais ce n'est pas interne ! Il vient d'un autre AZ, à savoir us-east-1a . Cela provient du système DNS.
J'ai étendu le filtre pour vérifier combien de ces messages se produisent :
sudo tcpdump "not src net 172.31.48.0 mask 255.255.240.0 and not src host $MY_HOSTNAME" -i eth0
J'ai attendu 10 secondes, j'ai arrêté la journalisation et il y avait 16 réponses du DNS !
Les jours suivants, toujours le même problème
Cependant, après avoir installé dnsmasq, rien n'a changé. Il y a toujours plusieurs Go de trafic lorsque j'utilise le cluster.
De jour en jour j'ai supprimé plus de tâches du cluster et finalement j'ai essayé un jour sans aucun scripts de démarrage (bien !) et un jour avec scripts de démarrage seulement + arrêt instantané (trafic !).
L'analyse du script de démarrage a révélé que apt-get update y apt-get install ... sont le seul composant qui tire des fichiers énormes. Grâce à une recherche sur Google, j'ai appris qu'Ubuntu a effectivement un dépôt de paquets dans AWS. Cela peut également être vu à partir du sources.list :
http://us-east-1.ec2.archive.ubuntu.com/ubuntu/
La résolution du nom d'hôte conduit aux adresses IP suivantes :
us-east-1.ec2.archive.ubuntu.com. 30 IN A 54.87.136.115
us-east-1.ec2.archive.ubuntu.com. 30 IN A 54.205.195.154
us-east-1.ec2.archive.ubuntu.com. 30 IN A 54.198.110.211
us-east-1.ec2.archive.ubuntu.com. 30 IN A 54.144.108.75
J'ai donc configuré un service Log Flow et j'ai enregistré le cluster pendant le démarrage. Ensuite, j'ai téléchargé les fichiers journaux et les ai fait passer par un script Python pour faire la somme de tous les octets transférés vers l'une de ces 4 adresses IP. Et le résultat correspond à mon trafic. J'ai eu 1,5 Go de trafic lors du dernier test, j'avais 3 clusters de 5 machines chacun et selon mon journal Log Flow, chaque machine interroge environ 100 Mo du dépôt Ubuntu.
