Я инженер-программист, который пытается обнаружить (и, если возможно, решить) странные проблемы с локальной сетью, уже 2 недели в среде многосерверного хостинга.
Мы купили 3 выделенных коробки с 32 ГБ оперативной памяти 8 Core i7 у европейской хостинговой компании. Каждый блок имеет два интерфейса: один для внешнего трафика, а другой - для локальной связи. Затем мы нанимаем системного инженера для настройки нашей исходной среды. Какой замечательный мир. До развертывания все идет нормально .. После развертывания приложения на серверах ниже начались проблемы:
Сервер 1 (БД): 32 ГБ, 8 ядер, 2 интерфейса, работает только 2 службы: mysql 5.5 на ubuntu 12.04 LTS с memcached 1.4.13-0ubuntu2
Сервер 2 (www): 32 ГБ, 8 ядер, 2 интерфейса, работает php5-fpm (v5.5), nginx 1.4.4 и crontab на ubuntu 12.04 LTS
Сервер 3 (Solr): 32 ГБ, 8 ядер, 2 интерфейса, работает только одна служба: Tomcat7 с Solr 4.5 на ubuntu 12.04 LTS с memcached 1.4.13-0ubuntu2
После развертывания мы обнаружили, что процессы массового индексирования нашего приложения были очень медленными. При массовом индексировании приложение считывает данные из базы данных (из srv1) (нет трафика конечного пользователя на этапе), обрабатывает их и создает более расширенные данные, кэшируя новые данные в memcached (srv1) в виде нескольких фрагментов и индексируя на solr. Я потратил более 5-6 дней на приложение, чтобы найти возможные узкие места или проблемы, связанные с приложением, но ничего не нашел.
При запуске нашего индексирующего cron на сервере приложение зависает, ожидает, иногда выдает ошибки подключения, связанные с memcached (НЕ НАЙДЕНЫ), но иногда нет, успешно проходит фазу чтения и выдает другие исключения подключения, связанные с подключением mysql. Db запущен и работает, в mysql.log нет строк с ошибками. Memcached запущен и работает, и нет журналов ошибок. Включено чрезвычайно подробное ведение журнала событий (-vvv). Я снова и снова проверяю приложение, никаких запросов в циклах (запросы достаточно оптимизированы), никаких ненужных соединений memcached - операции в циклах (мы используем методы multi_get - multi_set при массовом чтении и записи)
Затем я попытался переключить конфигурацию моего приложения на использование наших внешних IP-адресов (120.144.X.X) вместо использования локальных (10.10.X.X) и бум! Приложение начало слетать. Проблемы и исключения ушли, все идет идеально, как ветер.
Наш системный инженер все больше и больше копался в проблемах оборудования / проводки, много раз разговаривал с центром обработки данных, тестировал, снова тестировал, но последний момент: «ваше оборудование и проводка в порядке, проверьте конфигурацию сети и ваше приложение».
Sysengineer сказал мне, что «конфигурация -ipv6 в локальной сети не требуется, поэтому мы можем полностью отключить ее» на встрече. Не знаю почему. После этого диалога я больше не задавал вопросов.
Несколько дней спустя наша компания наняла еще одного сининженера, который снова ненавидит ipv6, и я очень удивлен. Мой первый вопрос: почему оба sysengineer ненавидят ipv6? В чем проблема с ipv6?
Основная проблема с нашим приложением теперь заключается в том, что оно общается с memcached и mysql, используя внешние IP-адреса, и мы хотим использовать для этого локальную сеть. Он отлично работает на внешних ip, но не на локальных.
Я не знаю, в чем проблема, я не системный или сетевой инженер, я не знаю, что они делали в системах, но я считаю, что это проблема неправильной конфигурации. Оба сисинженера отрицают, что все в порядке, но я хочу покопаться в этом подробнее.
С чего начать? Каковы подходящие инструменты для поиска проблемы? Нормальны ли эти выходы:
root@10.10.10.4 ~ # 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
root@10.10.10.4 ~ # ping6 10.10.10.3
unknown host
root@10.10.10.4 ~ # ping6 10.10.10.1
unknown host
root@10.10.10.4 ~ # 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)
Куда мне теперь обратиться, чтобы узнать, в чем проблема?
РЕДАКТИРОВАТЬ Думаю, эти выводы тоже интересны:
root@10.10.10.4 # 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
root@10.10.10.1 # 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
Эти выходы действительно нормальные?