Вопрос по репликации DFS

[Ferz]

Делаю отказоустойчивую систему из 2х серверов на базе ОС Win2008R2 std. Запнулся на проблеме с репликацией DFS.
Суть следующая - в офисе находится основой сервер. В другом здании находится вспомогательный сервер. Все пользователи работают с основным сервером(в том числе и удаленные пользователи), вспомогательный установлен на случай, если главный офис окажется "отрезанным от интернета" и в этом случае удаленные пользователи авторизируются и продолжают работать на вспомогательном сервера(происходят изменения\создания\удаления данных), в это время пользователи, находящиеся в главном офисе, продолжают работать с основным сервером, так же создавая\удаляя\изменяя данные. Но настает час Х и связь между серверами восстанавливается, запускается процесс репликации и тут я теряюсь. Что произойдет с данными, которые были изменены?

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

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

 

[!Chip]

я бы не связывался с DFS.
а для баз 1С вообще необходимо отключать всякое кеширование и репликацию на шарах
лучше сделайте резервный канал

 

[Ferz]

я бы не связывался с DFS.

Почему такое отношение к DFS?

для баз 1С вообще необходимо отключать всякое кеширование и репликацию на шарах

Пока только бекап на это дело. Вот до репликации дошел и задумался, а не натворит ли она мне делов в моем случае.

лучше сделайте резервный канал

Бывает, что вылетает оборудование в стойке. Устраняется конечно оперативно, но работа удаленных пользователей стоит. Именно по этой причине и ищу способ чтобы удаленные пользователи имели доступ к актуальной информации хотя бы в режиме "только на чтение", ну и их авторизация на AD.

 

[DAE]

я понятия не имею что такое DFS, поэтому попробую посоветовать исходя из опыта реплицирования web-сервисов вообще, и sql master-master в частности.

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

Стратегий решений может быть много, в зависимости от того какие пользователи являются приоритетными
Если более приоритетными являются внутренние - то 2й сервер должен быть read only как ты и говорил
Если более приоритетные внешние - то read only должен стать основной сервер на время краша

 

[DAE]

Именно по этой причине и ищу способ чтобы удаленные пользователи имели доступ к актуальной информации хотя бы в режиме "только на чтение", ну и их авторизация на AD.

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

 

[Ferz]

Если более приоритетными являются внутренние - то 2й сервер должен быть read only как ты и говорил

Видимо так и буду поступать.

в mysql была бы просто ошибка синхронизации)

Как в таких случаях синхронизировали инфу? Простое ее копирование на отвалившийся сервер и запуск репликации по новой?

озаботиться резервными каналами связи к основному серверу

В данном случае не осуществимо. Уже обсасывал эту тему.

 

[DAE]

Как в таких случаях синхронизировали инфу? Простое ее копирование на отвалившийся сервер и запуск репликации по новой?

в случае mysql реплицация может быть master-slave или master-master

для master-slave запросы на чтение могут идти к обоим серверам, а на запись - только к master.
если умирает slave - всем пофиг)
если умирает master - slave становится master. когда master оживет на него будет залит текущий дамп со slave и он снова станет master. как правило это сопровождается остановкой сервиса не некоторое непродолжительное время.
если рвется коннект между slave и master - слейв считается умершим(!)

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

PS с учетом нашей специфики (оборудование в датацентрах), вероятность физической смерти сервера в десятки раз выше чем потеря связи между ними

 

[DAE]

В данном случае не осуществимо. Уже обсасывал эту тему.

Не видел если честно, можно ссылку?

 

[Ferz]

Спасибо. Один из вариантов решения проблемы понял.
Осталось с DFS мануал докурить.

Не видел если честно, можно ссылку?

Это было обсуждено внутри организации с соответствующим отделом. Подробности можно отнести к коммерческой тайне

 

[!Chip]

Почему такое отношение к DFS?

после 4-х лет использования решил от неё отказаться, причин много.

Для работы режим read_only не подходит, ибо мало кому из пользователей надо просто смотреть, у тебя один верный вариант это организация бесперебойной связи м\у офисами. всё остальное порно

Бывает, что вылетает оборудование в стойке.

меняй

Вот до репликации дошел и задумался, а не натворит ли она мне делов в моем случае.

натворит, либо в лучшем случае ктото один потеряет изменения в файлах

 

[Ferz]

ибо мало кому из пользователей надо просто смотреть

В моем случае и да и нет.

меняй

см. ответ для DAE

ктото один потеряет изменения в файлах

А это может привести к тому, что клиент останется без услуг, либо ее окажут тому, кто от услуг отказался )))

причин много.

Можно основные услышать? Я сам с DFS еще не работал, и про возможные траблы не знаю или знаю не все.

 

[dalex]

Но настает час Х и связь между серверами восстанавливается, запускается процесс репликации и тут я теряюсь.

Ясен перец система за тебя не будет сводить экселевские таблички в одну.

 

[Ferz]

Ясен перец система за тебя не будет сводить экселевские таблички в одну.

Было бы иначе, я бы тему не создавал.

 

[!Chip]

Можно основные услышать? Я сам с DFS еще не работал, и про возможные траблы не знаю или знаю не все.

косяков особо нет, если конечно AD работает нормально, просто в моём варианте я решил упростить систему.

 

[Oleg249]

в случае mysql реплицация может быть master-slave или master-master

для master-slave запросы на чтение могут идти к обоим серверам, а на запись - только к master.
если умирает slave - всем пофиг)
если умирает master - slave становится master. когда master оживет на него будет залит текущий дамп со slave и он снова станет master. как правило это сопровождается остановкой сервиса не некоторое непродолжительное время.
если рвется коннект между slave и master - слейв считается умершим(!)

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

PS с учетом нашей специфики (оборудование в датацентрах), вероятность физической смерти сервера в десятки раз выше чем потеря связи между ними

А что, в mysql 2-phase commit в распределенных базах отсутствует? :dirol: Или там вообще commit как класс отсутствует?

 

[DAE]

Присутствует только в innodb.
Но его скорость работы категорически не устраивает