У меня 7 серверов Ubuntu 14.04.4, работающих в EC2. На одном сервере размещается memcached (порт 11211), а на других 6 - клиенты. Из 6 клиентов 5 могут подключиться, а один нет (см. Примечание).
Я сделал дамп TCP с обеих сторон соединения. Я видел, что клиент отправил SYN-запрос, но ACK не был отправлен обратно. Tcpdump выглядел так для сбойного соединения (после этого SYN-файлы повторяются много раз)
1 0.000000 172.16.1.58 172.16.1.94 TCP 76 43469 → 11211 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=849737 TSecr=0 WS=128
И для успешного подключения с другого сервера:
1 0.000000 172.16.1.64 172.16.1.94 TCP 76 44908 → 11211 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=19201098 TSecr=0 WS=128
2 0.000298 172.16.1.64 172.16.1.94 TCP 68 44908 → 11211 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=19201098 TSecr=3160738522
Еще несколько следов и команд:
working-client$ nc -vnz 172.16.1.94 11211
Connection to 172.16.1.94 11211 port [tcp/*] succeeded!
broken-client$ nc -vnz 172.16.1.94 11211
nc: connect to 172.16.1.94 port 11211 (tcp) failed: Connection timed out
broken-client$ nc -vnz -q 5 -u 172.16.1.94 11211
Connection to 172.16.1.94 11211 port [udp/*] succeeded!
Таблица маршрутизации (идентична для всех клиентов и серверов)
$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default ip-172-16-1-1.e 0.0.0.0 UG 0 0 0 eth0
172.16.1.0 * 255.255.255.0 U 0 0 0 eth0
Таблицы IP на сломанном клиенте
broken-client$ sudo iptables -nvL -t nat
--------------------------------------
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
broken-client$ sudo iptables -nvL
--------------------------------------
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Таблицы IP на сервере
server$ sudo iptables -nvL -t nat
--------------------------------------
Chain PREROUTING (policy ACCEPT 7332 packets, 531K bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 7332 packets, 531K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 370 packets, 25781 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 370 packets, 25781 bytes)
pkts bytes target prot opt in out source destination
server$ sudo iptables -nvL
--------------------------------------
Chain INPUT (policy ACCEPT 1963K packets, 341M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 2670K packets, 5518M bytes)
pkts bytes target prot opt in out source destination
Все клиенты были клонированы из одного и того же базового образа и должны быть идентичными. Мы не используем iptables, все серверы находятся в одной подсети и группе безопасности.
Проблема не в memcached: я могу воспроизвести проблему с telnet (порт 22 или порт 11211) или ssh, ни одному из них не разрешено подключаться, хотя они разрешены группой безопасности.
Пинг отключен, но я могу проследить маршрут между серверами (кеш <=> клиент, клиент <=> кеш), если это не эти два сервера.
Похоже (см. Следы выше), соединение UDP может быть установлено, но не TCP.
Проблема постоянная.
Примечание. 6 клиентских серверов входят в группу автоматического масштабирования (в VPC). В зависимости от нагрузки может быть от 1 до 6 серверов, и иногда один сервер не может подключиться. IP-адреса и имена серверов используются повторно.
На что я могу посмотреть, чтобы узнать, где происходит сбой соединения?
Похоже, это вызвано кешированием ARP (кешированием MAC-адресов) в новых ядрах Linux.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1331150