Появилась необходимость создать отказоустойчивый сервер. База большая. Подключений порядка 50. Имеем сейчас 1С+SQL. Ежедневные Backup. Но произошел недавно случай: отказал один из дисков системных в RAID. Пришлось восстанавливать, вообщем  полдня фирма простояла....

Прошу совета от тех, кто это уже делал. Опишу схему
Комп 1: - На нем 1с платформа, служа сервера 1С, вообщем кластер 1С.
Комп 2: - на нем субд (кто то за SQL, кто то за linux с postgre)

Комп 3: - на нем субд

Комп 2 И Комп 3  - настраивается "репликация". Не делал так никогда, не знаю пока досконально.

Идея в том, что если отвалился Комп2, то 1С-сервер переключается на Комп3.

Ну и 4 устройство: Сетевое хранилище (NAS вроде называют, будет уже как готовое решение)

Есть ли у кого опыт в такой настройке?
Вопрос возник по одной причине: в просторах описывают как создать отказоустойчивость, и там создают 2 компа со службой 1С-Сервер, и 1 комп со службой лицензирования. Для чего не пойму

(0) Как связана остановка фирмы и вылет одного из дисков в RAID - максимум что могло случится, производительность SQL упала, но остановка конторы откуда взялась?

в тему Репликация MS SQL Server для баз 1С работает?

для продолжения дискусии озвучте примерный бюджет....

1 лям
10 лямов
100 лямов

(2) Какие 100 лямов?
На что их можно потратить в (0)?

(1) Так зависит от того, что за раид был

(0) >>отказал один из дисков системных в RAID
Системный — это на котором ОС или что?

>>Пришлось восстанавливать, вообщем  полдня фирма простояла....
Восстанавливать что, сервер 1С, скуль, ОС, что?
Откуда полдня-то, на что?

>>в просторах описывают как создать отказоустойчивость, и там создают 2 компа со службой 1С-Сервер, и 1 комп со службой лицензирования. Для чего не пойму
Все просто
Если полетит один сервер 1С, то будет работать второй сервер 1С и нагрузка переключится на него
А со службой лицензирования отдельный потому, чтобы лицензии не были привязаны к конкретному серверу 1С, потому что тогда придется покупать лицензии и на один сервер и на другой

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

Систему ставили по новой, sql, там Raid отвалился как то, подробности не знаю, сис админ занимался.

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

(6) Получается 1 комп - Сервер 1С
2 комп - субд (Тут Raid)
3 - сетевое хранилище

Так?

(6) "Ну и сервер имей с развернутой подсистемой, на всякий пожарный" - это в этом случае 1 комп?

(7) >>Систему ставили по новой, sql
Так может озаботиться тем, чтобы, если что, под рукой был развернутый сервак на всякий случай?
Ну и сисадмину вставить люлей за то, что у него раид отвалился
А не придумывать всякую колхозную мутную херню вместо проверенных решений

>>Система, описанная мною реальна? работать может? есть раочие примеры такого?
Про твою систему я написал, что это какая-то непонятная хрень, непонятно ради нахрен чего

У тебя полетел системный диск, ты полдня занимался переустановкой оси, админ непрофессионал, и при этом ты предлагаешь что?
Правильно!
Порешать со скулем!

(10) Мою схему ты обругал, ок. А в противовес может уже предложишь рабочую схему? я же спросил по причине, что не знаю как лучше

Блять 🤦

Еще раз, все очень просто

У тебя есть:
1. Сервер 1С
2. Сервер SQL
3. Сервер лицензий

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

Серверов 1С делают несколько для того, чтобы:
1. Не простаивать полдня, если сервер вспыхнул синим пламенем и улетел в Вальгаллу
2. Распределить нагрузку между серверами, если у тебя, например, 10000 пользователей

Для чего делают несколько серверов SQL, я в душе не подозреваю
При условии, конечно же, что мы говорим про одну базу
Если баз несколько, то все просто, для того, чтобы распределить нагрузку
А так только что разве для того, чтобы иметь развернутый SQL, если рабочий почил в бозе
Но в этом случае важнее, чтобы не отдал душу диск, потому что если диск ку-ку, то тогда у тебя проблема, откуда взять базу, а не проблема, где взять SQL

Для чего делают отдельный сервер лицензий, я ужу написал

Теперь, прочитав все это, скажи мне, где здесь хоть как-то хоть каким-то краем описана твоя схема?

(11) Я же уже сказал, самое важное — это диски с раидом
Если есть раид (не любой, какой попало, а именно тот, который позволяет работать дальше, если полетел один из дисков), значит шансы, что все встанет из-за того, что полетел диск — минимум

При этом по-прежнему может что-то произойти с сервером, мать полетела, память сдохла и пр.
Поэтому имеет смысл иметь про запас сервак с развернутыми серверами 1С и SQL
Если вдруг что, у тебя какой никакой сервак есть, все запустить на нем не так уж проблемно, время простоя не такое большое

Все остальные схемы, на мой взгляд — это уж точно не для компании на 50 пользователей

То есть, в сухом остатке, я бы сделал так:
Везде раид (я не спец по раидам, но, видимо, нужен раид 0 https://hetmanrecovery.com/ru/recovery_news/summary-concept-and-description-of-available-capabilities-of-a-redundant-array-of-independent-disks-raid.htm)
Запасной сервак с развернутыми 1С и SQL

(14) вот только RAID не 0, 1 как минимум, а лучше 5

(15) Я поэтому сразу и написал, что я не спец по раидам

(7) Так это у вас у админа лапки, а не проблемы RAID'а.
(14) RAID10 если на HDD и RAID1 если на SSD, можно конечно и RAID10 на SSD собрать - будет дорого/богато и очень быстро.
(15) Я бы очень сильно подумал, перед тем как ставить RAID5 на сервер, где требуется отказоустойчивость.

(0) совершенно точно рабочие схемы есть.

Можно:
1. Отказоустойчивый кластер 1С
2. Отказоустойчивый кластер для SQL.

Я делаю так:
1. Мастер на нем все работают
2. Слейв на нем установлено и настроено все необходимое ПО.

Для сервера бд реализована master-slave репликация.

Прецеденты у меня были: на master развалился raid в середине дня. На восстановление ушло 30минут из них 15минут я убеждался, что master мертв.

Но я бы сделал описал в "можно". Просто у нас нет бюджета ни на хорошее железо, ни на толкового сис.админа.

(1) если был raid 0 или дектопный диск в массиве или диск и контроллер не совместимы. Вполне такое может быть.

(0) если нет денег то можно воспользоваться простым способом как делал когда-тот на одной системе еще на 7.7

1. Поднимается резервный сервер по принципу - дешево но без ущерба для производительности. т.е. клон основного но без райда (хороший райд особенно если это внешняя полка дороже сервака будет).
2. средствами УРБД делается в ту сторону каждые 15 минут обмен (можно хоть каждые 5 минут т.к. чем меньше пакет тем меньше транзакцию порождают). а в текущей при создании каждого дока его номер идет в файл на 3м компе для сохранения счетчиков.
3. база 2 итого получается клон основной с дельтой 15 минут.

в случае падения основного, база Б становится основной и админ переключает РДП на нее, поднимаются пустышки доков забивая последний номер из 3го файл. Максимум потеря доков 15 минут не критична и восстановима. Пока разбираются с райдом и лечат база Б поживет без него и вероятность что она погибнет даже на одном винте крайне мала.

Еще из практики и извращений-
В магазинах где была ПБ база магазина каждый день утром при первом входе делался бэкап базы и складывался в каталог который синхронизировался с облаком и бэкап отправлялся туда. Каждый чек пробиваемый писался в файл в тот же каталог. Если база умирала и комп, то админы брали из облака последний бэкап и после старта базы обработкой возвращали все чеки от последнего имеющегося в базе.

(21) это больше похоже на то, как 1Сниг решает админские задачи.

Если обмены 1 раз в 15минут, то "лаг репликации" в среднем 7.5минут.

У меня на postgres средний лаг репликации меньше 1секунды.

Повторяю: это бесплатно и не требует высокой квалификации. Просто работает.

(22) да нет проблем с репликацией MS SQL, технология появилась раньше, чем в postgres, разжёвана полностью

(22) (23) ну да админы не могли и с базой 77 была какая-то заморочка делающая ее не рабочей при репликации. Подробностей не помню.

(24) ни о чем, исключение подтверждающее правило

как говорит один специалист особого профиля "безопасность это дорого" (с).

на мой взгляд пользоваться кластерами 1С при не готовности "идти до конца" нет никакого смысла.

стабильная железка (уже выше говорили про рейды), бекапы и более или менее подготовленное "зеркало" (просто повторение работающей структуры, готовой принять восстановление бекапа и продолжение работы в 1С) более чем достаточно

(23) репликация в коммерческих постарее была вроде давно