Вы просматриваете старую версию данной страницы. Смотрите текущую версию.

Сравнить с текущим просмотр истории страницы

« Предыдущий Версия 5 Текущий »

Описание проблемы

На ECSS-10 кластер RestFS показывает статус disconnected_by_timeout (отключен по таймауту), хотя сам сервис (nginx/openresty, порт 9990) работает.

Так это выглядит в web-конфигураторе, окно "Кластеры RestFS":

Статус плавает: кластер то подключается, то снова отваливается. Причина в закрытом контуре: внешний DNS, указанный в dnsmasq, из него недоступен.

Страдает не только RestFS. Когда dnsmasq перестаёт отвечать, пропадает вся зона .ecss: system.restfs.ecss, *.mysql.ecss, *.broker.ecss. Поэтому та же причина может выглядеть так:

  • в IVR не проигрываются файлы;
  • запись разговора обрывается или не сохраняется;
  • кластер RestFS в web-конфигураторе то подключен, то отключен по таймауту.

Ни один из этих симптомов прямо на DNS не указывает.

Диагностика

Переключение default host restfs на 127.0.0.1 показывает статус connected, обратно на system.restfs.ecss даёт таймаут:

admin@[mycelium1@]:/$ restfs/change default host 127.0.0.1
admin@[mycelium1@]:/$ restfs/list
┌────────────┬─────────────────────┬─────────┐
│Cluster name│        Peer         │ Status  │
├────────────┼─────────────────────┼─────────┤
│default     │http://127.0.0.1:9990│connected│
└────────────┴─────────────────────┴─────────┘
admin@[mycelium1@]:/$ restfs/change default host system.restfs.ecss
admin@[mycelium1@]:/$ restfs/list
┌────────────┬──────────────────────────────┬───────────────────────┐
│Cluster name│             Peer             │        Status         │
├────────────┼──────────────────────────────┼───────────────────────┤
│default     │http://system.restfs.ecss:9990│disconnected_by_timeout│
└────────────┴──────────────────────────────┴───────────────────────┘

Вывод: проблема не в restfs, а в резолвинге доменного имени system.restfs.ecss.

После проверки верните настройку как была, иначе проблема с DNS останется скрытой:

restfs/change default host system.restfs.ecss

Главный признак: лог dnsmasq

Проверка DNS «в лоб» может ничего не показать. Между всплесками nslookup, getent и curl по system.restfs.ecss отвечают сразу и возвращают 127.0.0.1, поэтому причину легко пропустить. Смотреть нужно лог dnsmasq:

grep "Maximum number of concurrent DNS queries" /var/log/ecss/dns-env/dnsmasq.log*

Если проблема та же, там будут строки вида:

dnsmasq[2543]: Maximum number of concurrent DNS queries reached (max: 150)

Такие строки повторяются периодически, например раз в несколько часов. В момент такого всплеска dnsmasq не отвечает ни на какие имена, включая .ecss.

Проверить, что внешний DNS недоступен

Посмотреть, какой вышестоящий DNS указан:

grep "^server=" /etc/dnsmasq.d/ecss

Проверить, отвечает ли он из контура (пример для 77.88.8.8):

dig +short @77.88.8.8 ya.ru

Если команда ничего не вернула или завершилась по таймауту, DNS из контура недоступен.

Дополнительно видна задержка на запросах, которые dnsmasq отправляет наружу. Например, имя с доменом из строки search в /etc/resolv.conf:

time nslookup system.restfs.ecss.<домен из search>

Ответ через секунду и дольше означает, что запрос висит на недоступном DNS. Косвенно это видно и в CoCon: restfs/list по имени выполняется заметно дольше, чем по адресу 127.0.0.1 (секунды против миллисекунд).

Корневая причина

В /etc/dnsmasq.d/ecss указан вышестоящий DNS (строка server=), который из закрытого контура недоступен. Чаще всего это server=77.88.8.8 из инструкции по установке: там предлагается указать свой DNS, локальный или глобальный, а 77.88.8.8 приведён только как образец.

Все запросы, которые dnsmasq пересылает наружу, висят до таймаута. Очередь пересылаемых запросов заполняется до лимита в 150, и в этот момент dnsmasq перестаёт отвечать на любые запросы, в том числе на локальные имена зоны .ecss. Ядро не может разрешить system.restfs.ecss, и кластер RestFS уходит в disconnected_by_timeout, хотя сам restfs работает.

Решение

На всех серверах кластера в /etc/dnsmasq.d/ecss замените недоступный DNS.

Вариант 1, если внешние имена нужны (обновления из репозиториев, внешние интеграции). Укажите внутренний DNS, доступный из контура:

server=<IP внутреннего DNS>

Вариант 2, если внешние имена не нужны. Закомментируйте строку:

#server=77.88.8.8

Внимание. В этом же файле стоит no-resolv, поэтому dnsmasq не читает /etc/resolv.conf. Без строки server= он будет резолвить только зону .ecss, а внешние имена перестанут резолвиться. Выбирайте второй вариант только если это действительно не нужно.

Перезапустите dnsmasq:

sudo systemctl restart dnsmasq

Проверка

1. В CoCon кластер restfs подключен по имени:

restfs/list

Ожидаемо: http://system.restfs.ecss:9990 в статусе connected с обоих узлов.

В web-конфигураторе, окно "Кластеры RestFS", статус "подключен":

2. Через сутки в логе dnsmasq нет новых строк о переполнении очереди:

grep "Maximum number of concurrent DNS queries" /var/log/ecss/dns-env/dnsmasq.log

Если строки появились снова, значит, в конфигурации остался ещё один недоступный вышестоящий DNS. Проверьте все строки server= во всех файлах /etc/dnsmasq.d/.

Как не допустить

При установке в закрытом контуре в /etc/dnsmasq.d/ecss указывайте только DNS, который реально доступен из этого контура. Если такого нет, строку server= не добавляйте. Образец server=77.88.8.8 из инструкции по установке в закрытом контуре оставлять нельзя.

Версия ECSS-10Актуальность
3.14.x+
3.17.x+
3.18.x+

Проблема не связана с версией ECSS: она в настройке dnsmasq на хосте.

  • Нет меток