Всем привет.
Задачка.
У компании есть небольшая, но очень важная база (самописка) на 1С:Предприятие 8.3.
Она должна быть доступна 24/7, то есть всегда. На этом основывается весь бизнес клиента.
СУБД стоит отдельно, там всё ровно.
Каким образом можно построить отказоустойчивый сервис 1С, чтобы работал прям почти всегда?
Какие есть варианты?
Построение отказоустойчивого кластера 1С по методичке с ИТС само по себе штука хорошая, но как быть, если сдох центральный сервер?
Есть ли смысл просто виртуализировать серверы 1С, и как это сделать?
Может, есть смысл всегда держать "наготове" вторую машинку с установленным сервером, и "не париться"? Умер основной сервер - руками переключаем на резервный. Это же просто сервис, если СУБД отдельно.

Упрощения:
1. СУБД лежит отдельно, и для упрощения предполагаем, что там отказоустойчивость 100% (этим занимается отдельная команда, не наш вопрос). То есть предполагаем, что данные никогда не потеряются. Осталось защитить логику.
2. При тяжелом сбое (например, умер сервер) для бизнеса не критично "перезайти" в 1С.


Кто есть с опытом, делитесь мнениями.

РИБ с шиной-брокером
Короче вторая база на той же даже СУБД если там 100%
И РИБ на другом сервере 1С

Но имхо кластер 1С вполне надежно

(1)
Не совсем внимательно прочитали условия задачи.
О данных не заботимся, они в надёжной СУБД.

"Но имхо кластер 1С вполне надежно"
Да, но если нагнется центральный сервер кластера, что тогда?

Kubernetes! Camunda!

(3)
Хм.. а подробнее можно?
Это же виртуализация? Контейнеры, все дела...
Как 1С себя там чувствует?

(4) - это шутка девопсеров такая

(5)
как это к теме относится?

(2) >Да, но если нагнется центральный сервер кластера, что тогда?

пожалуются в 1С что они врут:

"Такие события, как выход из строя рабочего сервера (в том числе и центрального сервера), аварийное (или плановое) завершение рабочего процесса или менеджера кластера не влияют на работу пользователей. Пользователи продолжают работать так, как будто ничего не произошло."
https://v8.1c.ru/platforma/otkazoustoychivost-sistemy/

https://habr.com/ru/company/1c/blog/493008/

(7)
Я так понял, что это достигается резервированием всего кластера...
То есть, условно, для того, чтобы иметь хоть какую-то устойчивость от падения сервера, нужно как минимум 3 железных машинки.
Первые две - в первом кластере, третья машинка является резервным кластером для первого кластера.

На каждой машинке - по одной серверной лицензии 1С.

Это всё так, как я себе это представляю?

Условно, все клиенты сидят через веб-сервер (веб-клиент или тонкий клиент плюс http-сервисы).
Организована группа кластеров по схеме из (9).
На веб-сервере прописана публикация базы, с указанием основного кластера и имя самой базы.
Первый кластер (основной) умирает.
Как веб-сервер будет знать, что он умер, и что теперь потребуется коннектиться не к основному кластеру, а к резервному?
Получается, должен быть какой-то менеджер группы кластеров?

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

(11)
Ну вот по сути это тоже вариант.
Держим вторую железку с настроенным сервером 1С и расчехляем только в случае, если основной падает...

Но 1С заявляет об отказоустойчивом кластере, но вопросов, как всегда, больше чем ответов.
То есть он вроде как есть, но где он и как в него - вообще не понятно.

(0) Классически такие вещи делаются по следующей схеме, например:
Пара SAN подключенных к паре fc-свитчей, к ним несколько числодробилок под vsphere ha cluster. И можно не шибко заморачиваться количеством одноэс серверов и серверов бд итп.

(1) и сколько минут будет утеряно в случае сбоя? какие вообще объемы потянет данная "технология"?

(13)
про SAN я еще загуглил, тут понятно.
Но на "fc-свитчей" я вообще потерялся. "числодробилок под vsphere ha cluster" - ничего не понял...

Можешь более доходчиво объяснить для тех, кто в танке?
Я думаю, что это не только мне пригодится...

(0) >>СУБД стоит отдельно, там всё ровно.

что ровно, Паш?

(15) Могу, почему бы не объяснить,) SAN это сеть хранения данных. Для задачи берем две полки (железка со слотами для дисков) и подключаем их к двум свитчам (каждую полку к обоим свитчам). Берем два мощных (потому и числодробилка) сервера с процессорами и памятью, но без дисков, и подключаем каждый к обоим свитчам. Сразу отмечу, что подобная конструкция по деньгам начнется от 30k-40k$ без софта. Серверов неплохо побольше, конечно.

(15) https://en.wikipedia.org/wiki/Storage_area_network
https://www.vmware.com/products/vsphere/high-availability.html

(15)  Суть этого всего в полной виртуализации что хранения, что самих софт-серверов. Можно Разместить по узлу (полка, свитч и esx) в трех разных городах, например, и тогда конструкция будет устойчива к ядреной бомбе.

Основная проблема с несколькими центральными серверами - это сеансовые данные. Ну не смогла 1с написать хорошее распределённое хранилище.
Ради решения этой пробемы и выпускали 8.4
Но этот путь тоже не сработал

(20) да хрень это а не отказоустойчивость. единств норм вариант это хранилка

(0)
"Чтобы кластер серверов 1С:Предприятия мог запустить рабочие процессы на рабочем сервере, который отличен от центрального, необходимо, чтобы для рабочего сервера кластера, не являющегося центральным, в котором имеется не пустой список администраторов центрального сервера, в списке администраторов присутствовал администратор, у которого определена аутентификация ОС пользователя, от имени которого запущен «ragent» центрального сервера кластера или должен присутствовать администратор с именем и паролем, совпадающими с именем и паролем одного из администраторов центрального сервера кластера.

Для синхронизации данных между главным и резервным кластерами серверов 1С:Предприятия никаких дополнительных настроек прав пользователей ОС не требуется." (С)

(0) failover cluster windows решает эту проблему. round-robin DNS.
как минимум: 2 сервера СУБД, 2 сервера терминального доступа для 1с.

(2)
7.5.3. Параметры для клиент-серверного варианта информационной базы

Srvr
Имя сервера 1С:Предприятия.

Для обеспечения бесперебойной работы клиентских приложений возможно указание нескольких адресов кластера. Для этого:
● Значением параметра Srvr может быть список адресов кластера через запятую.
● В диалоге добавления информационной базы в клиентском приложении значением свойства Кластер серверов 1С:Предприятия может быть список адресов кластера через запятую.

Сцук, ну никто документацию вендора читать не хочет. Все хотят выпендрится знанием текущего развития IT и померяться умными словами.

(25) А кто-то имеет мнение не разбираясь в вопросе,) Нет никакого смысла плодить серверы приложений, если приложения работают с некластеризованной базой данных. А как только появляется необходимость кластера БД - автоматически прилетает SAN. А как только прилетает SAN автоматом прилетает нормальная виртуализация и «кластер1с» становится пятым колесом.

(26) Чуви, ты очень хороший пример поглаживания самого себя. Ты героически пропустил "СУБД лежит отдельно, и для упрощения предполагаем, что там отказоустойчивость 100%" из (0) и полез сорить словами, что ты, Великий, вообще все знаешь. При чем тут "необходимость кластера БД"?

(27)  «Чуви» это что? Я на птичьем не говорю.Ну а по остальному сразу видно «профи», который как делать HA даже на картинке не видел..

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

(29) Так все это и есть "сеансовые данные". Туда входят и параметры сеанса, и данные временных хранилищ и результаты повторно вычисляемых модулей и прочие кэши объектов/представлений...

Восстановление сеанса не гарантируется, ну оно и в (0) вторым пунктом явно написано - "для бизнеса не критично "перезайти""

Если не критично перезайти,то просто две независимых стойки полного комплекта субд и сервер с передачей изменений из одной в другую.
Если же СУБД уже сделана,то просто резервный сервер с переключением на шлюзе,когда умер основной.

Софтпоинт кучу лет назад уже умел бесперебойность делать

(25) Ты хотя бы уточнил, что в твоем варианте клиенту придется оплачивать 2 комплекта лицензий (серверных и клиентских).

(33) Ну так бери блокнот и дублируй систему в блокноте, наверное будет дешевле чем двойной набор лицензий

(6) Camunda и Kubernetes применяются для создания отказоустойчивых систем. Но не на 1C,а на Java.

(34) Можно же сделать без двойного набора лицензий на виртуалках, Валер.

(36) а можно в блейде

(0) Мы вам не поможем. Любая система от 1С работает с ошибками, особенно, когда приходится чего дорабатывать, либо обновлять платформу.

Вы должны для нас описать более детально, что требуется конторке от 1С - СУБД, что оно должно робить 24 часа в сутки?

Пример:
  1. Запускать Спутники на орбиту
  2. Директор ночью, бухой в хлам, должен всегда иметь возможность видеть свои отчетики...
  3. и т.д....

Тогда мы вам поможет , подкинем варианты...
А так, 1С зависает, Сервера дают сбой... Сервисы бывают ломаются... Интернет может быть потерян по вине короткого замыкания :)
И т.д.... Самое действенное, нанять тех. поддержку 24 часа в сутки :)
Который тупо будет следить за работоспособностью системы :)
Купить резервное оборудование, и канал... Научить тех. поддержку включать это... как мартышек - просто выдрессировать - Написать инструкции на все вариации событий :)

(24)
Круто, спасибо!

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

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

(38)
покритикуй вариант в (40)

(37) А что такое блейд?

(32)
Это круто, но я не софтпоинт)

+ (40)
Отдельно завиртуализировать сервер лицензирования, чтобы не дублировать клиентские лицензии.
Серверные лицензии, видимо, придётся задублировать.

В качестве апа, призывается DrZombi
DrZombi