Если к кластеру(1 физический) добавить второй в качестве резервного(в настройках так можно выставить) и повесить на этой второй еще и сервер лицензий. Оно взлетит?

В данный момент курю МАНы и что-то не очень понимаю. А протестировать возможности нет.

(0) 1 база подключена сразу к двум кластерам сервера?
было так в одной конторе, работало, надо бы наверное на один кластер блокировку фоновых поставить.

.

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

(3) там по другому было, надо было порт перепрописывать, чтобы к другому подключаться

(1) Садись, два

"По идеи если первый отваливается, то подхватить должен второй" // Бгг. Издание платформы какое?

нужно будет 2 комплекта лицензий

(5) хочешь сказать 1 базу нельзя к двум (и более) кластерам подключить?

(6) последняя

Есть очень неплохая статья на инфостарте, там это довольно подробно расписано http://catalog.mista.ru/public/907443/

(8) Нет, этого Я сказать не хочу.
Двойка тебе, во-первых, за саму такую мысль, во-вторых за неправильное понимание (или его отсутствие) озвученного в нулевом посте.

(0) Про windows-авторизацию забудь в этом случае, если нет домена.

(11) согласен) не правильно изначально понял мысль)

(10) (11)
1) спасибо за ссылку.
2) я так понимаю, что для создания реально отказоустойчивой связки нужно min 3 сервака.

(11) Когда уровень отказоустойчивости равен нулю, но есть хотя бы два центральных сервера, то при отказе одного из центральных серверов, те пользователи, сеансы которых к нему подключены, просто получат ошибку с предложением перезапустить 1С. Перезапустят 1С, подключатся ко второму центральному серверу, и все заработает.

(15) В той статье терминология хромает

Думаю, именно из-зя корявой терминологии статьи в ИС ты и думаешь, что "для создания реально отказоустойчивой связки нужно min 3 сервака". Двух достаточно.

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

Что там имеет в виду автор темы в нулевом посте под "резервным сервером" - не ясно

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

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

(21) Не ясно, как ты это понял (откуда это следует). Думаю, ты что-то неправильно понял.
Никакой "централизации" в случае с более чем одним центральным сервером быть не может.

(22) > Никакой "централизации" в случае с более чем одним центральным сервером быть не может

Может речь о синхронизации? Уж она то должна быть по-любому.

(23) Синхронизация конечно есть

Кстати говоря, что вы тут подразумеваете под словосочетанием "два кластера"? Реально два кластера или два центральных сервера в кластере? Что-то я запутался...

(25) Это товарищ из (1) навел шухер, никаких двух кластеров автором темы конечно же не подразумевалось

Гораздо интереснее лично мне (19). Уж не думает ли автор темы, что "резервный" может стоять в сторонке до тех пор, пока с "основным" все хорошо. Так не полуяится в 8.3, про группу резервирования забудь.

(22) посмотри раздел про требования назначений функциональности.

Статью на ИС не читал, но думал, что для реальной отказоустойчивости количество центральных серверов в кластере должно быть УровеньОтказоустойчивости + 1.

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

(29) Правильно

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

(32) "при чем тут требования назначения функциональности?" // Да просто в статье на ИС автор утверждает, что надо три рабочих сервера, чтобы пользователи перетекали с одного надругой без ошибок на клиенте. А это конечно же не так. Вот и придумываем, почему он мог так утверждать )

(30) (32) (33) Не обязательно пользоваться только запретами, есть же ещё приоритеты. Этот "третий" сервер назначаешь самым приоритетным по сеансовым данным, т.е. все сеансы будут жить там, т.е. при выходе из строя первого или второго (рабочих), получаем прозрачный и незаметный для клиента переход с сервера на сервер. Если падает третий, то  сеанс будет потерян, но при переподключении по приоритету (ввиду недоступности третьего) будет выбран первый или второй.

(34) Пусть так. Однако не ясно для чего всё таки непременно нужен третий сервер для уровня отказоустойчивости 1?
Ну будут у тебя сеансы пользователей по приоритетам прозрачно и незаметно скакать с отвалившегося сервера на оставшийся. Третий то тут при чем?
Или имеется ввиду задача сохранить уровень отказоустойчивости равный "1" даже в случае выхода из строя или останова на плановое ТО одного из серверов?...

(35) В том то и дело, что третий нужен чтобы не скакали. Сеансовые данные живут себе спокойно на третьем, переключается только сервер "обработки"(рабочий).
(33) :) Ты искал консоль запросов, что умеет планы строить
https://its.1c.ru/db/files/1CITS/EXE/ExtReps/Unireps83/RequestConsoleManaged/RequestConsoleManaged.zip

(34) Предложенная тобою схема ничем не выигрывает по сравнению с двумя центральными серверами, плюс ты не по назначению походу используешь словосочетание "рабочий сервер". Если два будут просто рабочими (не центральными), а центральный один, то это УГ, а не отказоустойчивость.

(35) "Или имеется ввиду задача сохранить уровень отказоустойчивости равный "1" даже в случае выхода из строя или останова на плановое ТО одного из серверов?" // Эта задача и в кластере только с двумя центральными серверами решается

Короче зачем третий так и не ясно, пока складывается впечатление что просто "для пущей надежности" )

(36) "искал консоль запросов" // Благодарю. Давно такой архив видел на локальном диске, все думал что это за хня там внутри понаверчена ))

(37) >> "рабочий сервер"
Не по назначению. Здесь под "рабочим" имею ввиду с точки зрения функциональности - что принимает клиентские соединения.
(39) Именно, для надежности.

(36) > Сеансовые данные живут себе спокойно на третьем

А он что - бессмертный? Ерунда какая-то. Только лишняя путаница возникает, когда пытаются в одном примере разобрать сразу и тему отказоустойчивости кластера и тему распределения нагрузки (различных сервисов) между рабочими серверами внутри кластера.
Смешались в кучу кони, люди,
И залпы тысячи орудий
Слились в протяжный вой… (с) Лермонтов М.Ю.

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

(43) Мы видимо не понимаем друг друга. Зачем нужен третий сервер? Что изменится, если при уровне отказоустойчивости "1" у нас будет в кластере только два сервера (оба центральные)?  Пользователи перестанут прозрачно и незаметно перетекать с одного сервера на другой при выходе из строя одного? Нет, не перестанут.

(44) Не перестанут, но в обычной жизни, когда живы все 3 сервера, первому и второму будет жить попроще.

Пятый год работаем в режиме отказоустойчивости (1), т.е. два кластера на каждом центральный сервер. Сейчас платформа 8.3.13 Мне нравится! На последней версии значительно улучшилась работа по балансировке нагрузки. Базы высоко нагруженные и пользователями и постоянными обменами (загрузка-выгрузка 24ч. в сутки). У начинающих возникнут проблемы даже на этапе развертывания такой системы однако дорогу осилит идущий. "100 лет" не писал на этом форуме... А да ещё, это похоже на зеркало, т.е. администрирование идет только на одном из кластеров все автоматом "переезжает" в зеркало (Завершение сеансов, регистрация баз, изменение свойств и т.д. но не настройки кластера и центрального сервера) Можно остановить один из серверов и посмотреть как будут мигрировать сеансы. Меня удивило, что в УЦ1С №1 (был грех) опытный преподаватель ничего не мог сказать о такой работе... Возможно он большой спец. в вопросах блокировок и прочего. Извините если не отвечу на какие-нибудь вопросы если они будут, но не отвечать на форумах это моё кредо. С уважением к сообществу!

(0) взлетит, только нужно сервер лицензий в оба кластера запихнуть, иначе при падении первого сеансы буду переходить, но лицензий на пользователей не будет.

(43) Ты что-то явно напутал. Поведение на клиенте (задержка или падение) никак не зависит от количества серверов в кластере.

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

(46) "работаем в режиме отказоустойчивости (1), т.е. два кластера на каждом центральный сервер" // Чувак, не хочу огорчать тебя, но...

(46) и (47) походу родственники товарища из (1) :)

(27) Терминология действительно запутанная, но потихоньку в нее въезжаю. На самом деле действительно надеялся на возможность поставить его в сторонку, на случай если основной сервер выпадает. По русски говоря есть самый простой вариант "Сервер 1с" <-> "сервер БД". Задумка была такая: поставить второй "Сервер 1с"(в "ролях" же можно выставить, что резервный) + "сервер лицензий". Если падает первый, то запускается(запускаем?) второй и он взамен подхватывает лицензии первого.

(45) > первому и второму будет жить попроще

Это вопрос не отказоустойчивости, а распределения нагрузки. Не следует смешивать эти два вопроса. Связаны они между собой очень и очень отдалённо. И уж тем более непонятно - зачем впаривать ради отказоустойчивости избыточное увеличение количества серверов, предназначенных для распределения нагрузки.

"в "ролях" же можно выставить, что резервный" // Покажи на картинке, что ты имеешь в виду

(52) Конечная цель так и остается непонятной. Нужен отказоустойчивый кластер из двух серверов? Или всё таки нужен второй сервер, который выключен и будет включаться только при выходе из строя основного сервера.
Это две совершенно разные задачи. И решаются совершенно разными методами.
Начиная с того, что для отказоустойчивого кластера нужны серверные лицензии на каждый сервер.

(54) http://v8.1c.ru/overview/Term_000000805.htm

(55) Конечная цель: сделать так, чтобы работа не встала колом. Собственно из-за каши в голове у меня нет понимая в решении.

(57) > цель: сделать так, чтобы работа не встала колом

Это нельзя назвать целью.
Цель - это, например, обеспечить бесперебойную работу при любых обстоятельствах. Тогда нужен отказоустойчивый кластер.
Или оговаривается максимально допустимое время простоя при сбое. Исходя из этого времени (от нескольких минут до нескольких часов) решения будут очень и очень разными. И одним только сервером 1С такие решения не ограничиваются. Тут и вопрос доступности, отказоустойчивости и резервирования серверов СУБД, и вопрос стратегии бекапирования/зеркалирования баз. А в довесок идут сервера инфраструктуры - DHCP, AD (если авторизация везде доменная) и пр.
Какое максимально допустимое время недоступности системы в случае локального армагедона у вас в сети? Каков минимально допустимый уровень качества сервиса в период восстановления? Допустимо ли, например, чтобы в случае сбоя основного сервера в течении какого-то времени (от нескольких часов до нескольких суток) вся система тормозила и подвисала, сидя на слабом резервном сервере, пока основной восстанавливают или заменяют.

Разные требования, разные цели, разные решения, разные деньги.

(58) вопрос доступности, отказоустойчивости и резервирования серверов СУБД, и вопрос стратегии бекапирования/зеркалирования баз. А в довесок идут сервера инфраструктуры - DHCP, AD (если авторизация везде доменная) и пр.  
в этом плане вопроса как раз таки и нет.

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

(54) я, кажется, понял свою ошибку.
собственно на картинках 8.2, у меня же 8.3.

Есть такой нюанс: В отличие от платформы 8.2, в 8.3 нет групп резервирования кластеров. Но можно в один кластер запихнуть еще 1 ЦС.

(56) А теперь перечитай (27)

(48) Зависит же. Чем больше серверов, тем устойчивее система. :)
(53) Мы просто о разном. Я так то писал не формуле избыточности и другой теории, а как сделал бы, если бы имел SLA в 2-3 и более девяток. Но, как ты правильно пишешь в (58), это бессмысленно, если остальные системы не отказоустойчивы - СУБД, АД и прочее.

(61) собственно все и перечитал. Где чего не понимал, понял. Кое-что еще интересного для себя нашел. Собственно я и написал в (60) .

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

(64) > если выйдет из строя еще один - большинства не будет

Ну как бы логично... Что, если из двух серверов выйдут из строя оба, то всё умрёт. Но исходя из этой логики нужно не 3, а 30 серверов. Вдруг 29 из них выйдут из строя...

Что должно случиться, чтобы два сервера упали одновременно или последовательно один за другим?... Как мне кажется, это что-то такое, что подразумевает маленький локальный армагеддон (всё рушится), когда работа какого-то одного конкретно взятого сервиса (1С) уже никого не волнует.

А если уж у вас три сервера, то почему не поднять уровень отказоустойчивости до "2"? Чего стесняться? Тем более в предложенном примере предлагается уронить два сервера из трёх....

(65) :) В обычной жизни не решают только задачу надежности или только задачу распределения нагрузки. Делают некий баланс между стоимостью, надежностью и производительностью. Когда все три сервера являются центральными, с одной стороны возрастает нагрузка на репликацию, но с другой, какого-то внятного увеличения надежности не получаем, т.к. "Что должно случиться, чтобы два сервера упали одновременно или последовательно один за другим?". А потому дальше уже стоит играть распределением функционала. Тем самым мы снижаем нагрузку на центральные сервера, т.е. косвенно повышаем надежность решения в целом.

(62) "Зависит же" // Похоже, ты невнимательно прочитал сообщение, на которое отвечаешь

(66) "Когда все три сервера являются центральными, с одной стороны возрастает нагрузка на репликацию" // И здесь ты опять заблуждаешься. Является или нет рабочий сервер центральным, на репликацию никак не влияет.

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

(67) > Поведение на клиенте (задержка или падение) никак не зависит от количества серверов в кластере.
Ответ Чем больше серверов, тем устойчивее система. Если падает сервер, что одновременно держит и сеансовые данные и обрабатывает клиентскую логику, то клиенту придется переподключаться. В общем случае, чем больше серверов, тем ментше шансов на сие совпадение. Ну при должной настройке требований естественно.
(69) Я не тестировал, лично моих данных нет. Я очень сильно сомневаюсь, что 1Сники писали бы просто так о падении производительности и необходимости соблюдать баланс. Цитирую, https://its.1c.ru/db/v836doc#bookmark:cs:TI000000035 :

Таким образом, можно вывести следующую формулу, связывающую количество центральных серверов в кластере и уровень отказоустойчивости: Количество центральных серверов = Уровень отказоустойчивости+1. При этом надо понимать, что буквальное следование этой формуле приведет к некоторому снижению производительности кластера, т. к. на синхронизацию реестра кластера будет тратиться некоторая часть мощности системы. При определении количества центральных серверов и уровня отказоустойчивости следует соблюдать баланс между отказоустойчивостью и приемлемым уровнем производительности кластера серверов, учитывая при этом характеристики оборудования компьютеров, входящих в состав кластера.

Я хз, на что ты отвечаешь. Предлагаю тебе сформулировать мысль в виде "твое утверждение в такой-то части считаю неверным / еще каким-нибудь по такой-то причине".

(71) вроде ставлю номера сообщений, на что отвечаю. Что именно не понятно? Хотя, забей, тема, имхо, себя исчерпала.

Вот именно: номера вроде ставишь и они ведут на мои сообщения, и типа какой-то должен диалог складываться, но по факту ты дальше отвечаешь совсем на что-то другое

(73) Ну или ты не понимаешь моего ответа. :)

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

А при чем тут выгода? Мы вроде тут не на базаре выгоду искать. Общаемся же, вопрос взаимопонимания. Ты пишешь примерно по одной "мысли на сообщение", я на эту мысль отвечаю. Тебе не понятно что я ответил и на какую именно твою мысль? Переспроси что именно не понятно, с цитатой. А отписываться "не на то ответил" или утверждать что всё понял, но не понял к чему... Ну как минимум не конструктивно, как максимум... Остановимся на как минимум.

(17) и лицух 2комплекта, либо 3ий сервак-виртуалка с ключами

(76) "Выгода" = "менее затратная" операция (акт мышления).
Ну т.е. мозгу выгоднее быстренько автономно дать объяснение происходящему, т.е. не вступая особо во взаимодействие с собеседником.

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

(78) > не вступая особо во взаимодействие с собеседником

Обоюдная история же. Проще отписаться, что ответ не на то сообщение, чем переспросить и/или признаться что не понял ответа. Ну да не суть, в контексте "Давай предположим, что Я тебя не понял.", проехали.

> ты считаешь, что судьба клиента (упадет он или плавно перетечет с одного сервера на другой) зависит от количества серверов в кластере?
Да.

>В чем проявляется эта зависимость?

Зависимость проявляется именно в снижении вероятности падения одного конкретного клиента. Совсем грубо, в условиях сферического коня в вакууме. Чем больше серверов в кластере, тем меньше вероятность, что падение конкретного сервера затронет именно этого клиента.

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

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

(79) Хмммм... Продолжение рассуждений в ключе "третий сервер - бессмертный". Почему при распределении вероятности падения какого-либо из трёх серверов предпочтения отдаются именно центральным? Почему ставится знак равенства между падением процесса rphost и падением сервера?
Или я чего-то не понимаю....

(79) Ну так ты подтверждаешь, что Я правильно тебя понял, так?
К чему тогда пассаж "Проще отписаться, что ответ не на то сообщение, чем переспросить и/или признаться что не понял ответа"? Зачем мне признаваться в чем-то, чего нет? Не ясно...

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

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

А поясните: в чем смысл делать некоторые серверы НЕцентральными?
Если падает центральный - падает всё. Тогда логично делать центральными (а не просто рабочими) все сервера. Разве не так?

(83) Центральный обслуживает начало сеанса, т.е. принимает клиентские соединения. Как дворецкий или гардеробщик.
Рабочий сервер этого не может - он уже просто далее (в рамках своих рпхостов) обслуживает отданный ему сеанс (или "частичку" сеанса, если разнесено через ТНФ).
Во всем остальном разницы (вроде как?) нет.
Не делать рабочий центральным - ну, чтобы быстрее можно было исключить его из состава кластера, например. Хотя не особо быстрее по сравнению со снятием галочки, да)

(84) Вот именно, зачем лишать себя сервера, способного принять клиентские соединения?

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

(83) > в чем смысл делать некоторые серверы НЕцентральными?

Несколько причин.
1. Сервер включается в кластер только для выполнения какого-то ограниченного круга задач (например только какие-то определенные регламентные задания, которые невозможно или нежелательно запускать на центральных серверах).
2. Увеличение количества центральных серверов приводит к росту накладных расходов на их синхронизацию. Зачем лишние тормоза, если отказоустойчивость не критична?

Не всем нужна отказоустойчивость. Для некоторых гораздо важнее иметь возможность распределения нагрузки между серверами.

(87) 2. Не приводит. См. (68) и (69).
К сколько-нибудь заметному увеличению расходов на синхронизацию приводит _только_ повышение уровня отказоустойчивости.

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

(81) > К чему тогда пассаж
Утомил, лень объяснять, проехали.

> Ты согласен с этим?
В такой формулировке, скажем так, почти.

(82) Может и ошибаюсь, я так мыслю. Клиент вылетает, когда при падении какой-то части кластера разрушаются его сеансовые данные. Понятно, что два центральных реплицируются и сеансовые данные содержатся и там и там. Но, как мне кажется, есть определенный шанс, когда при падении одного центрального упадет и клиент. При условии везения  - на нем в момент падения были расположены и сеансовые данные и выполнялась логика, но не успела пройти репликация. Собственно для этого нужен третий сервер, что не будет выполнять клиентскую логику, а будет только обслуживать кластер.