← На главную

Работа в многосерверном кластере 1С:Предприятие предоставляет отличные возможности для масштабирования и отказоустойчивости, однако она вносит свои коррективы в привычный процесс разработки. Основная сложность заключается в том, что сеанс пользователя может быть запущен на любом из рабочих серверов кластера, и если отладка включена не везде, «поймать» нужный момент в Конфигураторе становится практически невозможно. Разберем подробно, как настроить среду для эффективной отладки в условиях распределенной системы.

Проблема распределения сеансов в кластере

Проанализируем ситуацию: в кластере из трех серверов нагрузка распределяется динамически. Когда мы запускаем клиентское приложение, менеджер кластера определяет, какой рабочий процесс (rphost) на каком сервере будет обслуживать данный сеанс. Если мы включим режим отладки только на одном сервере, то вероятность того, что наш сеанс попадет именно на него, составляет всего 33%. В остальных случаях точки останова просто не будут срабатывать.

Рассмотрим два основных подхода к решению этой задачи: классическую TCP-отладку и современную HTTP-отладку.

Способ 1: Классическая TCP-отладка на всех узлах

Самый очевидный, но ресурсозатратный способ — включить режим отладки на всех серверах кластера. Это гарантирует, что на какой бы сервер ни бросило ваш сеанс, отладчик сможет к нему подключиться.

Для активации режима отладки необходимо изменить параметры запуска службы 1С:Предприятия (ragent). Выполним следующие шаги на каждом сервере:

1. Остановим службу 1C:Enterprise 8.3 Server Agent.
2. В реестре Windows (или в конфигурационном файле в Linux) найдем строку запуска и добавим ключ -debug.
3. Запустим службу заново.

Важный нюанс: включение отладки на рабочих серверах может снижать производительность системы примерно на 10-15%. Это происходит из-за необходимости передачи дополнительных метаданных. Поэтому в высоконагруженных «боевых» системах этот метод стоит использовать с осторожностью.

Способ 2: Использование требований назначения функциональности

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

Мы можем создать правило, которое будет направлять сеанс конкретного разработчика или конкретную информационную базу на выделенный сервер, где включена отладка. Разберем по шагам, как это сделать в консоли администрирования кластера:

1. Перейдем в раздел «Рабочие серверы» и выберем тот, на котором будет работать отладчик.
2. В контекстном меню выберем «Требования назначения функциональности».
3. Добавим новое правило:
   • Объект требования: Клиентское соединение.
   • Тип требования: Назначать.
   • Дополнительный параметр: Имя информационной базы или имя пользователя.
4. На остальных серверах кластера создадим запрещающее правило для этого же объекта с типом «Не назначать».

Таким образом, мы изолируем процесс отладки, не мешая работе остальных пользователей и не перегружая другие серверы кластера лишним функционалом.

Способ 3: Современная HTTP-отладка (рекомендуется)

Начиная с версии платформы 8.3.7, компания 1С внедрила механизм отладки по протоколу HTTP. В условиях кластера это наиболее правильный и стабильный вариант. Выясним причину, по которой он лучше: при использовании этого метода появляется такое понятие, как Сервер отладки (Debug Server).

В этой схеме все рабочие процессы со всех серверов кластера общаются с одним центральным узлом отладки. Нам больше не нужно гадать, на каком сервере исполняется код. Рассмотрим, как это настроить:

На всех серверах кластера в строку запуска службы ragent необходимо добавить следующие параметры:

-debug -http -debugServerAddr [адрес_центрального_сервера]

Здесь [адрес_центрального_сервера] — это IP или имя машины, которая будет выступать координатором отладки (это может быть один из серверов кластера). По умолчанию используется порт 1550.

Преимущества этого метода очевидны:

• Конфигуратор подключается к единой точке входа.
• Проблемы с брандмауэрами сводятся к минимуму, так как используется фиксированный HTTP-порт.
• Стабильная отладка фоновых заданий, которые в кластере могут «мигрировать» между серверами.

Особенности отладки фоновых заданий

В кластере фоновые задания представляют особую сложность. Даже если вы запустили клиентское приложение на одном сервере, фоновое задание, порожденное им, может запуститься на другом. Чтобы гарантированно перехватывать их, выполним следующие настройки в Конфигураторе:

1. Меню «Отладка» — «Подключение...».
2. Нажмем кнопку «Настройка...».
3. Установим флажок «Автоматическое подключение: Фоновые задания».

При использовании HTTP-отладки фоновое задание само сообщит серверу отладки о своем запуске, и ваш Конфигуратор мгновенно его «подцепит», вне зависимости от того, на каком физическом сервере оно выполняется.

Сетевые настройки и порты

Проанализируем типичную ошибку: отладка включена, но точки останова не срабатывают. Часто причина кроется в закрытых портах. При TCP-отладке сервер 1С пытается сам инициировать соединение с компьютером разработчика (открываются случайные порты в диапазоне 1560–1591). В кластере из трех серверов это означает, что вы должны разрешить входящие соединения от ВСЕХ трех серверов к вашему рабочему месту.

При HTTP-отладке ситуация проще: все узлы обращаются к порту 1550 на сервере отладки. Это гораздо легче согласовать с системными администраторами.

Резюме

Для эффективной работы в кластере из 3-х серверов наиболее правильным подходом будет:

1. Перевод кластера на HTTP-отладку с выделением одного сервера в качестве центрального сервера отладки.
2. Использование требований назначения функциональности, если отладка требуется только для определенных баз или разработчиков, чтобы не снижать общую производительность системы.
3. Обязательная проверка доступности портов между всеми участниками процесса: серверами кластера, сервером отладки и клиентским местом разработчика.

Следуя этим шагам, мы превратим отладку в кластере из «гадания на кофейной гуще» в предсказуемый и комфортный процесс разработки.