В соответствии с ГОСТ 27.002, под отказом понимается событие, заключающееся в нарушении работоспособного состояния изделия. В контексте данной работы изделие — это информационная система или ее компонент.
В простейшем случае можно считать, что отказы любого компонента составного изделия ведут к общему отказу, а распределение отказов во времени представляет собой простой пуассоновский поток событий (см., например, [4] ). В таком случае вводят понятие интенсивности отказов и среднего времени наработки на отказ, которые связаны между собой соотношением
— номер компонента, 
- интенсивность отказов, 
— среднее время наработки на отказ.
Интенсивности отказов независимых компонентов складываются:
, а среднее время наработки на отказ для составного изделия задается соотношением.
Уже эти простейшие выкладки показывают, что если существует компонент, интенсивность отказов которого много больше, чем у остальных, то именно он определяет среднее время наработки на отказ всей информационной системы. Это является теоретическим обоснованием изречения "где тонко, там и рвется" и принципа первоочередного укрепления самого слабого звена.
Пуассоновская модель позволяет обосновать еще одно очень важное положение, состоящее в том, что эмпирический подход к построению систем высокой доступности не может быть реализован за приемлемое время. В работе [5] показано, что при традиционном цикле тестирования/отладки программной системы по оптимистическим оценкам каждое исправление ошибки приводит к экспоненциальному убыванию (примерно на половину десятичного порядка) интенсивности отказов. Отсюда следует, что для того, чтобы на опыте убедиться в достижении необходимого уровня доступности, независимо от применяемой технологии тестирования и отладки, приходится потратить время практически того же порядка, что и требуемое среднее время наработки на отказ. Например, для достижения среднего времени наработки на отказ 10 5 часов потребуется более 10 4.5 часов, что составляет более трех лет. Значит, нужны иные методы построения систем высокой доступности, методы, действенность которых доказана аналитически или практически за пятьдесят лет развития вычислительной техники и программирования.
Пуассоновская модель применима в тех случаях, когда информационная система содержит одиночные точки отказа, то есть компоненты, выход которых из строя ведет к отказу всей системы. Для исследования систем с резервированием применяется иной формализм.
Будем считать (см. выше Разд. Постановка задачи ), что существует количественная мера эффективности предоставляемых изделием информационных услуг. В таком случае вводят понятия показателей эффективности отдельных элементов и эффективности функционирования всей сложной системы.
В качестве меры доступности можно принять вероятность приемлемости эффективности услуг, предоставляемых информационной системой, на всем протяжении рассматриваемого отрезка времени. Чем большим запасом эффективности располагает система, тем выше ее доступность. Очевидно, при наличии избыточности отказ компонента не обязательно приводит к отказу системы.
При наличии избыточности в конфигурации системы вероятность того, что в рассматриваемый промежуток времени эффективность информационных сервисов не опустится ниже допустимого предела, зависит не только от вероятности отказа компонентов, но и от времени, в течение которого они остаются неработоспособными, поскольку при этом суммарная эффективность падает и каждый следующий отказ может стать фатальным. Чтобы максимизировать доступность системы, необходимо минимизировать время неработоспособности каждого компонента. Кроме того, следует учитывать, что, вообще говоря, ремонтные работы могут потребовать понижения эффективности или даже временного отключения работоспособных компонентов; такого рода влияние также необходимо минимизировать.
Таким образом, мы видим, что доступность системы в общем случае достигается за счет применения трех групп мер, направленных на повышение:
Наряду с отказами можно рассматривать сбои — события, заключающиеся в кратковременном нарушении работоспособного состояния каких-либо компонентов информационной системы (типичные примеры — случайная ошибка четности при чтении из оперативной или долговременной памяти или опечатка пользователя при вводе команды). Очевидно, для распознавания и нейтрализации последствий сбоя нужна определенная избыточность, а соответствующие меры естественно отнести к мерам обеспечения живучести, что мы и будем делать в дальнейшем.
В соответствии с подходом клиент/сервер, информационную систему можно представить в виде графа сервисов, ребра в котором соответствуют отношению "сервис A непосредственно использует сервис B". На Рис. 1 приведен один из возможных примеров подобного графа.
Пусть в результате осуществления некоторой угрозы из строя выводится подмножество сервисов S 1 (то есть эти сервисы в силу нанесенных повреждений становятся неработоспособными). Назовем S 1 зоной поражения.
В зону риска S мы будем включать все сервисы, эффективность которых при осуществлении угрозы падает ниже допустимого предела. Очевидно, S 1 — подмножество S. S строго включает S 1 , когда имеются сервисы, непосредственно не затрагиваемые угрозой, но критически зависящие от пораженных, то есть неспособные переключиться на использование эквивалентных услуг либо в силу отсутствия таковых, либо в силу невозможности доступа к ним. На Рис. 2 приведен случай, когда зона поражения сводится к одному порту концентратора, обслуживающего критичный сервер, а зона риска захватывает все рабочие места пользователей.
Очевидно, чтобы система не содержала одиночных точек отказа, то есть оставалась живучей при осуществлении любой из рассматриваемых угроз, ни одна зона риска не должна включать в себя предоставляемые услуги. Нейтрализацию отказов нужно выполнять внутри системы, невидимым для пользователей образом, за счет размещения достаточного количества избыточных ресурсов. На Рис. 3 приведена конфигурация, аналогичная Рис. 2 , с той лишь разницей, что сетевое соединение между сервером и концентратором продублировано. В результате зоны поражения и риска при поломке порта концентратора стали совпадать.
С другой стороны, естественно соразмерять меры по обеспечению живучести с рассматриваемыми угрозами. Когда рассматривается набор угроз, соответствующие им зоны поражения могут оказаться вложенными, так что живучесть по отношению к более серьезной угрозе автоматически влечет за собой и живучесть в более легких случаях. Следует учитывать, однако, что обычно стоимость переключения на резервные ресурсы растет вместе с ростом объема этих ресурсов. Значит, для наиболее вероятных угроз целесообразно минимизировать зону риска, даже если в принципе предусмотрена нейтрализация объемлющей угрозы. Нет смысла переключаться на резервный вычислительный центр только потому, что у одного из серверов сгорел блок питания.
Зону риска можно трактовать не только как совокупность ресурсов, но и как часть пространства, затрагиваемую при реализации угрозы. В таком случае, как правило, чем больше расстояние дублирующего ресурса от границ зоны риска, тем выше стоимость его поддержания, поскольку увеличивается протяженность линий связи, время переброски персонала и т.п. Это — еще один довод в пользу адекватного противодействия угрозам, который следует принимать во внимание при размещении избыточных ресурсов и, в частности, при организации резервных центров.
Введем еще одно понятие. Назовем зоной нейтрализации угрозы совокупность ресурсов, вовлеченных в нейтрализацию отказа, возникшего вследствие реализации угрозы. Имеются в виду ресурсы, режим работы которых в случае отказа меняется. Очевидно, зона риска является подмножеством зоны нейтрализации. Чем меньше разность между ними, тем экономнее данный механизм нейтрализации.
Все, что вне зоны нейтрализации, отказа "не чувствует" и может трактовать внутренность этой зоны как безотказную. Таким образом, в иерархически организованной системе грань между живучестью и обслуживаемостью с одной стороны и безотказностью с другой стороны, относительна. Целесообразно конструировать целостную информационную систему из компонентов, которые на верхнем уровне можно считать безотказными, а вопросы живучести и обслуживаемости решать в пределах каждого компонента. К этому замечанию мы вернемся в Разд. Обеспечение живучести и Разд. Программно-технические меры .
Формирование режима информационной безопасности вообще и обеспечение высокой доступности в частности — проблема комплексная. Меры по ее решению, которые могут быть предприняты в рамках отдельной организации, можно подразделить на три уровня:
Соответственно, выделяются три группы людей, от согласованных действий которых зависит обеспечение доступности. Последующее изложение строится с учетом этого разделения, так что каждый читатель при желании может ограничиться знакомством лишь с частью данной работы, соответствующей его служебным обязанностям. Внутри каждой части, там, где это возможно, мы будет подразделять рекомендуемые меры в соответствии с тем, направлены ли они на обеспечение безотказности, живучести или обслуживаемости.
|
|
|
| Постановка задачи | Содержание | Административные меры повышения доступности |
| Copyright ╘ 1993-2000, Jet Infosystems |
