АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Политико-ориентированное управление

Экспертиза РАН

Logo-ran.pngLogo-ran-black.png
Проводится экспертиза
Российской академией наук
Подробнее
Times2.svg

Экспертиза РАН

Arrow-Right.png
Logo-ran.png
Проводится экспертиза
Российской академией наук
Подробнее

Политико-ориентированное управление (англ. policy-based management)[1][2][3] — технология, используемая для упрощения сложных задач управления сетями и распределёнными системами. В рамках этого подхода администратор может гибко и более просто управлять различными аспектами сети или распределённой системы, внедряя набор политик, определяющих поведение управляемой среды[4][5]. Политики представляют собой технологически независимые правила, предназначенные для расширения жёстко заданной функциональности управляемых устройств за счёт введения интерпретируемой логики, которую можно динамически изменять без модификации базовой реализации. Это обеспечивает определённую степень программируемости без необходимости прерывать работу как управляемой системы, так и самой системы управления. Политико-ориентированное управление может существенно увеличить свойства самоуправления в любой распределённой системе или сети, что приводит к проявлению автономного поведения, характерного для автономных вычислительных систем[6][7].

Архитектуры и языки

Наиболее известная архитектура политико-ориентированного управления была сформирована совместно IETF и DMTF. Она включает четыре основных функциональных элемента: инструмент управления политиками (Policy Management Tool, PMT), репозиторий политик (Policy Repository), точку принятия решений по политикам (Policy Decision Point, PDP) и точку применения политик (Policy Enforcement Point, PEP).

PMT используется администратором для определения или обновления политик, применяемых в управляемой сети. Полученные политики сохраняются в репозитории в форме, соответствующей информационной модели[8], что обеспечивает совместимость между продуктами различных производителей. После добавления новых политик в репозиторий или изменения существующих PMT отправляет соответствующие уведомления PDP, который интерпретирует политики и передаёт их PEP. PEP — это компонент, работающий на узле с поддержкой политик и способный выполнять (применять) различные политики. Компоненты архитектуры могут взаимодействовать друг с другом с использованием различных протоколов. Предпочтительными средствами передачи решений о политике между PDP и сетевыми устройствами (PEP) выступают COPS или SNMP, а для связи PMT/PDP с репозиторием — LDAP.

Самый простой способ спецификации политик — последовательность правил, каждое из которых представляет собой пару «условие-действие». Архитектура IETF использует этот подход и рассматривает политики как правила, определяющие действия, выполняемые при выполнении заданных условий: 

   if <условие(я)> then <действие(я)>

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

Конфликты политик

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

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

Конфликты политик в целом делятся на независимые от области применения и специфичные для конкретных приложений[11], где первые не зависят от сферы применения, а вторые определяются специфическими требованиями предметной области. В литературе примером прикладных областей выступают обеспечение качества обслуживания (QoS) в IP-сетях[9][12], распределённые системы[11][13], безопасность межсетевых экранов,[14][15][16] а также управление вызовами в телекоммуникационных сетях[17]. Конфликты политик можно также классифицировать по временным рамкам выявления: статические конфликты[18] могут быть обнаружены при офлайн-анализе во время спецификации политики, в то время как динамические конфликты[19] выявляются только при непосредственном применении политик, так как они зависят от текущего состояния управляемой системы. Например, конфликт может возникнуть между политикой динамического выделения ресурсов и политикой, устанавливающей лимиты для пользователей или классов обслуживания. Поэтому автоматизация является ключевым элементом механизмов анализа динамических конфликтов, чтобы минимизировать влияние конфликта на работу системы.

Обнаружение и разрешение конфликтов политик

Для эффективного использования политик и согласованного управления системой необходимо проверять, не вступают ли новые политики в противоречие друг с другом или с уже внедрёнными политиками. Для этого процессы обнаружения используют информацию об условиях возникновения конфликтов и анализируют пространство политик, чтобы выявить политики, соответствующие критериям конфликта. На основе различных типов конфликтов, описанных в литературе и различных областях применения, исследователи разрабатывают механизмы и техники для их эффективного выявления. Простые конфликты (например, модальные конфликты) могут быть обнаружены синтаксическим анализом, однако для более сложных несогласованностей требуется чёткое определение условий конфликта, что иногда предполагает использование предметно-ориентированных знаний. Популярные подходы к выявлению конфликтов базируются на метаполитиках (правилах обнаружения),[9][11][20] взаимосвязях политик[14],[15][16] пространствах применимости[21], и информационных моделях[22].

Разрешение является следующим этапом анализа политик и направлено на обработку обнаруженных несогласованностей, желательно автоматически, для восстановления согласованности политик. В процесс разрешения может входить отзыв, подавление, приоритизация, изменение политик или, в некоторых случаях, введение новой политики. Методика разрешения зависит прежде всего от типа политики и специфики прикладной области. Хотя в ряде ситуаций вмешательство человека неизбежно, многие исследования направлены на автоматизацию процесса разрешения. Наиболее распространёнными подходами являются метаполитики (правила разрешения)[9][19][20], приоритеты[11] упорядочивание политик,[15][21], и предотвращение конфликтов[23].

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

Декомпозиция и уточнение политик

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

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

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

Для декомпозиции политик предложено множество подходов. Наиболее заметные из них основаны на линейной временной логике[24], исчислении событий[25], и утилитарных вычислениях[26][27].

Примечания

  1. ↑ R. Boutaba и S. Znaty. Towards Integrated Network Management: A Domain/Policy Approach and its Application to a High Speed Multi-Network. In Proceedings of IEEE/IFIP International Symposium on Network Operation and Management (NOMS'94), pp. 777-789, февраль 1994.
  2. ↑ M.S. Sloman. Policy Driven Management for Distributed Systems. Journal of Network and Systems Management, том 2, № 4, стр. 333–360, Plenoum Press, декабрь 1994.
  3. ↑ R. Boutaba и I. Aib. Policy-Based Management: A Historical Perspective. Journal of Network and Systems Management, том 15, № 4, стр. 447–480, Springer, декабрь 2007.
  4. ↑ R. Boutaba и S. Znaty. An Architectural Approach for Integrated Networks and Systems Management. ACM SIGCOMM Computer Communication Review, том 25, № 5, стр. 13–39, 1995.
  5. ↑ D. Verma. Simplifying network administration using policy-based management. IEEE Network, 2002.
  6. ↑ R. Boutaba, S. Omari и A. Virk. SELFCON: An Architecture for Self-Configuration of Networks. KICS/IEEE International Journal of Communications and Networks (специальный выпуск по управлению новой сетевой инфраструктурой и сервисами), том 3, № 4, стр. 317–323, декабрь 2001.
  7. ↑ D. Agrawal, S. Calo, K. Lee, J. Lobo, D. Verma. Policy Technologies for Self Managing Systems. IBM Press, 2008.
  8. ↑ B. Moore, E. Ellesson, J. Strassner, A. Westerinen. Policy Core Information Model. RFC 3060, IETF, февраль 2001.
  9. ↑ 1 2 3 4 5 6 M. Charalambides, P. Flegkas, G. Pavlou, J.R. Loyola, A.K. Bandara, E.C. Lupu, M.S. Sloman, A. Russo, N. Dulay. Policy Conflict Analysis for DiffServ Quality of Service Management. IEEE Transactions on Network and Service Management, том 6, № 1, март 2009.
  10. ↑ J. Strassner. Policy-Based Network Management. Morgan Kaufmann Publishers, ISBN 1-55860-859-1, 2004.
  11. ↑ 1 2 3 4 E.C. Lupu, M.S. Sloman. Conflicts in Policy-based Distributed Systems Management. IEEE Transactions on Software Engineering — Special Issue on Inconsistency Management, том 25, стр. 852–869, 1999.
  12. ↑ T. Samak, E. Al-Shaer, H. Li. QoS Policy Modeling and Conflict Analysis. Proceedings of IEEE Workshop on Policies for Networks and Distributed Systems, Нью-Йорк, США, июнь 2008.
  13. ↑ A.K. Bandara, E.C. Lupu, A. Russo. Using Event Calculus to Formalise Policy Specification and Analysis. Proceedings of IEEE Workshop on Policies for Distributed Systems and Networks, озеро Комо, Италия, июнь 2003.
  14. ↑ 1 2 E. Al-Shaer, H. Hamed. Discovery of Policy Anomalies in Distributed Firewalls. Proceedings of IEEE Communications Society Conference, Гонконг, март 2004.
  15. ↑ 1 2 3 E. Al-Shaer, H. Hamed. Modeling and Management of Firewall Policies. IEEE Transactions on Network and Service Management, том 1, № 1, апрель 2004.
  16. ↑ 1 2 E. Al-Shaer, H. Hamed, R. Boutaba, M. Hasan. Conflict Classification and Analysis of Distributed Firewall Policies. IEEE Journal on Selected Areas in Communications, том 23, № 10, стр. 2069–2084, октябрь 2005.
  17. ↑ L. Blair, K. Turner. Handling Policy Conflicts in Call Control. Proceedings of International Conference on Feature Interaction, Лестер, Великобритания, июнь 2005.
  18. ↑ 1 2 M. Charalambides, P. Flegkas, G. Pavlou, A.K. Bandara, E.C. Lupu, M.S. Sloman, A. Russo, N. Dulay, J.R. Loyola. Policy Conflict Analysis for Quality of Service Management. Proceedings of IEEE Workshop on Policies for Distributed Systems and Networks, Стокгольм, Швеция, июнь 2005.
  19. ↑ 1 2 3 M. Charalambides, P. Flegkas, G. Pavlou, J.R. Loyola, A.K. Bandara, E.C. Lupu, M.S. Sloman, A. Russo, N. Dulay. Dynamic Policy Analysis and Conflict Resolution for DiffServ Quality of Service Management. Proceedings of IEEE/IFIP Network Operations and Management Symposium, Ванкувер, Канада, апрель 2006.
  20. ↑ 1 2 A. Polyrakis и R. Boutaba. The Meta-Policy Information Base. IEEE Network, специальный выпуск по Policy-Based Networks, том 16, № 2, стр. 40–48, 2002.
  21. ↑ 1 2 D. Agrawal, J. Giles, K.W. Lee, J. Lobo. Policy Ratification. Proceedings of IEEE Workshop on Policies for Networks and Distributed Systems, Стокгольм, Швеция, июнь 2005.
  22. ↑ S. Davy, B. Jennings, J. Strassner. Application Domain Independent Policy Conflict Analysis Using Information Models. Proceedings of IEEE/IFIP Network Operations and Management Symposium, Салвадор, Бразилия, апрель 2008.
  23. ↑ R. Chadha, Y. Cheng, J. Chiang, G. Levin, S.W. Li, A. Poylisher, L. LaVergne, S. Newman. Scalable Policy Management for Ad Hoc Networks. Proceedings of Military Communications Conference, Нью-Джерси, США, октябрь 2005.
  24. ↑ J.R. Loyola, J. Serrat, M. Charalambides, P. Flegkas, G. Pavlou. A Methodological Approach toward the Refinement Problem in Policy-Based Management Systems. IEEE Communications Magazine, Topics in Network and Service Management, том 44, № 10, октябрь 2006.
  25. ↑ A.K. Bandara, E.C. Lupu, A. Russo, N. Dulay, M. Sloman, P. Flegkas, M. Charalambides, G. Pavlou. Policy Refinement for IP Differentiated Services Quality of Service Management. IEEE Transactions on Network and Service Management (TNSM), том 2, № 2, 2006.
  26. ↑ I. Aib и R. Boutaba. Business-driven optimization of Policy Based Management Solutions; A Web Application Hosting SLA Use Case. In Proceedings of the IFIP/IEEE International Symposium on Integrated Network Management (IM'2007), Мюнхен, Германия, май 2007.
  27. ↑ I. Aib и R. Boutaba. On leveraging policy-based management for maximizing business profit. In IEEE Transactions on Network and Service Management, том 4, № 3, стр. 163–176, декабрь 2007.

Категории