Совмещать роли на одном сервере для небольшой инфраструктуры — обычная практика: меньше железа, меньше администрирования. Обратная сторона проявляется в момент сбоя — одна неисправность задевает сразу учёт, телефонию и выход в интернет. С таким случаем мы и работали: машина вела учёт, держала офисную сеть и обслуживала звонки.
Проблема
У клиента один физический сервер на openSUSE одновременно выполнял несколько ролей: на нём работала учётная система на Odoo вместе с телефонией, он же служил сетевым шлюзом, DNS- и DHCP-сервером для всей офисной сети, VPN-шлюзом и АТС на Asterisk. Сбой на такой машине останавливает всё сразу — от учёта до телефонии и интернета в офисе.
После сбоя выяснилось, что часть данных учётной системы оказалась в нерабочем состоянии. Хранение в Odoo состоит из двух физически разных частей: база PostgreSQL в СУБД и файлстор — обычные файлы на диске с вложениями и документами, прикреплёнными к записям. Повредиться эти части могут независимо друг от друга, поэтому проверять пришлось по отдельности каждую.
Вторая линия — телефония. Звонки через SIP-транк периодически пропадали на несколько минут: без системной ошибки, без видимой причины, транк просто переставал принимать вызовы. Обрывы случались в разгар рабочего дня и повторялись.
Решение
Сначала сеть, потом всё остальное
Первым делом восстановили сетевой шлюз. Логика простая: пока в офисе нет интернета, не работает ничто, включая диагностику остальных проблем на том же сервере. Дальше шли по сервисам.
Учётная система
Базу PostgreSQL и файлстор проверяли и восстанавливали как две независимые части хранения, а не как единый «бэкап системы»: у каждой свои признаки целостности и свой способ проверки. Работы вели без полной перезагрузки инфраструктуры — сервисы разделены логически, изменения применялись точечно, там, где это требовалось. Останавливать всё хозяйство ради правки одного сервиса необходимости не было.
Телефония: локальный DNS как источник обрывов
К диагностике звонков шли от сетевого уровня внутрь: правила NAT, файрвол, схема прохождения трафика — всё штатное. Источник оказался на последнем шаге — локальный DNS-резолвер на том же сервере.
В конфигурации DNS (BIND/named) форвардинг на внешние резолверы был отключён, и сервер пытался разрешать домены полностью самостоятельной рекурсией. Для домена SIP-провайдера — точнее, для CNAME-цели, на которую он указывает, — такая рекурсия стабильно возвращала SERVFAIL, хотя через внешний резолвер тот же домен разрешался без проблем.
Механика обрывов объяснилась сразу: пока у Asterisk оставался закешированный адрес транка, регистрация висела в состоянии Registered и звонки шли. Но когда для нового вызова требовался свежий DNS-лукап именно в момент неудачного резолвинга, вызов через этот транк на время переставал проходить. Отсюда и «случайные» паузы по несколько минут.
Форвардеры на рабочие резолверы вернули в конфигурацию. Простого rndc reload и rndc flush оказалось недостаточно — настройки подхватились только после полного перезапуска сервиса named. Сам Asterisk при этом не перезапускался, телефония не прерывалась.
Проверка
Результат проверяли не на глаз: пятнадцать резолвингов домена SIP-провайдера подряд — все с корректным ответом, регистрации всех SIP-транков восстановлены.
Результат
- Все сервисы — учётная система, телефония, DNS, VPN — восстановлены без остановки бизнес-процессов.
- Найдена и устранена первопричина обрывов звонков: неверная конфигурация форвардеров DNS давала SERVFAIL для конкретного домена SIP-провайдера.
- Проверка после правки: пятнадцать успешных резолвингов подряд и полное восстановление регистрации всех SIP-транков.
- Обе роли сервера — учётная система и сетевой шлюз — снова выполняются на одной машине, без потери данных.
- Понятен запас прочности: в таких случаях скорость восстановления определяет не мощность железа, а то, есть ли отдельное резервное копирование под каждую из ролей сервера.
С чего начать
Если у вас на одной машине живёт больше одной критичной роли, начинать стоит с инвентаризации: какие роли совмещены, какие из них действительно нужно держать рядом, а какие можно разнести без потери удобства. Для каждой роли проверяется отдельно, есть ли своё резервное копирование и пробовали ли из него восстанавливаться — резервная копия, которую ни разу не разворачивали, защитой не является.
Отдельный пункт — DNS на самом сервере. Если на нём поднят свой резолвер, убедитесь, что форвардинг на внешние резолверы настроен и работает, а домены внешних сервисов — SIP-провайдер, почта, ЭДО, платёжные сервисы — разрешаются стабильно. Похожий случай мы разбирали в материале про сайт, который не открывался: сервер был полностью исправен, а причина оказалась в локальном кэше DNS на стороне клиента. Проверка DNS с нескольких независимых точек занимает пару минут и сразу показывает, где на самом деле искать проблему.
Свяжитесь с нами: +7 913 916-61-17, info@erpha.ru