Нет ничего парадоксального в том, что сегодня оказались тесно взаимосвязанными две основные тенденции развития вычислительных систем — нарастание сложности и проникновение в сферы, в традиционном понимании, далекие от ИТ. Расширение области применения ИТ порождает лавинообразный рост сложности, а в результате управление системами усложняется и на низком уровне. Одновременно растет потребность в автономной работе систем, для управления которыми системный администратор должен только задавать «стратегические цели», связанные с выполнением бизнес-функций.

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

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

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

Политики в рамках Autonomic Computing Initiative

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

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

  • Использование в интерфейсе системы терминологии, отражающей ее бизнес-цели, а не особенности реализации. Система, которая обеспечивает некоторые сервисы, сгруппированные по уровню обслуживания (например, времени отклика), может оперировать такими обозначениями этих групп, как Premium (наименьшее время отклика), Standard и Lite.
  • Интеграция экспертных систем, в том числе с возможностью повторного использования. Система с интегрированными экспертными функциями позволяет оператору определять требования к поведению системы, не вдаваясь в детали. Например, вместо того чтобы устанавливать отдельные настройки защиты, оператор может дать указание системе «включить максимальный уровень безопасности, соответствующий последним правилам центра безопасности».
  • Распространение директив. Управляемая политикой система должна работать так, чтобы директивы, примененные к одним элементам системы, распространялись и на другие ее элементы, к которым они применимы. Скажем, в случае масштабирования системы принятые правила безопасности должны автоматически распространяться на новые компоненты.
  • Общность и специфичность правил политики. В то время как система в целом управляется общими директивами, у оператора всегда есть возможность сформулировать специфичные правила для определенных компонентов этой системы. Желательно, чтобы специфичные правила можно было формулировать в тех же терминах целевого назначения системы, что и общие правила.
  • Четкое разделение целей политики и средств ее реализации. Разделение целей и средств делает систему более гибкой, модернизируемой и надежной.
  • Адаптивность средств взаимодействия оператора с адаптивной системой. На начальном этапе работы система может запрашивать у оператора больше информации, чем в дальнейшем. В ходе обычной работы она использует опыт, накопленный в ходе предыдущего «общения» с оператором.

Три типа политик

В рамках программы Autonomic Computing Initiative предлагаются три типа политик. Они основаны на концепции рациональных агентов, развитой в рамках исследований по искусственному интеллекту. Различают три типа рациональных агентов. Рефлекторные агенты используют для поиска решения набор заданных правил «если, то». Ориентированные на достижение цели агенты способны выбирать из множества решений те, которые в наибольшей степени позволяют достичь поставленной цели. Ориентированные на полезность агенты наиболее гибки и «интеллектуальны»; для них главным критерием принятия решения является некая общая функция полезности.

Соответствующие этим агентам политики таковы:

  • политики действия (action policies);
  • политики цели (goal policies);
  • политики функций полезности (utility function policies).

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

Формализация политик

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

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

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

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

Рис. 1. Структура центра обработки данных

Каким образом эти концепции можно реализовать на практике? Представим себе центр обработки данных, состоящий из двух изолированных друг от друга серверов приложений (рис. 1). Каждый сервер приложений предоставляет клиентам определенный сервис. Серверы работают независимо, но используют аппаратные ресурсы из общего пула. Ресурсы распределяются динамически, в зависимости от распределения нагрузок на тот или другой сервер.

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

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

Рис. 2. Множество состояний системы

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

Политику менеджера ресурсов также можно сформулировать в виде набора правил «если, то». Например, можно присваивать серверам приоритеты и выполнять запросы менее приоритетного сервера только в том случае, если это не повредит выполнению запросов более приоритетного сервера.

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

В случае применения политики функции полезности с каждым состоянием (пара значений времени отклика) сопоставляется значение полезности. Это отношение и есть функция полезности для данной системы. В отличие от политики цели, каждое состояние оценивается не по двоичной шкале (желательное/нежелательное), а получает уникальное значение полезности, которое позволяет сделать однозначный выбор с учетом наличных ресурсов.

Проект Rio

Разумеется, не только в IBM озабочены проблемами построения адаптивных систем, управляемых политиками. Недавно компания Sun Microsystems выступила с аналогичной инициативой, инициировав проект Rio.

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

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

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

Классификация политик в Rio

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

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

С точки зрения представленной классификации, политики, реализуемые в рамках Rio, относятся к политикам действий и цели.

Практическая реализация политик

Для сбора информации о текущем состоянии системы в Rio применяются адаптеры контроля сервиса (service control adapter, SCA). Они определяют порядок измерений контролируемого параметра и разрешающую способность — минимальное изменение, вызывающее реакцию системы.

Вот как, например, может выглядеть описание политики для Web-сервера Tomсat, использующего для мониторинга состояния счетчик обращений.

«Экземпляр сервера должен прекратить работу, если приходящаяся на него нагрузка составляет меньше 10 обращений в секунду. Если нагрузка на каждый экземпляр сервера составляет более 100 обращений в секунду, должен быть запущен еще один экземпляр сервера. Общее число запущенных экземпляров сервера не должно превышать 5».

В перечень требований политики платформы для сервера Tomсat может быть включен пункт о том, что каждому экземпляру сервера необходимо предоставлять не менее 10% машинного времени. Понятно, что это описание политики представляет собой набор правил «если, то».

Концепция политик реализована и в рамках интерфейса Java для интегрированных сетей (Java API for Integrated Networks, JAIN). В задачу JAIN входит, в частности, обеспечение соответствия политики предоставления сервиса требованиям договора SLA. Компоненты JAIN реализуют голосовой интерфейс, позволяющий потребителю активировать сервис и по телефону выбрать уровень обслуживания. Основываясь на информации об уровне обслуживания и политиках серверов, компоненты-маршрутизаторы обеспечивают выбор сервера, наиболее подходящего для предоставления сервиса. Кроме того, JAIN дает возможность осуществлять гибкую тарификацию пользователей. n

Андрей Боровский (borovsky@pochtamt.ru) — инженер-программист ФГУП РНИИ КП (Москва).