Hello Alex,
Thursday, October 31, 2002, 12:56:52 AM, you wrote:
> А если мастер и один редиректор оказались в одной половине интернета
> (вместе с частью клиентов), зеркало и другой редиректор - в другой ?
> Между двумя половинками (M9 развалилась, скажем) интернет не ходит.
Редиректор видит мастера, но не видит остальных.
Он считает себя died, и отказывается принимать решение, редиректит на
корень редиректоров, это происходит до тех пор, пока днс не выдаст ip
из другой половинки, или не восставновится целостность сети.
>> Не обязательно. Редиректоры получают "я жив" от Мастера и зеркал,
>> кстати точно так-же они могут обмениваться информацией о том, кто
>> получает какой сигнал от других.
> Могут. Но это эскалация той же проблемы на уровень редиректоров.
Это позволяет более точно установить кто выпал.
>> Почему бы редиректору не _вспомнить_, какую информацию об этом
>> "дисконнекте" имеют остальные? Если остальные видят, что А и Б
>> недоступны, а Мастер жив, то считать его active.
> А если система из трех редиректоров и трех серверов БД распалась
> на три сегмента ? Каждый видит ровно один сервер БД.
> Я специально предлагаю симметричные случаи - они проще для анализа.
Предложеный вариант излишне притянут за уши.
Почему бы не держать зеркала и редиректоры в разных сегментах
изначально?
Если прекратил работать интернет, то происходят редиректы на корень до
того момента, пока несколько не увидят друг друга, и хотябы один из
них не увидит Мастера А или Б.
>> В ситуации необходим сторонний арбитр, = редиректор, который при
>> наличии ответов и от Мастера, и от А, установит на Мастере статус
>> Active,
> Я уже писал - если сторонний арбитр один, то он является SPF
> (и никто не гарантирует, что от сети не отвалился именно он)
> Если арбитров несколько - возникает проблема выборов среди них,
> которая ничем не отличается от выбора главного из серверов БД.
Текущий Арбитр принявший запрос от посетителя ориентируясь на данные
как остальных редиректоров, так и своих в случае, если Мастер
недоступен(Всем) передаёт active на А, и информирует об этом остальных
редиректоров, после чего они все считают A текущим Мастером.
>>если Мастера будеТ видеть только один редиректор из скажем 10,
>> то он на критический период берёт на себя функцию proxy.
> Олег, напишите все это в (псевдо)коде.
Зачем? =)
Первичная задача (про нерабочий Хост1 и рабочий Хост2) у меня работают
в штатном режиме, и проблем не возникает.
Все остальные рассуждения идут на уровне: "а вот если будет так..".
Практическая задача всегда будет иметь собственные ньюансы, причём
предугадать в каком именно месте может произойти отказ сложно.
Предусмотреть можно многое, но не всё.
Поэтому писать любой код имеет смысл, только в случае, если ситуацию
можно обкатать в железе, в реальных условиях.
> Можно выдвигать всякие забавные идеи, но они должны алгоритмизироваться.
> Я пока ничего разумного для алгоритмизации не увидел, кроме
> благих пожеланий "хорошо бы сделать так" (действительно, неплохо),
> "редиректоры могут обмениваться информацией" (действительно, могут).
> Ну а толку то.
Имея достаточно большое число редиректоров, можно иметь достаточно
полную информацию о том, кто отвалился, а кто жив.
Best regards,
Oleg mailto:ilin@rinet.ru
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
