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