При росте компании и увеличении нагрузки на информационные системы неизбежно встает вопрос обеспечения отказоустойчивости (High Availability) и балансировки нагрузки (Load Balancing) для серверов 1С. Начиная с версии платформы 8.3, компания 1С кардинально изменила механизмы работы кластера серверов по сравнению со старой версией 8.2. Теперь нам больше не нужно использовать общие сетевые папки реестра через нестабильные UNC-пути, так как платформа научилась автоматически реплицировать реестр между центральными серверами кластера.
В этой статье мы подробно и пошагово разберем, как объединить два физических (или виртуальных) сервера под управлением 1С:Предприятие 8.3 в единый отказоустойчивый кластер, как решить классическую ошибку «центральный сервер не аутентифицирован», а также как правильно разделить рабочие и тестовые базы данных без создания дополнительных кластеров на нестандартных портах.
Прежде чем переходить к практическим действиям, давайте разберем ключевые понятия, без понимания которых невозможно построить работающую систему. В платформе 1С 8.3 за отказоустойчивость отвечают два параметра: количество центральных серверов и уровень отказоустойчивости.
Уровень отказоустойчивости — это параметр кластера, определяющий максимальное количество рабочих серверов, одновременный выход из строя которых не приведет к аварийному завершению сеансов подключенных пользователей. Если этот параметр равен 0, то при падении любого сервера пользователи потеряют свои несохраненные данные и сеансы завершатся. Если мы хотим, чтобы система выдерживала падение одного сервера, уровень отказоустойчивости должен быть равен 1.
Связь между количеством центральных серверов и уровнем отказоустойчивости выражается следующей жесткой формулой:
Количество центральных серверов = Уровень отказоустойчивости + 1
Таким образом, для реализации отказоустойчивости уровня 1 нам необходимо иметь как минимум два центральных сервера. Центральный сервер отличается от обычного рабочего сервера тем, что он хранит локальную копию реестра кластера и координирует работу всей системы. Если один центральный сервер выходит из строя, второй берет на себя его функции, обеспечивая непрерывность работы пользователей.
Представим исходную ситуацию: у нас есть два сервера. Назовем их Server1 (основной, где крутятся рабочие базы) и Server2 (вспомогательный, где развернуты тестовые базы). На каждом из них запущена своя служба 1С со своим локальным кластером.
Самая распространенная ошибка системных администраторов — попытка объединить два уже существующих и настроенных кластера. Это приводит к конфликтам реестров. Чтобы объединение прошло успешно, нам необходимо полностью очистить настройки на втором сервере. Выполним следующие действия:
Server2).C:\Program Files\1cv8\srvinfo, в Linux — /home/usr1cv8/.1cv8/1C/1cv8).Server2. Это очистит информацию о старом локальном кластере. Не беспокойтесь за тестовые базы: сами СУБД находятся на сервере баз данных, мы удаляем лишь конфигурационные файлы кластера 1С.Server2 заново. Теперь этот сервер чист и готов к вхождению в состав общего кластера.Пример команд для перезапуска службы в операционной системе Linux:
systemctl stop srv1cv83
rm -rf /home/usr1cv8/.1cv8/1C/1cv8/*
systemctl start srv1cv83
При попытке добавить Server2 в качестве рабочего сервера в консоли администрирования Server1 администраторы часто сталкиваются с ошибкой: «Ошибка изменения параметров рабочего сервера кластера: центральный сервер не аутентифицирован. Выполнение операции на рабочем сервере невозможно».
Давайте выясним причину этой проблемы. Она кроется в безопасности системы. На серверах настроены разные параметры аутентификации администраторов кластера. Чтобы решить эту проблему, выполните следующие рекомендации:
Server1 успешно пингует Server2 по его имени, и наоборот. При необходимости пропишите соответствия IP-адресов и имен в файле hosts на обоих серверах.Пример настройки файла hosts (находится в C:\Windows\System32\drivers\etc\hosts для Windows или /etc/hosts для Linux):
192.168.1.10 Server1
192.168.1.11 Server2
Теперь, когда инфраструктура подготовлена, перейдем к непосредственной настройке в консоли администрирования серверов 1С (MMC-оснастка).
Server1.Server2).Server2 и установите флажок Центральный сервер.После этого начнется процесс автоматической репликации реестра кластера. Файлы конфигурации с первого сервера будут переданы на второй сервер. Теперь оба сервера полноценно координируют работу системы.
У автора исходной темы возник резонный вопрос: как сделать так, чтобы рабочие базы данных крутились в основном на мощном первом сервере, а тестовые базы — на втором сервере, но при этом они находились в рамках одного отказоустойчивого кластера?
Использовать разные локальные кластеры на разных портах (например, 1641) — не лучшее решение, так как это усложняет администрирование и лишает нас преимуществ единой точки входа. Вместо этого в платформе 1С 8.3 предусмотрен штатный мощный механизм: Требования назначения функциональности (ТНФ).
Давайте настроим правила распределения нагрузки. Перейдите в свойства каждого рабочего сервера в консоли администрирования, найдите ветку Требования назначения функциональности и создайте правила:
Для основного сервера (Server1):
Work_DB (имя вашей рабочей базы в кластере).Test_DB (или оставьте пустым для всех остальных баз).Для вспомогательного сервера (Server2):
Test_DB.Work_DB.Благодаря такой настройке, в штатном режиме пользователи рабочей базы будут направляться исключительно на Server1, а пользователи тестовых баз — на Server2. Но если Server1 выйдет из строя (например, отключится питание), сработает правило «Использовать в последнюю очередь», и рабочая база автоматически запустится на резервном Server2.
Как убедиться, что всё настроено верно и балансировка с отказоустойчивостью реально функционируют? Проведем два простых теста.
Тест 1: Анализ активных сеансов в консоли.
Подключитесь пользователями к рабочей и тестовой базам данных. В консоли администрирования перейдите в ветку Сеансы (Sessions). Обратите внимание на колонку Рабочий процесс. Вы должны увидеть, что сеансы рабочей базы привязаны к процессу rphost, запущенному на Server1, а сеансы тестовой базы — к процессу rphost на Server2. Это подтверждает работу требований назначения функциональности.
Тест 2: Эмуляция аварийного завершения работы сервера.
Запустите клиентское приложение 1С:Предприятие под тестовым пользователем в рабочей базе. Выясните по консоли, на каком сервере и в каком процессе rphost находится этот сеанс. Теперь сымитируем аппаратный сбой: принудительно завершим этот процесс на сервере.
Для этого в операционной системе Windows выполните команду принудительного завершения процесса через командную строку (подставив PID нужного процесса):
taskkill /F /PID 1234
Или остановите службу 1С целиком на этом сервере. У пользователя в режиме предприятия на несколько секунд появится крутящийся индикатор ожидания (происходит поиск резервного сервера и переподключение сеанса), после чего работа продолжится в штатном режиме. Пользователь даже не заметит, что его сеанс «переехал» на другой физический сервер, и программа не закроется с ошибкой потери связи.
В завершение необходимо упомянуть крайне важный аспект, о котором часто забывают при проектировании отказоустойчивых систем — лицензирование программных продуктов 1С.
Помните, что каждый сервер, входящий в кластер в качестве рабочего или центрального сервера и запускающий процессы rphost, требует наличия собственной лицензии на сервер 1С:Предприятие. То есть в нашей схеме вам потребуются две серверные лицензии.
Что касается клиентских лицензий: при падении первого сервера пользователи переключатся на второй. Соответственно, второй сервер должен иметь техническую возможность выдать им клиентские лицензии. В связи с этим рекомендуется использовать многопользовательские программные лицензии, активированные непосредственно на каждом из серверов кластера, либо выносить раздачу лицензий на выделенный сервер лицензирования.