Эксперты в подборе IT-оборудования
К обеду база встаёт. Полтораста человек в «Бухгалтерии», проведение документа висит по сорок секунд, в диспетчере задач один rphost.exe держит 20 гигабайт и не отпускает. Первое, что приходит в голову, - поставить перед сервером балансировщик и раскидать людей по машинам.
Балансировщика в привычном смысле у 1С нет. Ни nginx, ни HAProxy между пользователем и кластером не встают: клиент подключается к агенту сервера, а дальше кластер сам решает, какому рабочему процессу отдать это соединение. Ручки, которыми это решение можно изменить, лежат в консоли администрирования кластера - и часть из них заблокирована лицензией уровня ПРОФ.
Разберём, кто внутри кластера принимает решение, какие параметры его меняют, что делать с растущим rphost и в какой момент настройки заканчиваются и начинается железо.
Про балансировщики как класс - Round Robin, L4 и L7, аппаратные и программные - у нас есть отдельный разбор: балансировка нагрузки между серверами. Здесь речь только про внутреннюю механику 1С.
Кластер серверов 1С - это набор рабочих процессов, обслуживающих один и тот же список информационных баз. Работают в нём три службы, и путать их - обычное дело даже у тех, кто кластер уже поднял.
ragent - агент сервера. Служба «Агент сервера 1С:Предприятия», стартует вместе с машиной. Отвечает за то, что этот компьютер вообще состоит в кластере, и ведёт список кластеров, которые на нём живут. Сам пользовательские запросы не обрабатывает.
rmngr - менеджер кластера. Управляет работой кластера: ведёт сеансы, лицензии, журнал регистрации, полнотекстовый поиск и прочие служебные сервисы. Главный менеджер хранит реестр кластера - его конфигурацию и текущее состояние. Компьютер, где работает главный менеджер, и называется центральным сервером.
rphost - рабочий процесс. Вот он и делает работу: обслуживает клиентские приложения, исполняет процедуры серверных модулей конфигурации, ходит в СУБД. Именно rphost вы видите в диспетчере задач, когда память кончается.
Когда пользователь запускает 1С, соединение приходит на центральный сервер. Тот смотрит статистику загруженности рабочих процессов и направляет клиента к конкретному rphost, который будет его обслуживать. Это и есть штатная балансировка внутри кластера - без внешних сервисов и прокси.
| Процесс | Что делает | Что будет, если упадёт |
|---|---|---|
| ragent | Держит компьютер в составе кластера, ведёт список кластеров | Сервер выпадает из кластера целиком, на нём не запустится ничего |
| rmngr | Сеансы, лицензии, журнал регистрации, служебные сервисы; главный менеджер хранит реестр | Падение главного менеджера роняет кластер; резервные менеджеры на других серверах смягчают удар |
| rphost | Обслуживает соединения пользователей, исполняет серверный код, работает с СУБД | Отваливаются сеансы, которые он обслуживал; остальные продолжают работать |
Отсюда практический вывод про центральный сервер: он не «главный по мощности», он держит реестр. Класть на него же тяжёлые фоновые задания и всех пользователей сразу - плохая идея. Про то, как распределяются роли между машинами, есть отдельный материал про устройство кластера серверов 1С.
Рабочий процесс редко обслуживает что-то одно. По умолчанию один rphost берёт на себя до восьми информационных баз и до 128 соединений. То есть тестовая копия, архивная база пятилетней давности и рабочая «Бухгалтерия» вполне могут жить в одном процессе и делить его память.
Дальше одно накладывается на другое.
Память, которую процесс запросил под тяжёлый запрос, он не спешит возвращать системе - она остаётся у процесса под будущие вызовы. График потребления поэтому растёт ступеньками и почти никогда не падает сам.
Фоновые задания идут в общем потоке с людьми. Ночной обмен, пересчёт итогов, регламентное задание на закрытие месяца - всё это исполняется теми же рабочими процессами. Если задание запустилось в рабочее время, пользователи почувствуют его первыми.
Один неудачный запрос способен утянуть за собой процесс: соединение забирает память под выборку, процесс упирается в предел, и падают все сеансы, которые он обслуживал.
Смотреть, что происходит, надо в консоли администрирования кластера: раздел «Соединения» с колонками захваченных данных и времени вызова, раздел «Сеансы» - там видно, кто держит память и чей вызов идёт дольше остальных. Технологический журнал даст ту же картину подробнее, но начинать проще с консоли.
Перезапуск rphost - это не лечение. Совет «убить процесс и запустить агента заново» встречается в каждом втором обсуждении, и память он действительно освобождает. Только через день ситуация повторится: причина в том, сколько баз и соединений висит на процессе и какой код в них исполняется. Перезапуск покупает вам несколько часов.
Все настройки лежат в консоли администрирования: свойства кластера и свойства рабочего сервера. Ниже - те, что действительно влияют на распределение.
| Параметр | Где | Что делает |
|---|---|---|
| Количество ИБ на процесс | Рабочий сервер | По умолчанию 8. Значение 1 разводит каждую базу в свой rphost: тестовая база перестаёт ронять рабочую |
| Количество соединений на процесс | Рабочий сервер | По умолчанию 128. Уменьшение дробит пользователей по большему числу процессов - авария задевает меньше людей |
| Максимальный объём памяти рабочих процессов | Рабочий сервер | Потолок памяти на все rphost этого сервера, в байтах. Ноль означает «без ограничения» |
| Безопасный расход памяти за один вызов | Рабочий сервер | Предел на один серверный вызов. Превысивший его вызов завершается, процесс продолжает работать - падает один сеанс вместо всех |
| Объём памяти рабочих процессов, до которого сервер считается производительным | Рабочий сервер | Порог, выше которого сервер перестаёт принимать новые соединения и они уходят на соседние машины |
| Режим распределения нагрузки | Кластер | «Приоритет по производительности» - кластер тратит больше памяти ради скорости. «Приоритет по памяти» - экономит память, соглашаясь на меньшую скорость |
| Уровень отказоустойчивости | Кластер | Сколько рабочих серверов могут выйти из строя одновременно, чтобы пользователи не завершились аварийно. Резервирование стоит памяти и процессорного времени |
Прежде чем что-то здесь трогать, дочитайте до следующего раздела: часть этих ручек на лицензии ПРОФ должна оставаться в значениях по умолчанию.
Логика настройки простая: сначала изоляция, потом ограничения. «Количество ИБ на процесс» = 1 и уменьшенное число соединений на процесс дают предсказуемость - вы хотя бы знаете, кто кого утянет. Лимиты по памяти ставятся вторым шагом, когда понятно, сколько процесс реально просит под вашей нагрузкой.
Копировать конкретные пороги памяти из чужих статей бесполезно: они зависят от конфигурации, числа пользователей и объёма базы. Снимите потребление за неделю и отступите от пика вверх.
Половина советов из интернета не заработает на лицензии уровня ПРОФ - и об этом почти нигде не пишут.
С платформ 8.3.12.1852, 8.3.13.1791 и 8.3.14.1592 фирма 1С разделила серверные лицензии. К функциональности КОРП отнесли гибкое управление нагрузкой в кластере: количество ИБ на процесс, объём памяти рабочих процессов, безопасный расход памяти за один вызов, режим распределения нагрузки. Туда же ушли требования назначения функциональности, профили безопасности и механизм управления потреблением ресурсов. На ПРОФ параметры кластера остаются в значениях по умолчанию.
Плюс два численных ограничения ПРОФ, которые бьют по железу напрямую:
Считаются ядра так: на физическом сервере с включённым hyper-threading учитываются физические ядра, на виртуальной машине - виртуальные, то есть столько vCPU, сколько вы выдали гостю.
Что это значит при закупке. Под 1С на лицензии ПРОФ нет смысла брать процессор на 32 ядра: двадцать из них процессы кластера просто не увидят. Деньги честнее вложить в частоту, в память и в быстрый диск под СУБД - на 1С это даёт больше, чем лишние ядра. Мы разбирали это подробно в материале про то, какой процессор выбрать для сервера 1С. А на виртуалке следите за vCPU: под ПРОФ выдавать гостю больше двенадцати бессмысленно.
Что именно даёт КОРП и когда переход окупается, разобрано в статье про лицензию на сервер 1С.
Когда рабочих серверов в кластере больше одного, встаёт вопрос: кто и что на них выполняет. Механизм требований назначения функциональности (сокращённо ТНФ) как раз про это - администратор описывает, какие сервисы и соединения должны работать на каждом рабочем сервере.
Типичный сценарий: увести все фоновые задания на отдельную машину, чтобы ночной обмен и пересчёт итогов не мешали людям. Или наоборот - закрепить клиентские соединения одной тяжёлой базы за сервером помощнее. Требования задаются в консоли администрирования или программно из встроенного языка; в объектах требования перечисляются клиентские соединения с ИБ, фоновые задания, сервис полнотекстового поиска, сервис журнала регистрации и прочие сервисы менеджера.
Механизм относится к функциональности КОРП. Второй рабочий сервер в кластер добавляется и без него, но развести по машинам роли штатно не выйдет: кластер будет раскладывать соединения по своей внутренней статистике загруженности. И ещё одно правило, о котором вспоминают поздно: внутри одного кластера все лицензии - и серверные, и пользовательские - должны быть одного уровня. Смешать КОРП и ПРОФ в одном кластере не получится.
Ловушка, в которую попадают уже после настройки: если требования описаны так, что для какого-то сервиса не нашлось ни одного подходящего сервера, кластер честно сообщит об этом ошибкой и работать не станет. Правило «не назначать» удобно ставить последним, предварительно убедившись, что нужным сервисам есть куда приземлиться.
Ошибка выглядит пугающе, но означает всегда одно: центральному серверу некому отдать ваше соединение. Ниже - что проверять по порядку.
| Что смотрим | Почему сюда |
|---|---|
| Служба «Агент сервера 1С:Предприятия» | Если ragent не поднялся, кластера для клиента не существует. Проверяется первым, занимает полминуты |
| Список рабочих процессов в консоли кластера | Процессы могут числиться, но быть в состоянии «не используется» или «выключен» |
| Свободная память на сервере | rphost не стартует, когда памяти на новый процесс не осталось. Частый случай после того, как выставили жёсткий лимит и забыли про него |
| Порты и брандмауэр | Агент, менеджер и рабочие процессы слушают каждый свой порт. Правило, закрывшее диапазон rphost, даёт ровно эту ошибку |
| Серверные лицензии | Без действующей лицензии сервера рабочий процесс запустится, но обслуживать соединения не будет |
| Журнал регистрации и технологический журнал | Если процессы падают циклически, причина видна там: конкретный вызов, база, память |
Порядок в таблице неслучаен: сверху вещи, которые проверяются за минуту, снизу - те, что требуют времени. Перезапуск служб помогает почти всегда и почти всегда ненадолго, поэтому после восстановления работы стоит вернуться к нижним строкам.
Параметры кластера перераспределяют то, что есть. Если ресурсов не хватает физически, они лишь меняют, кому станет плохо первым.
Признаки, что вы упёрлись в железо, а не в настройки: память на сервере занята полностью при любых лимитах; процессор держится под сотню без явных тяжёлых запросов; дисковая очередь на томе СУБД растёт в рабочие часы; пользователи жалуются не на отдельные документы, а на всё сразу.
Что помогает в этой точке:
Подобрать конфигурацию под конкретное число пользователей и объём базы помогает материал про железо для сервера 1С. Если планируете резервирование, посмотрите разбор про резервный сервер в кластере 1С - там про то, во что обходится уровень отказоустойчивости.
Перед веб-сервером публикации - да, если пользователи работают через веб-клиент: тогда балансировщик распределяет HTTP-запросы между несколькими веб-серверами. До кластера 1С он не достаёт: соединения между рабочими процессами внутри кластера всё равно раскладывает центральный сервер.
Число задаётся косвенно, через параметры «количество ИБ на процесс» и «количество соединений на процесс»: кластер поднимает столько процессов, сколько нужно под текущую нагрузку. На 64-разрядном сервере ограничения в 2 ГБ на процесс нет, поэтому плодить процессы ради обхода лимита памяти, как делали на 32-разрядных системах, больше не требуется.
Если памяти на сервере хватает с запасом - производительность. Если сервер к вечеру подходит к потолку памяти - приоритет по памяти даст стабильность ценой скорости. Параметр относится к функциональности КОРП.
Как временная мера - да, ночной перезапуск снимает накопленную память. Как решение - нет: он маскирует причину, будь то тяжёлый код, отсутствие изоляции баз или нехватка памяти.
Нет. Второй сервер добавляет отказоустойчивость и снимает потолок по памяти и соединениям, а скорость отдельного документа определяется процессором, СУБД и качеством кода конфигурации.
Обычно нет. До нескольких десятков человек выигрыш даёт один правильно собранный сервер с СУБД на быстрых дисках, и обслуживать его проще. Кластер добавляет сложности, которую нужно кому-то поддерживать.
По теме: настройка кластера серверов 1С и проверка его работы.
Собираете сервер под кластер 1С и не знаете, сколько памяти и ядер закладывать?
Инженеры ITTELO помогут посчитать конфигурацию под реальное число пользователей и объём базы: память под рабочие процессы с запасом на рост, процессор с учётом ограничений вашей лицензии, диски под СУБД. Соберём и протестируем под задачу перед отгрузкой, отдадим с гарантией - на рынке серверов мы 11+ лет.
Посмотреть сервер для кластера 1с в каталоге или обсудить задачу: +7 (800) 551-80-12, info@ittelo.ru.
