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

  • Автор темы Ferz
  • Дата начала
Ferz

Ferz

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

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

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

!Chip

Активный участник
Регистрация
27.02.2008
Сообщения
42 382
Реакции
2 255
Баллы
113
я бы не связывался с DFS.
а для баз 1С вообще необходимо отключать всякое кеширование и репликацию на шарах
лучше сделайте резервный канал
 
OP
Ferz

Ferz

Участник
Регистрация
03.02.2007
Сообщения
8 779
Реакции
24
Баллы
38
я бы не связывался с DFS.
Почему такое отношение к DFS?
для баз 1С вообще необходимо отключать всякое кеширование и репликацию на шарах
Пока только бекап на это дело. Вот до репликации дошел и задумался, а не натворит ли она мне делов в моем случае.
лучше сделайте резервный канал
Бывает, что вылетает оборудование в стойке. Устраняется конечно оперативно, но работа удаленных пользователей стоит. Именно по этой причине и ищу способ чтобы удаленные пользователи имели доступ к актуальной информации хотя бы в режиме "только на чтение", ну и их авторизация на AD.
 
DAE

DAE

Moderator
Регистрация
11.07.2007
Сообщения
27 197
Реакции
71
Баллы
48
я понятия не имею что такое DFS, поэтому попробую посоветовать исходя из опыта реплицирования web-сервисов вообще, и sql master-master в частности.

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

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

DAE

Moderator
Регистрация
11.07.2007
Сообщения
27 197
Реакции
71
Баллы
48
Именно по этой причине и ищу способ чтобы удаленные пользователи имели доступ к актуальной информации хотя бы в режиме "только на чтение", ну и их авторизация на AD.
В таком случае мне кажется более оптимальным не извращаться с репликацией (которая предназначена все таки для защиты от выхода из строя железа-сторейджа), а озаботиться резервными каналами связи к основному серверу
 
OP
Ferz

Ferz

Участник
Регистрация
03.02.2007
Сообщения
8 779
Реакции
24
Баллы
38
Если более приоритетными являются внутренние - то 2й сервер должен быть read only как ты и говорил
Видимо так и буду поступать.

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

озаботиться резервными каналами связи к основному серверу
В данном случае не осуществимо. Уже обсасывал эту тему.
 
DAE

DAE

Moderator
Регистрация
11.07.2007
Сообщения
27 197
Реакции
71
Баллы
48
Как в таких случаях синхронизировали инфу? Простое ее копирование на отвалившийся сервер и запуск репликации по новой?
в случае mysql реплицация может быть master-slave или master-master

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

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

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

Ferz

Участник
Регистрация
03.02.2007
Сообщения
8 779
Реакции
24
Баллы
38
Спасибо. Один из вариантов решения проблемы понял.
Осталось с DFS мануал докурить.

Не видел если честно, можно ссылку?
Это было обсуждено внутри организации с соответствующим отделом. Подробности можно отнести к коммерческой тайне :)
 
!Chip

!Chip

Активный участник
Регистрация
27.02.2008
Сообщения
42 382
Реакции
2 255
Баллы
113
Почему такое отношение к DFS?
после 4-х лет использования решил от неё отказаться, причин много.

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


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


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

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

Ferz

Участник
Регистрация
03.02.2007
Сообщения
8 779
Реакции
24
Баллы
38
ибо мало кому из пользователей надо просто смотреть
В моем случае и да и нет.

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

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

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

dalex

Новичок
Регистрация
15.02.2006
Сообщения
17 333
Реакции
49
Баллы
0
Но настает час Х и связь между серверами восстанавливается, запускается процесс репликации и тут я теряюсь.
Ясен перец система за тебя не будет сводить экселевские таблички в одну.
 
!Chip

!Chip

Активный участник
Регистрация
27.02.2008
Сообщения
42 382
Реакции
2 255
Баллы
113
Можно основные услышать? Я сам с DFS еще не работал, и про возможные траблы не знаю или знаю не все.
косяков особо нет, если конечно AD работает нормально, просто в моём варианте я решил упростить систему.
 
Oleg249

Oleg249

Активный участник
Регистрация
20.05.2008
Сообщения
4 774
Реакции
46
Баллы
48
в случае 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

DAE

Moderator
Регистрация
11.07.2007
Сообщения
27 197
Реакции
71
Баллы
48
Присутствует только в innodb.
Но его скорость работы категорически не устраивает
 
Верх Низ