Общее устройство кластера серверов 1С

Три компоненты системы: ragent, rmngr, rphost. Чтобы было понятно, о чем идет речь, лучше взглянуть на картинку.

Кластер 1СНа что здесь стоит обратить внимание? В первую очередь – порты сервера 1С. Они все должны быть открыты. Как показано на рисунке, соединения в основном проходят непосредственно к рабочим процессам сервера 1С, т.е. по портам 1560-1591 (посчитайте сами максимальное количество рабочих процессов, которое можно запустить на одном сервере).

Но основной порт – 1541 – по нему будет первичное подключение к серверу 1С, соответственно, его тоже нужно открывать через Firewall для работы с сервером. Зато часто можно не открывать порт 1540 – там находится процесс ragent, с которым общается только менеджер кластера (rmngr). Для клиентского приложения данный порт ни к чему.

Все порты задаются в строке запуска агента сервера 1С:Предприятия:

-regport 1541 -port 1540 -range 1560:1591

Отсюда вывод – два сервера 1С разных версий на один компьютер установить можно – достаточно просто указать разные диапазоны портов. Я обычно это делаю посредством редактирования реестра Windows. Открываем службы, копируем строку запуска – ищем в реестре, меняем на ту, которая понравится. Собственно, это действие часто приходится проделывать при обновлении сервера 1С, потому как автоматически не всегда обновляется. Теперь рассмотрим, что на самом деле делает каждый компонент системы.

Ragent – в сущности, бесполезный компонент. В теории предназначается для того, чтобы передавать управление другому менеджеру кластера при проблемах в текущем менеджере. На практике даже в тестовом режиме подобные переключения редко срабатывают. В рабочем не срабатывают практически никогда. В 8.3 заявлен полноценный отказоустойчивый кластер, агент сервера теряет свою актуальность еще больше, несмотря на то что отказоустойчивость в ее лучшем варианте в 8.3 тоже не работает как надо. В общем, кластер должен быть один, это, конечно, ИМХО, но проверенное очень большим опытом. Дело в том, что ragent не может определить, что rmngr перестал функционировать, потому как основная проблема менеджера кластера – не «аварийное завершение», а «зависание», т.е. те случаи, когда он ждет получения информации о сеансовых данных, а этой информации по каким-либо причинам нет, либо есть какие-то блокировки разных сервисов.

Rmngr – главный проблемный компонент в системе. Лучше всего вынести его на отдельный рабочий сервер, поставив минимальную производительность, этим оградив от всякой рабочей нагрузки и оставив только служебные функции. Данный процесс отвечает за блокировки 1С, время, список информационных баз, журнал регистрации, сеансовые данные… т.е. выполняет все сервисные функции, кроме непосредственно выполнения программного кода 1С. В них, как правило, и содержится большая часть проблем.

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

Вообще сеансовые данные 1С и их организация – это тема для отдельной статьи. Как в этом случае все организовано, разобраться непросто, но то, что криво, – понятно сразу. Зачем сеансовые данные пишутся обязательно на диск, вместо того чтобы храниться в памяти каждого сервера, зачем их миграция организована файловым образом? Почему управлением репликацией данных не занимается отдельная служба, почему не организован протокол разрешения коллизий, почему они никогда не сохраняются в СУБД? Поэтому организация хранения сеансовых данных – основное узкое место сервера 1С на настоящий момент.

Rphost – рабочий процесс сервера 1С. Функции его предельно просты – принять запрос, обработать и/или отправить к СУБД, потом обработать и вернуть ответ. Несмотря на то что большая часть кода выполняется в rphost, проблем с ними не так много, как кажется.

По сути дела, проблем всего две:

  • Сеансы падают.
  • Съедают память.

В случае (1) если проблема разовая, то ничего страшного в этом нет. Менеджер кластера просто перекинет сеансы на другой рабочий процесс. Если регулярно повторяется, то нужно включить технологический журнал 1С , посмотреть на каком участке кода «падает» процесс, и переписать этот участок кода либо долго и мучительно регистрировать в 1С ошибку в платформе.

В случае (2) нужно просто настроить как лимиты памяти на вызов, так и перезапуск рабочих процессов. Как работает, лично не проверял, есть предположение, что не всегда.  Найти сеанс, который «съел» памяти больше лимита, убить сеанс.

Установка и запуск

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

Нужно бы еще отдельно отметить расположение файлов srvinfo – это каталог, который обычно находится в C:\ Program Files\1cv8\srvinfo. Бытует мнение, что «сервер 1С не требователен к диску, и ему не нужно много места». Так вот, все это ерунда, если у вас включен полный журнал регистрации. Конечно, диск, такой как на сервере СУБД, не нужен, но сам журнал может занять достаточно много места и создавать существенную дисковую нагрузку.

Администрирование

По администрированию особо, наверное, отметить нечего – лишь несколько мелких замечаний из опыта:

  •  Признаком неработоспособности менеджера кластера является невозможность получения списка сеансов в течение нескольких секунд – в этом случае нужно сразу принимать решение об остановке кластера серверов (при этом нужно не забыть «убить» процесс rmngr руками).
  • Если сервер 1С запустить раньше сервера MS SQL, могут перестать работать фоновые задания.
  • Если рабочий процесс добавлен (для 8.2), это еще не значит, что он запустился.
  • Если сервер «не поднимается», нужно чистить папку srvinfo и добавлять в него все базы заново, поэтому резервную копию изначальной srvinfo лучше бы иметь.

Вот кратко и все по проблемным ситуациям. Как видим, большинство проблем возникает из-за особенностей 1С, о которых нужно знать и их учитывать.

Нужна безотказная работа 1С? мы знаем как это сделать. Подробнее [email protected]

0 ответы

Ответить

Хотите присоединиться к дискуссии?
Приглашаем поучаствовать!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *