Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

6.7. Итоги 401

Опишите своими словами, какова главная причина создания моделей слабой

непротиворечивости.

Опишите, как реализована репликация в DNS и почему она так хорошо рабо-

тает на практике.

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

тракт между программой и хранилищем данных. Зачем нужен такой кон-

тракт?

6. Линеаризуемость предполагает существование глобальных часов. Однако, как

мы видели, подобное требование делает нереальным поддержание в большин-

стве распределенных систем строгой непротиворечивости. Можно ли реали-

зовать линеаризуемость в физически распределенных хранилищах данных?

Мультипроцессорная система имеет одну шину. Можно ли реализовать в та-

кой системе память со строгой непротиворечивостью?

8. Почему последовательность W1(x)a R2(x)NIL R3(x)a по отношению к пред-

ставленному на рис. 6.5, б хранилищу данных запрещена?

9. Рассмотрим рис. 6.7. Является ли допустимым результатом для распределен-

ной разделяемой памяти, поддерживающей только непротиворечивость FIFO,

значение 001110? Поясните свой ответ.

10.

Рассмотрим рис. 6.8. Является ли значение 001110 допустимым результатом

для последовательно непротиворечивой памяти? Поясните свой ответ.

И. В конце пункта 6.2.2 мы обсуждали формальную модель, которая гласит, что

любой набор операций в последовательно непротиворечивом хранилище дан-

ных может быть промоделирован строкой истории Я, из которой могут быть

выведены все индивидуальные последовательности процессов. Для процес-

сов Р1 и Р2, показанных на рис. 6.9, приведите все возможные значения Н.

Игнорируйте процессы РЗ и Р4 и не включайте в Я их операции.

12.

Последовательно непротиворечивая память допускает шесть вариантов чере-

дования инструкций, представленных в табл. 6.4. Перечислите их.

13.

Часто утверждается, что модели слабой непротиворечивости

—

это дополни-

тельная «головная боль» для программистов. В какой степени это высказыва-

ние соответствует действительности?

14.

Во многих реализациях свободной непротиворечивости в распределенных сис-

темах с разделяемой памятью общие переменные синхронизируются при ос-

вобождении, а не при захвате. Зачем для них вообще нужен захват?

15.

Какую непротиворечивость обеспечивает система Огса, последовательную или

поэлементную? Поясните свой ответ.

16.

Способна ли полностью упорядоченная групповая рассылка, организуемая

секвенсором и предназначенная для сохранения непротиворечивости при ак-

тивной репликации, повредить аргумент, передаваемый от точки к точке,

в архитектуре системы?

17.

Какой тип непротиворечивости вы будете использовать при реализации про-

екта электронной биржи? Поясните свой ответ.

402 Глава 6. Непротиворечивость и репликация

18.

Рассмотрим персональный почтовый ящик мобильного пользователя, реали-

зованный как часть глобальной распределенной базы данных. Какой тип не-

противоречивости, ориентированной на клиента, будет для него наиболее под-

ходящим?

19.

Опишите простую реализацию непротиворечивости чтения своих записей для

отображения только что обновленных web-страниц.

20.

Приведите пример, когда непротиворечивость, ориентированная на клиента,

может легко привести к конфликтам двойной записи.

21.

Необходимо ли, чтобы в условиях аренды часы клиента и сервера были точно

синхронизированы?

22.

Рассмотрим неблокирующий протокол первичного архивирования, исполь-

зуемый для гарантированного соблюдения последовательной непротиворечи-

вости в распределенном хранилище данных. Будет ли это хранилище всегда

обеспечивать непротиворечивость чтения своих записей?

23.

Обычно для работы активной репликации необходимо, чтобы все операции

выполнялись всеми репликами в одном и том же порядке. Всегда ли это необ-

ходимо?

24.

Один из методов реализации полностью упорядоченной групповой рассылки

с помощью секвенсора

—

сначала передать операцию секвенсору, который

присвоит ей уникальный номер и произведет групповую рассылку операции.

Предложите два альтернативных метода и сравните эти три решения.

25.

Файл реплицирован на 10 серверах. Перечислите все комбинации кворумов

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

26.

В тексте мы описывали ориентированную на отправителя схему, предотвра-

щающую реплицирование обращений. В схеме, ориентированной на получате-

ля,

реплика, получающая сообщение, распознает копии входящих сообщений,

относящихся к одному и тому же обращению. Опишите, как можно предот-

вратить реплицирование обращений в схеме, ориентированной на получателя.

27.

Рассмотрим причинно непротиворечивую медленную репликацию. Когда опе-

рации могут быть удалены из очереди?

28.

В этом упражнении вам предстоит реализовать простую систему, поддержи-

вающую групповые вызовы RPC. Мы предполагаем, что имеется несколько

реплицированных серверов и каждый клиент работает с сервером посредст-

вом RFC. Однако в условиях репликации клиент должен послать RFC каж-

дой реплике. Программируя клиента, помните, что для приложения это должно

выглядеть посылкой единственного вызова RFC. Считайте, что репликация

требуется для повышения производительности, а серверы подвержены сбоям.

Глава 7

Отказоустойчивость

7.1.

Понятие отказоустойчивости

7.2. Отказоустойчивость процессов

7.3. Надежная связь клиент-сервер

7.4. Надежная групповая рассылка

7.5. Распределенное подтверждение

7.6. Восстановление

7.7. Итоги

Характерной чертой распределенных систем, которая отличает их от единичных

машин, является возможность частичного отказа. Частичный отказ происходит

при сбое в одном из компонентов распределенной системы. Этот отказ может на-

рушить нормальную работу некоторых компонентов, в то время как другие ком-

поненты это никак не затронет. В противоположность отказу в распределенной

системе отказ в нераспределенной системе всегда является глобальным, в том

смысле, что он затрагивает все ее компоненты и легко может привести к нерабо-

тоспособности всего приложения.

При создании распределенной системы очень важно добиться, чтобы она мог-

ла автоматически восстанавливаться после частичных отказов, незначительно

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

отказ, распределенная система в процессе восстановления должна продолжать

работать приемлемым образом, то есть быть устойчивой к отказам, сохраняя в

случае отказов определенную степень функциональности.

В этой главе мы познакомимся со способами обеспечения отказоустойчиво-

сти распределенной системы. После изложения определенных базовых сведений

об отказоустойчивости мы рассмотрим вопросы отказоустойчивости процессов и

надежной групповой рассылки. Под отказоустойчивостью процессов мы пони-

маем методы, при помощи которых отказ одного или более процессов проходит

для остальной части системы почти незаметно. С этим вопросом связана пробле-

ма надежной групповой рассылки, при которой передача сообщений набору про-

цессов производится с гарантией доставки. Надежная групповая рассылка часто

необходима для поддержания синхронности процессов.

404 Глава 7. Отказоустойчивость

Как мы уже говорили в главе 5, атомарность

—

это свойство, важное для мно-

гих приложений. Так, например, в распределенных транзакциях необходимо га-

рантировать, что все операции, входящие в транзакцию, либо происходят, либо

нет. Фундаментальным для атомарности в распределенных системах является

понятие распределенных протоколов подтверждения, которые обсуждаются в

отдельном разделе этой главы.

И, наконец, мы рассмотрим, как восстанавливать систему после отказов. В ча-

стности, мы обсудим, когда и как следует сохранять состояние распределенной

системы на тот случай, если позже это состояние потребуется восстанавливать.

7.1.

Понятие отказоустойчивости

Исследованию отказоустойчивости посвящено большое количество трудов. Этот

раздел мы начнем с рассмотрения базовых концепций обработки отказов, а далее

обсудим модели отказов. Основа всех методик ликвидации последствий отка-

зов

—

избыточность, о ней мы тоже поговорим. Дополнительную информацию

общего характера по отказоустойчивости можно найти, например, в

[213].

7.1.1.

Основные концепции

Чтобы понять роль отказоустойчивости в распределенных системах, сначала не-

обходимо выяснить, что для распределенных систем означает «быть отказоустой-

чивыми». Отказоустойчивость тесно связана с понятием

надежных систем

{de-

pendable systems). Надежность

—

это термин, охватывающий множество важных

требований к распределенным системам

[241],

включая:

4 доступность (availability);

-¥ безотказность (reliability);

> безопасность (safety);

4 ремонтопригодность (maintainability).

Доступность — это свойство системы находиться в состоянии готовности к

работе. Обычно доступность показывает вероятность того, что система в данный

момент времени будет правильно работать и окажется в состоянии выполнить

свои функции, если пользователи того потребуют. Другими словами, система

с высокой степенью доступности

—

это такая система, которая в произвольный

момент времени, скорее всего, находится в работоспособном состоянии.

Под

безотказностью

имеется в виду свойство системы работать без отказов в

течение продолжительного времени. В противоположность доступности безот-

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

Система с высокой безотказностью

—

это система, которая, скорее всего, будет

непрерывно работать в течение относительно долгого времени. Между безотказ-

ностью и доступностью имеется небольшая, но существенная разница. Если сис-

тема отказывает на одну миллисекунду каждый час, она имеет доступность по-

рядка 99,9999 %, но крайне низкую безотказность. С другой стороны, система.

7.1.

Понятие отказоустойчивости 405

которая никогда не отказывает, но каждый август отключается на две недели,

имеет высокую безотказность, но ее доступность составляет всего 96 %. Эти две

характеристики

—

не одно и то же.

Безопасность

определяет, насколько катастрофична ситуация временной не-

способности системы должным образом выполнять свою работу. Так, многие

системы управления процессами, используемые, например, на атомных электро-

станциях или космических кораблях, должны обладать высокой степенью безопас-

ности. Если эти управляющие системы даже временно, на короткий срок, пере-

станут работать, результат может быть ужасен. Множество примеров происхо-

дивших в прошлом событий показывают, как тяжело построить безопасную сис-

тему (и может быть еще больше таких примеров ожидают нас в будущем).

И, наконец,

ремонтопригодность

определяет, насколько сложно исправить

неполадки в описываемой системе. Системы с высокой ремонтопригодностью

могут также обладать высокой степенью доступности, особенно при наличии

средств автоматического обнаружения и исправления неполадок. Однако, как мы

увидим позже в этой главе, говорить об автоматическом исправлении неполадок

гораздо проще, чем создавать способные на это системы.

Часто надежные системы требуют также повышенного уровня защиты, осо-

бенно когда дело доходит до такого вопроса, как непротиворечивость. Мы пого-

ворим о защите в следующей главе.

Говорят, что система

отказывает

{fail), если она не в состоянии выполнять

свою работу. В частности, если распределенная система создавалась для предо-

ставления пользователям некоторых услуг, то система будет считаться находя-

щейся в состоянии отказа в том случае, если она не сможет предоставлять все

или некоторые услуги.

Ошибкой {error)

называется такое состояние системы, ко-

торое может привести к ее неработоспособности. Так, например, при передаче

пакетов по сети может случиться, что некоторые пакеты, пришедшие к получате-

лю,

окажутся поврежденными. Повреждения в данном случае будут означать,

что получатель может неверно прочесть значения битов (например, 1 вместо 0)

или оказаться не в состоянии определить сам факт прихода пакета.

Причиной ошибки является отказ {fault). Понятно, что найти причину

ошибки очень важно. Так, например, вызвать повреждение пакетов вполне мо-

жет неисправная или некачественная среда передачи. В этом случае устранить

отказ относительно легко. Однако ошибки передачи в беспроводных сетях могут

быть вызваны, например, плохой погодой. Изменение погоды с целью предупре-

дить возникновение ошибок нам пока не под силу.

Построение надежных систем тесно связано с управлением отказами. Управ-

ление в данном случае означает нечто среднее между предотвращением, исправ-

лением и предсказанием отказов

[256].

Для нашей цели наиболее важным вопро-

сом является отказоустойчивость {fault tolerance), под которой мы будем

понимать способность системы предоставлять услуги даже при наличии отказов.

Отказы обычно подразделяются на проходные, перемежающиеся и постоян-

ные.

Проходные отказы

{transient faults) происходят однократно и больше не по-

вторяются. Если повторить операцию, они не возникают. Птица, пролетевшая

через луч микроволнового передатчика, в некоторых сетях может привести к по-

406 Глава 7. Отказоустойчивость

тере битов. Если передатчик, выждав положенную паузу, повторит отправку, то

по всей вероятности передача пройдет как положено.

Перемежающиеся

отказы (intermittent faults) появляются и пропадают, «ко-

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

бывают вызваны потерей контакта в разъеме. Из-за трудностей в диагностике

перемежающиеся отказы часто вызывают сильное раздражение. Обычно когда

приходит ремонтник, система работает просто прекрасно.

Постояниые отказы {permanent faults) — это отказы, которые продолжают

свое существование до тех пор, пока отказавший компонент не будет заменен.

Примерами постоянных отказов могут быть сгоревшие микросхемы, ошибки в

программном обеспечении или сместившиеся головки дисков.

7.1.2. Модели отказов

Отказавшая система не в состоянии корректно выполнять ту работу, для которой

она была создана. Если рассматривать распределенную систему как набор сер-

веров, взаимодействующих друг с другом и с клиентами, то некорректное вы-

полнение работы будет означать, что серверы или коммуникационные каналы,

а возможно и оба этих компонента, не в состоянии делать то, для чего они, как

предполагалось, предназначены. Однако

самР1

по себе нефункционирующие сер-

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

корректной работы нуждается в услугах других серверов, причину ошибки, мо-

жет быть, следует искать в другом месте.

Таких зависимостей в распределенных системах великое множество. Отказав-

ший диск осложняет работу файлового сервера, который разрабатывался для

реализации файловой системы с высокой степенью доступности. Если этот фай-

ловый сервер является частью распределенной базы данных, под угрозой нахо-

дится работа всей базы, поскольку доступной оказывается только часть данных.

Чтобы лучше понимать, насколько серьезен на самом деле конкретный отказ,

были разработаны различные схемы классификации. Одна из таких схем, приве-

денная в табл. 7.1, основана на выкладках из [114, 191].

Таблица 7.1. Различные типы отказов

Тип отказа Описание

Поломка Сервер перестал работать, хотя до момента отказа работал

правильно

Пропуск данных Сервер неправильно реагирует на входящие запросы

пропуск приема Сервер неправильно принимает входящие запросы

пропуск передачи Сервер неправильно отправляет сообщения

Ошибка синхронизации Реакция сервера происходит не в определенный интервал времени

Ошибка отклика Отклик сервера неверен

ошибка значения Сервер возвращает неправильное значение

ошибка передачи Сервер отклоняется от верного потока управления

состояния

Произвольная ошибка Сервер отправляет случайные сообщения в случайные моменты

времени

7.1,

Понятие отказоустойчивости 407

Поломка

{crash

failure) имеет место при внезапной остановке сервера, при

этом до момента остановки он работает нормально. Важная особенность полом-

ки состоит в том, что после остановки сервера никаких признаков его работы не

наблюдается. Типичный пример поломки — полное зависание операционной

системы, когда единственным решением проблемы

является

перезагрузка. Мно-

гие операционные системы персональных компьютеров претерпевают поломки

настолько часто, что люди уже начинают полагать, что для них это обычное дело.

В этом смысле перенос кнопки Reset с задней части корпуса компьютера на пе-

реднюю панель был, несомненно, оправдан.

Пропуск данных

{omission

failure) возникает в том случае, когда сервер непра-

вильно реагирует на запросы. Эту ошибку могут вызывать различные причины.

случае пропуска приема

{receive omission)

сервер может, например, не получать

запросов. Отметим, что такая ошибка может произойти, в частности, и в том слу-

чае,

когда соединение между клиентом и сервером установлено совершенно пра-

вильным образом, но на сервере не запущен процесс для приема приходяш.их за-

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

сервер остается в неведении о посланных ему сообщениях.

Похожая ошибка

— пропуск передачи {send omission) —

происходит, когда сер-

вер выполняет свою работу, но по каким-либо причинам не в состоянии послать

ответ. Подобная ошибка может произойти, например, при переполнении буфера

передачи, если сервер не готов к подобной ситуации. Отметим, что в противопо-

ложность пропуску приема в данном случае сервер может перейти в состояние,

соответствующее полному выполнению услуги для клиента. Впоследствии, если

обнаружится, что имел место пропуск передачи, сервер, вероятно, должен быть

готов к тому, что клиент повторно пошлет свой последний запрос.

Другие типы пропусков не имеют отношения к взаимодействию и могут быть

вызваны ошибками в программе, такими как бесконечные циклы или некоррект-

ная работа с памятью, которые способны «подвесить» сервер.

Следующий класс ошибок связан с синхронизацией. Ошибки

сшрсронизации

(timing failures) возникают при ожидании ответа дольше определенного времен-

ного интервала. Как мы говорили во время обсуждения изохронных потоков дан-

ных в главе 2, слишком раннее предоставление данных легко может вызвать у

принимающей стороны проблемы, связанные с отсутствием места в буфере для

хранения получаемых данных. Чаще, однако, сервер отвечает слишком поздно,

этом случае говорят, что произошла

ошибка производительности

(performance

failure).

Еще один важный тип ошибок

— ошибки отклика

(r^esponse

failures),

при кото-

рых ответы сервера просто неверны. Существует два типа ошибок отклика.

слу-

чае

ошибки

значения (value failure) сервер дает неверный ответ на запрос. Так,

например, эту ошибку демонстрирует поисковая машина, систематически воз-

вращающая адреса web-страниц, не связанных с запросом пользователя.

Другой тип ошибок отклика

—

ошибки передачи состояния (state transition

failures).

Этот тип ошибок характеризуется реакцией на запрос, не соответствую-

щей ожиданиям. Так, например, если сервер получает сообщение, которое он

не в

состоянии распознать, и никаких мер по обработке подобных сообщений

408 Глава 7. Отказоустойчивость

не предусмотрено, возникает ошибка передачи состояния. В частности, сервер мо-

жет неправомерно осуществить по умолчанию некие действия, производить ко-

торые в данном случае не следовало бы.

Весьма серьезны произвольные ошибки

{arbitrary

failures), известные также

под названием византийских

ошибок {Byzantine

failures). Когда случается произ-

вольная ошибка, клиент должен приготовиться к самому худшему. Например,

может оказаться, что сервер генерирует сообщения, которые он в принципе не

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

неправильно функционирующий сервер может, участвуя в работе группы серве-

ров,

приводить к появлению заведомо неверных ответов. Эта ситуация показы-

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

восходит к Византийской империи (Балканы и современная Турция) времен

330-1453 годов, когда бесконечные заговоры, интриги и ложь считались в правя-

щих кругах обычным делом. Византийские ошибки впервые были проанализи-

рованы в [252, 347]. Ниже мы вернемся к разговору об ошибках такого рода.

Произвольные ошибки похожи на поломки. Поломка

—

наиболее распростра-

ненная причина остановки сервера. Поломки известны также под названием

ошибок аварийной остановки {fail-stop failures). В действительности аварийно

остановленный сервер просто прекращает генерировать исходящие сообщения.

По этому признаку его остановка обнаруживается другими процессами. Напри-

мер,

по настоящему дружественный сервер может предупредить нас о том, что

находится на грани поломки.

Разумеется, в реальной жизни серверы, останавливаясь по причине пропуска

данных или поломок, не настолько дружественны, чтобы оповестить нас о над-

вигающейся остановке. Другие процессы должны сами обнаружить «безвремен-

ную кончину» сервера. Однако в подобных

системах остановки без уведомления

{fail'Silent

systems)

другие процессы могут сделать неверный вывод об остановке

сервера. Сервер может просто медленно работать, то есть может иметь место

ошибка производительности.

И, наконец, возможно, что сервер производит случайные сообщения, которые

другие процессы считают абсолютным мусором. В этом случае мы имеем дело с

наиболее простым случаем произвольной ошибки. Подобные ошибки называют

безопасными

{fail-safe).

7.1.3. Маскирование ошибок

при помощи избыточности

Если система считается отказоустойчивой, она должна пытаться маскировать

факты ошибок от других процессов. Основной метод маскирования ошибок

—

ис-

пользование избыточности {redundancy). Возможно применение трех типов

избыточности

—

информационной избыточности, временной избыточности и фи-

зической избыточности

[218].

В случае информационной избыточности к со-

общению добавляются дополнительные биты, по которым можно произвести

исправление сбойных битов. Так, например, можно добавить к передаваемым

7.1.

Понятие отказоустойчивости 409

данным код Хемминга для восстановления сигнала в случае зашумленного кана-

ла передачи.

При временной избыточности уже выполненное действие при необходимости

осуществляется еще раз.

качестве примера

этому способу рассмотрим тран-

закции (описанные

главе 5). Если транзакция была прервана, ее можно без

ка-

ких-либо опасений повторить. Временная избыточность особенно полезна, если

мы имеем дело

проходным или перемежающимся отказом.

В случае физической избыточности мы добавляем

систему дополнительное

оборудование или процессы, которые делают возможной работу системы при ут-

рате

или

неработоспособности некоторых компонентов. Физическая избыточ-

ность, таким образом, может быть

как

аппаратной,

так и

программной. Так,

на-

пример, можно добавить

системе дополнительные процессы, так что при крахе

некоторых

из них

система продолжит функционировать правильно. Другими

словами, посредством репликации достигается высокая степень отказоустойчи-

вости. Ниже мы вернемся

этому типу программной избыточности.

Физическая избыточность

—

это широко распространенный способ добиться

отказоустойчивости.

Она

используется

биологии (млекопитающие имеют

по

два глаза, по два уха, по два легких и т. д.), самолетостроении

(у

Боинга-747 четы-

ре двигателя, но он может лететь

на трех)

спорте (несколько судей на тот слу-

чай, если один чего-нибудь

не

заметит).

Она

также много

лет

используется

для

обеспечения отказоустойчивости

радиосхемах. Рассмотрим, например, схему,

показанную на рис.

7.1,

<2.

На

ней сигнал проходит последовательно через устрой-

ства А,

В и

С. Если одно

из них

неисправно, результат, вероятно, будет неверен.

& <£>

Устройство

голосования

Рис. 7.1. Тройное модульное резервирование

На рис. 7.1,

каждое

из

устройств присутствует

трех экземплярах. Переход

к следующему участку схемы определяется тройным голосованием. Устройство

голосования

—

это схема с тремя входами и одним выходом. Если два или три вход-

ных сигнала совпадают, выходной сигнал равен входному. Если все три входных

сигнала различны, выходной сигнал

не

определен. Такая схема известна под

на-

званием

тройного модульного

резервирования

(Triple

Modular

Redundancy,

TMR).

410 Глава 7. Отказоустойчивость

Допустим, элемент А2 отказал. Каждое из устройств голосования,

V1,

и V3,

получает два правильных (идентичных) входных сигнала и один неправильный,

и каждое из них передает на второй участок цепи правильное значение. В ре-

зультате эффект отказа А2 оказывается полностью замаскированным, а значит,

входные сигналы элементов В1, В2

ВЗ абсолютно такие же, как если бы ника-

кого отказа не было.

Рассмотрим теперь, что будет, если в придачу к А2 откажут также элементы

ВЗ и

С1.

Эффект их отказа также будет замаскирован, и все три выходных сигна-

ла окажутся правильными.

Прежде всего, непонятно, зачем на каждом этапе нужно использовать три

устройства голосования. Вообще-то определить и донести до нас мнение боль-

шинства может и одно устройство голосования. Однако устройство голосова-

ния

—

это тоже компонент, который тоже может отказать. Рассмотрим, напри-

мер,

отказ У1 Входящий сигнал В1 в этом случае будет неверным, но до тех пор,

пока все остальное работает, В2 и ВЗ будут давать одинаковые выходные сигна-

лы,

и устройства

V4,

образуют правильный результат для третьего этапа.

Отказ V1 практически ничем не будет отличаться от отказа В1.В обоих случаях

выходной сигнал

от

В1 будет неверным, и в любом случае при голосовании он

окажется в меньшинстве.

Хотя не все отказоустойчивые распределенные системы используют TMR,

эта технология является очень распространенной и помогает яснее понять, что

такое отказоустойчивая система и чем она отличается от системы, составленной

из высоконадежных компонентов, но не обладающей отказоустойчивой структу-

рой. Разумеется, TMR можно применять и рекурсивно. Например, можно повы-

шать надежность микросхем, встраивая в них механизмы TMR. Для разработчи-

ков,

использующих микросхемы, это останется неизвестным.

7.2. Отказоустойчивость процессов

Теперь, когда мы обсудили основные понятия отказоустойчивости, сосредото-

чимся на том, как она реализуется в распределенных системах на практике. Пер-

вой темой, которую мы обсудим, будет отказоустойчивость процессов, которая

организуется путем репликации процессов в группах. Далее мы рассмотрим об-

щие вопросы разработки групп процессов и поговорим о том, что собой представ-

ляет отказоустойчивая группа. Кроме того, мы увидим, как достигается согласие

в группе процессов в том случае, если обнаружится, что один или более процес-

сов дают неправильные ответы.

7.2.1.

Вопросы разработки

Основной подход к защите от последствий отказа процессов

—

объединить не-

сколько идентичных процессов в группу. Основное свойство всех подобных

групп состоит в том, что когда сообщение посылается группе, его получают все

члены этой группы. Таким образом, если один из процессов группы перестает ра-

ботать, можно надеяться на то, что его место займет другой

[187].