| Оглавление |
|---|
| Версия ECSS-10 | Актуальность |
|---|---|
| 3.14.x | + |
| 3.17.x | + |
| 3.18.x | + |
Проблема не связана с версией ECSS: она в настройке dnsmasq на хосте.
Описание проблемы
На 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 из инструкции по установке в закрытом контуре оставлять нельзя.

