У меня есть сервер Debian wheezy, на котором запущено несколько веб-приложений, база данных MongoDB и сервер Redis за сервером NGinx. Только сервер NGinx является общедоступным, а другие службы проксируются за ним. Эта установка отлично работала до тех пор, пока два дня назад не произошло временное отключение электроэнергии в центре обработки данных, где находится мой сервер. После перезагрузки и регулярного обслуживания после сбоя (удаление файлов блокировки, восстановление БД и т. Д.) Я заметил, что время ожидания NGinx истекло для каждой службы, которую он прокси. Вот шаги, которые я предпринял, чтобы попытаться решить проблему:
Проверить журналы
Я проверил журналы для каждой службы, и все чисто, без ошибок (кроме того, что NGinx сообщает о тайм-ауте восходящего соединения).
Проверить работу служб
Все процессы для приложения WSGI, MongoDB и т. Д. Запущены, и я также проверил netstat:
# netstat -ntple
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 0 21730537 1469/nginx
tcp 0 0 0.0.0.0:2525 0.0.0.0:* LISTEN 1000 21730714 1511/python
tcp 0 0 0.0.0.0:9090 0.0.0.0:* LISTEN 1000 21730931 1627/python
tcp 0 0 0.0.0.0:2022 0.0.0.0:* LISTEN 0 21730651 1553/sshd
tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN 1000 21730885 1624/python
tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN 104 21730531 1376/mongod
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 105 21730621 1532/redis-server *
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1000 21730731 1500/python
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 21730536 1469/nginx
tcp6 0 0 :::2022 :::* LISTEN 0 21730654 1553/sshd
tcp6 0 0 :::6379 :::* LISTEN 105 21730619 1532/redis-server *
Проверьте интерфейс обратной связи и пинг 127.0.0.1
Интерфейс обратной связи правильно настроен в /etc/network/interfaces и ifconfig сообщает об этом и работает. Я также могу без проблем пинговать 127.0.0.1 и localhost.
Отключить брандмауэр
Отключение брандмауэра ситуацию не изменило. Время ожидания соединения все еще истекает.
Попробуй подключиться через телнет
Я попытался подключиться к одной из служб по telnet, и именно здесь я заметил странную картину:
# telnet 127.0.0.1 6379
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection timed out
# telnet ::1 6379
Trying ::1...
Connected to ::1.
Escape character is '^]'.
Когда я пытаюсь подключиться к службе (Redis в этом примере) через IPv4, время ожидания истекает, но если я пытаюсь подключиться через IPv6, он подключается мгновенно. Есть ли какой-либо файл, связанный с подключением IPv4, который может вызвать такое поведение? Есть ли способ исправить это без повторного создания образа сервера?
После прочтения ответа SYN я попытался подключиться к той же службе (см. Выше), но вместо этого использовал общедоступный IP-адрес моего сервера (но все еще изнутри сервера), и он мгновенно подключается. Я так понимаю, что он работает, потому что он слушает 0.0.0.0, который принимает соединения на любом интерфейсе. Но подключение из 127.0.0.1 по-прежнему не работает, как и подключение к службе, которая специально прослушивает 127.0.0.1. Тогда я пришел к выводу, что проблема с моим интерфейсом обратной связи (на IPv4) действительно существует. Вот результат ifconfig :
# ifconfig
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:7984 errors:0 dropped:0 overruns:0 frame:0
TX packets:7984 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:711801 (695.1 KiB) TX bytes:711801 (695.1 KiB)
venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:127.0.0.2 P-t-P:127.0.0.2 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:35812 errors:0 dropped:0 overruns:0 frame:0
TX packets:47530 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2568793 (2.4 MiB) TX bytes:34332070 (32.7 MiB)
venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:*public ip* P-t-P:*public ip* Bcast:*public ip* Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
Есть ли что-то оттуда, что могло бы объяснить неисправность интерфейса обратной связи? Есть ли другой файл журнала или конфигурации, который я пропустил, который мог бы объяснить или потенциально исправить проблемы, которые у меня возникают с этим интерфейсом?
Быстрое обновление, чтобы добавить, что мой сервер - это VPS под OpenVZ. Из моих (продолжающихся) поисков в Google я обнаружил, что OpenVZ работает с сетями немного иначе, чем другие платформы, поэтому я включаю эту информацию сюда, чтобы потенциально направить нас в правильном направлении. Однако из того, что я видел, никто, у кого была проблема, отдаленно похожая на мою, похоже, не нашел решения ... (например, эта почта из Unix и Linux StackExchange).
Готов поспорить, вы можете подключить Redis к своему IPv4. Если Redis не слушает 127.0.0.1:6379, вы не можете подключиться (или по telnet) к localhost.
Не достаточно знаком с IPv6, чтобы объяснить, почему он работает.
Опять же, я сомневаюсь, что прокси-сервер nginx направляет трафик на redis. Можете ли вы показать нам, какие виртуальные хосты включены? Это нормально, что ваши процессы Python слушают 0.0.0.0? Если это так, вам, вероятно, следует снова включить все отключенные вами правила брандмауэра.
Обновление, чтение обновлений OP:
Приятно видеть, что ты что-то нашел. Между тем, мое первое замечание относительно подключения к localhost было совершенно неправильным, извиняюсь.