Обеспечение непрерывной работы информационных систем является одной из ключевых задач в современном бизнесе. Для пользователей 1С:Предприятия 8.3, особенно в условиях критичных бизнес-процессов, простои крайне нежелательны. В связи с этим возникает необходимость организации резервирования кластера 1С. Рассмотрим сценарий, при котором требуется настроить два центральных сервера 1С в рамках одного кластера, где один из них является основным и предпочтительным для работы пользователей, а второй — резервным, активирующимся только при недоступности основного. Основная сложность заключается в том, чтобы сделать этот процесс максимально автоматизированным, учитывая особенности каналов связи и архитектуры 1С.
Представим типовую ситуацию: у нас развернут кластер 1С:Предприятия 8.3 с двумя центральными серверами. Первый сервер, который мы обозначим как ОсновнойСервер1C, физически расположен близко к основным пользователям, обеспечивая им высокую скорость доступа по локальной сети. Второй сервер, РезервныйСервер1C, находится удаленно и доступен по интернет-каналу, который значительно уже и медленнее, чем локальный. Руководство требует минимизировать простои, поэтому РезервныйСервер1C должен вступать в работу немедленно, если ОсновнойСервер1C выходит из строя, но при этом пользователи не должны подключаться к нему без крайней необходимости, чтобы не перегружать узкий канал.
В процессе анализа данной задачи мы рассмотрим несколько подходов к решению, проанализируем их преимущества и недостатки, а также укажем на важные аспекты, которые необходимо учитывать при реализации подобной схемы резервирования.
Перед погружением в технические детали настройки, важно обратить внимание на несколько фундаментальных моментов, которые часто упускаются, но критически влияют на общую стабильность и эффективность системы резервирования:
Автор вопроса справедливо отмечает, что канал до РезервногоСервер1C является «узким». Это не просто неудобство, а потенциальный источник серьезных проблем. При полном переключении всех пользователей на резервный сервер через такой канал, производительность работы может значительно упасть, делая работу невозможной или крайне затруднительной. Важно понимать, что резервирование в этом случае обеспечивает только доступность системы, но не гарантирует приемлемую скорость работы. Рекомендуется тщательно оценить максимальную пропускную способность канала и количество одновременно работающих пользователей, чтобы понять, насколько длительной и эффективной будет работа в аварийном режиме. Возможно, это решение подходит только для краткосрочного периода восстановления ОсновногоСервера1C.
В контексте кластера 1С:Предприятия существует понятие «уровня отказоустойчивости» для рабочих процессов (rphost). Уровень «0», как упомянуто в исходной проблеме, означает, что при сбое отдельного рабочего процесса на одном из серверов его функции не будут автоматически переданы другому рабочему процессу на этом же или другом сервере кластера. Это может приводить к отключению пользователей, чьи сеансы обслуживались упавшим процессом. Для достижения более высокой отказоустойчивости и бесшовности работы, особенно при наличии нескольких рабочих серверов в кластере, рекомендуется устанавливать уровень отказоустойчивости «1» или выше. Это означает, что для каждого рабочего процесса будет создан резервный экземпляр, готовый принять нагрузку в случае сбоя. Для этого требуется наличие дополнительных рабочих процессов на разных серверах кластера, что, в свою очередь, увеличивает потребление ресурсов.
Независимо от того, насколько хорошо зарезервирован кластер серверов 1С, вся система будет уязвима, если не зарезервирована база данных. Автор подтверждает, что SQL зарезервирован, что является правильным подходом. Мы должны помнить, что отказоустойчивость СУБД (например, SQL Server AlwaysOn Availability Groups, PostgreSQL Streaming Replication) является краеугольным камнем всей архитектуры отказоустойчивости информационной системы 1С.
Одним из наиболее прямолинейных и эффективных способов обеспечить автоматическое переключение на уровне клиентского приложения является указание нескольких адресов центральных серверов 1С в строке соединения. Этот механизм встроен в клиентскую часть 1С:Предприятия и не требует дополнительного программного обеспечения или сложных настроек кластера.
В файле публикации (для веб-клиента), или в ярлыке запуска (для тонкого/толстого клиента), или в диалоге добавления/изменения информационной базы в клиентском приложении 1С:Предприятия, мы можем использовать параметр Srvr для указания списка адресов центральных серверов. Адреса следует перечислять через запятую.
Пример строки соединения для файла запуска или настройки информационной базы:
Srvr="ОсновнойСервер1C:1541,РезервныйСервер1C:1541";Ref="ИмяВашейБазы";Usr="Пользователь";Pwd="Пароль";
В данном примере ОсновнойСервер1C:1541 — это сетевой адрес (DNS-имя или IP-адрес) и порт нашего основного центрального сервера. РезервныйСервер1C:1541 — соответственно, адрес и порт резервного сервера. Если порт не указан, по умолчанию используется стандартный порт 1541.
Когда клиентское приложение 1С запускается, оно пытается установить соединение с серверами кластера в том порядке, в котором они указаны в строке Srvr.
ОсновнойСервер1C:1541.ОсновнойСервер1C оказывается неудачной (например, сервер недоступен, служба 1С не запущена, или произошел сетевой сбой, мешающий доступу), клиент автоматически прекращает попытку с этим сервером.РезервныйСервер1C:1541 — и пытается установить соединение с ним.РезервныйСервер1C успешно, пользователь подключается к информационной базе через этот резервный сервер.Таким образом, первый сервер в списке имеет высший приоритет. Это позволяет добиться желаемого поведения: пользователи всегда будут пытаться подключиться к быстрому основному серверу, и только при его недоступности автоматически переключатся на резервный, работающий через узкий канал.
После того как ОсновнойСервер1C будет восстановлен и станет доступен, текущие сеансы пользователей, работающие на РезервномСервер1C, продолжат функционировать там. Для того чтобы пользователи снова начали работать с ОсновнымСервером1C, им потребуется перезапустить свои клиентские приложения 1С. При следующем запуске клиент снова попытается подключиться к первому серверу в списке (ОсновнойСервер1C) и, найдя его доступным, установит с ним соединение.
Требования назначения функциональности (ТНФ) — это мощный инструмент администрирования кластера 1С, позволяющий детально регулировать, какие типы функциональности (например, клиентские соединения, фоновые задания, внешние соединения, COM-соединения) могут быть назначены на конкретные рабочие процессы или серверы кластера. Этот метод позволяет более тонко управлять распределением нагрузки и ролями серверов.
На ОсновномСервере1C мы устанавливаем ТНФ, которое разрешает клиентские соединения. Например, мы можем создать требование с именем "ОсновнойСерверДляКлиентов" и назначить его на ОсновнойСервер1C, указав тип назначения "Клиентские соединения, назначать".
На РезервномСервере1C можно изначально установить ТНФ, которое запрещает клиентские соединения, либо делает его менее приоритетным. Это предотвратит случайные подключения пользователей к резервному серверу, пока основной работает. Если на резервном сервере должны выполняться фоновые задания или другие служебные процессы (например, для поддержания репликации данных или актуализации отчетов), мы можем создать отдельные ТНФ для этих целей и разрешить их выполнение.
В случае падения ОсновногоСервера1C, администратор может оперативно зайти в консоль администрирования кластера 1С и изменить ТНФ на РезервномСервере1C. Например, деактивировать запрещающее клиентские соединения ТНФ и/или активировать разрешающее. Этот подход дает полный контроль и позволяет администратору убедиться в готовности резервного сервера перед тем, как на него хлынет поток пользователей. Однако он требует ручного вмешательства и может привести к небольшому простою во время выполнения операции.
Для достижения максимальной автоматизации можно разработать скрипт, который будет мониторить состояние ОсновногоСервера1C и, в случае его недоступности, программно изменять ТНФ на РезервномСервере1C. 1С:Предприятие предоставляет для этого службу удаленного администрирования кластера (RAS). Скрипт может быть написан на PowerShell, VBScript или даже на встроенном языке 1С через COM-соединение с кластером.
ОсновнымСервером1C по порту 1541, или выполнить простой запрос через RAS.ОсновнойСервер1C становится недоступным после нескольких последовательных проверок, скрипт инициирует процедуру переключения.РезервномуСервер1C (или к любому доступному центральному серверу, где работает RAS) и с помощью методов объекта COMConnector (или напрямую через командную строку утилиты rac) изменяет ТНФ для РезервногоСервер1C, разрешая на нем клиентские соединения.ОсновногоСервера1C, скрипт может автоматически вернуть ТНФ РезервногоСервер1C в исходное состояние (запретить клиентские соединения), чтобы пользователи снова переподключались к основному.Этот пример демонстрирует, как можно использовать объект COMConnector для управления кластером из среды 1С. В реальной системе такой скрипт скорее всего будет запускаться как отдельное приложение или служба на другом сервере для большей надежности.
// Пример использования COMConnector для программного изменения ТНФ
// Этот код может быть частью внешней обработки или регламентного задания,
// запущенного на отдельном сервере или в надежной среде.
// Важно: для работы необходимо, чтобы на машине, где выполняется код, был установлен COMConnector 1С.
// Параметры подключения к кластеру
ИмяХостаRAS = "server_ras_host:port"; // Адрес и порт центрального сервера или службы RAS
ИмяКластера = "НашКластерПредприятия";
ПарольАдминистратораКластера = "SuperSecretPassword";
ИмяРабочегоСервераДляИзменения = "РезервныйСервер1C:1541";
ИмяТребованияКлиентскихСоединений = "КлиентскиеСоединенияРазрешены"; // Имя вашего ТНФ для клиентских соединений
Попытка
// Создаем объект для подключения к кластеру
МенеджерКластеров = Новый COMОбъект("V83.COMConnector");
МенеджерКластеров.Connect(ИмяХостаRAS);
// Получаем список кластеров и ищем нужный
НайденныйКластер = Неопределено;
Для Каждого Кластер Из МенеджерКластеров.GetClusters() Цикл
Если Кластер.Name = ИмяКластера Тогда
НайденныйКластер = Кластер;
Прервать;
КонецЕсли;
КонецЦикла;
Если НайденныйКластер = Неопределено Тогда
Сообщить("Кластер '" + ИмяКластера + "' не найден.");
Возврат;
КонецЕсли;
// Подключаемся к кластеру
НайденныйКластер.Connect(ПарольАдминистратораКластера);
// Находим целевой рабочий сервер (РезервныйСервер1C)
НайденныйРабочийСервер = Неопределено;
Для Каждого РабочийСервер Из НайденныйКластер.GetWorkingServers() Цикл
Если РабочийСервер.Name = ИмяРабочегоСервераДляИзменения Тогда
НайденныйРабочийСервер = РабочийСервер;
Прервать;
КонецЕсли;
КонецЦикла;
Если НайденныйРабочийСервер = Неопределено Тогда
Сообщить("Рабочий сервер '" + ИмяРабочегоСервераДляИзменения + "' не найден в кластере.");
// Если требование не найдено, можно его создать или использовать другой механизм
// Например, использовать свойство РабочийСервер.ClientConnectionsAllowed = Истина;
// Однако более гибко работать именно с именованными требованиями.
Возврат;
КонецЕсли;
// Ищем ТНФ для клиентских соединений и изменяем его
НайденноеТребование = Неопределено;
Для Каждого Требование Из НайденныйРабочийСервер.Requirements Цикл
Если Требование.Name = ИмяТребованияКлиентскихСоединений Тогда
НайденноеТребование = Требование;
Прервать;
КонецЕсли;
КонецЦикла;
Если НайденноеТребование = Неопределено Тогда
Сообщить("Требование '" + ИмяТребованияКлиентскихСоединений + "' не найдено на рабочем сервере.");
Возврат;
КонецЕсли;
// Изменяем свойство Enabled требования
// Здесь должна быть логика проверки состояния ОсновногоСервера1C
// Если ОсновнойСервер1CНедоступен Тогда
// НайденноеТребование.Enabled = Истина; // Разрешаем клиентские соединения на резервном
// Иначе
// НайденноеТребование.Enabled = Ложь; // Запрещаем, если основной доступен
// КонецЕсли;
НайденноеТребование.Enabled = Истина; // Для примера, всегда включаем
НайденныйРабочийСервер.Update(); // Применяем изменения
Сообщить("Требование '" + ИмяТребованияКлиентскихСоединений + "' на сервере '" + ИмяРабочегоСервераДляИзменения + "' успешно изменено.");
Исключение
Сообщить("Произошла ошибка при работе с кластером: " + ОписаниеОшибки());
КонецПопытки;
Важно подчеркнуть, что данный пример кода является концептуальным. Для его использования в продуктивной среде потребуется более сложная логика проверки доступности ОсновногоСервера1C, обработка ошибок, журналирование и, возможно, механизм подтверждения действий.
Еще один потенциальный путь с ТНФ — это назначение требований "Клиентские соединения, назначать" на оба сервера, но с разными приоритетами. Мы можем установить более высокий приоритет для ТНФ на ОсновномСервере1C и более низкий на РезервномСервер1C. Теоретически, кластер 1С должен предпочитать назначать новые клиентские соединения на сервер с более высоким приоритетом, если он доступен. Этот подход менее документирован для сценариев чистого аварийного переключения и требует тщательного тестирования для подтверждения желаемого поведения в различных условиях нагрузки и сбоев. Он может быть полезен в сценариях актив-актив с балансировкой, но для строгого актив-пассив лучше подходят первые два подпункта этого метода.
Для создания по-настоящему надежной и устойчивой к сбоям инфраструктуры 1С:Предприятия, помимо рассмотренных базовых методов, мы настоятельно рекомендуем рассмотреть следующие дополнительные аспекты и инструменты:
Это часто недооцениваемый, но критически важный фактор. Все серверы в кластере 1С (центральные серверы, рабочие серверы) и сервер СУБД должны иметь строго синхронизированное время. Разница во времени даже в несколько секунд может приводить к некорректной работе транзакций, проблемам с блокировками, ошибкам кеширования, некорректному поведению регламентных заданий и другим труднодиагностируемым сбоям в работе кластера и баз данных. Используйте NTP-серверы для автоматической синхронизации времени в домене или рабочей группе.
Надежная система мониторинга — это ваши «глаза и уши» в инфраструктуре. Она должна отслеживать не только доступность портов 1С и СУБД, но и ключевые метрики производительности: загрузку CPU, использование оперативной памяти, свободное место на дисках, сетевую активность, количество активных сеансов 1С, ошибки в журналах событий Windows и технологическом журнале 1С. Системы мониторинга (например, Zabbix, Prometheus+Grafana, Nagios) должны быть настроены на оперативное уведомление администраторов о любых отклонениях, что позволит реагировать на проблемы до того, как они станут критическими.
Никакая система резервирования не может считаться надежной без регулярного и полноценного тестирования. Мы должны периодически симулировать различные сценарии сбоев: отключение основного сервера, имитацию сетевых проблем, остановку служб 1С или СУБД. Это позволяет:
Тестирование — это не одноразовая акция, а постоянный процесс.
Для крупных и высоконагруженных систем, а также для обеспечения более гибкого управления трафиком и повышения отказоустойчивости, мы рекомендуем рассмотреть использование аппаратных или программных балансировщиков нагрузки. Балансировщик (такие как Nginx, HAProxy, F5 Big-IP, Kemp LoadMaster) выступает как единая виртуальная точка входа для всех клиентских приложений 1С. Он автоматически:
Такой подход обеспечивает не только отказоустойчивость, но и эффективное масштабирование, позволяя использовать ресурсы обоих центральных серверов (или множества рабочих серверов) в режиме актив-актив. Это идеальное решение, когда требуется распределение нагрузки, а не только холодное резервирование.
В обсуждении возник вопрос о конфликте уникальных идентификаторов (УИДов) объектов при использовании резервного сервера. Важно четко понимать, что в описанном сценарии, когда оба центральных сервера являются частью одного логического кластера 1С:Предприятия и работают с одной и той же информационной базой, проблемы с конфликтами УИДов не возникнет. Система 1С:Предприятия самостоятельно и корректно управляет присвоением УИДов для всех объектов информационной базы, независимо от того, через какой центральный сервер (из того же кластера) был создан или изменен объект. Конфликты УИДов могли бы возникнуть, если бы мы имели дело с двумя совершенно независимыми информационными базами или кластерами, которые пытаются синхронизировать данные без механизмов распределенных информационных баз 1С.
В заключение, организация отказоустойчивого кластера 1С:Предприятия с основным и резервным серверами — это выполнимая задача, которая может быть решена как на уровне клиентских соединений, так и с помощью более сложных механизмов управления функциональностью кластера. Выбор конкретного метода зависит от требований к автоматизации, времени восстановления, доступных ресурсов и квалификации администраторов. В любом случае, комплексный подход, включающий в себя мониторинг, тестирование и резервирование всех компонентов системы, является залогом успеха.