Журнал регистрации в «1С:Предприятии» — это один из наиболее критичных компонентов системы с точки зрения администрирования. В нем фиксируются все действия пользователей, ошибки конфигурации и системные события. Однако в крупных инфраструктурах, где развернут отказоустойчивый кластер из нескольких серверов, обеспечение непрерывной работы сервиса журнала регистрации (ЖР) становится нетривиальной задачей.
В этой статье мы подробно разберем, как ведет себя сервис журнала регистрации при падении одного из серверов кластера, проанализируем результаты реальных тестов, научимся правильно настраивать Требования назначения функциональности (ТНФ) и рассмотрим архитектурные нюансы хранения файлов логов.
---
Рассмотрим стандартную ситуацию: в кластере работают несколько центральных серверов приложений. Настроена отказоустойчивость, используется старый (текстовый) формат хранения журнала. Администратор ограничил запись журнала регистрации рамками одного конкретного сервера.
Возникает закономерный вопрос: куда будет записываться журнал регистрации, если этот единственный сервер внезапно выйдет из строя (например, из-за аппаратного сбоя)?
Существует несколько ошибочных мнений:
Давайте разберем, как система ведет себя на самом деле и как настроить кластер для идеальной и бесперебойной работы.
---
Для управления распределением сервисов по рабочим серверам в кластере 1С используются требования назначения функциональности. Чтобы журнал регистрации продолжал записываться при выходе из строя основного сервера, нам необходимо правильно сконфигурировать ТНФ для Сервиса журналов регистрации на всех серверах кластера.
На основе практических экспериментов выработаны две рабочие схемы настройки.
Этот вариант отлично подходит для простых кластеров из двух серверов:
Назначить. Это жестко указывает системе, что сервис по умолчанию должен запускаться именно здесь.Автоматически. При такой настройке резервный сервер не будет забирать на себя сервис ЖР в штатном режиме, но перехватит его, если основной сервер станет недоступен.Для гибкого управления отказоустойчивостью эксперты рекомендуют использовать приоритеты в ТНФ. Это позволяет четко определить порядок «выживания» сервиса, если серверов в кластере больше двух:
Назначить с приоритетом 1.Назначить с приоритетом 0.При такой конфигурации сервис всегда будет работать на Сервере 1. В случае его аварии кластер мгновенно и безболезненно для сеансов пользователей перенесет сервис ЖР на Сервер 2.
Важное предупреждение: избегайте установки требования Не назначать для сервиса ЖР на резервных серверах. Если на основном сервере будет стоять Назначить, а на резервном — Не назначать, то при падении основного сервера кластер полностью потеряет работоспособность. Платформа требует обязательного наличия активного сервиса ЖР для авторизации пользователей. Если резервному серверу запрещено его запускать, новые пользователи просто не смогут войти в базу данных.
---
Проанализируем еще одну важную техническую деталь. Предположим, произошла авария, Сервер 1 отключился, и сервис ЖР успешно мигрировал на Сервер 2. Спустя некоторое время Сервер 1 починили и вернули в кластер.
Вернется ли сервис обратно на более приоритетный Сервер 1 автоматически? Нет, не вернется.
В платформе 1С реализован так называемый эффект «прилипания» активных сервисов. Кластер не будет лишний раз прерывать работу пользователей для обратного переноса службы. Сервис ЖР останется работать на резервном сервере до тех пор, пока системный администратор вручную не выполнит команду полного применения требований назначения функциональности в консоли администрирования кластера (или не сделает это программно во время технологического окна с помощью утилиты командной строки rac).
---
Настраивая отказоустойчивость, мы должны помнить о важной архитектурной особенности платформы 1С версии 8.3. «Сервис журналов регистрации» относится к категории мигрирующих сервисов без встроенной репликации данных (тип «Перенос–»).
Это приводит к следующему поведению системы:
srvinfo на диске этого сервера.srvinfo на диске Сервера 2.В результате ваш журнал регистрации оказывается «разорванным» на два физических файла, находящихся на разных машинах. Объединить файлы нового формата (базы данных SQLite с расширением .lgd) простым копированием невозможно — это приведет к повреждению структуры данных.
Как решать проблему разделения логов в Enterprise-сегменте?
Для крупных высоконагруженных систем стандартным решением является отказ от чтения журнала стандартными средствами 1С. Вместо этого настраивается непрерывная трансляция записей ЖР во внешние специализированные базы данных (например, Elasticsearch, Logstash, Kibana (стек ELK) или ClickHouse) с помощью легких внешних утилит-парсеров, работающих в реальном времени.
---
Если вы используете новые версии платформы, то проблема разрозненных файлов решена на уровне ядра системы. В платформу был добавлен полноценный отказоустойчивый сервис журнала регистрации.
Рассмотрим принципы его работы:
ВыгрузитьЖурналРегистрации() разработчик может проверить свойство ДанныеАктуальны. Если синхронизация после сбоя еще не завершилась, свойство вернет Ложь.Разберем пример кода для безопасного программного анализа логов в новых версиях платформы:
ПараметрыВыгрузки = Новый Структура;
ТаблицаЛогов = Новый ТаблицаЗначений;
// Выгружаем события за последний час
ПараметрыВыгрузки.Вставить("НачалоПериода", ТекущаяДата() - 3600);
ВыгрузитьЖурналРегистрации(ТаблицаЛогов, ПараметрыВыгрузки);
// Проверяем, успели ли синхронизироваться узлы кластера после возможного сбоя
Если ПараметрыВыгрузки.Свойство("ДанныеАктуальны") И Не ПараметрыВыгрузки.ДанныеАктуальны Тогда
ЗаписьЖурналаРегистрации("АдминистрированиеКластера",
УровеньЖурналаРегистрации.Предупреждение, , ,
"Внимание! Данные журнала регистрации на текущем узле могут быть неполными из-за идущей синхронизации.");
КонецЕсли;
Важное ограничение: встроенное дублирование и синхронизация в новых версиях работают только для старого (текстового) формата хранения журнала.
---
Многие администраторы задаются вопросом: стоит ли переходить на новый формат хранения ЖР (база данных SQLite с расширением .lgd)? Практика показывает, что для высоконагруженных и отказоустойчивых кластеров старый текстовый формат предпочтительнее по следующим причинам:
rmngr.exe) база данных SQLite часто повреждается (битые транзакции, заблокированные таблицы). После этого ЖР просто перестает открываться. Старый текстовый формат лишен этого недостатка — система всегда может просто дописать новые строки в конец текстового файла.rmngr.exe начинает утилизировать 100% процессора, замедляя работу всего кластера. Использование текстового формата решает эту проблему производительности.Таким образом, сочетание старого формата хранения журнала регистрации и грамотно настроенных приоритетов требований назначения функциональности гарантирует стабильную, быструю и отказоустойчивую работу вашей системы 1С.