Доверие к программной среде

on

Любая сложная самоуправляемая или построенная в соответствии с природными аналогами компьютерная система должна быть надежной, чтобы избежать риска потери контроля над ней и быть уверенным в ее безотказности. Доверительные отношения — ключевое условие успешного динамического взаимодействия между пользователями компьютеров, системами и сервисами. Корректное функционирование современных распределенных систем часто обусловлено тем, насколько тесно взаимодействуют между собой их компоненты. В системе со всеобъемлющей и мобильной вычислительной функциональностью эти зависимости охватывают огромное разнообразие устройств и связанных с ними программных продуктов. Изменения в таких системах — постоянная головная боль аналитиков и ИТадминистраторов, состояние отдельных компонентов может изменяться так быстро, что рассогласования и нестабильность постепенно становятся нормой . Однако управлять сложной динамической средой чрезвычайно важно: поставщики услуг должны продавать потребителям надежные сервисы; администраторы должны предоставлять пользователям прочную инфраструктуру; пользователи не должны беспокоиться о надежности сетей. Проблема управления системой становится особенно острой, когда у ИТадминистратора мало возможностей воздействия на многие аспекты программной среды. Кроме того, часто сисадмин имеет лишь слабое представление о взаимосвязях внутри системы. Разберем несколько подходов к обеспечению надежности сложных систем. Мониторинг состо яни я системыШ ироко распространенный метод мониторинга состояния крупномасштабных систем заключается в наблюдении за их поведением — изменения могут свидетельствовать об ухудшении состояния системы, а необычные условия среды могут указывать на возникновение ситуации, для которой система не подготовлена. Этот принцип, часто применяемый к оборудованию, можно расширить и на программы. С помощью мониторинга состояния можно отслеживать характеристики крупномасштабных информационных систем несколькими различными способами. Наблюдение за программной средой Операционный профиль, в котором функционирует система, представляет собой статистический срез информации, получаемый системой из ее среды. Отслеживать операционный профиль важно, когда доверие к программной системе основано лишь на прошлом опыте — возникновение ранее неизвестного рабочего условия может обесценить опыт. Кроме того, разработчики часто делают неявные предположения относительно рабочей среды, не всегда документируя или проверяя их. Сервис может успешно функционировать в течение многих лет, поскольку изначально рабочая среда соответствовала предположениям разработчика, но если система развертывается в новой рабочей среде, такие предположения могут быть нарушены, а это приведет к отказу. Наблюдение за операционными профилями в интерфейсах системы поможет обеспечить раннее предупреждение: об опасности отказов из-за ошибок в конфигурации; об опасности отказов из-за новых условий работы, нарушающих неявные предположения разработчика; о переходе системы в аномальное или ранее неизвестное состояние, которое может оказаться некорректным или просто вызвать отклонения от привычного поведения. Используя методы поддержки состояния, системные администраторы могут обнаружить, что некоторые компоненты вычислительной системы взаимодействуют с другими компонентами (или другими частями среды) необычными способами . Выявление надвигающихся нарушений К снижению готовности могут привести несколько факторов, в том числе возросший спрос на услуги, связанные с интенсивным потреблением ресурсов, многочисленные отказы отдельных компонентов и отказы оборудования. Лучший способ прогнозировать проблемы готовности с применением мониторинга состояния — отслеживать ранние симптомы ухудшения готовности, а не пытаться определить коренные проблемы, такие как возросший спрос. Перед нарушениями готовности часто заметно увеличиваются задержки — например, задержка поиска в базе данных может зависеть от локального кэширования запрошенной операции. С помощью простых методов мониторинга ИТ-администраторы могут обнаруживать закономерности на различных диаграммах задержек. Определение ненадежного сервиса Надежность эксплуатируемой в реальных условиях системы может со временем меняться, так как в определенных ситуациях некоторые отказы могут стать более вероятными, чем другие. Если заранее известно, что сервис ненадежен в определенных рабочих условиях, то можно специально настроить систему мониторинга состояния для проверки именно этих условий. Исходящие запросы сервиса могут привести к проблемам в остальной части системы, и их тоже надо отслеживать — например, возможны конфликты соглашений об именовании сервисов в разных подсистемах, что мешает полному или оптимальному исполнению динамического набора сервисов. Определение нестабильного поведения Во многих физических системах схожие входные воздействия должны вести к похожим результатам на выходе, но в пограничных случаях изменение в одном входном бите может привести к тому, что выполнение программы пойдет по другому пути и выход существенно изменится даже при отсутствии неисправности. ИТадминистраторы могут с помощью метода мониторинга состояния определить, когда обычно происходят столь резкие изменения, и предупредить, что выходы подсистемы непредсказуемы. Классический пример непредсказуемого поведения — программный компонент, выдающий бессмысленные выходные результаты из-за порчи внутренней памяти; такие ошибки быстро обнаруживаются прикладными программами в настольных ПК, но могут оставаться незамеченными в большой распределенной системе. Ранее скрытые «гонки» (состязание за одни и те же ресурсы), неисправное оборудование или другие возмущения среды могут стать причиной асимптотических граничных отклонений. Проверка аномальных значений Не все отказы подсистем обязательно приводят к неустойчивому поведению: некоторые отказы могут вызвать стабильное, но неверное поведение. Такое часто случается, если один модуль передает значения, не ожидаемые другими модулями. В самых крайних случаях подсистема может выдать необрабатываемое исключение, возможно, также выдавая значения по умолчанию, которые ошибочно воспринимаются другими модулями как полезные данные. Даже механизмы обнаружения ошибок на основе жесткой логики могут пропустить возникшую проблему, если изза нарушений в конфигурации различные подсистемы по-разному интерпретируют коды ошибок. Проблема еще более усугубляется, когда разработчики приложения используют исключения в качестве нормального средства управления. Среди не столь явных случаев — подсистемы, которые обрабатывают исключения способами, неожиданными для других подсистем, что не нарушает устойчивости, но все же приводит к неправильному поведению. Мониторинг состояния можно применять при поиске необычных постусловий так же, как при проверках необычных профилей. Измерени я параметров компь ютерно й среды Изменения параметров среды оказывают серьезное влияние на функционирование программного обеспечения и в конечном итоге — на стабильность и надежность системы. Часто такие изменения могут разрушить сложившееся на основе прошлого опыта мнение о качестве программного продукта и других его свойствах. Кроме того, в сложной программной системе собственно отказы иногда проявляются только в форме отклоняющегося от нормы поведения. Традиционные подходы к мониторингу состояния трудно применять в компьютерных системах, так как эти подходы основываются на числовых порогах, формируемых инструментальными механическими устройствами. С другой стороны, от компьютеров поступает большой объем информации, которую ИТ-администраторы систем могут использовать для диагностики. К сожалению, не вся эта информация собирается осмысленно, и еще меньше преобразуется в числовую форму и используется, чтобы задать распознаваемое поведение на основе порогов. Кроме того, трудно использовать традиционные методы для мониторинга состояния программного обеспечения, так как поведение программных продуктов часто формируется с применением цепочек символов или номинальных значений (идентификаторов, таких как IP-адреса или номера портов). Даже если значения представлены в числовой форме, похожие значения не обязательно имеют одинаковый смысл (сравниваем яблоки с яблоками, а не апельсинами). Недавние работы в области машинного обучения привели к появлению строковых ядер (string kernel), предоставляющих различные меры схожести для цепочек символов . Возможность определить одинаковость или различие двух цепочек — ключ к адаптации традиционных методов мониторинга состояния для информационных систем. Исследователи уже используют строковые ядра в различных приложениях анализа данных, в том числе для обнаружения аномалий. Современные под ходы Современные подходы к определению состояния системы обычно состоят в применении сетевых или хост-схем. Поставщики сетевого оборудования предпочитают первый вариант как удовлетворяющий традиционным требованиям к устранению неполадок в конфигурации, отчетности, производительности и безопасности при управлении сетями. Для этих целей применяются, например, такие продукты, как Cisco CiscoWorks LAN Management Solution, IBM Tivoli Netcool и HP Business Technology Optimization. С помощью этих систем операторы могут наблюдать за своими сетями через упрощенные интерфейсы для обнаружения топологии, предоставления сервисов и проверки обслуживания оборудования. Internet-сообщество также предоставляет несколько сетевых инструментов инспекции, в основном для проверки согласованности или синтаксиса настройки маршрутизатора. Коммерческие программы на базе хостсхем обычно предназначены для корпоративного пространства ПК и серверов. К таким программам, например, относятся IBM Tivoli Service Management, CA NSM, Microsoft Systems Management Server (SMS), предназначенный для меньших систем на платформе Win ows. Все эти коммерческие продукты полезны, но их возможностей недостаточно для управления доверительной вычислительной средой, так как в них предполагается предварительное знание корректного состояния квазистатичного набора всех компонентов программной системы. Такие упрощающие предположения плохо подходят для разнообразных, динамичных и специализированных систем будущего. Сообщество исследователей прилагает много усилий, чтобы повысить надежность систем, специальным образом выстраивая операционные системы и архитектуры для распределенных и критически важных для повседневной деятельности людей систем . Но какими бы надежными и гибкими ни были отдельные компоненты, им всегда будут требоваться функции распределенного мониторинга и управления. Управление надежностью, основанное на предположении о полном контроле внутри четко определенного периметра, начинает казаться очень хрупким в контексте динамично развивающихся сетей устройств и одноранговых программных систем. Программы управления для такой среды должны быть специализированными и постоянно развиваться. Прин ципы проектировани я с учетом требовани й надежности Лучший способ обеспечить высокий уровень безопасности и доверия — заложить эти качества в систему на этапе проектирования. Разработчикам следует учитывать немногие, но важные принципы доверительности, начиная обдумывать систему. Как всегда при вдумчивом проектировании, разумные инженерные компромиссы проще сделать на ранних этапах. Отделение наблюдения за состоянием от функционирования В большинстве инструментов управления системами функции наблюдения и управления тесно соединены. Главное — выбрать желательное состояния системы, а затем добиться соответствия ему элементов системы. Такой подход может быть удачным в высоко централизованной и управляемой среде, но в большой и сложной среде полная согласованность вряд ли достижима по ряду следующих причин. Время, необходимое системе для перехода в нужное состояние, должно быть сопоставимо с интервалом между изменениями конфигурации. Изменения часто вносятся независимо от управляющей сущности. Во многих случаях централизованнная система управления просто недостаточно успешно масштабируется, так как требования пользователя к изменениям инфраструктуры слишком велики, чтобы реализовать их своевременно. В результате пользователи берут инициативу в свои руки. Может отсутствовать четко определенная сущность централизованного управления, так как система постоянно взаимодействует с другими системами, конфигурации которых в свою очередь меняются. Именно такой будет ситуация для мобильных пользователей в будущей среде всеобъемлющих вычислений, но данное условие справедливо и для больших сетей Internet- провайдеров, имеющих равноправные отношения с другими операторами. Альтернативный подход к наблюдению за состоянием системы — построить представление о ее действительной конфигурации, а затем предоставить оператору возможность управлять системой и достигать желаемых результатов. В открытой и динамической среде логические языки, похоже, имеют много преимуществ перед реляционными базами данных, используемыми в современных пакетах системного мониторинга, поскольку упрощают трудные задачи администрирования сети и безопасности . Объединение разнообразных источников информации Существует большое разнообразие превосходных специализированных инструментов системного мониторинга. Эти инструменты функционируют успешно, так как направлены на конкретную функциональность: сканирование портов, ловушки SNMP и т.д. Для эффективной диагностики распределенной системы требуется сопоставлять и агрегировать информацию из как можно большего количества источников . Со временем, по мере развития систем, мониторинг их состояния, в котором успешно объединяются результаты из других инструментов, окажется предпочтительнее, нежели интегрированное решение, в котором сделана попытка соединить все функции. Однако здесь возникают две проблемы: как организовать общее представление результатов, поступающих от разных инструментов (для объединения), и инженерная проблема создания интерфейса между системой мониторинга и этими инструментами. Системные противоречия В крупных распределенных системах часто возникают противоречия между представлением ИТ-администраторов о конфигурации системы и действительным состоянием системы в глазах независимых наблюдателей. Обычно эти противоречия являются симптомами проблем безопасности, отказов или ошибок конфигурации, но их трудно обнаружить с помощью монолитных систем на основе точно определенной схемы — концепция самой схемы всегда заранее предполагает некоторое постоянство состояния. В а ж н о р а з д е — лить наблюдаемые факты о системе и подразумеваемые заключения о системном состоянии. Системы мониторинга с реляционными базами данных плохо учитывают противоречия, но разработчики могут расширить системы, чтобы овладеть ситуацией. Труднее найти решения для неожиданных рассогласований, которые могут появляться постфактум, особенно когда важная информация уже отброшена. Привязка предположений о состоянии — как можно позднее Благодаря чрезвычайно полезному гибкому представлению знаний, заложенному в декларативных языках программирования, удается отложить привязку любых предположений относит