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

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

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

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

нравилась бы семантика

«только однажды»

{exactly once

semantics)^

но обычно

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

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

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

подтверждение доставки этого запроса на сервер. Сервер может действовать дву-

мя способами. Он может посылать клиенту сообщение об окончании работы еще

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

будет напечатан.

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

всех клиентов о том, что был сломан, но теперь работает снова. Проблема в том,

что клиенты не знают, были или нет обработаны их запросы на печать текста.

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

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

чатан. Во-вторых, он может всегда повторять запрос, но это может привести к

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

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

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

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

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

запроса на печать.

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

комбинаций. К сожалению, ни одна из них нас не устраивает. Чтобы объяснить,

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

вере,

—

посылка сообщения о завершении работы (М), печать текста (Р) и по-

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

ностях.

М-^Р->С: Поломка происходит после отсылки сообщения и печати текста.

М-^С(-^Р): Поломка происходит после отсылки сообщения, но до печати

текста.

Р->М->С:

Поломка происходит после отсылки сообщения и печати текста.

Р~>С(-^М): Печатается текст, после чего происходит поломка (до отправки

сообщения).

С(->Р->М):

Поломка происходит до того, как сервер успевает что-либо сде-

лать.

6. С(-^М-^Р): Поломка происходит до того, как сервер успевает что-либо сде-

лать.

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

вер к этому времени уже сломан. Рисунок 7.6 иллюстрирует все возможные ком-

бинации. Как легко можно убедиться, не существует такой комбинации стратегий

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

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

сервер до или после печати текста.

422

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

Клиент

Стратегия повторных

посылок

Сервер

Стратегия М -> Р Стратегия Р -> М

МРС МС(Р) С(МР) МРС МС(Р) С(МР)

Всегда

Никогда

Если есть подтверждение

Если нет подтверждения

DUP

ОК

DUP

ОК

ZERO

ОК

ZERO

ОК

ZERO

DUP

ZERO

OK = Текст печатается один раз

DUP = Текст печатается дважды

ZERO = Текст вообще не печатается

Рис. 7.6. Различные комбинации стратегий клиента и сервера

при наличии поломок на сервере

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

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

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

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

смысленно. В случае распределенной системы можно и нужно предпринимать

соответствующие действия.

Потеря ответного сообщения

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

—

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

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

еще раз. Проблема этого решения состоит в том, что клиент на самом деле не уве-

рен в причине отсутствия ответа. Потерялся запрос, потерялся ответ или просто

сервер слишком медленный? Между этими вариантами имеется существенная

разница.

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

но,

и это не вызовет никаких нарушений. Так, например, запрос на чтение пер-

вых 1024 байтов файла не имеет побочных эффектов и может производиться так

часто, как это необходимо без каких-либо проблем. Запрос, обладающий такими

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

идемпотентным

(idempotent).

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

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

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

са и посылает его повторно. Банковский сервер считает, что это новый запрос,

и выполняет его. Переводятся два миллиона долларов. Вся надежда на то, что

небеса не позволят ответному сообщению потеряться 10 раз. Перевод денег не

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

Единственный способ справиться с этой проблемой

—

попытаться строить

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

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

многие запросы (например, перевод денег) не идемпотентны по своей природе,

значит,

необходимы какие-то другие меры. Другой способ состоит в том, что

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

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

работавших с этим сервером, он сможет обнаружить разницу между оригиналь-

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

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

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

нительной защитой послужит специальный бит в заголовке сообщения, позво-

ляющий отличать исходные запросы от повторных передач (мы предполагаем,

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

требует осторожности).

Поломка клиента

Последний пункт в списке ошибок

—

поломка клиента. Что произойдет, если

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

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

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

зываются

сиротами

{orphans).

Сироты могут породить разнообразные проблемы. Как минимум, они вызовут

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

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

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

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

Что делать с сиротами? В [313] предлагаются четыре решения. В соответст-

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

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

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

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

и все сироты уничтожаются. Это решение называется

истреблением

сирот {ex-

termination).

Недостатки этого сценария в том, что он требует для каждого вызова RPC за-

писи на диск огромного объема информации. Однако он может и не сработать,

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

рот

{grandorphans)

или сирот еще большей степени, которых трудно или вообще

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

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

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

щий подход.

Согласно решению 2, именуемому

реигтарнацией

{reincarnation),

все эти про-

блемы могут быть решены без записи на диск. Способ, которым это делается,

предполагает разбиение времени на последовательно пронумерованные эпохи.

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

всем машинам сообщение, объявляющее о начале новой эпохи. Когда эта рас-

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

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

казу этого клиента, прекращаются. Разумеется, если сеть разделена на части, не-

которые сироты могут выжить. Однако в ответах от них будет содержаться

номер прошедшей эпохи, что предельно упростит их обнаружение.

Решение 3

—

это вариант предыдущей идерг, но не настолько драконовский.

Он называется

мягкой реинкарнацией {gentle

reincarnation).

Когда приходит сооб-

щение о смене эпох, каждая машина проверяет, происходят ли на ней какие-либо

удаленные вычисления, и если да, пытается найти их владельца. Вычисления

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

И, наконец, у нас есть решение 4,

истечение

срока

{expiration).

В этом реше-

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

ты

Т.

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

щий срок, что создает определенные неудобства. С другой стороны, если после

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

вают умереть. Проблема решается путем выбора разумного времени Т для вызо-

вов RPC с сильно различающимися требованиями.

На практике неприменим ни один из этих методов. Что еще хуже, истребле-

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

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

базы данных. Если сироту внезапно истребить, эта блокировка сохранится. Кро-

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

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

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

ние сирот подробно рассматривается в

[340].

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

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

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

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

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

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

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

процессов.

7.4.1.

Базовые схемы надежной

групповой рассылки

Хотя большинство систем транспортного уровня предоставляют в наше распоря-

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

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

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

—

это позволить любому процессу

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

димо связаться. Очевидно, что подобная организация связи не слишком эффек-

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

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

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

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

ние,

которое часто используется на практике.

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

групповая рассылка (reliable

multicasting).

Интуитивно мы понимаем, что имеется

в виду. Сообщение, отправленное группе процессов, должно быть гарантирован-

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

станет членом группы непосредственно в момент рассылки? Должен ли этот

процесс также получить сообщение? Точно так же мы должны определить, что

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

откажет.

Чтобы разрешить и эти ситуации, следует провести границу между надежной

связью в присутствии ошибочно функционирующих процессов и надежной связью

с корректно работающими процессами. В первом случае групповая рассылка счи-

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

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

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

нить,

какие процессы входили в группу до получения сообщения. Мы еще вер-

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

Ситуация немного прояснится, если допустить, что существует соглашение о

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

цессы в ходе сеанса связи не отказывают, не входят в группу и не покидают ее, то

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

тавляется всем текущим членам группы. В простейшем случае между членами

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

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

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

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

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

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

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

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

потребителям.

Простой способ реализации надежной групповой рассылки в таких условиях

иллюстрирует рис. 7.7. Передающий процесс приписывает каждому рассылаемо-

му сообщению последовательный номер. Предположим, что сообщения прини-

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

легкостью обнаружит пропажу сообщения. Каждое посылаемое сообщение со-

храняется отправителем в локальном буфере истории. Полагая, что получатели

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

буфере до получения подтвержденир! его приема ото всех получателей. Если по-

лучатель обнаружит пропажу сообщения, он возвращает отправителю отрица-

тельное подтверждение, запрашивая повторную передачу. С другой стороны, от-

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

произвести повторную передачу автоматически.

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

Получатель пропустил

сообщение № 24

Буфер

истории

Отправитель

Получатель Получатель Получатель Получатель

Сеть -

Рис. 7.7. Простой способ получения надежной групповой рассылки

том случае, если

предполагается, что получатели известны и безотказны. Передача сообщений (а).

Получение подтверждений приема (б)

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

мер,

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

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

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

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

Дополнительные сведения по этой теме можно найти, например, в [90].

7.4.2. Масштабируемость надежной

групповой рассылки

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

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

чии

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

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

погребен под ответами. Этот эффект известен под названием обратный удар

(feedback

implosion).

Кроме того, мы должны прршимать во внимание и тот факт,

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

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

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

щение отправителю только при потере сообщения. Если возвращать только нега-

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

тельно снижена

[462],

но твердые гарантии того, что обратный удар никогда не

произойдет, по-прежнему отсутствуют.

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

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

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

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

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

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

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

фера истории по истечении определенного срока, что предохранит буфер от пе-

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

сов на повторную передачу не будет удовлетворен.

Существуют определенные требования к масштабируемым надежным систе-

мам групповой рассылки. Сравнение различных схем можно найти в

[262].

Сей-

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

соответствуют многим из существующих решений.

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

Ключевая задача при создании масштабируемых решений для надежной групповой

рассылки

—

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

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

давления откликов

(feedback

suppression),

которая лежит в основе протокола мас-

штабируемой надежной групповой рассылки (Scalable Reliable Multicasting,

SRM),

предложенного в [146] и работающего следующим образом.

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

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

отслеживает потерю сообщения, зависит от него самого. Итак, в качестве откли-

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

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

ет свой отклик остальным членам группы.

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

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

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

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

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

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

будет вполне достаточно, если S получит один-единственный запрос.

По этой причине получатель R, не получивший сообщения т, планирует по-

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

посылку отправляется только по прошествии некоторого случайного интервала

времени. Если, однако, в это время к R приходит другой запрос на повторную

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

и так будет послано повторно. Таким образом, в идеале до S дойдет только одно

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

схему иллюстрирует рис. 7.8.

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

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

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

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

НИИ.

Однако такой подход порождает множество серьезных проблем. Во-первых,

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

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

телей. В противном случае множество получателей могут послать свои отклики

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

процессов

—

задача непростая.

Отправитель получает

только один негативный отклик

Получатели отменяют посылку откликов

Отправитель

/. /

Получатель Получатель Получатель Получатель

Негативный

отклик

Негативный

отклик

Т=1

Негативный

отклик

'Негативный

^ отклик

Негативный

отклик

-А^

Сеть

Рис. 7.8. Посылку запросов на повторную передачу планируют несколько получателей,

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

Другая проблема состоит в том, что групповая рассылка отклика прерывает

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

ми,

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

Единственное решение этой проблемы

—

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

сообщения

гПу

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

но в

[226].

К сожалению, это решение требует очень эффективного управления

группами, что в глобальных системах трудноосуществимо. Наилучшим подхо-

дом поэтому было бы объединить получателей, имеющих тенденцию к пропуску

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

рассылки как для откликов, так и для повторной посылки сообщений. Детали та-

кого подхода можно найти в

[270].

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

тели осуществляли локальное восстановление. Так, если получатель, который

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

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

разослать это сообщение /тг. Дополнительные подробности можно найти в [146,

270].

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

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

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

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

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

Для простоты будем считать, что рассылкой сообщений большой группе по-

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

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

множество подгрупп, которые организованы в виде дерева. Подгруппа, содер-

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

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

группы.

Отправитель

Линия дальней связи

Получатель

Локальная сеть

Рис. 7.9. Сущность иерархической надежной групповой рассылки. Каждый локальный

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

запросы на повторную передачу

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

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

дящими в эту подгруппу

[201].

Локальный координатор поддерживает для этой

цели собственный буфер истории. Если сам координатор пропускает сообщение т,

он запрашивает повторную рассылку этого сообщения у координатора родитель-

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

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

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

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

Основная проблема в иерархическом подходе

—

построение дерева. Во мно-

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

это

—

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

вует. В принципе для этого достаточно расширить задачу маршрутизаторов

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

нять функции локальных координаторов. К сожалению, адаптировать таким об-

разом существующую компьютерную сеть не так-то легко.

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

которые можно было бы масштабировать на варианты систем с большим числом

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

проблему. Не существует какого-либо наилучшего решения, а каждое из сущест-

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

еще немало работы.

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

7.4.3. Атомарная групповая рассылка

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

рассылка при наличии ошибок в процессах. Часто в распределенных системах

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

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

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

нием

проблемы атомарной групповой рассылки {atomic multicast

problem).

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

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

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

ки.

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

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

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

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

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

тивной репликации.

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

ния одного из них случается поломка реплики. Соответственно, обновление этой

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

успешно.

Естественно, реплика восстанавливается в том виде, в котором она была пе-

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

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

Приведение реплики в соответствие с другими репликами требует полной ин-

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

ции выполнялись.

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

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

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

на всех корректно работающих репликах или

HPI

на одной из них. В сущьюсти,

слу-

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

чими репликами, только если они заключат новое соглашение о членстве. Други-

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

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

Когда сломанная реплика будет восстановлена, она должна будет снова войти

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

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

приведено в соответствие с состоянием остальных членов группы. Соответствен-

но,

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

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

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

Виртуальная синхронность

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

но определена в терминах групп процессов и изменения членства в группе. Далее