<<
>>

Восстановление после сбоев

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

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

Транспортный уровень сервера просто передает приходящие ТРББ-мо- дули один за другим пользователю транспортного уровня. Получив половину файла, сервер сбрасывается и перезагружается, после чего все его таблицы пере- инициализируются, поэтому он уже не помнит, что с ним было раньше.

Пытаясь восстановить предыдущее состояние, сервер может разослать широковещательный ТРББ-модуль всем хостам, объявляя им, что он только что пе- резагрузился, и прося своих клиентов сообщить ему о состоянии всех открытых соединений. Каждый клиент может находиться в одном из двух состояний: один неподтвержденный ТРБи-модуль (состояние 57) или ни одного неподтвержденного ТРББ-модуля (состояние 50).

Этой информации клиенту должно быть достаточно, чтобы решить, передавать ему повторно последний ТРБи-модуль или нет.

На первый взгляд, здесь все очевидно: узнав о перезапуске сервера, клиент должен передать повторно последний неподтвержденный ТРБи-модуль. То есть повторная передача требуется, если клиент находится в состоянии 5/. Однако при более детальном рассмотрении оказывается, что все не так просто, как мы наивно предположили. Рассмотрим, например, ситуацию, в которой транспортная сущность сервера сначала посылает подтверждение, а уже затем передает пакет прикладному процессу. Запись ТРББ-модуля в выходной поток и отправка подтверждения являются двумя различными неделимыми событиями, которые не могут быть выполнены одновременно. Если сбой произойдет после отправки подтверждения, но до того как выполнена запись, клиент получит подтверждение, а при получении объявления о перезапуске сервера окажется в состоянии 50.

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

В этом месте вы, должно быть, подумаете: «А что если поменять местами последовательность действий, выполняемых транспортной сущностью сервера, чтобы сначала осуществлялась запись, а потом высылалось подтверждение?» Представим, что запись сделана, но сбой произошел до отправки подтверждения. В этом случае клиент окажется в состоянии 57 и поэтому передаст ТРЭи-мо- дуль повторно, и мы получим дубликат ТРЭи-модуля в выходном потоке.

Таким образом, независимо от того, как запрограммированы клиент и сервер, всегда могут быть ситуации, в которых протокол не сможет правильно восстановиться. Сервер можно запрограммировать двумя способами: так, чтобы он сначала передавал подтверждение, или так, чтобы сначала записывал ТРЭи-модуль. Клиент может быть запрограммирован одним из четырех способов: всегда передавать повторно последний ТРЭи-модуль, никогда не передавать повторно последний ТРЭи-модуль, передавать повторно ТРЭи-модуль только в состоянии 50 и передавать повторно ТРЭи-модуль только в состоянии 57.

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

На сервере могут происходить три события: отправка подтверждения (А), запись ТРЭи-модуля в выходной процесс (IV) и сбой (С). Они могут произойти в виде шести возможных последовательностей: АС(\У), AWC, С(А \¥), С(\¥А), \¥АС и WC{A), где скобки означают, что после события С событие А или В может и не произойти (то есть уж сломался — так сломался). На рис. 6.15 показаны все восемь комбинаций стратегий сервера и клиента, каждая со своими последовательностями событий. Обратите внимание на то, что для каждой комбинации существует последовательность событий, приводящая к ошибке протокола. Например, если клиент всегда передает повторно неподтвержденный ТРЭи-модуль, событие А\¥С приведет к появлению неопознанного дубликата, хотя при двух других последовательностях событий протокол будет работать правильно.

Усложнение протокола не помогает. Даже если клиент и сервер обменяются несколькими Т Р Б и - м о дул ям и, прежде чем сервер попытается записать полученный пакет, так что клиент будет точно знать, что происходит на сервере, у него нет возможности определить, когда произошел сбой на сервере: до или после записи. Отсюда следует неизбежный вывод: невозможно сделать отказ и восстановление хоста прозрачными для более высоких уровней.

В более общем виде это может быть сформулировано следующим образом: восстановление от сбоя уровня N может быть осуществлено только уровнем N + 1 и только при условии, что на более высоком уровне сохраняется достаточное количество информации о состоянии процесса. Как упоминалось ранее, транспортный уровень может обеспечить восстановление от сбоя на сетевом уровне, если каждая сторона соединения отслеживает свое текущее состояние.

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

вателя к удаленной базе данных. Предположим, что удаленная транспортная сущность запрограммирована сначала передавать ТРБи-модуль вышестоящему уровню, а затем отправлять подтверждение. Даже в этом случае получение подтверждения машиной пользователя не означает, что удаленный хост успел обновить базу данных. Настоящее сквозное подтверждение, получение которого означает, что работа была сделана, и, соответственно, отсутствие которого означает обратное, вероятно, невозможно. Более подробно этот вопрос обсуждается в (Бакгег и др., 1984)

<< | >>
Источник: Э. ТАНЕНБАУМ. КОМПЬЮТЕРНЫЕ СЕТИ 4-Е ИЗДАНИЕ. 2003

Еще по теме Восстановление после сбоев:

  1. ВОССТАНОВЛЕНИЕ
  2. ФУНКЦИЯ ПСИХИЧЕСКАЯ ВЫСШАЯ: ВОССТАНОВЛЕНИЕ
  3. ОТЧИСЛЕНИЕ И ВОССТАНОВЛЕНИЕ
  4. Часть 1 ПОДГОТОВКА К ВОССТАНОВЛЕНИЮ ДУШИ
  5. РАДИЭСТЕЗИЧЕСКИЙ МЕТОД ВОССТАНОВЛЕНИЯ ЗДОРОВЬЯ
  6. 2. Восстановление нарушенного права
  7. ВОССТАНОВЛЕНИЕ ПРАВ
  8. 6. Восстановление срока исковой давности
  9. § 2. Исчисление, приостановление и восстановление процессуальных сроков
  10. 3. Досрочное прекращение и восстановление действия патента. Право послепользования
  11. § 8. Прекращение и восстановление патентных прав (п. 1642, 1643)
  12. Психологическое обеспечение восстановления сил и боевого настроя.
  13. Тема восстановления и дальнейшего подъема народного хозяйства в советской прессе
  14. Тема восстановления и развития экономики в прессе послевоенных лет