Вообщем есть площадка в виде главного офиса
Есть дата центр
Есть идентичные сервера 1С 8.2 на SQL
Пользователь работает в 1С и затем сервер падает в головном офисе
Пользователь запускает 1С ярлык терминала, запускает 1С из дата центра, продолжает работу с базой

Вопрос, как реплицировать данные в режиме реального времени ? между разнесенными площадками....
Сначала думал о встроенном в SQL но почитав, понял что для 1С может не сработать..
Есть какой то годный вариант?
При чем, предположим, что Тетя Клава, забыла что сервер в головном офисе обратно поднялся, продолжает пользоваться 1С терминалом...

Как решить данный вопрос?

(0)[Сначала думал о встроенном в SQL но почитав, понял что для 1С может не сработать.. ]
ошибся
1С ни чем от любой другой транзакционной базки не отличается

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

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

Прошу помощи именно какой подход мне нужно копать? надстройка над 1С, SQL зеркалирование, репликация....
Возможно какаой то вариант настройки кластера? учитывая ВАН сегмент между базами.....

По моему как то один раз ошибочно добавил одну и ту же sql базу в разных кластеров и работало.

При подходе кластера, учитывая что сервера локально стоят и латентности нет.
Если я просто сделаю кластер с датацентром, при падение головного офиса, даже если люди переключаться на датацентр, через ОБОЛОЧКУ 1С, работать не будет.... так как задержка будет большой. Будет постоянно выпадать ошибки хершибки и прочее приключения, поэтому для датацентра, я рассматирваю только РДП подключение.

А тут получается, что кластер то есть, но тип подключения отличается, в головном офисе это ОБОЛОЧКА а датацентр это РДП

Или я не прав?

смешались люди кони кластера..

помогите не путать теплое с мягким, буду благодарен

вам нужно настроить зеркалирование на SQL серверах.
И делать ручной файловер для переключения ролей.
Соответственно на резервном сервере 1С у вас должна будет зарегена зеракальная база.

То есть мне не нужно что то читать о Кластере или РИБ, достаточно синхронного зеркалирования между офисом и дата центром, потом переключить РОЛЬ, что бы вышел из режима восстановления, объяснить людям что нужно запускать в такой ситуации уже не ОБОЛОЧКУ, а РДП файлик, они конектятся к базе и продолжают работать?

(7) +1
или Репликация и доставка журналов

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

Очень приятно выглядит AlwaysOn Availability Groups. Сейчас поднимаю для баз 7.7. В тестовой эксплуатации проверено, скоро будет продакшн.

(8) Да, но сначала нужно после смены ролей праймари базу зарегить на сервере 1С.

(11) да AG крутая штука, но нужен Enterprise. Если он есть то конечно лучше заюзать его.

Спасибо, проверю что к чему
для прокладок вроде нужен 2012? или 2008R2 подайдет? ( в редакции ентр )

(14) http://msdn.microsoft.com/en-us/library/ff878487.aspx