Как организовать отказоустойчивый кластер 1С?

Question

[Александр Абакумов]

Доброго дня коллеги.
У нас есть 2 абсолютно одинаковых сервера. Задача, сделать отказоустойчивый кластер из этих серверов для 1С.
Сервера стоят на складе и нуно обеспечить 100% автономность работы склада, для этого куплено 2 сервера.
Нужно чтобы стояла 1С+MSSQL, и в случае отказа одного из серверов, не прерывая работу, все переключилось на второй. Чтобы не было простоя и все переключения были автоматизированы.
Была мысль установить HA кластер Hyper-V, но для него нужно внешнее хранилище.
Была мысль сделать кластер средствами компонента "Отказоустойчивая кластеризация" и соответственно поднять кластер MSSQL и 1С, но там так же требуется внешнее хранилище.
Поставщик программного решения 1С предложил сделать на Proxmox кластер и что все будет работать, но имея опыт работы с Proxmox, я не очень горю желанием использовать его в продуктиве.
Если рассмотреть установку HA-кластера на ESXi, то там нужен третий сервер.
В общем я в некотором замешательстве.
Подскажите кто подобное реализовывал и какими средствами.

Answer 1

[Александр Абакумов]

Нашел решение самостоятельно.
1. Устанавливаем 2 сервера, и ставим на них Windows Server 2019 Std
2. Устанавливаем компонент "отказоустойчивая кластеризация"
3. Создаем кластер.
4. Устанавливаем MSSQL, в моем случае 2019
5. В настройка MSSQL, в консоли, включаем поддержку Always on и все возможные подключения.
6. Создаем на одном сервер базу и заливаем в нее нужный нам бекап(если он в SQL)
7. Добавляем группу доступности Always on.
8. После синхронизации проверяем что база синхронизирована.
9. Берем за основу инструкцию https://infostart.ru/1c/articles/307973/ и создаем отказоустойчивый кластер 1С.
10. После успешной установки и синхронизации, перезагружаем сначала первичную ноду, ждем пока запустится, потом вторичную.
11. Проверяем работу 1С. Во время работы работы 1С, тушим первичную ноду и убеждаемся что все работает и переключение произошло автоматически на вторичную ноду. Включаем обратно и производим такую же операцию со вторичной нодой.

Answer 2

[Drno]

Для того чтобы это работало - нужно общее хранилище
Иначе как будут синхронится данные в реалтайме?

Comments

[Александр Абакумов]

в Proxmox это как-то делают в локальными хранилищами.
Я потому и задаю вопрос. Может быть возможно как-то диски между собой тоже подружить, чтобы они оба было как один общий диск доступный одинаково на обеих нодах?

Answer 3

[rPman]

Без внешнего хранилища можно попробовать кластерные файловые системы, но базы данных с ними будут работать неудовлетворительно, а во что превратится работа 1c я даже представить не могу, в общем будут тормоза.

Так как используются sql базы данных, то можно попробовать настроить master-master репликацию межу ними (т.е. только sql сервер), и вручную контролировать, с какой машины производить запуск (т.е. нужен какой то механизм проверки доступности соответствующей ноды с автоматическим запуском резервной) не уверен что готовые скрипты для 1c есть но они не должны быть сложными.

Т.е. итог - настраиваешь для файлов кластерную файловую систему а для базы настраиваешь репликацию для базы данных. В сети (той что между нодами) запускаешь скрипт, проверяющий доступность ноды и при ее недоступности переключающий (например на управляющем коммутаторе) подключение на резервную и запустить сервер-приложений 1с (должен быть запущен одномоментно только на одной ноде, это важно).

В этой схеме важно гарантировать запрет на одновременное подключение двух работающих серверов 1с к базе данных (иначе будет каша), это может произойти к примеру из-за фальшивого определения недоступности базы (а она проснется и начнет в базу данные записывать). Чтобы гарантировать это, можно дополнительно завершить процессы сбойной ноды (kill а не штатное завершение или даже выключение питания, чтобы исключить проблемы с софтом, например драйверами) и средствами роутера обрубать соединение ноды с пользователями. Настройки сети у обоих нод должны быть идентичные (например статика, так быстрее чем через dhcp, но только одна нода в один момент доступна пользователям) для внешних пользователей и отдельное подключение для sql базы данных (тут адреса само собой разные в своей сети).

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

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

В идеале резервный сервер должен стоять не просто в другом здании, но должен быть подключен к другому интернет провайдеру (или даже отдельным кабелем) со своим независимым питанием (т.е. другая организация обеспечивающая энергию как на постоянке так и поставка топлива для генератора)