Кластер серверов 1С 8.3 из двух серверов: настройка и сервер лицензирования

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

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

Чего кластер 1С не сделает

Начнём с границ, потому что вокруг отказоустойчивости 1С много завышенных ожиданий.

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

Дальше начинается то, чего кластер не умеет:

• СУБД он не резервирует. PostgreSQL или MS SQL живут отдельно, и если умрёт машина с базой, кластер приложений останется без данных. Резервирование СУБД настраивается своими средствами и стоит отдельных денег.
• Бэкап он не заменяет. Кластер защищает от отказа железа, а не от удалённого документа, шифровальщика или кривого обновления конфигурации.
• Центральный сервер остаётся уязвимым местом, если не позаботиться о нём отдельно - об этом ниже, это и есть та самая вторая половина настройки, которую пропускают.

Три процесса и три порта

Прежде чем настраивать, полезно понимать, что именно вы запускаете. На каждом сервере кластера крутятся три вида процессов, и у каждого своя роль и свой порт.

Клиент подключается по цепочке: сначала к порту 1541, получает адрес свободного рабочего процесса, дальше общается с ним напрямую по порту из диапазона 1560-1591. Отсюда практический вывод для брандмауэра: открыть только 1540 и 1541 мало, без диапазона рабочих процессов клиенты будут доходить до кластера и молча спотыкаться на последнем шаге.

До начала: что проверить

Половина проблем с двухсерверным кластером лечится до первого клика в консоли.

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

Настройка кластера из двух серверов

Схема простая: берём два сервера приложений и добавляем второй в кластер первого.

Шаг 1. Установить платформу. На обе машины ставим «1С:Предприятие 8.3» с компонентой сервера, одной и той же версии. Служба агента должна подняться и остаться в работе.

Шаг 2. Выбрать образцовый сервер. Один из серверов будет тем, чей кластер мы оставляем. Назовём его srv1.

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

Шаг 4. Добавить второй сервер в кластер первого. В консоли администрирования открываем кластер srv1 и добавляем в список рабочих серверов srv2.

Шаг 5. Отметить оба сервера центральными. В свойствах добавленного сервера ставим флажок «Центральный сервер». Это тот шаг, без которого весь остальной результат рассыпается, - почему, разберём в следующем разделе.

Шаг 6. Задать уровень отказоустойчивости. В свойствах кластера ставим значение 1.

Шаг 7. Открыть порты. На обеих машинах: 1540, 1541 и диапазон 1560-1591.

Шаг 8. Проверить. Документация тут не поможет, нужен натурный тест: подключите пользователей, погасите srv2 и посмотрите, что произошло с сеансами. Потом верните srv2, погасите srv1 и повторите. Кластер, который не проверяли отключением, считается ненастроенным. Что ещё стоит посмотреть после сборки - в статье настройка кластера 1С и проверка работы.

Уровень отказоустойчивости и его главная ловушка

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

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

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

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

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

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

Сервер лицензирования: зачем его выносят отдельно

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

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

Два нюанса, на которых спотыкаются чаще всего:

Аппаратные ключи HASP на выделенном сервере лицензирования не поддерживаются. Если у вас клиентские лицензии в виде USB-ключей, схема с отдельной машиной под лицензии для них не сработает - она рассчитана на программные лицензии.

Порядок выдачи не тот, которого ждут. Если в сети параллельно есть другие источники лицензий (тот же локальный HASP на рабочем месте), сервер лицензирования начнёт раздавать свои программные лицензии в последнюю очередь, когда остальные способы исчерпаны. Лицензии в итоге уходят не с той машины, с которой вы планировали, а картина в отчётах не сходится с ожиданиями.

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

ПРОФ или КОРП: половина настроек вам недоступна

Про это молчит почти вся выдача по настройке кластера, а вопрос практический.

Кластер запускается на серверной лицензии уровня ПРОФ, и уровень отказоустойчивости на ней задать можно. Но инструменты, которые превращают два сервера в осмысленно работающую пару, относятся к функциональности КОРП: требования назначения функциональности (та самая ТНФ, которой разводят фоновые задания и сеансы по серверам), профили безопасности, режим распределения нагрузки, управление потреблением ресурсов. На ПРОФ свойства кластера должны оставаться в значениях по умолчанию.

Что из этого следует. Малому и среднему бизнесу на ПРОФ двухсерверный кластер стоит рассматривать как защиту от отказа железа - и на этом остановиться. Тонкая настройка распределения нагрузки на ПРОФ либо не даст эффекта, либо выведет вас за рамки условий лицензии. Разбор ТНФ, профилей безопасности и остальных параметров - в статье устройство кластера серверов 1C.

Что менялось от версии к версии

Механизмы отказоустойчивости появлялись в платформе постепенно, и это объясняет, почему советы из старых инструкций часто не работают.

Практический смысл таблицы один: инструкции, написанные под 8.2, для 8.3 не годятся, и наоборот. Если нашли в интернете руководство без указания версии - проверяйте, о чём оно, прежде чем повторять шаги.

Сколько рабочих процессов держать

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

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

Отдельно про ОС: кластер 1С работает и на Windows Server, и на Linux, и выбор чаще определяется тем, на чём живёт СУБД и что умеет обслуживать ваш админ. Сравнение вариантов - в статье Какую ОС выбрать для сервера 1С.

Частые вопросы

Как создать кластер серверов в 1С 8.3?
Установить платформу с компонентой сервера на обе машины, удалить локальный кластер на втором сервере, добавить его в кластер первого через консоль администрирования, отметить оба сервера центральными и задать уровень отказоустойчивости 1. После этого открыть порты 1540, 1541 и 1560-1591 и проверить работу отключением одного из узлов.

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

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

Почему после настройки кластера пользователей всё равно выбивает?
Самая частая причина - центральным отмечен только один сервер. Для уровня отказоустойчивости 1 центральных серверов должно быть два. Вторая по частоте - закрытый диапазон портов 1560-1591 в брандмауэре.

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