Доброго всем дня! Возникла необходимость резервирования кластера 1с. Сделали 2 центральных сервера, уровень отказоустойчивости "0". Один сервер рядом с пользователями, доступен локально, второй - удаленный, доступен по интернету. Второй должен использоваться только если упадет первый, т.к. до него узкий канал. Ну и собственно вопрос: как сделать, чтобы пользователи, если жив первый - назначались на него, а если нет - то на второй. Требованиями назначения функциональности знаю как совсем запретить клиентские соединения. Но этот вариант не подходит, т.к. нужно вручную будет тогда их отключить на втором сервере при падении первого. Господа, какие есть еще варианты? Есть еще вариант, создать скрипт, который будет пинговать первый кластер, и , если он недоступен через RAS поменять ТНФ, но вариант замороченный, и не факт, что RAS это умеет.

(0) Что случилось, что возникла такая необходимость?

Требования руководства случились). Простои крайне критичны для бизнеса.

Панятна.

(0) канал ооооочень толстый?

(0) >т.к. до него узкий канал.

если первый рухнет - то потянет за собой второй в могилу... пробовали

(5) А как разделяли сеансы? Канал узкий, но это только на время, пока воскрешаем первый сервер.

(6) Я думаю, у них стоит отдельная настроенная машина с тем же доменным именем/IP, которая тупо включается при случае катаклизма вместо основного сервера.

(7) Думали про такой вариант, но в таком случае, если кто-то умудриться зайти на резервный сервер, то возможно пересечение УИДОВ, т.к. службы УИДОВ между серверами при такой настройке не синхронизируются.

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

(8) Просто не включайте его.

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

(9) Если на обоих серверах будут запущены центральные кластеры 1с, то база выживет(пользователям придется перезайти в базу), только из-за канала будут тормоза. Но с временными тормозами можно жить.

(0) Встроеная справка,"Строка соединения":

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

?

(13) Вот это уже интересно. Спасибо. А приоритеты как разруливаются? Если первый не получается, то ко второму? Или как рпхосты по памяти и по производительности?

Серверу с СУБД уже обеспечили 100%-ю отказоустойчивость? А то никакое резервирование 1С не поможет, если он, вдруг, испортится.

(15) Да, SQL зарезервирован.

(14) Скорей всего тупо по порядку. Если не сможет соединится или получит отлуп - пойдет на следующий.
Есть еще вариант попробовать при падении сервера просто переставлять DNS на новый

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

https://is1c.ru/about/pc/article/klaster-serverov-1s/ Судя по этой статье, в том месте, где описывается механика ТНФ, нужно на 2-х серверах назначить ТНФ "Клиентские соединения, назначать", но с разным приоритетом. Но это не точно)

(0) Не нравятся мне все эти "устойчивоотказывающие" решения. Проще руками передернуть провод как в (7). Чем сложнее система, тем больше вероятность что она сломается. Да и второй сервер по сути в простое всегда.