Кластер серверов для 1С

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

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

Архитектура кластера

За работу кластера отвечают три процесса, и понимать их роли полезнее, чем любую схему.

ragent - агент сервера. Запускается вместе с системой, стартует остальные процессы и ведёт список кластеров, которые живут на этой машине. Сам прикладной код не исполняет.

rmngr - менеджер кластера. Управляет работой кластера: распределяет соединения, следит за состоянием, ведёт служебные сервисы. Прикладной код тоже не исполняет.

rphost - рабочий процесс. Вот он и делает работу: исполняет код конфигурации, обслуживает клиентские соединения, держит данные сеансов. Именно rphost съедает память, и именно к нему относится большинство настроек, из-за которых потом спорят на планёрках.

Клиент подключается не к базе напрямую, а к кластеру: указывает имя сервера и порт. Дальше кластер сам решает, какой рабочий процесс возьмёт соединение, и при необходимости перекидывает нагрузку. Из-за этого одну и ту же базу можно обслуживать несколькими машинами, а можно одной - для приложения ничего не меняется.

Реестр кластера - список серверов, баз, сеансов и настроек - хранится и синхронизируется отдельно. За это отвечают серверы с признаком центрального.

Если нужен разбор самого понятия и полного состава механизмов платформы, он у нас в отдельном материале - что такое кластер серверов 1С. Здесь дальше идёт практика проектирования.

В чем отличия центрального и рабочего сервера?

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

Это место, где чаще всего возникает путаница, поэтому разложим по полочкам.

Отсюда два практических следствия.

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

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

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

Какой уровень отказоустойчивости при проектировании серверов 1С выбрать?

Здесь в старых материалах гуляет ошибка, которую стоит проговорить прямо.

Уровень отказоустойчивости - это число серверов, которые могут выйти из строя без аварийного завершения пользовательских сеансов. Не «уровень защиты от нагрузки», не абстрактная шкала качества. Просто счётчик допустимых отказов.

Из определения следует главное правило:

Значение «0» означает, что резервирования нет. Читать его как «режим для высоконагруженных систем» - распространённая ошибка, и стоит она потом простоя. Если система нагруженная и час простоя считается в деньгах, вам нужен уровень 1 и второй центральный сервер.

У отказоустойчивости есть цена. Чтобы сеанс пережил падение сервера, кластер должен непрерывно копировать данные этого сеанса на резервные серверы. Это дополнительная память и дополнительный сетевой трафик, причём тем больше, чем выше уровень. Ставить уровень «на всякий случай» побольше - плохая идея: вы заплатите ресурсами за защиту, которая вам не нужна.

Как выбирать на практике для небольшой и средней компании:

• Один сервер, 1С встаёт на полчаса раз в год - уровень 0. Честно, без самообмана: с одним сервером резервировать нечего, и любое другое значение просто не заработает.
• Простой в рабочее время бьёт по деньгам - уровень 1 и две машины. Это первый шаг, который реально что-то меняет.
• Уровень 2 и выше - история для крупных внедрений с соответствующим бюджетом. В сегменте малого и среднего бизнеса встречается редко, и обычно раньше упираются в другое узкое место: диски, СУБД или канал.

Отказоустойчивость кластера не заменяет резервное копирование и не спасает от отказа СУБД. Это защита от падения сервера приложений, не более того. Как подбирают вторую машину под эту задачу, разбирали отдельно - резервный сервер кластера 1С.

ПРОФ или КОРП: где вы упрётесь в лицензию

Про это редко пишут в статьях про кластер, а вопрос стоит денег.

Сам по себе кластер работает уже на серверной лицензии уровня ПРОФ. Ограничения там есть, но они про масштаб: число сеансов и число ядер процессора.

А вот часть механизмов, которые как раз и обсуждают, когда говорят «настроим кластер по-взрослому», доступна только в лицензии КОРП:

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

Отсюда практический вывод: если в проекте заложены ТНФ и разнесение сервисов по серверам, а куплен ПРОФ, схема не заработает - и выяснится это обычно на внедрении.

Хорошая новость про деньги: число рабочих серверов в кластере на стоимость серверной лицензии не влияет. Лицензия одна на кластер, а не на каждую машину. Добавить второй сервер под отказоустойчивость дешевле, чем многие ожидают, - платить придётся за железо и клиентские лицензии, но не за вторую серверную. Что именно даёт серверная лицензия и что будет без неё, разобрано в материале про лицензию на сервер 1С.

Как правильно настроить требования назначения функциональности?

Требования назначения функциональности (ТНФ) - механизм, которым администратор говорит кластеру, какие сервисы и какие информационные базы должны работать на каком сервере. Нужен он, когда серверов несколько и они разные.

Типичный сценарий: есть мощная машина под рабочую базу и машина послабее. Через ТНФ вы отправляете на слабую машину фоновые задания и тестовую базу, а рабочие сеансы оставляете на мощной. Без ТНФ кластер распределит нагрузку по своему усмотрению, и тяжёлое регламентное задание вполне может приземлиться туда, где сидят пользователи.

Настраиваются требования в консоли администрирования, на конкретном рабочем сервере. Для каждого требования указывается объект (сеансы, фоновые задания, сервис лицензирования и так далее), тип использования и, при необходимости, значение дополнительного параметра.

Три вещи, о которые спотыкаются:

1. Каждому типу нагрузки нужно куда-то приземлиться. Если для какого-то объекта на всех серверах выставлено «Не назначать», он не поедет никуда, и сервис просто не поднимется. Проверяйте, что для каждого типа нагрузки остался сервер, который её принимает.
2. Порядок требований имеет значение. Правила применяются сверху вниз, первое подошедшее выигрывает.
3. Схему нужно проверить отказом. Выключите по очереди каждый сервер и посмотрите, что происходит с сервисами. Это единственный способ убедиться, что вы построили то, что задумали, а не красивую картинку в консоли.

На что влияют настройки кластера и сервера 1С и как в них не запутаться?

Настроек в консоли много, но регулярно трогают четыре, и все они про память рабочих процессов.

Отдельный параметр - «безопасный расход памяти за один вызов». Ноль в нём задаёт долю от максимального объёма памяти рабочих процессов, по умолчанию 5 %. Многие читают его как «без ограничений», и это ошибка. Логика в том, чтобы один тяжёлый вызов ронял себя, а не весь рабочий процесс вместе с чужими сеансами.

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

И имейте в виду: часть настроек рабочих процессов доступна только в КОРП-лицензии, о чём было выше. В консоли они видны, но не применяются.

Установка серверной части 1С

Порядок стандартный, и на нём редко возникают вопросы, но пара мест стоит внимания.

Перед установкой сверьтесь с документацией по совместимости: связка платформы, операционной системы и СУБД должна быть поддерживаемой. Дальше запускаете установочный файл, отмечаете нужные компоненты (сервер 1С:Предприятия, администрирование сервера), указываете каталог и пользователя, от которого будет работать служба.

После установки настраивается автозапуск службы и подключение к СУБД. Встроенную файловую базу в клиент-серверной схеме не используют - подключаются к внешней СУБД: PostgreSQL, Microsoft SQL Server или другой поддерживаемой.

Дальше - проверка: поднять службу, подключить тестовую базу, зайти клиентом, посмотреть, что сеанс появился в консоли администрирования. И только потом пускать пользователей. Пошаговый порядок с проверкой каждого этапа расписан в статье про настройку кластера 1С и проверку его работы.

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

Преимущества и настройка кластера серверов 1С

Что кластер реально даёт:

• Распределение нагрузки. Пользователей и фоновые задания можно развести по разным машинам, и тяжёлый отчёт перестаёт тормозить весь отдел. Механика распределения - в разборе про балансировку нагрузки кластера 1С.
• Живучесть при отказе. С уровнем отказоустойчивости от единицы падение одного сервера перестаёт быть остановкой работы.
• Управляемость. Через ТНФ вы решаете, что где выполняется, а не надеетесь на удачу.
• Масштабирование без переезда. Выросли - добавили сервер в кластер, а не переносили базу на новое железо в выходные.

Чего кластер не даёт - тоже стоит сказать. Он не ускорит медленные запросы, не исправит неудачную конфигурацию и не компенсирует слабую СУБД. Если 1С тормозит на одном пользователе, второй сервер не поможет.

Настройку обычно делают штатные инженеры по документации. Если своих компетенций нет, берут подрядчика - и вот здесь стоит договориться на берегу: акт выполненных работ, описание получившейся схемы и гарантийные обязательства. Кластер, настроенный «как-то так» и не задокументированный, через год превращается в чёрный ящик, который страшно трогать.

Оптимизация высоконагруженных систем

Сигнал, что пора заниматься производительностью, обычно приходит от пользователей раньше, чем из мониторинга: жалобы на зависания, вылеты сеансов, «отчёт стал считаться полчаса».

Порядок работы, который экономит время:

1. Сначала измерить, потом крутить. Аудит: какие запросы выполняются дольше всего, где ошибки в базе, хватает ли памяти и дисковой производительности. Технологический журнал и замер производительности в конфигураторе дают куда больше, чем перебор настроек наугад.
2. Проверить очевидное. Антивирус, который сканирует файлы базы, неотключённые полнотекстовый поиск и лишние регламентные задания, устаревшая платформа - всё это чинится быстро и почти бесплатно, а встречается чаще, чем хочется.
3. Разобраться с базой. Тестирование и исправление через конфигуратор, пересчёт итогов, актуальная статистика в СУБД. Перед любыми исправлениями - резервная копия, без вариантов.
4. И только потом - железо и кластер. Добавлять серверы имеет смысл, когда вы понимаете, во что упираетесь. Иначе легко купить процессоры, когда узкое место в дисках. На что смотреть в конфигурации, разобрано в материале про железо для сервера 1С.

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

Когда кластер не нужен

Честный раздел, которого обычно не хватает.

• Пользователей мало и все в одном офисе. До нескольких десятков активных пользователей типовая связка «один сервер + нормальная СУБД» работает предсказуемо. Кластер из одной машины вы получите автоматически, отдельных телодвижений он не требует.
• Нет второго сервера. Уровень отказоустойчивости выше нуля без второй машины не заработает, сколько его ни выставляй.
• Куплен ПРОФ, а в плане ТНФ и профили безопасности. Схема упрётся в лицензию, см. раздел про КОРП.
• Проблема в СУБД или дисках. Кластер серверов приложений её не лечит. Сначала диагностика, потом архитектура.
• Нет того, кто это будет сопровождать. Кластер добавляет точек отказа и требует внимания. Если администрировать его некому, одна хорошо настроенная машина надёжнее двух заброшенных.

Короткие ответы

Чем центральный сервер отличается от рабочего?
Центральный - это тот же рабочий сервер с включённым признаком «Центральный сервер». Дополнительно он принимает подключения клиентов и синхронизирует реестр кластера. Отдельная машина под это не нужна.

Что означает уровень отказоустойчивости 1 и чем он отличается от 0?
Уровень 1 - один сервер может выйти из строя, и пользовательские сеансы переедут на оставшийся без перезапуска 1С. Уровень 0 - резервирования нет, при отказе пользователи получат ошибку и будут заходить заново. Для уровня 1 нужно два работающих центральных сервера.

Сколько серверов нужно для отказоустойчивого кластера?
На один больше, чем значение уровня отказоустойчивости. Для уровня 1 - два, для уровня 2 - три.

Нужна ли лицензия КОРП для кластера?
Сам кластер работает и на ПРОФ. КОРП нужен для гибких требований назначения функциональности, профилей безопасности, выноса фоновых заданий на отдельный сервер и расширенной отказоустойчивости.

Сколько стоит серверная лицензия на кластер из нескольких машин?
Как на одну: число рабочих серверов в кластере на стоимость серверной лицензии не влияет. Платить придётся за железо и клиентские лицензии.

Можно ли собрать кластер 1С на одной машине?
Да, и в клиент-серверном варианте так и происходит по умолчанию. Кластер - это архитектура платформы, и несколько компьютеров для него не обязательны. Отказоустойчивости в такой схеме, конечно, не будет.

Коротко о главном

Центральный сервер - признак на рабочем сервере, а не отдельная машина. Уровень отказоустойчивости - число серверов, которые могут упасть без потери сеансов, и работающих центральных серверов нужно на один больше. Значение 0 означает, что резервирования нет.

Перед проектированием проверьте две вещи: есть ли у вас вторая машина под отказоустойчивость и какая лицензия куплена. Эти два ответа определяют схему сильнее, чем любые настройки в консоли.