>
> Есть Мастер(M), и зеркала: A и Б. Над ними стоит несколько
> редиректоров, работающих по ранее предложеной схеме.
>
> Если (М) становится недоступным пользователю (U), то он(U) попадает на
> А. Если не доступен А, то попадает на Б.
Редиректор не знает доступен ли М, А и Б пользователю. Максимум что
он знает - доступен ли М, А, Б редиректору. Что не одно и то же -
связность в интернете не транзитивна.
Далее. Если редиректоров несколько, то для одного из них доступным
может остаться М, для другого - А. Которых каждый из редиректоров
и будет считать главным - как единственно доступного.
При этом и М и А продадут тот самый последний билет.
Если редиректор один, то он становится той самой single point of failure,
соответственно выгодно с точки зрения надежности вынести мастера
туда же и получить более надежную систему.
> При этом каждый ((М) А, Б) обмениваются сообщениями вида "я жив!"
> Если Мастер не получает сообщения от А и Б, то блокирует операцию и
> выдаёт редирект на редиректор, который отправляет (U) на то из зеркал,
При этом на самом деле отвалились именно А и Б, а мастер - жив
( но сообщений от А и Б не получил - связности нет)
Но он выдаст редирект на редиректор, который отправит на одно из
зеркал - которые на самом деле отвалились от пользователя. Или
не отвалились :)
> которое живо в порядке очереди. На тот момент, когда Мастер не выдаёт
> "Я жив", A становится Мастером.
То-есть мы считаем A главным. Что делать, если именно он отвалился
от сети - в этом случае ни он не получит сообщения от Мастера, ни
Мастер от него.
Я все-таки предлагаю забыть о редиректорах и рассмотреть совсем
простую ситуацию - есть M и А с синхронизированной базой в которой
происходят операции UPDATE. Связь между ними нарушилась, но
запросы от пользователей продолжают поступать (т.е. интернет
частично жив). Кто из двух будет продолжать обслуживание, а кто не будет ?
Если будут оба, то последний билет будет продан два раза.
Если будет только один, то на второй нужно поставить proxy
и забыть об этом :). Ситуация на самом деле симметричная, поэтому
главный в такой ситуации должен быть назначен заранее.
Алексей Тутубалин
mailto: lexa@lexa.ru
Web:
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
