Иерархия ошибок в распределённых системах — различия между версиями

Материал из Викиконспекты
Перейти к: навигация, поиск
(Новая страница: «То, что принципиально усложняет жизнь в распределённых системах — проблемы с доставкой…»)
 
м (rollbackEdits.php mass rollback)
 
(не показаны 3 промежуточные версии 3 участников)
Строка 1: Строка 1:
 +
[[Категория:Параллельное программирование]]
 
То, что принципиально усложняет жизнь в распределённых системах — проблемы с доставкой сообщений, отказы процессов и каналов связи.
 
То, что принципиально усложняет жизнь в распределённых системах — проблемы с доставкой сообщений, отказы процессов и каналов связи.
  
Строка 4: Строка 5:
 
Более сложный отказ может моделировать более простой, т.е. алгоритм, который хорошо работает с более сложным отказом, с более лёгким тоже должен справиться.
 
Более сложный отказ может моделировать более простой, т.е. алгоритм, который хорошо работает с более сложным отказом, с более лёгким тоже должен справиться.
 
# Отсутствие отказов.
 
# Отсутствие отказов.
−
# Полный отказ одного или нескольких узлов (crash): узел упал и больше гарантированно никогда не поднимается. Не отвечает на сообщения, не посылает свои.
+
# Полный отказ одного или нескольких узлов (crash): узел упал и больше гарантированно никогда не поднимается. Не отвечает на сообщения, не посылает свои. "Воскреснуть" тоже не может. На практике этого можно достичь, если каждому процессу давать в начале случайное число, а при перезапуске его генерировать заново.
 
# Полный отказ одного или нескольких каналов связи (link failure): сообщения между парой процессов с некоторого момента никогда не доставляются. Можно проэмулировать отказ узла, убрав все ведущие к нему каналы. Тут тонко с алгоритмами, которые требуют что-нибудь для всех живых узлов, но это ладно. (Не)ориентированность не обсуждали.
 
# Полный отказ одного или нескольких каналов связи (link failure): сообщения между парой процессов с некоторого момента никогда не доставляются. Можно проэмулировать отказ узла, убрав все ведущие к нему каналы. Тут тонко с алгоритмами, которые требуют что-нибудь для всех живых узлов, но это ладно. (Не)ориентированность не обсуждали.
 
# Ненадёжная доставка сообщений (omission): сообщения между парой процессов иногда теряются, а иногда доходят. Можно проэмулировать полный отказ канала, сказав, что теряются всегда.
 
# Ненадёжная доставка сообщений (omission): сообщения между парой процессов иногда теряются, а иногда доходят. Можно проэмулировать полный отказ канала, сказав, что теряются всегда.
 
# Византийская ошибка (byzantine failure): есть один или несколько "византийских" процессов, которые могут делать что угодно: игнорировать сообщения, посылать любые сообщения любым процессам, с которыми есть связь (в том числе не соответствующие протоколу). В частности, "византийский" процесс может имитировать процесс, с которым плохая связь.
 
# Византийская ошибка (byzantine failure): есть один или несколько "византийских" процессов, которые могут делать что угодно: игнорировать сообщения, посылать любые сообщения любым процессам, с которыми есть связь (в том числе не соответствующие протоколу). В частности, "византийский" процесс может имитировать процесс, с которым плохая связь.
−
 
−
Также полезно разделить синхронные/асинхронные системы.
 
−
* Синхронные системы
 
−
** Известно, что любое сообщение либо доставляется за некоторое время $C$, либо полностью исчезает
 
−
** Тогда можно разбить выполнение алгоритма на фазы длиной $O(C)$: в начале фазы все процессы отправляют сообщения, потом ждут, а в конце знают, что получили все сообщения, которые только могли прийти
 
−
* Асинхронные системы
 
−
** Время передачи сообщения сверху не ограничено
 
−
** Но гарантируется, что если нет отказов, то сообщение рано или поздно дойдёт
 
−
** Мы принципиально не можем использовать таймауты, поэтому нельзя смотреть на время даже внутри одного процесса: он либо что-то делает внутри себя, либо ждёт очередного сообщения бесконечно долго.
 
−
 
−
Асинхронную систему можно на практике попробовать(?) превратить в синхронную при помощи таймаутов: к каждому сообщению прикрепляем wall clock time (которое не может быть идеально синхронизировано в распределённой системе, но на практике хоть как-то можно, сбои не всегда играют против нас) и игнорируем слишком старые сообщения. Надо аккуратно поиграть с определениями и учесть погрешность и потребовать, чтобы часы не расходились, возможно, ещё что-то.
 
−
Выберем большой таймаут — будет тормозить, выберем маленький — будут большие потери сообщений.
 
−
 
−
Если решили задачу для асинхронной системы, то в синхронной будет работать то же самое.
 
−
Но, возможно, для синхронной системы существует более эффективный алгоритм.
 
−
 
−
На практике могут использоваться алгоритмы и для тех, и для других.
 

Текущая версия на 19:43, 4 сентября 2022

То, что принципиально усложняет жизнь в распределённых системах — проблемы с доставкой сообщений, отказы процессов и каналов связи.

Мы рассматриваем пять видов отказов, в порядке усложнения. Более сложный отказ может моделировать более простой, т.е. алгоритм, который хорошо работает с более сложным отказом, с более лёгким тоже должен справиться.

  1. Отсутствие отказов.
  2. Полный отказ одного или нескольких узлов (crash): узел упал и больше гарантированно никогда не поднимается. Не отвечает на сообщения, не посылает свои. "Воскреснуть" тоже не может. На практике этого можно достичь, если каждому процессу давать в начале случайное число, а при перезапуске его генерировать заново.
  3. Полный отказ одного или нескольких каналов связи (link failure): сообщения между парой процессов с некоторого момента никогда не доставляются. Можно проэмулировать отказ узла, убрав все ведущие к нему каналы. Тут тонко с алгоритмами, которые требуют что-нибудь для всех живых узлов, но это ладно. (Не)ориентированность не обсуждали.
  4. Ненадёжная доставка сообщений (omission): сообщения между парой процессов иногда теряются, а иногда доходят. Можно проэмулировать полный отказ канала, сказав, что теряются всегда.
  5. Византийская ошибка (byzantine failure): есть один или несколько "византийских" процессов, которые могут делать что угодно: игнорировать сообщения, посылать любые сообщения любым процессам, с которыми есть связь (в том числе не соответствующие протоколу). В частности, "византийский" процесс может имитировать процесс, с которым плохая связь.
Источник — «http://neerc.ifmo.ru/wiki/index.php?title=Иерархия_ошибок_в_распределённых_системах&oldid=85883»