Тактики реализации готовности

Не забыли терминологию готовности, приведенную в главе 4? Отказом называется ситуация, при которой система теряет возможность обслуживания в соответствии со своей спецификацией; кроме того, признаки отказа заметны пользователям системы. Предвестником отказа является неисправность (или сочетание неисправностей). Мы также говорили о том, что одним из важнейших аспектов готовности является восстановление (устранение неисправности). Тактика, описание которой содержится в этом разделе, не позволяет неисправностям превращаться в отказы или, по меньшей мере, ограничивает последствия неисправности, обеспечивая возможность восстановления. Иллюстрация этой тактики приводится на рис. 5.2.

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

В первую очередь, мы рассмотрим обнаружение неисправностей. Затем перейдем к восстановлению после неисправностей и, наконец, к их предотвращению.

Обнаружение неисправностей

Из всех тактик обнаружения неисправностей наибольшим признанием пользуется при: ping/echo-пакеты, heartbeat-запросы и исключения.

♦ Ping/echo-пакеты. Проверяющий компонент отправляет проверяемому компоненту ping-запрос, ожидая через установленный период времени получить в ответ echo-пакет. Эта схема используется в группах компонентов, которые выполняют в отношении друг друга одну и ту же задачу. Кроме того, она может применяться клиентами, которые при помощи таких пакетов удостоверяются в приемлемой работоспособности объекта на сервере и канала связи. Детекторы неисправностей по схеме ping/echo можно расположить в рамках иерархии, согласно которой детектор нижнего уровня должен отправлять ping-запросы тем программным процессам, с которыми у него общий процессор, а детекторы верхних уровней обязаны запрашивать нижележащие уровни. В результате, по сравнению с ситуацией, при которой удаленный детектор неисправностей отправляет ping-запросы всем процессам, наблюдается экономия рабочей пропускной способности.

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

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

Тактики ping/echo-пакетов и heartbeat-сообщений применимы к ряду отдельных процессов, а тактика исключений, напротив, распространяется на единичный процесс. Обработчик исключений обычно выполняет семантическое преобразование неисправностей, тем самым переводя их в такую форму, в которой их можно обработать.

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

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

♦ Голосование. Процессы, исполняемые на резервированных процессорах принимают равнозначные исходные данные, а затем, вычислив простое выходное значение, отправляют его голосующему. Если голосующий выявляет у одного из процессоров отклонение от нормы, тот отключается. Алгоритм голосования может действовать по «мажоритарному принципу», ориентироваться на «предпочтительный алгоритм» или руководствоваться какими-либо другими правилами. Этот метод исправляет неисправности в работе алгоритмов или отказы процессора и чаще всего встречается в системах управления. Если все процессоры используют одни и те же алгоритмы, выявляются только неисправности процессоров — неисправности алгоритмов не обнаруживаются. Таким образом, если последствия отказа чрезвычайно серьезны — например, не исключают возможность полного выхода из строя, — есть смысл использовать разнообразные резервируемые компоненты.

Разнообразие иногда доходит до крайности — например, когда программное обеспечение каждого резервируемого компонента разрабатывается разными рабочими группами и исполняется на несходных платформах. Более обычной является ситуация, при которой на разных платформах разрабатывается один и тот же программный компонент. Разнообразие в разработке и сопровождении слишком дорого обходится, и поэтому применяется оно только в исключительных ситуациях — например, при отслеживании земной поверхности в авиационных системах. В системах управления разнообразие применяется в тех случаях, когда выходные данные, предоставляемые голосующему, просты и легко поддаются классификации по признаку эквивалентности или отклонения, вычисления проводятся циклически и все резервируемые компоненты получают от датчиков равнозначные входные данные. В случае отказа разнообразие исключает простой, поскольку голосующий продолжает работать. Среди вариантов этой методики следует упомянуть симплекс-метод, предполагающий применение результатов «предпочтительного» компонента во всех случаях, кроме тех, когда они отклоняются от результатов «доверенного» компонента, с показаниями которого голосующий сверяется. Если резервируемые компоненты проводят параллельные вычисления с одним и тем же набором входных значений, их (компонентов) синхронизация проводится автоматически.

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

1 Излагаемая в книге классификация методов резервирования отличается от предложенной в отечественном стандарте ГОСТ 27.002-89 и отражает американскую терминологию в теории надежности систем. — Примеч. науч. ред.

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

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

+ Пассивное резервирование (теплый перезапуск/двойное резервирование/тройное резервирование). Один из компонентов (первичный) реагирует на поступающие события и сообщает другим компонентам (запасным) о том, каким образом им требуется обновить состояние. В случае неисправности система в первую очередь проверяет актуальность состояния резервных копий и только после этого возобновляет обслуживание. Эта методика применяется в системах управления — как правило, в тех случаях, когда по каналам связи или от датчиков приходят входные данные, которые при обнаружении неисправности требуется перенаправить на резервный компонент. В частности, она используется в системе управления воздушным движением, рассматриваемой в главе 6. В этой системе решение о том, когда следует заменить первичный компонент, принимается вторичным компонентом; в других системах принятие таких решений происходит в рамках других компонентов. Настоящая тактика делает ставку на надежность резервных компонентов. Регулярное проведение необходимых переключений — например, раз в сутки или раз в неделю — способствует повышению готовности системы. В некоторых системах управления базами данных переключение производится с сохранением каждого нового элемента данных. Новый элемент сохраняется на теневой странице, а старая страница становится резервной. В таком случае простой, как правило, огранивается секундами.

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

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

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

♦ Затенение. Компонент, в котором недавно произошел отказ, может после восстановления некоторое время работать в «теневом режиме» — таким образом обеспечивается полное соответствие его поведения поведению работающих компонентов, после чего он снова вводится в действие.

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

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