Проблемы кластера и балансировщика

Задания не распечатываются в отказоустойчивой конфигурации
Файл недоступен при отложенной печати в кластере
Как диагностировать проблемы NFS и DNS

Задания не распечатываются в отказоустойчивой конфигурации

Симптом

В конфигурации с балансировщиком HAProxy пользователи авторизуются, но задания не выходят на печать.

Диагностика

Шаг 1. Проверить панель HAProxy

Откройте панель администратора HAProxy. Проверьте, что все секции зелёные:

ftp
cups_1631
tcp_converter_7776 / tcp_converter_7777
admin_8010 / admin_8080

Красная строка сервера = сервер установлен некорректно или недоступен.

Шаг 2. Проверить флаг use_cups_ssl в клиенте ПМ

Ошибка http.client.RemoteDisconnected: Remote end closed connection without response означает неверный флаг SSL.

Перейдите в директорию клиента ПМ: C:\Program Files\printum\printmanager_client\
Откройте файл settings.yml с правами администратора.
Установите: use_cups_ssl: true

Шаг 3. Проверить NFS-хранилище

Убедитесь, что NFS-хранилище доступно. Недоступность NFS приводит к потере файлов заданий.

Шаг 4. Проверить синхронизацию ПринтМенеджер с Мониторингом

Запустите ручную синхронизацию в личном кабинете: Настройки → Интеграции → ПМ.

Связанные страницы

Файл недоступен при отложенной печати в кластере

Симптом

Пользователь авторизовался на МФУ, но задание недоступно или файл документа отсутствует в очереди.

Причина

Файлы заданий в кластерной конфигурации хранятся на NFS-хранилище. Если NFS недоступен или неправильно смонтирован на одном из серверов ПринтМенеджер — файлы заданий не видны этому серверу.

Диагностика

Шаг 1. Проверить монтирование NFS

# На каждом сервере ПМ:
df -h | grep nfs
mount | grep nfs

Шаг 2. Проверить права доступа к папке NFS

ls -la /scratch
# Ожидаемые права: 777, владелец nobody

Шаг 3. Проверить сетевую доступность NFS-сервера

ping <NFS_ADDR>
# Проверка экспортов NFS:
showmount -e <NFS_ADDR>

Шаг 4. Перемонтировать NFS при необходимости

sudo umount /scratch
sudo mount <NFS_ADDR>:<NFS_FOLDER_PATH> /scratch

Связанные страницы

Задания не распечатываются в отказоустойчивой конфигурации

Как диагностировать проблемы NFS и DNS

Назначение

DNS и NFS являются критически важными инфраструктурными зависимостями системы Printum.

Проблемы с DNS или NFS могут вызывать:

restart loop контейнеров;
недоступность ПринтМенеджера;
ошибки синхронизации;
недоступность очередей печати;
проблемы работы встроенных приложений;
ошибки авторизации пользователей;
недоступность архива заданий.

Типовые признаки проблем DNS

Симптом	Возможная причина
Контейнеры постоянно перезапускаются	hostname не резолвится, nfs-сервер недоступен
Ошибки timeout	DNS-сервер недоступен
Ошибки синхронизации	неверное DNS-имя
SSL/TLS errors	hostname не соответствует сертификату
ПринтМенеджер недоступен	отсутствует DNS-resolve между узлами, nfs-сервер недоступен

Диагностика DNS

Проверка resolv.conf

Проверить содержимое файла:

cat /etc/resolv.conf

Необходимо убедиться:

DNS-серверы указаны корректно;
DNS-серверы доступны;
отсутствуют ошибочные записи;
указан корректный search domain (если используется).

Проверка разрешения hostname

Проверить разрешение hostname:

ping monitoring.local

Дополнительно рекомендуется выполнить:

nslookup monitoring.local

Проверить:

hostname успешно резолвится;
IP-адрес соответствует ожидаемому;
отсутствуют timeout;
ответ приходит от корректного DNS-сервера.

Проверка сетевой связности

Проверить доступность серверов:

ping printmanager.local

При использовании отказоустойчивой конфигурации необходимо проверить связность между:

Мониторингом;
всеми узлами ПринтМенеджера;
NFS-сервером;
балансировщиком;
PostgreSQL;
Redis/Sentinel.

Диагностика NFS

Проверка доступности NFS-портов

Проверить доступность NFS:

telnet nfs-server.local 2049

Если используется stunnel:

telnet nfs-server.local 20490

Ожидаемый результат:

TCP-соединение успешно устанавливается;
отсутствуют timeout;
отсутствует ошибка Connection refused.

Проверка mounted volumes

Проверка NFS volume в Docker

Проверить список Docker volumes:

docker volume ls

Найти volume, который используется ПринтМенеджером (printmanager-app).

Проверить параметры volume:

docker volume inspect <volume_name>

Проверить:

volume существует;
указан корректный NFS server;
указан корректный путь NFS export;
параметры подключения соответствуют конфигурации.

Проверка mount внутри контейнера

Зайти в контейнер ПринтМенеджера:

docker exec -it printmanager-app sh

Проверить подключённые файловые системы внутри контейнера:

df -h

Дополнительно проверить доступность каталога:

ls -la <mount_path>

Проверить:

каталог доступен из контейнера;
отсутствуют ошибки Stale file handle;
файловая система не находится в режиме read-only;
файлы создаются и читаются корректно.

Проверка сервисов NFS

На NFS-сервере проверить состояние сервисов:

systemctl status nfs-server.service

Если используется stunnel:

systemctl status stunnel.service

Проверить:

сервисы находятся в состоянии active (running);
отсутствуют restart loop;
отсутствуют ошибки systemd.

Перезапуск сервисов NFS

При необходимости выполнить перезапуск:

systemctl restart nfs-server.service

Если используется stunnel:

systemctl restart stunnel.service

После перезапуска рекомендуется повторно проверить:

доступность портов;
состояние mount;
доступность каталогов;
состояние контейнеров Printum.

Что делать при restart loop контейнеров

Если контейнеры Printum постоянно перезапускаются, необходимо последовательно проверить:

DNS;
NFS;
сетевую связность;
mounted volumes;
доступность PostgreSQL;
доступность Redis;
корректность hostname;
срок действия SSL-сертификатов.

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

cd /opt/printmanager
docker-compose down && docker-compose up -d

Дополнительная диагностика Docker

Проверить состояние контейнеров:

docker ps -a

Просмотреть логи контейнера:

cd /opt/printmanager/
docker-compose logs -f --tail=5

Важно помнить

DNS является одной из самых частых причин инфраструктурных отказов.
NFS критически важен для работы отказоустойчивой конфигурации ПринтМенеджера.
Большинство restart loop связано с инфраструктурными зависимостями.
Проверка DNS и NFS должна быть первым этапом диагностики.
В Active-Active конфигурации стабильная работа DNS и NFS обязательна для всех узлов кластера.