Адекватные системы

Компьютерные системы хранят сегодня основную информацию о работе предприятия и их выход из строя способен остановить работу компании. Жизненно важные (BCC — Business Critical Computing) системы должны обладать адекватным уровнем отказоустойчивости в рамках отведенных бюджетов. До недавнего времени надежными считались только сложные закрытые и дорогие системы, предполагающие частое дублирование узлов. С появлением открытых компьютерных сетей появилась возможность строить надежные системы из универсальных компонентов, которые можно заменить в случае аварии без нарушения работоспособности конфигурации.

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

Условия и требования работоспособности

Хотя кажется, что выход системы из строя можно легко определить, в действительности это не совсем так [1]. Дело в том, что не всегда простая работа серверов или обработка запросов является достаточным признаком функционирования системы. Если при этом хранящиеся в ней данные не соответствуют реальности, то систему можно считать неработоспособной. В то же время авария одного сервера может не нарушить работоспособности всей системы в целом. Рассмотрим подробнее, какие именно условия должны соблюдаться при нормальном функционировании системы.

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

Управляемость. Для изменения конфигурации и исправления ошибок в системе должны быть предусмотрены механизмы управления и контроля ее состояния. Если система выйдет из-под контроля администратора, то так же нельзя говорить о ее штатной работе, поскольку она может неадекватно реагировать на запросы пользователей. Поэтому все важные информационные системы должны иметь механизмы контроля состояния и инструменты для изменения их конфигурации без остановки всей системы.

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

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

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

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

Надежность. Доля времени непрерывной работы вычислительной системы — чем больше эта величина, тем меньше система простаивает. Для критически важных приложений нужно добиваться минимум 99,9% надежности. Общим требованием сегодня стали «пять девяток» — 5 мин простоя в год. Однако такие же требования нужно предъявлять и к сетевому оборудованию, каналам подключения и электропитанию. Естественно, что надежность серверов должна быть выше надежности рабочих станций и мобильных устройств.

Отказоустойчивость. Количество одновременных отказов компонентов системы, которые приводят к прекращению работы — чем больше узлов системы нужно вывести из строя для прекращения ее работы, тем более отказоустойчива такая система. Отказоустойчивость повышает общую надежность системы, собранной из недостаточно надежных компонентов [2]. Требования по отказоустойчивости определяются по разности между требуемым уровнем надежности и реальной надежностью существующих компонентов.

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

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

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

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

Повышение надежности

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

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

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

Диагностика. Немаловажным элементом надежных систем является диагностика компонентов: перегрев процессора, памяти, системной платы, а также контроль возникновения ошибок. Диагностика позволяет предупредить аварию и вовремя заменить блок, который пока еще работает корректно, но уже «дышит на ладан». Если в системе предусмотрена горячая замена данного компонента, то это позволяет исправить поломку еще до ее возникновения. Правильная диагностика важна для тех серверов, доступ к которым получить не очень просто, например, если они располагаются на технической площадке провайдера.

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

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

Более сложной проблемой является обеспечение непрерывной работы процессоров, что возможно в многопроцессорных серверах, где процессор располагается на отдельном модуле с возможностью горячей замены. Однако нужно еще обеспечить программную поддержку смены процессорных модулей в операционной системе. Так, на серверах Compaq NonStop Himalaya используется программная технология парных процессов. Суть ее заключается в том, что на различных процессорах выполняются два процесса — первичный и резервный. Первичный посылает резервному контрольные сообщения, чтобы тот в случае аварии мог подхватить исполнение. В результате при замене или выходе из строя одного процессора его функции тут же подхватят другие. Причем эта технология никак не связана с конкретным типом процессора. В частности, Compaq объявил о переносе NonStop Kernel — ОС с поддержкой парных процессов — на процессор Itanium.

По другому пути пошла компания IBM, которая реализовала аппаратное резервирование процессоров прямо на кристалле. Процессоры Power4, на которых у IBM построены серверы серии p690, имеют два одинаковых ядра, которые могут проверять работу друг друга. Кроме того, в серверах этой серии есть дополнительная система, которая контролируют состояние оборудования. В частности, именно эта система динамически перераспределяет вычисления между процессорами в случае выхода одного из них из строя. В серверах серии p690 также предусмотрен один независимый процессор, который контролирует работу всего оборудования: от процессоров до шин PCI и ISA. В результате, в этих серверах обеспечивается достаточно высокий уровень надежности и доступности.

Рассмотрим теперь системные методы увеличения надежности.

Многоуровневые приложения. Разделение монолитного приложения на несколько уровней позволяет увеличить масштабируемость и доступность, а также частично уменьшить время восстановления. Поскольку компоненты многоуровневой системы могут быть разнесены на любое расстояние друг от друга, то возникает возможность максимально приблизить внешние компоненты к пользователям и достигнуть максимальной доступности системы. Кроме того, при разделении системы на уровни обычно предусматривается, что компонент одного уровня может работать с несколькими компонентами других уровней, поэтому при выходе из строя одного компонента достаточно подключиться к другому аналогичному. Время восстановления в этом случае равно времени переподключения.

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

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

Такие методы построения жизненно важных систем предлагает, например, компания Fujitsu Siemens Computers в универсальных серверах Primergy, предназначенных для построения распределенной жизненно важной системы, некоторые элементы которой можно доверить провайдеру ISP или ASP. Кроме того, имеются компании, создающие для своих клиентов резервные защищенные офисы, куда постоянно дублируются данные из основной системы. Возможным вариантом такого решения является разделение офиса на две части, в каждой из которых работают две согласованные системы. При этом общая производительность будет выше, а в случае выхода из строя одной части вторая будет выполнять функции обеих.

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

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

Конкретные реализации

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

Корпоративный портал обычно состоит из следующих подсистем (рис. 1).

Кэширование. Еще до уровня Web-сервера лучше всего расположить интеллектуальную систему кэширования и, возможно, декодирования протокола SSL. Эта система позволит снять с Web-сервера рутинные, но ресурсоемкие операции шифрования и быстрой выдачи часто повторяющихся элементов, например навигационного меню или картинок. Причем, если Web-серверов несколько, такая система может справиться и с балансировкой нагрузки. Впрочем, для надежности лучше предусмотреть резервную или распределенную систему кэширования.

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

Серверы приложений. Основная логика системы заложена в серверах приложений, которые по запросу пользователя получают данные из разрозненных источников, обрабатывают их и выдают получателю через Web-сервер. Кроме этого, сервер приложений следит за авторизацией доступа пользователей к ресурсам компании и целостностью хранимых данных. Сервер приложений может использовать различные протоколы для получения данных от NFS до IIOP. Серверов приложений может быть несколько, но они, как правило, располагаются во внутренней сети компании и соединяются с Web-серверами по выделенным линиям.

СУБД. Чаще всего данные накапливают в какой-нибудь системе управления базами данных, выполняющих также наиболее общие операции и следящих за целостностью данных и разрешениями на доступ пользователей. Серверов баз данных может быть несколько, при этом даже одна база может располагаться на нескольких компьютерах, что увеличивает отказоустойчивость всей системы. С серверами приложений СУБД взаимодействуют по локальной сети, а с подсистемой хранения — с помощью технологий SAN.

Хранилище. Последним уровнем является подсистема хранения, которая может состоять из RAID-массивов, библиотек CD-R или CD-ROM, ленточных накопителей и других устройств. Этот уровень может состоять из нескольких сегментов, разнесенных на достаточно большое расстояние. Управляют его работой, как правило, СУБД или специализированные программные продукты. Правильно построенная система хранения позволяет в случае выхода из строя одного накопителя переключаться на резервный без потери доступности.

Дополнительными элементами системы являются подсистемы контроля, управления сетью и механизмами защиты. Они должны быть универсальными, пронизывая все уровни системы, а на основании, собранных ими данных, определяется работоспособность системы и запускаются те или иные механизмы восстановления. Есть еще один уровень — это пользователи, а точнее их браузеры, которые подключаются к системе либо через Internet, либо по локальной сети. Причем web-сервер договаривается с браузером о том, какой лучше всего использовать протокол для представления данных. Часто здесь используются еще и серверы кэширования, расположенные у провайдеров, но они, с точки зрения системы, прозрачны и их можно не рассматривать.

Многоуровневая система позволяет достигнуть максимальной надежности. При этом для связи компонентов системы используются протоколы Internet, а иногда и сама Сеть, которая хотя и считается ненадежной, но имеет удобные механизмы повышения отказоустойчивости. Кроме того, разделение системы на несколько компонентов, которые работают на различных компьютерах, позволяет оптимизировать аппаратуру под требования программного обеспечения. Так Web-сервер может работать под управлением Linux, сервер приложений — на Java под Solaris, а база данных — под Oracle Parallel Server. Это позволяет подобрать для каждого уровня наиболее оптимальную платформу.

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

Заключение

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

Литература