jgroups — Обнаружение сбоя при смерти координатора группы

Документация по JGroups (http://www.jgroups.org/manual/html/index.html) говорится, что при использовании протокола обнаружения FD текущий координатор группы отвечает за обновление представления кластера, когда узел кластера умирает, но из документации не ясно, что делается, когда сам координатор группы умирает.
Например, у нас есть кластер {A,B,C,D}, и узел A здесь является координатором. Теперь, если новый член «E» хочет присоединиться, координатор запускает протокол JOIN и разрешает E присоединиться к кластеру, и если член, скажем «C», выходит из строя, тогда соседи «C» передают подозрительное сообщение, и Протокол GMS координатора исключит «C» и транслирует новое представление членам кластера. Это понятно. Но в случае смерти самого координатора группы тогда (по некоторой логике) следующий участник в этом представлении становится координатором.

  • Мой вопрос в том, как следующий участник узнает о новом представлении?
  • Канал становится координатором на данный момент и устанавливает новое представление для участников, и каждый участник проверяет, является ли он новым координатором или нет, проверяя первого/самого старого участника в представлении?

person Sayan    schedule 07.07.2016    source источник


Ответы (1)


Во-первых, вы просматриваете устаревшую документацию; новый находится по адресу http://www.jgroups.org/manual/index.html.

Когда координатор умирает, второй в очереди вступает во владение и становится новым координатором. Поэтому, если B получает сообщение SUSPECT(A), он знает, что ему нужно взять на себя управление, поскольку координата (A) потерпела крах.

Обратите внимание, что FD_ALL или FD_ALL2 предпочтительнее FD, если вы используете UDP в качестве транспорта.

person Bela Ban    schedule 08.07.2016
comment
Спасибо @Бела. Извините за просмотр устаревшей документации. Но у меня все еще есть несколько сомнений. если B получает сообщение SUSPECT(A), он знает, что должен взять на себя управление, так как координата (A) потерпела крах. - это означает, что B становится координатором, а затем B будет использовать VERIFY_SUSPECT и, в конечном итоге, исключит A из кластера и опубликует новое представление {B,C,D} для членов. Это так? Но в таком случае, если обнаружится, что после использования VERIFY_SUSPECT A жив, что будет с координацией? - person Sayan; 08.07.2016
comment
Могу я также задать вопрос, связанный с этим. Что, если B тоже рухнет? Если список участников выглядит как A, B, C, D... и одновременно происходит сбой текущего координатора и нескольких следующих кандидатов, как поведет себя система? Заранее спасибо, - person Basri Kahveci; 11.08.2016
comment
Следующий в очереди вступит во владение: если и A, и B потерпят крах, C станет новым координатором. - person Bela Ban; 13.08.2016