Лекция: Обработка ошибок и координация в распределенных системах
Как видим, технология RPC — это прозрачный для пользователя способ превращения локальных программ в распределенные. Некоторые реализации RPC дают возможность для решения этой задачи ограничиться минимальными изменениями программного кода. Возникает вопрос: всегда корректен ли такой «автоматический» подход? Во время изучения этого раздела увидим, что это далеко не так. Можно сказать, что уровень абстракции, предоставленный RPC, не всегда отвечает специфике распределенных систем.
Это связано с тем, что структура приложений, разработанных с использованием RPC, рассчитана на работу при условиях успешного функционирования сети, при этом обработку ошибок выполняют почти так же, как и для локальных приложений. Отдаленная процедура, подобно локальной, возвращает простой код ошибки («сетевая ошибка», «нет связи» и тому подобное), при этом нет возможности исследовать, какие компоненты распределенной системы оказались источником проблемы.
В действительности ошибки в распределенных системах значительно отличаются по своему характеру от локальных ошибок, поскольку их источником является взаимодействие целого набора ненадежных компонентов (сетевых соединений, промежуточных узлов и тому подобное). Кроме того, возможно появление частичных ошибок, за которые некоторую часть действий выполняют корректно, а какую-то — нет.
Сформулируем главное правило обработки ошибок в распределенной системе, которая не выполняется в случае использования RPC: поведение распределенной системы при возникновении ошибок должно быть исследовано так же тщательным образом, как и корректное поведение системы.
В этом пункте рассмотрим некоторые особенности такого поведения и способы ее исследования.
Задача распределенной координации
Эту задачу формулируют так: возможно ли надежно скоординировать действия на двух разных компьютерах (например, выполнение некоторого кода в одно и то же время, выполнение действия только один раз, атомарное изменение состояния на двух разных машинах и тому подобное)?
До действий, которые требуют такой синхронизации, принадлежат, например:
♦ атомарное перемещение файла из сервера С1 на сервер С2;
♦ атомарное перемещение суммы денег из счета в одном банке на счет в другом.
Главная проблема, которая возникает при этом, связана с тем, что сеть, которая связывает эти компьютеры, является ненадежной:
♦ сообщения могут быть потеряны;
♦ компьютеры могут быть выключенные или выйти из строя.
С учетом ненадежности сети можно уточнить формулировку этой задачи.
Можно ли использовать обмен сообщениями через ненадежную сеть для надежной синхронизации двух компьютеров (чтобы они гарантированно могли выполнять ту же операцию одновременно)?
Ответ на этот вопрос является однозначно негативным даже тогда, когда все сообщения будут доставлены и ни один компьютер не выйдет из строя.
Эту проблему обычно иллюстрируют парадоксом византийских генералов. Допустимо, что два генерала во главе армий находятся на некотором расстоянии друг от друга, потому они могут обмениваться сообщениями только через посыльных, причем во время доставки сообщения посыльных могут пленять. Задачей является согласовать время одновременной атаки на врага (общих сил достаточно для победы, сил каждой армии отдельно — нет). Рассмотрим протокол обмена сообщениями, который можно использовать в данном случае.
1. Генерал Г1 отсылает сообщение С1 с точным временами атаки.
2. Генерал Г2 получает С1, отсылает свое сообщение С2 с высказыванием согласия и начинает ожидать подтверждение получения П1.
3. Генерал Г1 получает П1, отсылает подтверждение его получения П2 и начинает ожидать подтверждение получения П3.
Подобный обмен сообщениями может длиться бесконечно. Очевидно, что согласовать время атаки генералам не удастся (последнее сообщение все время будет оставаться неподтвержденным). Доказано, что решений эта задача не имеет.
Дальше в этом пункте рассмотрим протоколы распределенной координации, которые не нуждаются в одновременном выполнении операций разными сторонами.