Назад | Перейти на главную страницу

Включение IPv6 приводит к увеличению времени ожидания на TIME_WAIT

На прошлой неделе мы включили IPv6 на наших авторитетных DNS-серверах и соответствующие записи Glue на нашем регистраторе для серверов доменных имен, а также добавили записи AAAA для нашего собственного веб-сайта. Это развертывание прошло без сучка и задоринки, и теперь мы обслуживаем наш веб-сайт изначально на IPv6.

В эти выходные мы добавили IPv6-адрес на один из выделенных серверов нашего клиента, убедились, что Apache настроен для IPv6, и добавили этот IP-адрес в свой собственный файл зоны DNS.

С тех пор наш Nagios отслеживает URL (http://www.allgirlsallowed.org) жаловался на:

КРИТИЧЕСКИЙ - Тайм-аут сокета через 10 секунд

Мы подтвердили, что веб-сайт полностью функционирует и что DNS настроен правильно, хотя внешние инструменты (такие как тесты веб-сайта Pingdom и http://www.downforeveryoneorjustme.com) имеют смешанные результаты (Pingdom говорит, что работает нормально, Down for Every говорит, что не работает).

В ходе нашего расследования мы заметили несколько десятков TIME_WAIT, приходящих с одного и того же IPv6-адреса (который находится в нашем же блоке / 64 и является IP-адресом хостинг-провайдера).

Теперь я понимаю, что статус TIME_WAIT означает, что соединение фактически закрыто и процесс скоро прекратится. Тем не менее, это только странная вещь, которую мне удалось найти на сервере. Мы также наблюдали устойчивое увеличение нагрузки (~ 0,5, даже если текущих посетителей нет).

Что меня беспокоит, так это то, что мы не наблюдали такого поведения на других наших серверах с поддержкой IPv6 (хотя и разрешено, другие наши серверы IPv6, вероятно, получают намного меньше трафика, чем этот конкретный клиент).

Есть ли что-нибудь, что вы могли бы предложить мне изучить? Очевидно, я мог бы вернуться и отключить IPv6, но это чушь. Я хочу выявить проблему и решить ее напрямую.

Майкл - Спасибо за ответ. Я считаю, что нашел причину жалоб Nagios, а также gazillion TIME_WAIT, которые я видел (поскольку я только что внес изменения в / etc / sysconfig / network-scripts / ifcfg-eth0), хотя я не понимаю почему это имело бы значение, и я не понимаю, почему это устранило проблему.

Проблема заключалась в том, что сервер запрашивает DHCP-адрес для IPv6 (мы не устанавливали его специально в ifcfg-eth0). Тем не менее, мы ДЕЙСТВИТЕЛЬНО включили в этот файл следующую строку:

IPV6INIT=no

Только несколько минут назад я сравнил этот файл построчно с файлом на другом из наших серверов, на котором запущен IPv6, так как проблемный сервер продолжал иметь проблемы, продолжал иметь ПУТЬ больше TIME_WAIT, чем Я думал, что был прав, продолжал иметь высокую нагрузку, а клиент жаловался, что их веб-сайт был очень медленным (а иногда и раньше сегодня).

Я обнаружил, что вставил эту строку IPV6INIT в их файл, хотя я не вставлял эту строку в файл на других наших серверах с включенным IPv6.

Как только я удалил эту строку и перезапустил сетевую службу, все TIME_WAIT исчезли, нагрузка на сервер упала, и Nagios немедленно выдал предупреждение «Восстановление» для критического статуса, на которое он постоянно жаловался последние 3 дня.

Мы продолжим внимательно следить за происходящим со своей стороны, но похоже, что проблема решена.