Корректное функционирование современных распределенных систем часто обусловлено тем, насколько тесно взаимодействуют между собой их компоненты. В системе со всеобъемлющей и мобильной вычислительной функциональностью эти зависимости охватывают огромное разнообразие устройств и связанных с ними программных продуктов. Изменения в таких системах – постоянная головная боль аналитиков и ИТ-администраторов, состояние отдельных компонентов может изменяться так быстро, что рассогласования и нестабильность постепенно становятся нормой [1]. Однако управлять сложной динамической средой чрезвычайно важно: поставщики услуг должны продавать потребителям надежные сервисы; администраторы должны предоставлять пользователям прочную инфраструктуру; пользователи не должны беспокоиться о надежности сетей. Проблема управления системой становится особенно острой, когда у ИТ-администратора мало возможностей воздействия на многие аспекты программной среды. Кроме того, часто сисадмин имеет лишь слабое представление о взаимосвязях внутри системы.

Разберем несколько подходов к обеспечению надежности сложных систем.

Мониторинг состояния системы

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

Наблюдение за программной средой

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

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

Используя методы поддержки состояния, системные администраторы могут обнаружить, что некоторые компоненты вычислительной системы взаимодействуют с другими компонентами (или другими частями среды) необычными способами [2].

Выявление надвигающихся нарушений

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

Определение ненадежного сервиса

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

Определение нестабильного поведения

Во многих физических системах схожие входные воздействия должны вести к похожим результатам на выходе, но в пограничных случаях изменение в одном входном бите может привести к тому, что выполнение программы пойдет по другому пути и выход существенно изменится даже при отсутствии неисправности. ИТ-администраторы могут с помощью метода мониторинга состояния определить, когда обычно происходят столь резкие изменения, и предупредить, что выходы подсистемы непредсказуемы. Классический пример непредсказуемого поведения – программный компонент, выдающий бессмысленные выходные результаты из-за порчи внутренней памяти; такие ошибки быстро обнаруживаются прикладными программами в настольных ПК, но могут оставаться незамеченными в большой распределенной системе. Ранее скрытые «гонки» (состязание за одни и те же ресурсы), неисправное оборудование или другие возмущения среды могут стать причиной асимптотических граничных отклонений.

Проверка аномальных значений

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

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

Измерения параметров компьютерной среды

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

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

Недавние работы в области машинного обучения привели к появлению строковых ядер (string kernel), предоставляющих различные меры схожести для цепочек символов [3]. Возможность определить одинаковость или различие двух цепочек – ключ к адаптации традиционных методов мониторинга состояния для информационных систем. Исследователи уже используют строковые ядра в различных приложениях анализа данных, в том числе для обнаружения аномалий.

Современные подходы

Современные подходы к определению состояния системы обычно состоят в применении сетевых или хост-схем. Поставщики сетевого оборудования предпочитают первый вариант как удовлетворяющий традиционным требованиям к устранению неполадок в конфигурации, отчетности, производительности и безопасности при управлении сетями. Для этих целей применяются, например, такие продукты, как Cisco CiscoWorks LAN Management Solution, IBM Tivoli Netcool и HP Business Technology Optimization. С помощью этих систем операторы могут наблюдать за своими сетями через упрощенные интерфейсы для обнаружения топологии, предоставления сервисов и проверки обслуживания оборудования. Internet-сообщество также предоставляет несколько сетевых инструментов инспекции, в основном для проверки согласованности или синтаксиса настройки маршрутизатора.

Коммерческие программы на базе хост-схем обычно предназначены для корпоративного пространства ПК и серверов. К таким программам, например, относятся IBM Tivoli Service Management, CA NSM, Microsoft Systems Management Server (SMS), предназначенный для меньших систем на платформе Windows. Все эти коммерческие продукты полезны, но их возможностей недостаточно для управления доверительной вычислительной средой, так как в них предполагается предварительное знание корректного состояния квазистатичного набора всех компонентов программной системы. Такие упрощающие предположения плохо подходят для разнообразных, динамичных и специализированных систем будущего.

Сообщество исследователей прилагает много усилий, чтобы повысить надежность систем, специальным образом выстраивая операционные системы и архитектуры для распределенных и критически важных для повседневной деятельности людей систем [4-6]. Но какими бы надежными и гибкими ни были отдельные компоненты, им всегда будут требоваться функции распределенного мониторинга и управления. Управление надежностью, основанное на предположении о полном контроле внутри четко определенного периметра, начинает казаться очень хрупким в контексте динамично развивающихся сетей устройств и одноранговых программных систем. Программы управления для такой среды должны быть специализированными и постоянно развиваться.

Принципы проектирования с учетом требований надежности

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

Отделение наблюдения за состоянием от функционирования

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

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

Альтернативный подход к наблюдению за состоянием системы – построить представление о ее действительной конфигурации, а затем предоставить оператору возможность управлять системой и достигать желаемых результатов. В открытой и динамической среде логические языки, похоже, имеют много преимуществ перед реляционными базами данных, используемыми в современных пакетах системного мониторинга, поскольку упрощают трудные задачи администрирования сети и безопасности [2].

Объединение разнообразных источников информации

Существует большое разнообразие превосходных специализированных инструментов системного мониторинга. Эти инструменты функционируют успешно, так как направлены на конкретную функциональность: сканирование портов, ловушки SNMP и т.д. Для эффективной диагностики распределенной системы требуется сопоставлять и агрегировать информацию из как можно большего количества источников [7]. Со временем, по мере развития систем, мониторинг их состояния, в котором успешно объединяются результаты из других инструментов, окажется предпочтительнее, нежели интегрированное решение, в котором сделана попытка соединить все функции. Однако здесь возникают две проблемы: как организовать общее представление результатов, поступающих от разных инструментов (для объединения), и инженерная проблема создания интерфейса между системой мониторинга и этими инструментами.

Системные противоречия

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

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

Привязка предположений о состоянии – как можно позднее

Благодаря чрезвычайно полезному гибкому представлению знаний, заложенному в декларативных языках программирования, удается отложить привязку любых предположений относительно состояния системы до последнего момента. Гибкость, которая позволяет объединять разнородные инструменты, позволяет также принимать данные из инструментов «без предубеждений» и только позже интерпретировать факты в рамках конкретной модели поведения (и проверить их соответствие модели). Это несовместимо с реляционными базами данных, которые применяют явную схему к результатам наблюдений за сетью или системой. В процессе, известном как «очистка данных» (data cleaning), выход от инструментов сначала подается в СУБД, и здесь часто отбрасываются как раз наиболее интересные аномальные наблюдения. Использование схемы также затрудняет развитие системы по мере того, как становятся важными новые характеристики сети.

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

Общая оценка компьютерной среды

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

Проблему доверительности можно было бы разрешить с помощью Semantic Web, особенно благодаря ее положению на вершине семантической пирамиды как механизма «доверия», это предполагает, что модели доверительности требуют онтологических представительских структур. К сожалению, онтологические структуры становятся более ограниченными из-за стандартов, приводящих ко все большей статичности и, следовательно, уменьшающих потенциал для определения реального уровня доверительности в динамической программной среде. Это влияет на результаты, так как в стандартах не учитывается семантика естественного человеческого взаимодействия. Семантика – проявление познавательной способности; она раскрывает, как люди лингвистически передают свои восприятия, и поэтому уходит корнями в человеческий опыт. Можно утверждать, что семантика – продукт коллективного разума. Более важно то, что нейрокогнитивные модели семантического представления предполагают массовый параллелизм, ассоциативную сложность и хаотическую обработку. Такая обработка необходима, чтобы разобраться в беспорядочных, многогранных и постоянно меняющихся программных средах.

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

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

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

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

***

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

Литература

  1. D. Liben-Nowell et al., Observations on the Dynamic Evolution of Peer-to-Peer Networks. Proc. 1st Int’l Workshop on Peer-to-Peer Systems (IPTPS ’02), MIT Faculty Club, 2002, www.cs.rice.edu/Conferences/IPTPS02/187.pdf.
  2. T. Roscoe et al, InfoSpect: Using a Logic Language for System Health Monitoring in Distributed Systems. Planetlab, Dec. 2002; www.planet-lab.org/files/pdn/PDN-02-008/pdn-02-008.pdf.
  3. R. Herbrich, Learning Kernel Classifiers. MIT Press, 2002.
  4. J. S. Shapiro et al., Operating SystemSupport for Active Networks. Tech. report MS-CIS-97-03, Univ.of Pennsylvania, Feb. 1997.
  5. D. Reed et al., Xenoservers: Accounted Execution of Untrusted Code. Proc. 7th Workshop Hot Topics in Operating Systems (HotOS-VII),IEEE Press, 1999, pp. 136–141.
  6. R. Grimm et al., A System Architecture for Pervasive Computing. Proc. 9th ACM SIGOPS European Workshop, ACM Press, 2000, pp. 177–182.
  7. D.C. Price et al., An Integrated Health Monitoring System for an Ageless Aerospace Vehicle. Structural Health Monitoring 2003: From Diagnostics & Prognostics to Structural Health Management, F.-K. Chang, ed., DEStech Publications, 2003, pp. 310–318.
  8. M. Newman, A. Barabasi, D. Watts, Function, and Evolvability of Software Collaboration Graphs. Physics Rev., vol. 68, no. 4, 2003, pp. 332–346.
  9. G. Hurlburt, K. Miller, J. Voas, An Ethical Analysis of Automation, Risk, and the Financial Crises of 2008. IT Professional, vol. 11, no. 1, 2009, pp. 14–19.

Джон Харауз (j.harauz@computer.org) – независимый консультант по компьютерным системам в области безопасности; Джеффри Воас (j.voas@ieee.org) – технический руководитель SAIC; Джордж Харлберт (ghurlburt@change-index.com) – директор компании Change Index, бывший старший системный аналитик ВМФ США.

John Harauz, Jeffrey Voas, George Hurlburt. Trustworthiness in Software Environments. IEEE ITPro, September/October 2009. All rights reserved. Reprinted with permission.

Чертова дюжина проблем программной инженерии

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

http://www.osp.ru/os/2007/07/4391815