Sou um engenheiro de software que tenta detectar (e resolver, se possível) estranhos problemas de rede local desde 2 semanas em um ambiente de hospedagem de vários servidores.
Compramos 3 caixas dedicadas com ram de 8GB e 8 núcleos i7 cpu de uma empresa de hospedagem européia. Cada caixa tem duas interfaces, uma para tráfego externo e outra para comunicação local. Então contratamos um engenheiro de sistemas para configurar nosso ambiente inicial. Que mundo maravilhoso. Tudo vai bem até a implantação .. Após a implantação do aplicativo nos servidores abaixo dos problemas iniciados:
Servidor 1 (DB): 32 GB, 8 núcleos, 2 interfaces, executando apenas 2 serviços: o mysql 5.5 no Ubuntu 12.04 LTS com o memcached 1.4.13-0ubuntu2
Servidor 2 (www): 32 GB, 8 núcleos, 2 interfaces, executando php5-fpm (v5.5), nginx 1.4.4 & crontab no Ubuntu 12.04 LTS
Servidor 3 (Solr): 32 GB, 8 núcleos, 2 interfaces, executando apenas um serviço: Tomcat7 com Solr 4.5 no Ubuntu 12.04 LTS com memcached 1.4.13-0ubuntu2
Após a implantação, detectamos que os processos de indexação em massa de nosso aplicativo eram extremamente lentos. Durante a indexação em massa, o aplicativo lê dados do banco de dados (de srv1) (sem tráfego do usuário final no estágio), processa e produz mais dados estendidos, armazenando em cache os novos dados no memcached (srv1) como vários fragmentos e indexando no solr. Passei mais de 5 a 6 dias no lado do aplicativo para encontrar possíveis afunilamentos ou problemas relacionados ao aplicativo, mas nada foi encontrado.
Ao executar nosso cron de indexação no servidor, suspensão de aplicativo, espera, algum tempo lançando erros de conexão relacionados memcached (NÃO ENCONTRADO) mas às vezes não, passando com sucesso a fase de leitura e lança outras exceções de conexão relacionadas com a conexão mysql. Db está instalado e funcionando, sem linhas de erro no mysql.log. Memcached instalado e em execução e nenhum evento de logs de erros extremamente detalhado (-vvv) o log está ativado. Eu verifico uma e outra vez aplicação, sem consultas em loops (consultas são otimizadas o suficiente), sem conexões desnecessárias memcached - operações em loops (estamos usando multi_get - multi_set métodos enquanto a leitura e escrita em massa)
Então eu tentei mudar a configuração do meu aplicativo para usar nossos endereços IP externos (120.144.X.X) ao invés de usar os endereços locais (10.10.X.X) e boom! Aplicativo começou a voar. Problemas e exceções se foram, correndo perfeitos como um vento.
Nosso programador investigou cada vez mais problemas de hardware / fiação, conversou muitas vezes com o datacenter, testou e testou novamente, mas o ponto final é: "seu hardware e fiação estão ok, verifique sua configuração de rede e seu aplicativo".
Sysengineer disse-me que "a configuração -ipv6 na rede local é desnecessária, por isso podemos encerrar completamente isso" em uma reunião. Eu não sei porque. Eu não fiz mais perguntas depois desse diálogo.
Poucos dias depois, nossa empresa contratou outro sysengineer que odeia o ipv6 novamente e estou muito surpreso. Minha primeira pergunta é: por que ambos os sysengineers odeiam o ipv6? Qual é o problema com o ipv6 é?
O principal problema com a nossa aplicação agora é falar com memcached e mysql usando endereços IP externos e queremos usar a rede local para isso. Funciona perfeitamente em ip's externos, mas não nos locais.
Eu não sei qual é o problema, eu não sou um engenheiro de rede ou de sistemas, não sei o que eles fizeram nos sistemas, mas acredito que haja um problema de erro de configuração. Ambos os sysengineers são negados, não há nada errado, mas eu quero cavar isso mais.
Onde posso começar? Quais são as ferramentas adequadas para encontrar o problema? Essas saídas são normais:
[email protected] ~ # ping6 google.com
PING google.com(fra02s20-in-x04.1e100.net) 56 data bytes
64 bytes from fra02s20-in-x04.1e100.net: icmp_seq=1 ttl=56 time=5.46 ms
64 bytes from fra02s20-in-x04.1e100.net: icmp_seq=2 ttl=56 time=5.43 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 5.432/5.447/5.462/0.015 ms
[email protected] ~ # ping6 10.10.10.3
unknown host
[email protected] ~ # ping6 10.10.10.1
unknown host
[email protected] ~ # ifconfig
eth0 Link encap:Ethernet HWaddr d4:3d:7e:ec:f0:11
inet addr:144.XX.XX.XX Bcast:144.XX.XX.XX Mask:255.255.255.224
inet6 addr: fe80::d63e:7efe:fedf:f011/64 Scope:Link
inet6 addr: 2c01:4e8:200:7343::2/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3523880 errors:0 dropped:0 overruns:0 frame:0
TX packets:7026713 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1042946956 (1.0 GB) TX bytes:9140153208 (9.1 GB)
eth0:1 Link encap:Ethernet HWaddr d4:3d:7e:ec:f0:11
inet addr:144.XX.XX.XXX Bcast:144.XX.XX.XX Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr 68:05:ca:06:68:a2
inet addr:10.10.10.4 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr:fde80::6c05:caff:fe26:57a2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:47434 errors:0 dropped:986 overruns:0 frame:0
TX packets:364069 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7188468 (7.1 MB) TX bytes:527053731 (527.0 MB)
Interrupt:16 Memory:f7cc0000-f7ce0000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:4765 errors:0 dropped:0 overruns:0 frame:0
TX packets:4765 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:540280 (540.2 KB) TX bytes:540280 (540.2 KB)
Onde devo ir agora para descobrir qual é o problema?
EDITAR Eu acho que essas saídas também são interessantes:
[email protected] # netstat -s | egrep -i 'loss|retrans|drop'
1588 segments retransmited
63 times recovered from packet loss by selective acknowledgements
TCPLostRetransmit: 4
9 timeouts in loss state
375 fast retransmits
46 forward retransmits
519 retransmits in slow start
1 SACK retransmits failed
[email protected] # netstat -s | egrep -i 'loss|retrans|drop'
32 dropped because of missing route
2290 segments retransmited
2 SYNs to LISTEN sockets dropped
150 times recovered from packet loss by selective acknowledgements
TCPLostRetransmit: 5
4 timeouts in loss state
410 fast retransmits
85 forward retransmits
150 retransmits in slow start
12 SACK retransmits failed
Estas saídas são realmente normais?