Отказоустойчивость 1С: резервирование центрального сервера и сервисов кластера

«Сделайте нам отказоустойчивый кластер 1С» — просьба, за которой у разных людей стоят совершенно разные ожидания. Кто-то хочет, чтобы пользователи не заметили падения сервера. Кто-то — чтобы система поднялась за десять минут вместо трёх часов. Это разные архитектуры и разные бюджеты. Разберём, что механизмы 1С умеют на самом деле и где проходит граница.

Начнём с честного разграничения, потому что термин перегружен.

Кластер серверов 1С умеет две вещи. Первая — распределять нагрузку между несколькими рабочими серверами. Вторая — переживать падение одного из них без потери пользовательских сеансов, если включено резервирование.

Чего кластер 1С не умеет: он не резервирует СУБД. Вообще. Если умрёт сервер базы данных, кластер 1С будет жив, здоров и совершенно бесполезен.

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

• Слой СУБД — Always On, зеркалирование, репликация PostgreSQL. Самый дорогой и самый важный.
• Слой сервера приложений — тот самый кластер 1С с резервированием.
• Слой доступа — терминальные серверы, публикации, балансировка.

Резервировать только средний слой — распространённая ошибка. Она даёт красивую схему в презентации и нулевой эффект в аварии, потому что статистика отказов у СУБД и у сервера приложений примерно одинаковая.

В свойствах кластера есть параметр «Уровень отказоустойчивости». По умолчанию ноль.

Число означает, отказ скольких рабочих серверов кластер должен пережить без потери сеансов. Единица — переживём падение одного сервера. Двойка — двух.

Механика такая: при ненулевом значении кластер начинает реплицировать данные сеансов между серверами. Каждый сеанс имеет основную копию на одном сервере и резервную на другом. Умер сервер — сеансы подхватываются с резервных копий, пользователь в худшем случае видит короткую паузу.

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

Ставить уровень выше нуля на одиночном сервере бессмысленно: реплицировать некуда. Это, кстати, частая находка при аудите — параметр выставлен «для надёжности» на единственном сервере и просто расходует память впустую.

Не все серверы кластера равны. Один или несколько имеют статус центрального.

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

Если центральный сервер один и он падает, кластер не работает целиком, даже если остальные рабочие серверы живы. Некому раздать клиентам информацию о том, где искать базу.

Решение — назначить второй центральный сервер. Тогда реестр реплицируется между ними, и падение одного не выносит систему.

Клиенты при этом должны знать оба адреса. В строке соединения они перечисляются через запятую:

Srvr="srv-1c-01,srv-1c-02";Ref="buh_prod";

Платформа попробует первый, при неудаче — второй. Работает это прозрачно, но требует, чтобы строку соединения обновили у всех клиентов. Через список баз, раздаваемый групповой политикой или файлом ibases.v8i, это делается централизованно.

Практическая деталь, которую легко упустить: если у вас настроена публикация на веб-сервере, в default.vrd тоже надо перечислить оба сервера. Иначе веб-доступ ляжет вместе с первым центральным, хотя тонкий клиент продолжит работать.

Соберём конкретную конфигурацию, которую мы разворачиваем клиентам с требованием «учёт не должен останавливаться дольше чем на полчаса».

Настройки кластера: уровень отказоустойчивости 1, оба сервера центральные, количество ИБ на процесс — 1.

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

Важно: синхронный режим Always On добавляет задержку к каждой транзакции записи, потому что коммит подтверждается только после записи на вторичной реплике. На гигабите в пределах одной стойки это доли миллисекунды и незаметно. Через WAN между площадками — уже секунды на пакетных операциях, и синхронный режим туда не годится.

Что эта схема даёт: падение любого одного узла из четырёх не останавливает работу. Что не даёт: защиты от логической ошибки. Удалённые по ошибке документы реплицируются на вторую реплику мгновенно и с тем же успехом.

Сервисы кластера — журнал регистрации, полнотекстовый поиск, блокировки, нумерация объектов — распределяются по серверам менеджерами.

По умолчанию все живут на центральном сервере, и это создаёт перекос: один узел работает за двоих. На двухсерверной схеме имеет смысл развести хотя бы тяжёлые сервисы.

Делается это требованиями назначения функциональности. И вот здесь надо быть осторожным — механизм мощный и легко ломается.

Правила, которые мы для себя вывели после нескольких неприятных случаев:

1. Никогда не задавать требования так, чтобы какой-то тип объектов не мог быть размещён нигде. Всегда оставлять хотя бы один сервер с правилом «Назначать» без указания конкретного объекта — как страховочная сеть.
2. После настройки обязательно проверять список сеансов и фоновых заданий: они должны реально распределиться, а не осесть все на одном узле.
3. Изменения вносить при работающих пользователях нельзя — часть требований применяется только при перезапуске рабочих процессов.
4. Записывать схему распределения в документацию. Через год никто не вспомнит, почему фоновые задания ходят только на второй сервер.

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

Полезно проговорить границы, чтобы ожидания совпадали с реальностью.

Не спасёт от падения СУБД. Уже говорили, но повторю: это отдельный слой с отдельным бюджетом.

Не спасёт от логических ошибок. Проведённый не тем числом документ, удалённая группа справочника, кривая обработка — всё это реплицируется идеально.

Не спасёт от шифровальщика. Наоборот: два сервера с общими правами — вдвое больше поверхности.

Не спасёт от ошибки в обновлении. Обновление конфигурации применяется к базе, а база одна.

Не спасёт от исчерпания лицензий. Кластер жив, работать никто не может.

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

Формулировка для клиента, которую мы используем: резервирование кластера превращает трёхчасовой простой всего офиса в тридцатисекундную заминку с потерей текущего действия. Это очень много. Но это не «никто ничего не заметит».

Полная схема на четыре узла подходит не всем. Порядок, в котором мы рекомендуем вкладываться, если денег на всё сразу нет.

1. Проверенные бэкапы и измеренный RTO. Это база. Без неё остальное — украшения. Стоит ноль рублей сверх уже имеющегося.
2. Резервирование питания и дисков. ИБП, RAID с горячей заменой, мониторинг состояния массива. Самые частые отказы — именно здесь.
3. Репликация виртуальной машины на второй хост. Даёт RTO порядка 15–30 минут при потере хоста, стоит только диска на приёмнике.
4. Резервирование СУБД. Always On или хотя бы log shipping.
5. Резервирование кластера 1С. Второй сервер приложений, уровень отказоустойчивости 1.
6. Резервирование слоя доступа. Второй терминальный сервер, брокер соединений.

Заметьте порядок: кластер 1С стоит на пятом месте, а не на первом. Мы регулярно приходим к клиентам, где потрачены деньги на второй сервер приложений, а бэкап при этом лежит на том же RAID-массиве, что и база, и ни разу не проверялся восстановлением.

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

• Зафиксированы целевые RPO и RTO, согласованы с руководителем письменно.
• Бэкапы проверены восстановлением, фактическое время замерено.
• Определено, какие слои резервируются: СУБД, сервер приложений, слой доступа.
• Уровень отказоустойчивости кластера соответствует числу серверов (не выше нуля на одиночном).
• Назначено два центральных сервера, оба перечислены в строках соединения клиентов и в default.vrd.
• В строке подключения к СУБД указан слушатель группы доступности, а не имя конкретного сервера.
• Требования назначения функциональности имеют страховочное правило «Назначать» без объекта.
• Схема распределения сервисов задокументирована.
• Проведено учебное переключение с отключением узла и замером фактического времени.
• Мониторинг покрывает оба узла кластера, обе реплики СУБД и сам факт репликации.

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

Достаточно ли двух серверов 1С для отказоустойчивости?

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

Заметят ли пользователи падение одного сервера кластера?

Заметят, но кратковременно. Сеансы подхватываются с резервных копий, повторный вход не нужен. Однако операция, выполнявшаяся в момент отказа, потеряется, и её придётся повторить.

Нужен ли уровень отказоустойчивости выше нуля на одном сервере?

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

С чего начать, если бюджет небольшой?

С проверенных бэкапов и измеренного времени восстановления, затем резервирование питания и дисков, затем репликация виртуальной машины на второй хост. Второй сервер приложений имеет смысл только после того, как закрыты эти пункты.