При построении отказоустойчивых систем на базе 1С:Предприятие 8.3 системные администраторы часто сталкиваются с вопросом: каким образом клиентское приложение узнает о существовании резервного сервера и как происходит процесс переподключения при выходе из строя основного узла? Разберем детально механизмы сетевого взаимодействия, логику работы менеджеров кластера и способы устранения типовых ошибок связи.
Для того чтобы клиентское приложение (тонкий или толстый клиент) знало о наличии нескольких потенциальных точек входа в кластер, мы должны использовать специальный синтаксис в строке подключения. Рассмотрим, как это выглядит на практике. Вместо указания одного имени сервера в поле «Кластер серверов 1С:Предприятия», необходимо перечислить имена всех центральных серверов через запятую.
Проанализируем пример строки соединения для информационной базы:
Srvr="Server1,Server2";Ref="Trade_Base";
В этой ситуации Server1 и Server2 — это имена рабочих серверов, на которых запущены службы ragent и зарегистрированы менеджеры кластера rmngr. Выясним, как ведет себя клиент при такой настройке. При запуске программа последовательно опрашивает указанные адреса. Если первый сервер в списке недоступен по порту 1540, клиент автоматически пробует установить соединение со вторым. Это первый и самый простой уровень обеспечения доступности.
Важно понимать, что в кластере 1С не все серверы равнозначны в каждый конкретный момент времени. Несмотря на то, что у нас может быть два и более «центральных» сервера, один из них всегда является ведущим (Master). Разберем, зачем это нужно. Ведущий менеджер кластера (rmngr) отвечает за управление реестром кластера, распределение сеансов по рабочим процессам и мониторинг состояния других узлов.
Посмотрим, что происходит при аварии ведущего сервера. Остальные менеджеры кластера инициируют процедуру «выборов» нового лидера. Этот процесс занимает несколько секунд. В течение этого времени новые попытки подключения могут завершаться ошибкой, так как кластер временно «обезглавлен». Как только новый rmngr принимает на себя функции ведущего, работа возобновляется. Однако для того, чтобы пользователи, уже находящиеся в системе, не заметили сбоя, необходимо настроить дополнительные параметры.
Просто указать два сервера через запятую недостаточно для полноценной отказоустойчивости. Рассмотрим критически важный параметр кластера — Уровень отказоустойчивости (Fault Tolerance Level). По умолчанию он равен 0.
Проанализируем ситуацию: для работы уровня отказоустойчивости 1 нам требуется как минимум два работающих центральных сервера. В этом случае данные сеанса, хранящиеся на Server1, будут дублироваться на Server2. Если Server1 исчезнет из сети, Server2 уже имеет всю необходимую информацию, чтобы продолжить обслуживание клиента без потери данных.
Часто при настройке отказоустойчивого кластера администраторы сталкиваются с тем, что соединение по IP-адресу работает, а по имени — нет, или наоборот. Разберем двухэтапную логику подключения клиента к кластеру, чтобы выяснить причину.
Шаг 1: Клиент обращается по адресу, указанному в строке соединения (например, 192.168.1.10). Он успешно соединяется с ragent.
Шаг 2: В ответ кластер передает клиенту список рабочих серверов и портов, по которым нужно работать дальше. Эти имена кластер берет из своей внутренней настройки — ветки «Рабочие серверы» в консоли администрирования 1С.
Если в консоли сервер добавлен под коротким именем SERVER-1C, то кластер скажет клиенту: «Продолжай работу по адресу SERVER-1C:1560». Если на компьютере клиента это имя не резолвится через DNS (например, нет нужного DNS-суффикса), возникнет ошибка No such host is known. Даже если вы изначально подключались по IP!
Чтобы избежать этой проблемы, рассмотрим рекомендации:
server1.company.local), либо статические IP-адреса.hosts или корректные записи в DNS.Выясним, как распределяются пользователи между серверами. В кластере 1С встроен балансировщик, который оценивает производительность и загруженность каждого рабочего сервера. При подключении нового клиента менеджер кластера анализирует объем доступной оперативной памяти и количество текущих соединений на каждом узле.
Посмотрим на механизм Требований назначения функциональности. Мы можем гибко настроить, какой сервер за что отвечает. Например, можно жестко закрепить сервис лицензирования за определенным сервером или запретить одному из узлов принимать новые соединения, сохранив его только как резервный для репликации сеансов. Это позволяет тонко настроить работу кластера под конкретное оборудование.
Для корректной работы отказоустойчивого кластера информация о базах, пользователях и настройках должна быть идентична на всех центральных серверах. Разберем, где она хранится. По умолчанию это папка srvinfo в каталоге установки 1С.
В современных версиях 1С (начиная с 8.3.5) механизм синхронизации реестра встроен в саму платформу. Серверы обмениваются изменениями в файлах 1cv8wsrv.lst и 1cv8clust.lst автоматически. Однако для этого критически важно, чтобы службы 1С на всех серверах были запущены от имени пользователя с достаточными правами, и сетевые экраны (firewalls) не блокировали трафик между ними.
Рассмотрев все аспекты, мы можем составить алгоритм настройки надежного подключения:
1540, 1541 и диапазон 1560-1591 для взаимодействия между всеми участниками сети.Таким образом, сетевая работа кластера 1С базируется на интеллектуальном взаимодействии менеджеров, которые направляют клиента на нужные узлы, а отказоустойчивость обеспечивается за счет дублирования управляющих функций и данных сеансов на нескольких физических серверах.