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

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

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

1. Отсутствие отказов.
2. Полный отказ одного или нескольких узлов (crash): узел упал и больше гарантированно никогда не поднимается. Не отвечает на сообщения, не посылает свои.
3. Полный отказ одного или нескольких каналов связи (link failure): сообщения между парой процессов с некоторого момента никогда не доставляются. Можно проэмулировать отказ узла, убрав все ведущие к нему каналы. Тут тонко с алгоритмами, которые требуют что-нибудь для всех живых узлов, но это ладно. (Не)ориентированность не обсуждали.
4. Ненадёжная доставка сообщений (omission): сообщения между парой процессов иногда теряются, а иногда доходят. Можно проэмулировать полный отказ канала, сказав, что теряются всегда.
5. Византийская ошибка (byzantine failure): есть один или несколько "византийских" процессов, которые могут делать что угодно: игнорировать сообщения, посылать любые сообщения любым процессам, с которыми есть связь (в том числе не соответствующие протоколу). В частности, "византийский" процесс может имитировать процесс, с которым плохая связь.

Также полезно разделить синхронные/асинхронные системы.

• Синхронные системы
  • Известно, что любое сообщение либо доставляется за некоторое время $C$, либо полностью исчезает
  • Тогда можно разбить выполнение алгоритма на фазы длиной $O(C)$: в начале фазы все процессы отправляют сообщения, потом ждут, а в конце знают, что получили все сообщения, которые только могли прийти
• Асинхронные системы
  • Время передачи сообщения сверху не ограничено
  • Но гарантируется, что если нет отказов, то сообщение рано или поздно дойдёт
  • Мы принципиально не можем использовать таймауты, поэтому нельзя смотреть на время даже внутри одного процесса: он либо что-то делает внутри себя, либо ждёт очередного сообщения бесконечно долго.

Асинхронную систему можно на практике попробовать(?) превратить в синхронную при помощи таймаутов: к каждому сообщению прикрепляем wall clock time (которое не может быть идеально синхронизировано в распределённой системе, но на практике хоть как-то можно, сбои не всегда играют против нас) и игнорируем слишком старые сообщения. Надо аккуратно поиграть с определениями и учесть погрешность и потребовать, чтобы часы не расходились, возможно, ещё что-то. Выберем большой таймаут — будет тормозить, выберем маленький — будут большие потери сообщений.

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

На практике могут использоваться алгоритмы и для тех, и для других.