История страницы

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

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

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

Image Added

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

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

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

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

Диагностика

Переключение 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  name│        Peer         │ Status  │
├────────────┼─────────────────────┼─────────┤
│default │default       │http│http://127.0.0.1:9990│connected│
└────────────┴─────────────────────┴─────────┘

admin@[mycelium1@]:/$ restfs/change default default host system.restfs.ecss


admin@[mycelium1@]:/$ restfs/list
┌────────────┬──────────────────────────────┬───────────────────────┐
│Cluster name│             Peer             │        Status         │
├────────────┼──────────────────────────────┼───────────────────────┤
│default     │http 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 (секунды против миллисекунд).

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

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

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

Решение

На обоих серверах в конфигурации dnsmasq всех серверах кластера в /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", статус "подключен":

Image Added

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 закомментировать #server указывайте только DNS, который реально доступен из этого контура. Если такого нет, строку server= не добавляйте. Образец server=77.88.8.8 и перезагрузить dnsmasq из инструкции по установке в закрытом контуре оставлять нельзя.

Актуальность

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