Автоматический ввод резерва (АВР) в 1С: настройка отказоустойчивости

АВР (автоматический ввод резерва) в 1С — это набор мер, при которых отказ одного узла не останавливает работу: нагрузку подхватывает резервный узел без ручного вмешательства. Сделать АВР в 1С означает зарезервировать все четыре уровня — оборудование, сервер приложений (кластер 1С), СУБД и среду виртуализации. Пропуск любого из них оставляет единую точку отказа, и вся схема перестаёт работать.

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

Ниже — рабочие схемы по каждому уровню: от розетки до виртуальной машины.

Из чего складывается отказоустойчивость 1С

Отказоустойчивость 1С — многослойная. Сбой возможен на любом уровне, поэтому резервируют каждый по отдельности:

• 🔌 Оборудование и сеть — дублированные блоки питания, RAID-массивы, две сетевые карты, резервные коммутаторы, ИБП.
• 🖥 Сервер приложений — отказоустойчивый кластер серверов 1С:Предприятия (несколько рабочих серверов).
• 🗄 СУБД — репликация и автоматическое переключение PostgreSQL или группы доступности MS SQL.
• ☁️ Виртуализация — перезапуск виртуальной машины на другом хосте (VMware HA, Hyper-V).

Выбор глубины резерва зависит от требований к простою. Их описывают двумя величинами:

• RTO — допустимое время восстановления. Сколько минут система может лежать, пока резерв поднимается.
• RPO — допустимая потеря данных. За какой период транзакций не жалко при переключении.

Если RTO измеряется часами, а RPO — сутками, хватает резервных копий и запасного сервера «в холодном резерве»: его включают и разворачивают базу руками. Если RTO — минуты, а RPO стремится к нулю, нужен полный автоматический ввод резерва на всех уровнях с синхронной репликацией.

Различают три типа резерва:

• ❄️ Холодный — запасной сервер выключен, разворачивается из копии вручную. Дёшево, но простой большой.
• 🌤 Тёплый — резерв включён, данные подгружаются с задержкой, переключение частично ручное.
• 🔥 Горячий — резерв работает синхронно и подхватывает нагрузку автоматически. Это и есть полноценный АВР.

Резервирование на уровне оборудования и сети

Без аппаратного резерва программные схемы бессмысленны: кластер 1С не спасёт, если оба процесса крутятся на одном физическом сервере с одним блоком питания.

Базовая аппаратная схема автоматического ввода резерва:

Ключевые приёмы, без которых аппаратный резерв неполон:

1. RAID вместо одиночного диска. RAID 1 (зеркало) или RAID 10 переживут выход диска из строя. Контроллер с горячей заменой позволяет поменять диск без остановки.
2. Агрегация сетевых карт. Две карты объединяют в один логический канал (NIC teaming на Windows, bonding на Linux). Отказ одной карты или линии не рвёт связь.
3. Отдельная сеть для трафика СУБД и репликации. Нагрузка 1С и обмен между репликами по одному каналу — риск потери синхронизации при пиках.
4. ИБП с автоотключением. При длительном пропадании питания ИБП должен корректно завершить работу сервера, а не разрядиться в середине транзакции.

Запасной сервер без заранее настроенного переключения — это не АВР, а ручное восстановление. Автоматизм даёт только программный уровень поверх железа.

Отказоустойчивый кластер серверов 1С:Предприятия

Главный механизм АВР на уровне приложения — отказоустойчивый кластер серверов 1С. Платформа 8.3 умеет держать несколько рабочих серверов в одном кластере и переносить сеансы с упавшего узла на живой.

Схема клиент-сервера в 1С трёхзвенная: клиент обращается к агенту сервера (порт 1540), затем к менеджеру кластера (порт 1541) и к рабочим процессам rphost (диапазон портов задаётся в свойствах рабочего сервера). Консоль администрирования идёт через агент. Для резерва дублируют именно эту цепочку.

Как настроить кластер на два узла:

1. Установите сервер 1С:Предприятия на обе машины. На каждой запускаются служба агента ragent, менеджер кластера rmngr и рабочие процессы rphost.
2. В консоли администрирования откройте свойства кластера и задайте уровень отказоустойчивости — число узлов, отказ которых кластер переживёт без потери данных. Значение по умолчанию 0 означает, что резерва нет.
3. Добавьте в кластер второй рабочий сервер. В его свойствах укажите диапазон портов рабочих процессов и требования назначения функциональности (какие процессы на нём разрешены).
4. Зарегистрируйте резервный центральный сервер, чтобы при падении основного клиенты находили кластер через дубль.

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

Переключение не абсолютно бесшовное. Операция, которая выполнялась в момент аварии (проведение документа, формирование отчёта), откатывается, и пользователь повторяет её заново — но сам сеанс и подключение к базе сохраняются, повторный вход не требуется. Для большинства задач это выглядит как короткая заминка вместо полной остановки.

Требования назначения функциональности позволяют распределить роли между узлами: например, фоновые задания и регламентные операции закрепить за одним сервером, а обслуживание клиентов — за обоими. При отказе узла запрещённые на нём роли автоматически перейдут на оставшийся, если там они разрешены.

Для проверки состояния кластера из командной строки используйте утилиту rac. Список кластеров смотрят командой rac cluster list, список серверов и сеансов — соответствующими подкомандами; полный синтаксис выдаёт rac help. Не придумывайте параметры наугад — у rac строгий набор команд.

Кластеризация СУБД: PostgreSQL и MS SQL

Кластер 1С резервирует сервер приложений, но данные лежат в СУБД. Если база одна, её отказ останавливает всё. Поэтому СУБД резервируют отдельно.

PostgreSQL. Основа — потоковая репликация (streaming replication): ведущий сервер (primary) передаёт журнал транзакций на одну или несколько реплик (standby). Сама по себе репликация автоматического переключения не даёт — для этого ставят менеджер кластера:

• Patroni в связке с etcd или Consul — следит за узлами и при падении primary повышает реплику до ведущей.
• repmgr или pg_auto_failover — альтернативные менеджеры с похожей логикой.

Клиенты 1С подключаются не к конкретному серверу, а к точке входа — виртуальному IP или балансировщику (например, HAProxy), который всегда указывает на текущий primary. При переключении адрес остаётся прежним.

MS SQL Server. Штатное решение — группы доступности Always On (Availability Groups). Синхронные реплики с автоматическим переключением работают поверх отказоустойчивого кластера Windows (WSFC). Клиенты 1С подключаются через слушатель (listener) — единое сетевое имя, которое сам направляет запрос на активную реплику.

Альтернатива — экземпляр отказоустойчивого кластера (Failover Cluster Instance) с общим дисковым хранилищем, но тогда хранилище само становится точкой отказа и его тоже резервируют.

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

Отказоустойчивость через виртуализацию

Виртуализация добавляет ещё один слой резерва — на уровне целой машины. Если 1С и СУБД работают в виртуальных машинах, гипервизор переносит их между физическими хостами.

VMware vSphere:

• HA (High Availability) — при отказе физического хоста виртуальная машина автоматически перезапускается на другом хосте кластера. Это перезагрузка ВМ, то есть короткий простой на время старта системы, а не бесшовное переключение.
• vMotion — «живая» миграция работающей ВМ между хостами без остановки. Используется для планового обслуживания: вывели хост в ремонт, машины уехали на соседний.

Microsoft Hyper-V: аналогичную роль играют отказоустойчивая кластеризация Windows и Live Migration.

Важная оговорка: виртуализация перезапускает машину, но не продолжает транзакцию с того же места. Для бесшовного АВР виртуализацию совмещают с кластером 1С и репликацией СУБД: гипервизор страхует от отказа хоста, кластер 1С — от обрыва сеанса, репликация — от потери данных.

Типичные ошибки при настройке АВР и диагностика

Схема, которая выглядит отказоустойчивой на бумаге, часто не срабатывает в бою. Самые частые причины:

• 🔴 Резерв на одном железе. Два рабочих сервера 1С как виртуальные машины на одном физическом хосте — при отказе хоста падают оба. Разносите узлы.
• 🔴 Уровень отказоустойчивости остался 0. Сервера добавлены, а параметр в свойствах кластера не поднят — данные сеансов не дублируются, переключение не происходит.
• 🔴 Один сервер в строке подключения. Клиенты знают только основной центральный сервер и при его падении не находят резервный.
• 🔴 Асинхронная репликация там, где нужна синхронная. После переключения теряются последние транзакции.
• 🔴 Нехватка лицензий на резервном узле. Сервер поднялся, а сеансы не стартуют из-за отсутствия серверной лицензии.
• 🔴 Переключение ни разу не проверяли. АВР, который не тестировали учебным отключением, с высокой вероятностью не сработает в реальной аварии.

Диагностику ведут по трём точкам: журнал регистрации кластера 1С, логи менеджера кластера СУБД (Patroni/WSFC) и события гипервизора. Расхождение по времени между узлами ломает синхронную репликацию, поэтому синхронизация часов (NTP) — обязательное условие.

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