Traffico regionale AWS: traccia da where proviene

Ho iniziato ad utilizzare più macchine in un cluster su AWS EC2. Da quando ho iniziato questo progetto, vedo i costi per il traffico regionale nelle mie informazioni di fatturazione:

trasferimento di dati regionali – in / out / tra EC2 AZ o utilizzando IP o ELB elastici

Secondo il nome, sono tre possibilità:

  • diverse zone di disponibilità
  • comunicazione utilizzando IP elastici
  • utilizzando un bilanciatore elastico forte

Aveva diverse AZ per le mie macchine, questo era un problema. Così ho risolto questo, ora tutte le macchine sono nello stesso AZ, ma i costi sono aumentati per 24 ore (ci sono stati 3 aggiornamenti in quel periodo). Sembra che l'impostazione di tutte le macchine allo stesso AZ non lo risolva.

Tuttavia, non utilizzo IP Elastici né ELB. Quando visito queste pagine sul mio portle web mi mostra solo una list vuota con un messaggio che non ho componenti in questo momento.

In un'altra domanda su serverfault leggiamo anche che questo accade quando gli indirizzi IP pubblici vengono utilizzati per la comunicazione, ma in alcune discussioni di github possiamo leggere che anche il nome DNS pubblico verrà risolto internamente (sempre, passare attraverso la networking esterna, in modo da innescare i costi).

Se traccia la mia comunicazione di networking dal master e uno degli slave nel mio cluster usando

sudo tcpdump -i eth0 | grep -v $MY_HOSTNAME 

Posso vedere solo traffico interno come questo:

 IP ip-172-31-48-176.ec2.internal.56372 > ip-172-31-51-15.ec2.internal.54768 

Quindi il mio problema: come posso scoprire quale componente sta causando questo traffico regionale?

  • CentOS segnalando la memory totale inferiore rispetto agli altri in AWS
  • beanstalk usando php-git su windows client
  • Colbind il database RDS dal lato esterno di VPC
  • Crittografia completa a fine con AWS Elastic Load Balancer, Nginx e SSL
  • CDN per la memorizzazione della cache REST api
  • Come utilizzare le variables nel nomefile di access_log con Nginx (healthd)
  • Come mantenere l'Amazon EBS Backed AMI persistente?
  • Può una CloudFormation di AWS creare un KeyPair per utilizzare successivamente quando avvii istanze?
  • One Solution collect form web for “Traffico regionale AWS: traccia da where proviene”

    tl; dr

    L'enorme quantità di traffico regionale è stata causata da un apt-get update all'avvio della macchina.

    In un primo momento ho sospettato che il software che sto eseguendo sul cluster, perché questo invia un inferno molte richieste DNS – probabilmente non utilizza alcun caching DNS. E il server DNS si trova in un'altra zona di disponibilità.

    Modo completo per eseguire il debug di tali cose

    Ho eseguito il debug di questo con un amico, ecco come siamo arrivati ​​alla soluzione in modo che tutti con questo problema possano seguire:

    Prima di tutto, dalla gestione della fatturazione, puoi vedere che il costo è di $ 0.01 per GB. Quindi rispecchia i seguenti punti della pagina web Pricing (che vanno un po 'più in dettaglio):

    • Amazon EC2, Amazon RDS, Amazon Redshift e Amazon ElastiCache o Elastic Network Interfaces nella stessa zona di disponibilità
      • Utilizzo di un indirizzo IP pubblico o elastico
    • Amazon EC2, Amazon RDS, Amazon Redshift e Amazon ElastiCache o Elastiche Network Interfaces in un'altra zona di disponibilità o peered VPC nella stessa regione AWS

    Avanti ho controllato una spiegazione su AWS su zone e regioni di disponibilità . Quello che devo pagare è sicuramente il traffico che proviene dalla stessa regione ( us-east-1 nel mio caso). Può essere il traffico che passa da un AZ ad un altro AZ (abbiamo saputo prima) o traffico utilizzando un indirizzo IP pubblico o un indirizzo IP elastico all'interno dello stesso AZ (sapevamo anche dall'altra domanda serverfault ). Tuttavia, ora sembra che questa list sia effettivamente esaustiva.

    Sapevo che avevo:

    • 6 macchine EC2 in un cluster
    • nessun RDS
    • nessun Redshift
    • no ElastiCache
    • nessun indirizzo IP elastico

    Peer VPC

    VPC è un prodotto proprio, quindi vai a VPC . Da lì puoi vedere quanti VPC avete. Nel mio caso era solo uno, quindi il peering non è affatto ansible. Ma puoi ancora andare a Peering Connections e vedere se c'è qualche cosa.

    sottoreti

    Dalla substring in VPC abbiamo anche scoperto alcuni importnti indizi per ulteriori debug. Intervalli IP delle diverse zone di disponibilità in us-east-1 :

    • 172.31.0.0/20 per us-east-1a
    • 172.31.16.0/20 per us-east-1b
    • 172.31.32.0/20 per us-east-1e
    • 172.31.48.0/20 per us-east-1d

    Dal momento che tutte le mie macchine dovrebbero essere in us-east-1d , ho verificato che. E infatti tutti avevano IP iniziando con 172.31.48 , 172.31.51 e 172.31.54 . Fin qui tutto bene.

    tcpdump

    Ciò poi finalmente ci ha aiutato a impostare i filtri giusti per tcpdump. Ora sapendo con quale IP dovrei comunicare per evitare costi (solo networking 172.31.48.0/20 ), abbiamo impostato un filter per tcpdump . Questo ha contribuito a rimuovere tutti i rumori che mi hanno fatto non vedere la comunicazione esterna. Inoltre, prima che non sapessi nemless che la comunicazione con [something].ec2.internal potrebbe essere il problema, dato che non sapevo abbastanza per le regioni, gli AZ ei rispettivi intervalli IP.

    In primo luogo abbiamo trovato questo filter tcpdump:

     tcpdump "not src net 172.31.48.0 mask 255.255.240.0" -i eth0 

    Questo dovrebbe mostrare tutto il traffico in arrivo da ovunque ma us-east-1d . Ha mostrato un sacco di traffico dalla connessione SSH, ma ho visto qualcosa di strano volare da un indirizzo ec2.internal . Non dovrebbero essere tutti filtrati, perché non mostriamo più il traffico AZ?

     IP ip-172-31-0-2.ec2.internal.domain > ip-172-31-51-15.ec2.internal.60851 

    Ma questo non è interno! È da un altro AZ, cioè da us-east-1a . Questo è dal sistema DNS.

    Ho esteso il filter per verificare quanti messaggi si verificano:

     sudo tcpdump "not src net 172.31.48.0 mask 255.255.240.0 and not src host $MY_HOSTNAME" -i eth0 

    Ho aspettato 10 secondi, ho interrotto la logging e sono state 16 risposte da DNS!

    I prossimi giorni, ancora lo stesso problema

    Tuttavia, dopo l'installazione di dnsmasq nulla è cambiato. Ancora diversi GB di traffico quando ho usato il cluster.

    Da giorno in giorno ho rimosso più attività dal cluster e ho finalmente provato un giorno senza script di avvio (fine!) E un giorno solo con script di avvio + arresto istantaneo (traffico!).

    L'analisi dello script di avvio ha rivelato che l' apt-get update apt-get install ... e apt-get install ... sono l'unico componente che estrae file enormi. Attraverso una ricerca su Google ho imparato che Ubuntu effettivamente ha un repository di pacchetti all'interno di AWS. Ciò può essere visto anche dalle sources.list :

     http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ 

    Risolvere il nome host port ai seguenti indirizzi IP:

     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 

    Così ho installato un servizio Log Flow e ho registrato il cluster durante l'ora di avvio. Quindi ho scaricato i file di registro e li ho eseguiti attraverso uno script python per riassumere tutti i byte trasferiti a uno di questi 4 indirizzi IP. E il risultato corrisponde al mio traffico. Ho avuto 1.5 GB di traffico durante l'ultimo test, avevo 3 cluster di 5 macchine ciascuna e secondo il mio log log Flow each macchina interroga circa 100 MB dal repository di Ubuntu.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.