1 / 32

A Policy-Definition Language and Prototype Implementation Library for

A Policy-Definition Language and Prototype Implementation Library for Policy-based Autonomic Systems Richard John Anthony University of Greenwich R.J.Anthony@gre.ac.uk. Introduction

allene
Download Presentation

A Policy-Definition Language and Prototype Implementation Library for

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Policy-Definition Language and Prototype Implementation Library for Policy-based Autonomic Systems Richard John Anthony University of Greenwich R.J.Anthony@gre.ac.uk

  2. Introduction • This work is towards a generic policy toolkit to support the implementation of autonomic computing systemsin which thepolicies themselves can be adapted dynamically and automatically. • Clearly identifiable need for powerful, easy to deploy tools to facilitate policy-based self-managing behaviours in a very-wide range of application domains. • A generic solution must: • Be flexible to enable a diverse set of behaviours to be defined; • Be sufficiently expressive to capture both simple and complex business • logic; • Support re-use of behaviour to reduce policy development time; • Be accessible to non autonomics-expert software developers working in a • diverse range of application fields; • Facilitate integration with legacy applications. Richard Anthony University of Greenwich ICAC 2006 1

  3. Background • Policies identified as a key concept for implementation of AS • (At least 50% of papers at ICAC 2006 use or advocate policies) • (Current state of policy technology a Key identified shortcoming) • Developed self-config, self-opt Parallel Processing application early 2005 • (eventually supported by 5 separate policies, addressing various aspects of • business logic – dynamic adjustment of granularity, resource management etc). • An exploration exercise • Policies directly embedded into application • Policies ranged in complexity and functionality • Each policy required some common, and some unique features • Simple self-adaptation achieved in some policies • Developer time split evenly between: • Business logic and mechanisms, and • Self management / policy aspects • There must be a better way … Richard Anthony University of Greenwich ICAC 2006 2

  4. Direction • Current policy-based systems can exhibit self-adaptive behaviour by embedding • a policy which itself is static at run-time. • → Policy changes typically require open-loop adaptation. • This work is concerned with future policy-based systems: • Able to ‘evolve’ because the policy can adapt itself. • Embed a suite of policies and use a meta-policy to dynamically select based • on environment / context. • It will be possible for several dimensions of adaptation to occur concurrently: • Fine-grained policy-static control, • Medium-grained optimisation achieved through policy self-adaptation, • Coarse grained behavioural shifts achieved through meta-policy high-level • governance. Richard Anthony University of Greenwich ICAC 2006 3

  5. Interpretation of the term ‘policy’ • A set of configuration values that parameterise a rule-based decision engine • - in this work referred to as a Template. • A set of rules that are applied to determine the behaviour of the system • given certain inputs. • Polices thus contain the configuration parameters and the actual decision rules externally to the embedded mechanism. • Templates and policies are ideal entry-level techniques for embedding adaptive behaviours into applications. • → Current schemes usually provide only initiation-time configuration, • i.e. - configuration remains static at run-time, or • - run-time behaviour scoped within pre-set bounds. • Complex systems with wide potential behaviour space do not lend themselves well to governance by a single policy. • → Better to have a collection of policies and use a Meta-policy to select. Richard Anthony University of Greenwich ICAC 2006 4

  6. Current State-of-Practice in Policy-based Autonomics • Three distinct levels of sophistication are found in current approaches: • Policy rules are statically embedded. The template configuration is • exposed and can be modified between executions. • 2. Policy updates are open-loop. An external entity (usually a human) • identifies, or is alerted to, potential configuration optimisations, which • can be applied between executions. • 3. Closed-loop adaptation, where the policy dynamically and automatically • adapts its own rule-base or template settings during execution. • (Few schemes target or achieve this level at present). Richard Anthony University of Greenwich ICAC 2006 5

  7. Manual configuration Policy (rule based) Library of templates Template configuration Meta policy Library of policies Direct configuration / control Controlled system Persisted state Feedback / monitoring / update State propagation (a) (e) P P M P P M M (b) P T (c) P T (f) P T T T T T T T T (d) P P P P P P Pictographic representation of policy life-cycles found in current practice Richard Anthony University of Greenwich ICAC 2006 6

  8. Extending the state of the art The new policy language and library support self-adaptive policy behaviour: The policy is able to adapt its own behaviour as well as adapting the controlled system. This gives rise to a number of envisioned policy-system configurations beyond current practice. Richard Anthony University of Greenwich ICAC 2006 7

  9. Manual configuration Policy (rule based) Library of templates Template configuration Meta policy Library of policies Direct configuration / control Controlled system Persisted state Feedback / monitoring / update State propagation (g) P T P M M P M P (h) P T (i) T T T T T T T T (j) P P P P P P P P P Advanced policy configurations beyond the current state of practice Richard Anthony University of Greenwich ICAC 2006 8

  10. Differential between existing and proposed approaches (V. generalised) Manager Controlled component Policy State of Practice ? Manager Meta- Policy Controlled component Proposed / Targeted Policy Policy Policy Some governance delegated to meta-policy Richard Anthony University of Greenwich ICAC 2006 9

  11. The Policy Definition Language Extends the state of the art in policy languages: Explicit support for dynamic self-adaptation of policies over both short and long term through persisted configuration changes. Policy suites, in which a particular type of policy can have many differently-geared instances (e.g. cautious and aggressive versions). Suites of templates for a given policy-type allow different initial configurations to be used, depending on circumstances. Meta-policies can be used to select amongst many policy-instances and templates at initiation time. Meta-policies can automatically ‘hot-swap’ between instances of the same type of policy at run-time. Features to support bounded behaviour and enhance stability. Facilitates policy-object reuse. Richard Anthony University of Greenwich ICAC 2006 10

  12. Overview of the policy definition language features (1) Object oriented. Objects represent policies, rules, actions etc. OO approach facilitates re-use of behaviour, through reusing tested objects. A polymorphic Variable-type (PolicyObject) facilitates referencing of policy objects within the policy rules and actions themselves. Hierarchical support for three levels of ‘policy’: 1. Templates provide configuration parameters which are used to initialise the other types of policy. 2. Normal policies contain the low-level autonomics logic. 3. Meta-policies provide higher-level adaptation. A single policy script may contain all three types forms of ‘policy’. Meta-policies can be used to perform an initial configuration decision, and / or can operate continuously. In this latter mode, meta-policies support ‘hot-swapping’ between normal policy instances. Richard Anthony University of Greenwich ICAC 2006 11

  13. Overview of the policy definition language features (2) • Reinforces natural semantic differences between: • Variables that convey external information to the policy, • Variables used to maintain internal policy state. • External variables cannot be modified, configured in a template, or • persisted. Must be passed into the policy via the library interface each • time the policy is invoked. • Dynamic state represented by internal variables can be persisted to • enable longer-term adaptation. • Separating variables into 2 classes reinforces type-safety and semantic • checking. E.g. an external variable may only occur on the RHS of an • assignment operation. • Template configuration of internal variables supports specification of various • attributes, which include: upper and lower value limits, • increment and decrement amounts. • (Attributes can be dynamically adjusted at run-time) • Policies are formatted in XML which enforces a standard general syntax and • facilitates portability and deployment in heterogeneous systems. Richard Anthony University of Greenwich ICAC 2006 12

  14. Class Hierarchy strName Evaluate() CPolicyObject CTemplate CRule CAction CPolicy CVariable CInternalVariable CExternalVariable Richard Anthony University of Greenwich ICAC 2006 13

  15. Language structure and components (1) ExternalVariable: Variables that are passed in to the policy at the point of policy evaluation. These variables represent environmental or contextual conditions. InternalVariable: Variables used internally by a policy (e.g. counters and flags). Variables can be of three basic types: Long, Boolean and PolicyObject. Strong validation is used to ensure correct usage. Template: A collection of InternalVariable configuration statements that apply to a particular policy-type. ReturnValue: Named Numerical return codes for use within the policy script. Action: A grouped sequence of activities. A particular Action may occur when a Rule evaluates to either true or false, or when a ToleranceRangeCheck evaluates to either in-zone or not-in-zone. Rule: A statement that evaluates to either true or false. Rules have separate Actions for the evaluate true and evaluate false cases. Richard Anthony University of Greenwich ICAC 2006 14

  16. Language structure and components (2) ToleranceRangeCheck: A specialized rule that is used to implement fuzzy variable comparison, as well as dead-zones. Separate Actions can be specified for the In-Zone and Not-in-Zone evaluation cases. Policy: A sequence of Rules and ToleranceRangeChecks that implement the self-management business logic. MetaPolicy (special case of Policy): A sequence of Rules and ToleranceRangeChecks that can be used to dynamically select the current policy and template configuration. PolicySuite: A collection of Policies of the same ‘type’ (i.e. concerned with a certain aspect of business logic). Richard Anthony University of Greenwich ICAC 2006 15

  17. The Policy Library • Easy integration with legacy code: • Provides internal support for many powerful language-support features. • Clear demarcation between internally managed and externally maintained • aspects of policy behaviour. • Supports use by non-autonomics-experts: • Simplifies mapping of business logic into policy specifications, through features such as: • Powerful library-internal validation and semantic checking, • Distinction between internal and external variables, • Automatic restriction of low-level adaptation within higher-level • expressed bounds, • Silent conflict / violation handling. • Generic applicability to a wide range of problem domains: • Flexible methods for defining application-to-policy interface objects such as • ExternalVariables and ReturnValues in programming-language-neutral ways. Richard Anthony University of Greenwich ICAC 2006 16

  18. Case Example 1: Self-optimisation in parallel processing Conforms to configuration (f) in the policy taxonomy. This example is one of several policies deployed in an exploratory self-managing parallel processing application. This particular policy dynamically optimises Round-Trip Time (RTT) measurement activity (as part of the embedded discovery and dynamic optimisation capabilities). The optimisation is in terms of achieving a balance between saving network bandwidth and processing by cutting out some calibration messages, and yet performing sufficient measurements to keep track of the variability of communication latency between components. Richard Anthony University of Greenwich ICAC 2006 17

  19. Policies operate at several logical levels Business-level policy (expression of user intent) “Optimise costs of calibration”, “I don’t care whether a specific calibration event is skipped or not”, “No more than 5 consecutive calibration measurements should be skipped” System-Level policy (lower-level behaviour rules) Attribute values govern manipulation of specific variables, e.g. Variable: CalibrateInterval Attributes: InitialValue="1" MaxValue="5" IncrementAmount="1“ … One object (such as a variable) can directly impact the evaluation of another object (such as a rule) – obvious case. But also (for example) a rule can impact the manipulation of a variable by changing its attributes Richard Anthony University of Greenwich ICAC 2006 18

  20. Case Example 1: Self-optimisation in parallel processing (Outline operation) A variable that governs the current number of calibration messages that can be skipped (the soft limit) is initialised to 1, and has a MaxValue attribute set to 5 (the hard limit). The policy keeps track of variability in RTT measurements, allowing calibrations to be skipped when the communication latency is stable. During prolonged periods of stability the policy gradually ramps up the soft limit value – until eventually it reaches the hard limit. Further increment requests can be made, but the library mechanisms ignore any requests that violate the variable’s attribute settings. When the communication latency becomes more volatile the soft limit is dropped back to its initial value. Summary: One set of rules maintain configuration parameters that govern the behaviour of other rules. Richard Anthony University of Greenwich ICAC 2006 19

  21. The RTT policy Script (abridged) Part 1 <!-- Policy Definition XML file: Policy Language version 1.0 --> <!-- Application: Self-Management in Cooperative Distributed Problem Solving --> <PolicyConfiguration> <!-- PolicyTypeName=RTT Measurement Policy --> <EnvironmentVariables> <Variable Name="E_iCurrentSample" Type="long"/> </EnvironmentVariables> <InternalVariables> <Variable Name="I_iCalibrateInterval" Type="long"/> <Variable Name="I_iSimilarSampleCountThreshold" Type="long"/> </InternalVariables> <Templates> <Template Name="DefaultTemplate"> <Assign Variable="I_iCalibrateInterval" InitialValue="1" MinValueValid="true" MinValue="1" MaxValueValid="true" MaxValue="5" IncrementAmount="1"/> <Assign Variable="I_iSimilarSampleCountThreshold" InitialValue="3“ MinValueValid="true" MinValue="1" MaxValueValid="false" MaxValue="0“ IncrementAmount="1"/> </Template> </Templates> <ReturnValues> <ReturnValue Name="YES_Forced" Value="1"/> </ReturnValues> <Actions> <Action Name="A_ContinueAfterInterval"> <Increment Variable="I_iCalibrateInterval"/> <Assign Variable="I_bCanSkipCalibrationUnlessIntervalReached" Value="true"/> <Assign Variable="I_iSkippedCount" Value="0"/> <Assign Variable="I_iPrevSample" Value="E_iCurrentSample"/> <Return ReturnValue="NO_Stable"/> </Action> </Actions> Soft Limit Hard Limit Externally configured values Richard Anthony University of Greenwich ICAC 2006 20

  22. The RTT policy Script (abridged) Part 2 <Rules> <Rule Name="R_ContinueAfterInterval" LHS="I_bStable_CanSkipAfterCalibrateInterval“ Operator="EQ" RHS="true" ActionIfTrue="A_ContinueAfterInterval" ElseAction="Null"/> <Rule Name="R_SkipIntervalReached" LHS="I_iSkippedCount" Operator="LT" RHS="I_iCalibrateInterval" ActionIfTrue="A_CanSkipCalibration" ElseAction="A_MustPerformIntervalCalibration"/> </Rules> <ToleranceRangeChecks> <ToleranceRangeCheck Name="C_CurrentSampleStable“ CheckVariable="E_iCurrentSample" CompareAgainstVariable="I_iPrevSample" ToleranceRangePercentSpecifier="I_iSampleTolerancePercent" ActionIfInZone="A_CurrentSampleStable" ActionIfOutsideZone="A_CurrentSampleNotStable"/> </ToleranceRangeChecks> <Policies> <Policy Name="DefaultPolicy" PolicyType="NormalPolicy"> <Initialise CurrentTemplate="DefaultTemplate"/> <Evaluate Rule="R_OptimisationAllowed"/> <Evaluate Rule="R_CanSkipCalibrationUnlessIntervalReached"/> <Evaluate ToleranceRangeCheck="C_CurrentSampleStable"/> <Evaluate Rule="R_ContinueAfterInterval"/> <Evaluate Rule="R_SameCountSufficient"/> </Policy> </Policies> </PolicyConfiguration> Externally configured values Richard Anthony University of Greenwich ICAC 2006 21

  23. Sample results: the RTT policy in action Richard Anthony University of Greenwich ICAC 2006 22

  24. Case Example 2: A multi-policy stock trading scheme (1) Conforms to configuration (i) in the policy taxonomy (beyond current state of practice). This example illustrates the use of meta-policies and the advantage of dynamic switching between instances of business policies. The stock system is representative of many real-world problems that have: Highly complex behaviour, Sensitivity to several sources of environmental volatility, Non-linear sensitivity to some environmental parameters, Many dimensions of freedom. For a system with any of these characteristics, it is not realistic to closely track the system over its entire behaviour range with a single policy. Richard Anthony University of Greenwich ICAC 2006 23

  25. Zone # 4 Zone # 2 Rate of Price change Zone # 1 Zone # 3 Rate of Volume Traded change Case Example 2: A multi-policy stock trading scheme (2) Trading decisions are subject to influences such as price behaviour trends, the rate of change in traded volumes and the rate of change in price, etc. A single, generalised (and thus coarse) policy could lead to significant sub-optimality across a wide spectrum of behaviours. One solution is to divide the application behaviour space into several zones. Each zone requires a stock-price-based trading strategy, contextualised by a given range of rate of change in traded volumes and in price. The policies have different configuration but are of the same ‘type’ since they address the same business decision (but arrive at their decisions differently). Richard Anthony University of Greenwich ICAC 2006 24

  26. Case Example 2: A multi-policy stock trading scheme (3) Each policy is configured such that its operational envelope (that over which it guarantees safe and desirable behaviour) is tuned to map closely onto its ‘zone’. A self-adaptive policy may adjust its own thresholds over time, or these might be supplied externally. Richard Anthony University of Greenwich ICAC 2006 25

  27. Case Example 2: A multi-policy stock trading scheme (4) Individual policies need not be aware of the delimitation of their zones. A MetaPolicy is employed to select between the different business policies. The MetaPolicy monitors the behaviour of the target system and determines which policy should be employed at any given moment. Richard Anthony University of Greenwich ICAC 2006 26

  28. Case Example 2: A multi-policy stock trading scheme (5) There is a risk of instability if simple cut-off points are used to determine the policy selection. If the behaviour of the monitored system is close to one of the cut-offs there is a possibility that the policies will be switched to and fro, causing extra work for the system. The ToleranceRangeCheck language object facilitates easy configuration of dead-zones, enhancing stability (localised oscillatory behaviour in the target system is not mirrored in the behaviour of the MetaPolicy). Richard Anthony University of Greenwich ICAC 2006 27

  29. The stock-trading multi-policy script (abridged) Part 1 <PolicyConfiguration> <!-- PolicyTypeName= Stock-Trading Policy --> <EnvironmentVariables> <Variable Name="E_iCurrentPriceRateChange" Type="long"/> <Variable Name="E_iCurrentVolumeRateChange" Type="long"/> </EnvironmentVariables> <InternalVariables> <Variable Name="I_iPriceRateChangeDeadZone" Type="long"/> <Variable Name="I_iVolumeRateChangeDeadZone" Type="long"/> <Variable Name="I_iDeadZoneTolerancePercent" Type="long"/> </InternalVariables> <Templates> <Template Name="MetaTemplate"> <Assign Variable="I_pCurrentPolicy" InitialValue="Policy1"/> <Assign Variable="I_iPriceRateChangeDeadZone" InitialValue="60"/> <Assign Variable="I_iVolumeRateChangeDeadZone" InitialValue="50"/> <Assign Variable="I_iDeadZoneTolerancePercent" InitialValue="10"/> </Template> </Templates> <ReturnValues> </ReturnValues> <Actions> <Action Name="A_DeterminePolicyBasedOnPriceRateChange"> <Evaluate Rule="R_CurrentPriceRateChange"/> </Action> <Action Name="A_DeterminePolicyBasedOnVolumeRateChange"> <Evaluate Rule="R_CurrentVolumeRateChange"/> </Action> </Actions> Externally configured values Richard Anthony University of Greenwich ICAC 2006 28

  30. The stock-trading multi-policy script (abridged) Part 2 <Rules> <Rule Name="R_CurrentPriceRateChange" LHS="E_iCurrentPriceRateChange" Operator="LT" RHS="I_iPriceRateChangeDeadZone" ActionIfTrue="A_SelectLowPriceRateChangePolicy" ElseAction="A_SelectHighPriceRateChangePolicy"/> </Rules> <ToleranceRangeChecks> <ToleranceRangeCheck Name="C_PriceRateChangeDeadZone" CheckVariable="E_iCurrentPriceRateChange" CompareAgainstVariable="I_iPriceRateChangeDeadZone" ToleranceRangePercentSpecifier="I_iDeadZoneTolerancePercent" ActionIfInZone="Null" ActionIfOutsideZone="A_DeterminePolicyBasedOnPriceRateChange"/> </ToleranceRangeChecks> <Policies> <Policy Name="Meta_Policy" PolicyType="MetaPolicy"> <Initialise CurrentTemplate="MetaTemplate"/> <Evaluate ToleranceRangeCheck="C_PriceRateChangeDeadZone"/> <Evaluate ToleranceRangeCheck="C_VolumeRateChangeDeadZone"/> </Policy> <Policy Name="Policy1" PolicyType="NormalPolicy"> <!-- Detail omitted --> </Policy> <Policy Name="Policy2" PolicyType="NormalPolicy"> <!-- Detail omitted --> </Policy> <Policy Name="Policy3" PolicyType="NormalPolicy"> <!-- Detail omitted --> </Policy> <Policy Name="Policy4" PolicyType="NormalPolicy"> <!-- Detail omitted --> </Policy> </Policies> </PolicyConfiguration> Externally configured values Richard Anthony University of Greenwich ICAC 2006 29

  31. Conclusion Meta-policies represent a meta-state transition in policy computing; bringing greater flexibility and a hierarchical aspect that helps control complexity. The policy language supports several dimensions of adaptability: - Low-level changes enforced by a particular policy; - Dynamic adjustments to internal state variables (e.g. including the parameters that define the position and width of dead-zones). - Automatic switching of policies to ensure that the current policy always remains within its optimal operational envelope; - Longer-term adaptation by dynamically updating template configurations and persisting their state. The direct support for dead-zones enables stability despite a potentially high extent of adaptability. The library mechanisms automatically enforce adherence to constraints such as maximum value for a given variable (these attributes are themselves dynamically re-configurable). The library facilitates integration into legacy code - many applications in current use need self-management, without complete re-development. Richard Anthony University of Greenwich ICAC 2006 30

  32. (Lots of) Further work • Further development of language specification • Support for utility functions (CUtility) and fuzzy comparisons are planned, • Richer attribute sets on objects. • Further development of library and interface • Flexible persistence support, • Internal logging / trace facility, • An instrumentation interface for external monitoring. • Development of a suite of demonstrator / validator applications Richard Anthony University of Greenwich ICAC 2006 31

More Related