7.7. Итоги

Отказоустойчивость — это важная область построения распределенных систем. Отказоустойчивость определяется как способность системы маскировать появле­ние ошибок и исправлять их. Другими словами, система отказоустойчива, если она продолжает функционировать при наличии отказов.

Существуют разные типы отказов. Поломка означает простую остановку сис­темы. Пропуск данных наблюдается в том случае, если процесс не реагирует на входящие запросы. Если процесс отвечает слишком быстро или слишком мед­ленно, мы говорим об ошибке синхронизации. Отклик на входящий запрос с ошиб­кой — пример ошибки отклика. Сложнее всего обрабатывать ситуации, когда в процессе может случиться ошибка любого типа. Такие ошибки называют произ­вольными или византийскими.

Избыточность — это стандартный способ обеспечения отказоустойчивости. Если избыточность применяется к процессам, становится важным понятие груп­пы процессов. Процессы в группе тесно взаимодействуют между собой для пре­доставления некоторой услуги. В отказоустойчивых группах один или более процессов могут отказать, не оказывая при этом заметного влияния на доступ­ность услуги, реализуемой группой. Часто необходимо, чтобы взаимодействие внутри группы было высоконадежным и в плане обеспечения отказоустойчиво­сти поддерживало свойства строгой упорядоченности и атомарности.

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

Проблемы усложняются, когда требуется соблюсти атомарность. В протоко­лах атомарной групповой рассылки важно, чтобы каждый член группы имел оди­наковое представление о том, каким элементам группы доставляется сообщение. Атомарная групповая рассылка должна быть точно сформулирована в понятиях модели виртуально синхронного выполнения. В частности, эта модель вводит гра­ницы, внутри которых членство в группах не меняется, а сообщения передаются надежно. Сообщения никогда не пересекают границ.

Механизм изменения членства в группе — это пример того, что каждый про­цесс должен согласиться с единым списком членов. Такое соглашение может быть заключено при помощи протоколов подтверждения, самым распространен­ным из которых является протокол двухфазного подтверждения. В условиях протокола двухфазного подтверждения координатор сначала проверяет готов­ность всех процессов к выполнению одной и той же операции (то есть к ее под­тверждению), а на втором этапе рассылает результат этого голосования. Прото­кол трехфазного подтверждения используется для того, чтобы справиться с отказом координатора без необходимости блокировать все процессы, для дости­жения соглашения дожидаясь восстановления координатора.

Восстановление в отказоустойчивых системах неизменно организуется на ос­нове регулярного сохранения информации о состоянии системы. Работа с кон­трольными точками полностью распределена. К сожалению, создание контроль­ной точки — довольно затратная операция. Для повышения производительности множество распределенных систем сочетают контрольные точки с протоколиро­ванием сообщений. Благодаря протоколированию взаимодействия между про­цессами после отказа системы можно воспроизвести ход ее функционирования.

Вопросы и задания

1. Надежные системы часто требуют обеспечения высокой степени защиты. По­чему?

2. Что делает модель аварийной остановки трудной для реализации в случае по­ломок?

3. Рассмотрим web-браузер, возвращающий устаревшие страницы из кэша, а не обновленные с сервера. Является ли это ошибкой, и если да, какой это тип ошибки?

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

5. Сколько отказавших элементов (обычных устройств и устройств голосова­ния) может быть обработано схемой, представленной на рис. 7.1? Дайте при­мер ошибки, которая может быть замаскирована.

6. Можно ли обобщить тройное модульное резервирование на пять элементов в группе вместо трех? Если да, какие свойства будет оно иметь?

7. Для какого из следующих приложений, по вашему, наилучшим образом по­дойдет семантика «минимум однажды» или «максимум однажды»? Дайте раз­вернутое объяснение.

• Чтение и запись файлов на файловый сервер.

• Компиляция программы.

• Домашний банк.

8. В случае асинхронных вызовов RPC клиент блокируется до момента получе­ния его запроса сервером (см. рис. 7.12). В какой степени наличие ошибок влияет на семантику асинхронных вызовов RPC?

9. Приведите пример, когда для группового взаимодействия вообще не нужно никаких синхронизирующих сообщений.

10. Всегда ли в надежных групповых рассылках есть необходимость в том, чтобы копии сообщений сохранялись на коммуникационном уровне с целью по­вторной посылки?

11. В какой степени важна масштабируемость для атомарных групповых рассы-лок?

12. В тексте мы предложили, что при атомарной групповой рассылке можно со­хранять дату осуществления изменения согласного на это набора процессов. В какой степени мы можем гарантировать, что каждое из изменений действи­тельно было сделано?

13. Виртуальная синхронность аналогична слабой непротиворечивости распреде­ленных хранилищ данных с изменениями представления групп в качестве то­чек синхронизации. В этом контексте что будет аналогом строгой непротиво­речивости?

14. Каков разрешенный порядок доставки для комбинации FIFO и полностью упорядоченной групповой рассылки (см. табл. 7.3)?

15. Адаптируйте протокол для установки следующего представления в слу­чае виртуальной синхронности, чтобы он мог противостоять ошибкам в про­цессах.

16. Почему в протоколе двухфазного подтверждения невозможно полностью ис­ключить блокировку, даже в случае выбора участниками нового координа­тора?

17. Из нашего объяснения механизма трехфазного подтверждения можно по­нять, что завершение транзакции определяется большинством голосов. Так ли это?

18. В случае кусочно детерминированной модели достаточно ли заносить в жур­нал только сообщения? Или также требуется протоколировать другие собы­тия?

19. Опишите, как для восстановления после отказов можно использовать в рас­пределенных транзакциях журнал с упреждающей записью.

20. Нуждается ли в создании контрольных точек сервер без фиксации состоя­ния?

21. Протоколирование сообщений получателем обычно считается более правиль­ным, чем протоколирование отправителем. Почему?