Как классифицировать детектор отказов?

Я понимаю, что детекторы отказов в асинхронных системах в основном классифицируются как (в конечном счете) совершенные/(в конечном итоге) сильные и как определяются эти классы, но я изо всех сил пытаюсь понять, что за этим стоит.

Предположим, у меня есть конкретная реализация детектора сбоев, который периодически прослушивает сообщения heartbeat от каждого процесса. Если процесс какое-то время не отправлял свое контрольное сообщение, этот процесс будет добавлен в список подозрительных до тех пор, пока от процесса не будет получено сообщение.

Теперь, как мне узнать, какой класс является этой реализацией FD? Потребуется ли для этого формальное доказательство свойств полноты/точности FD? Если можно реализовать идеальный FD, зачем изучать другие (более слабые)? Или классы только «предполагаются» при разработке отказоустойчивых распределенных алгоритмов?

Я немного озадачен этим (как на самом деле классифицировать данный (конкретный) FD). Буду признателен за любые ответы.


person Andy Scott    schedule 15.03.2015    source источник


Ответы (1)


Сначала вам нужно смоделировать синхронность процессов и связей между ними; например: «все процессы могут в конечном итоге взаимодействовать своевременно, сообщения передаются в течение известного срока, а процессы выполняют крайние сроки в пределах известного срока». Как только вы определите такую ​​модель, вы сможете проанализировать конкретный алгоритм и определить его класс (и доказать это).

Различные классы детекторов отказов полезны для инкапсуляции и абстрагирования от таких базовых предположений при разработке алгоритмов более высокого уровня. Их также можно использовать для определения того, какие проблемы (консенсус, широковещательная рассылка, выборы слабого лидера и т. д.) сложнее/легче решить в зависимости от требуемого класса детектора отказов.

В отличие от того, что указано в вашем вопросе, идеальный FD не может быть реализован ни в одной модели системы. Фактически, одна активная область исследований заключается в поиске минимальных требований к синхронности, таких как, например, детектор отказов омега (см. статью «Омега встречает Паксос»).

Вы можете представить различные сценарии, в которых синхронность является лишь частичной, например, некоторые ссылки слишком ненадежны, некоторые процессы защищены брандмауэрами (исходящие сообщения разрешены, но не входящие) и т. д. Когда вы моделируете синхронность конкретных развертываний, а затем отвечаете на вопрос того, какой ФД можно построить на такой модели, вы одновременно отвечаете, какие задачи можно решить в этой модели (и, следовательно, в том развертывании).

person danyhow    schedule 16.03.2015
comment
Верно, просто чтобы уточнить, фактический класс зависит от модели сети? Кроме того, разрабатывают ли люди алгоритмы для конкретного класса FD, а не для конкретной модели сети? т.е. вместо того, чтобы сказать, что я разработал алгоритм решения проблемы P в сети со всеми этими предположениями A... они сказали бы, что я разработал алгоритм решения P с использованием детектора отказов класса C? (где C может быть реализован на модели с предположениями A). Надеюсь, это понятно. Кстати, спасибо за ваш ответ! - person Andy Scott; 19.03.2015
comment
Просто обратите внимание, что фактический класс зависит от модели сети, следует читать фактический класс зависит от модели системы, где модель системы относится к сетевым процессам и. (потому что, если сеть идеально синхронна, но процессы никогда не бывают своевременными, вам может быть невозможно создать некоторые классы обнаружения сбоев) - person danyhow; 19.03.2015
comment
Ох, хорошо. Не могли бы вы также уточнить, верны ли те утверждения, которые я сделал в своем предыдущем комментарии? - person Andy Scott; 22.03.2015
comment
Да. Когда люди используют абстракцию детектора отказов, они разрабатывают свой алгоритм, предполагая, что у них есть доступ к детектору отказов данного класса. Возможно, этот опрос поможет вам в дальнейшем. - person danyhow; 26.03.2015