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

Как видим, технология RPC - это прозрачный для пользователя способ превращения локальных программ в распределенные. Некоторые реализации RPC дают возможность для решения этой задачи ограничиться минимальными изменениями программного кода. Возникает вопрос: всегда корректен ли такой «автоматический» подход? Во время изучения этого раздела увидим, что это далеко не так. Можно сказать, что уровень абстракции, предоставленный RPC, не всегда отвечает специфике распределенных систем.

Это связано с тем, что структура приложений, разработанных с использованием RPC, рассчитана на работу при условиях успешного функционирования сети, при этом обработку ошибок выполняют почти так же, как и для локальных приложений. Отдаленная процедура, подобно локальной, возвращает простой код ошибки («сетевая ошибка», «нет связи» и тому подобное), при этом нет возможности исследовать, какие компоненты распределенной системы оказались источником проблемы.

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

Сформулируем главное правило обработки ошибок в распределенной системе, которая не выполняется в случае использования RPC: поведение распределенной системы при возникновении ошибок должно быть исследовано так же тщательным образом, как и корректное поведение системы.

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

Задача распределенной координации

Эту задачу формулируют так: возможно ли надежно скоординировать действия на двух разных компьютерах (например, выполнение некоторого кода в одно и то же время, выполнение действия только один раз, атомарное изменение состояния на двух разных машинах и тому подобное)?

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

• атомарное перемещение файла из сервера С₁ на сервер С₂;

• атомарное перемещение суммы денег из счета в одном банке на счет в другом.

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

• сообщения могут быть потеряны;

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

С учетом ненадежности сети можно уточнить формулировку этой задачи.

Можно ли использовать обмен сообщениями через ненадежную сеть для надежной синхронизации двух компьютеров (чтобы они гарантированно могли выполнять ту же операцию одновременно)?

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

Эту проблему обычно иллюстрируют парадоксом византийских генералов. Допустимо, что два генерала во главе армий находятся на некотором расстоянии друг от друга, потому они могут обмениваться сообщениями только через посыльных, причем во время доставки сообщения посыльных могут пленять. Задачей является согласовать время одновременной атаки на врага (общих сил достаточно для победы, сил каждой армии отдельно — нет). Рассмотрим протокол обмена сообщениями, который можно использовать в данном случае.

1. Генерал Г1 отсылает сообщение С1 с точным временами атаки.

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

2. Генерал Г1 получает П1, отсылает подтверждение его получения П2 и начинает ожидать подтверждение получения П3.

Подобный обмен сообщениями может длиться бесконечно. Очевидно, что согласовать время атаки генералам не удастся (последнее сообщение все время будет оставаться неподтвержденным). Доказано, что решений эта задача не имеет.

Дальше в этом пункте рассмотрим протоколы распределенной координации, которые не нуждаются в одновременном выполнении операций разными сторонами.

Протокол запроса-справки

Проанализируем особенности обмена сообщениями в сети при наличии ошибок. Допустимо, что случаются только ошибки передачи данных (потери сообщений), участники протокола не выходят из строя.

Для обмена сообщениями при таких условиях с гарантией одноразовой доставки назначен протокол запроса-справки (request/acknowledge protocol).

1. Отправитель пересылает получателю сообщения и устанавливает таймер.

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

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

4. В случае исчерпания времени, заданного таймером, шаги протокола повторяют. Этот протокол гарантирует, что сообщение будет доставлено хотя бы один раз из условия, что участники не выходят из строя. При этом получатель может получить сообщение несколько раз (в случае потери подтверждения). Чтобы иметь возможность отбрасывать дубликаты, сообщение можно сопровождать уникальными номерами.

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

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

Двухфазное подтверждения

Поскольку одновременного выполнения действий на отдаленных компьютерах в соответствии с парадоксом генералов добиться невозможно, для распределенной координации действий используют методы, в которых допустимое выполнение действий в разное время. Рассмотрим один из них — двухфазное подтверждение (two-phase commit, 2PC) .

В этом случае две стороны выполняют действия, оформленные в виде транзакций -атомарних операций, которые выполняются полностью (подтверждаются, commit) или не выполняются совсем (откатываются, rollback).

Примером распределенной транзакции может быть перенесение файла из сервера С1 на сервер С2. Если выполнение этого действия перерывается, при отсутствии атомарности может оказаться, что файл был изъят из сервера С1, но при этом не был перенесен на сервер С2.

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

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

1. Координатор отсылает всем участникам запрос. Он содержит описание действия, которое должно выполняться, например «изъять файл а.txt из корневого каталога». Перед отсылкой информацию о нем сохраняют в журнале транзакций координатора.

2. Участники получают запрос и выполняют транзакцию локально (например, пытаются изъять файл). Информацию о результате этого действия отображают в виде сообщения (М_ok — успех, М_abort— неудача), которое хранят в журнале транзакций каждого участника и отсылают координатору. Этот этап завершен, когда координатор получит сообщение от всех участников (или окончится максимальное время ожидания). Отметим, что ни для одной транзакции в конкретный момент еще не было выполнено ни подтверждения, ни отката (например, информацию об исключении файла хранят лишь в памяти).

Вторым этапом является этап принятия решения координатором.

3. Сначала координатор принимает решение относительно подтверждения или отката распределенной транзакции. На этом шаге могут возникнуть две ситуации:

- координатора получает сообщение М_abort хотя бы от одного участника. После этого он создает сообщение M_{GLOBAL_ROLLBACK} хранит его в журнале и отсылает всем участникам;

- координатор получает сообщение М_ok от каждого участника. После этого он создает сообщение M_global__commit хранит его в журнале и отсылает всем участникам.

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

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

• Если участник выйдет из строя на шаге 2 (во время выполнения транзакции), координатор не получит сообщения о завершении транзакции на протяжении максимального времени ожидания и откатает транзакцию, отослав участникам сообщения M_{GLOBAL_ROLLBACK} -

• Если координатор выйдет из строя на шаге 3, после возобновления он должен обратиться к своему журналу транзакций. Когда в нем нет ни одного сообщения M_{GLOBAL_ХХХ} или есть сообщение M_{GLOBAL_ROLLBACK}, то всем участникам отсылают сообщение об откате. Когда в журнале есть M_{GLOBAL_COMMIT} участникам отсылают сообщение о подтверждении.

• В случае выхода участника из строя на шаге 4 после возобновления он должен обратиться к координатору за информацией и выполнить соответственно подтверждение или откат.

К недостаткам протокола 2РС принадлежат высокие требования к надежности координатора. Если он выйдет из строя на шаге 3 и не возобновит свою работу, все участники могут быть заблокированы.

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

• Когда хотя бы один из участников получил M_{GLOBAL_XXX} необходимо выполнить действие, которое отвечает этому сообщению.

• Когда хотя бы один из участников отослал M _ABORT транзакцию необходимо откатать.

Если же все участники отослали M_ОК, но никто из них не получил M_{GLOBAL_XXX} решение не может быть принято, поскольку координатор мог сохранить в журнале (но не успел отослать) M_{GLOBAL_ROLLBACK} через свою внутреннюю ошибку. Такая ситуация и влечет блокировку всех участников. Во время реализации 2РС нужно всегда учитывать возможность такой блокировки.