1. Application Quality of Service
Tuesday, 14:00, 14 Sept 2004
Karl Schopmeyer
V 1.1, 14 Sept 2004

2. Agenda Introduction Objectives Overview of the Architecture
Technologies involved
State of the Standards
What we need to make AQOS work
Future Directions for AQOS

3. Increasing QUALITY while
Overview
The Objective
Increasing QUALITY while
decreasing COST of the
services you provide.
Some of thhe Issues
Resolve bottlenecks quickly or better yet, prevent them from happening.
Make sure important users not waiting
Let the right apps get through and not break the network
Make efficient use of resources and have flexibility to move them quickly to where they are required
AQRM – Application Quality and Resource Management
An open management framework that all component providers, applications or hardware, can plug their own product into and work together with all other components to deliver priority tasks and adjust to meet critical workloads based on policy from a business viewpoint.

4. AQRM Work Group
Work Group of the Open Group Enterprise Management Forum
Application Quality and Resource Management
Actively working with DMTF WGs
Application Management Work Group
Policy Work Group
Etc.
Participating in CIM/WBEM Implementations

5. Charter Overview - AQRM
Understand the current state of the industry regarding Application Quality & Resource Management
Develop a framework for the accomplishment of automated Application Quality & Resource Management
Identify the standards and open tools that fill the needs of the framework
Identify gaps that need to be filled
Provide solutions for the gaps or challenge other organizations working in closely related fields to fill the gaps

6. A Perception of The Solution
AQRM is about management, not monitoring
AQRM is a value-add management function
Build on existing management
Do not duplicate what exists
Depend on the existence of effective instrumentation (networks, applications, systems)
AQRM is an abstraction
Requires management concepts that allow abstracting information to the resource management model
Abstract from managed elements to resource view
AQRM must be based on standards
AQRM is only one component of the general management solution (e.g. it must work with other FCAPS management components).

7. The Major AQRM Objectives
To develop:
a set of architecture principles,
profiles of standards, and
appropriate standards for an adaptive approach to measuring and controlling the Quality of Experience and the Quality of Service of existing and new applications across one or more real-time* enterprises.
Includes:
Recognition/acceptance/endorsement of an adaptive approach to managing distributed applications.
Industry ratification of architecture principles and profiles of standards for the above objective.
Identification of standards gaps and an action plan to close gaps.
Ensure management interoperability, across management domains, and plug-and-play integration, within resource domains.

8. Applications and Resources

9. The AQRM Functional Model
Resources
Control
Analysis
&
Decision
Monitor

10. Integrating Standard Management Functionality into the Model
Behavioral
Control
Common
Management
Instrumentation
Infrastructure
Control
Resources
Analysis
&
Decision
SLAs
Monitor
Policies
AQRM
Abstractions

11. A Management Approach For AQRM
Components:
Application Management
Manages the application and interfaces to underlying infrastructure
Web Services
Manages Web services, including interfaces to network and database elements
Database
Manages database elements, including server and storage interfaces, as well as elements required for distributed operation
Server Management
Manages server system resources
Storage Management
Manages storage disk / SAN elements
Network Management
Manages the connections between all the systems and networks (including storage, as in the case of IP-SAN)
Common Infrastructure
Manages the common elements required to facilitate disaggregated rack-based systems (e.g., cabling, power, etc.)
Application Management
Web Services Management
Database Management
Network Management
Server Management
Storage Management
Common Low-Level Elements

12. What is required to bring this together
Monitoring
A common instrumentation infrastructure
Information on performance of objects of interest to App management
Application performance model
A Service Measurement model
Control
Control of managed resources
A state and behavior control model so that behavior can be controled, not simply executed.
Analysis and Decision
State model for managed resources
Policy objectives models
Mapping between objective level policies and decision implementation
Abstraction between decision and Monitor/Control

13. The components of AQRM
A lot of things have to come together for AQRM to work:
Management of Networks, Systems, etc.
Management of Applications
Management of information flow
Measurement of Service oriented metrics
Service Level concepts (SLAs, SLOs
Policies

14. AQRM Basic Decisions Use CIM as the modeling base
CIM is the only standards based management instrumentation that meets AQRM requirements.
Work with the CIM/WBEM groups to extend/complete the functionality needed for AQRM
SLAs
Policy
Application Management
Behavior and State control
Etc.

15. Early conclusions This is not just a application problem.
This is not just a network or OS problem
Typically just a few of the many monitor variables are significantly indicative of service performance
Typically just a few of the many control variables available have a significant impact on service performance.

16. Measuring Service Time UOW and ARM
App Response time measurement API, ARM
App Response time measurement API, ARM
Servers
Network
App
App
App
App
App
Client
Client
Client
Client
Client
Response time measurement
Is the Unit of Work (UofW) model
App Component definition, performance and resource measurement – App runtime Model

17. Modeling The Transaction - UOW
Measure a time interval
Identify the transaction
Identify the application
Provides information for correlation of multiple measurements
Provides information to understand component UofWork (parent/child units of work)
Provides metric information places for resource, etc. information
Marry with the instrumentation technology - ARM

18. Unit of Work Defines a type of work
Represents a UOW that has started and may have completed executing
Associated to a UOW definition
Provides information such as:
Response or elapsed time
Status
Active, Suspended, Completed (with status), Aborted
Metric Information about the UOW
Examples
Update account balance
Execute batch
Query Data server
Execute subroutine

19. Status UOW model ARM Model Developed by DMTF Application Work Group
Corresponds today to ARM 1, 2, 3
Working on ARM 4 equivalent model
ARM
ARM API for C and Java today (Open Group Standard
Version 4 extend model to more useful metrics, correlation.

20. Service Levels and Objectives
Service Level Agreement
Documented result of a negotiation between a customer/consumer and a provider of a service, that specifies the levels of availability, serviceability, performance, operation or other attributes of the service. [RFC2475]
Service Level Objective
Partitions an SLA into individual metrics and operational information to enforce and/or monitor the SLA. It is a set of parameters and their values. The actions of enforcing and reporting monitored compliance can be implemented as one or more policies.

21. Intersections of SLAs and Management
Formalize SLA concepts of SLAs and their metrics
Standard and “exchangable” definitions
Monitor and programmatically enforce SLAs
Decompose high-level business SLAs to device/resource configurations and monitored parameters.
View the SLAs as goals
Define identity information to support per-customer billing and SLAs
Within and across boundaries
Define and enforce application-specific SLAs

22. SLAs and Semantics SLAs require understanding of syntax and semantics
Describe what is managed and what happens when problems occur (e.g. policies)
SLAs cannot go from general to specific without a general semantic framework
What does it mean to understand a specific application without understanding what an application is.

23. Service Level – Measuring the User experience
Service levels are a measure of the user experience
How much
How fast
How available
How reactive to problems
SLAs define what will keep the user happy

24. Application Management and SLAs
Typical runtime service level parameters
User perspective on performance
Interactive responsiveness
Transaction Response time / Time to accomplish
Throughput / How many simultaneous users or how many things can be done in a defined time
Batch turnaround
Critical deadlines (e.g. end-of-month processing)
Availability
Percentage of time service is available
Maximum limits on service-down times
Other non-runtime SLA issues
Recoverability
Data Integrity
Problem responsiveness
Affordability

25. Goals of Application Measurement
Provide Monitors for
Service Level management
Need information and controls so that analysis can be done and decisions made and implemented
Business and Business Process management
Provide Application Controls for
Fault Determination
Performance characteristic attribution
Application monitor, management and manipulation in terms of application components, aggregation into whole to support SLOs OR
Monitor to provide information for SLA reporting
Provide controls for SLA tuning
Provide means to find why not meeting SLAs
It is not enough to know you have a problem if you do not know why or how to solve the problem.
It is even more worthless to have a means for defining SLAsAnd SLOs and no means to measure them on the system.

26. What are Applications? Complex collections of software components
Multilayered functionally
E.g. Presentation, application, database, etc.
Dynamically assembled
GOALS
Model the components as viewed in runtime including the interactions
Aggregate the information into the whole
Disaggregate information from whole into the components

27. Application Runtime Management
Model being developed by DMTF Application Work Group
app
status
deployable
installable
executable
running
initial
life cycle
sub -model
transport
setup
installation
runtime
Requirements:
Architecture, Management,
Manageability, Meta

28. Application Runtime Manageability Requirements
Define logical runtime structure of complex applications
Define Application components/layers
Support distributed and dynamic applications
Relate physical structures and logical runtime structures
Model usage of system resources as viewed by the application
Model dataflow between components and applications and between applications
Relate Unit of Work information to runtime structure
Allow monitor and control of application state
Support fault management
Aggregate information from components to the whole

29. Modeling FCAPS Fault Indications
Error and status properties (counter, information)
Log-entries, traces, etc.
Performance
Base metrics (IO, timebound metrics, etc.)
UoW
Metric properties
Statistics
Configuration
Persistent configuration information: configuration, settings
Control: methods
Current configuration: object properties, support classes, associations

30. App Runtime Model Concepts (Simplified)

31. Application Model Hierarchy
In development today
Application System submodel (CIM 2.8)
Components of Function submodel (CIM 2.9 prelim)
Data submodel, structure submodel planned for future CIM verisons (2.10, etc.)
Application
Runtime Model
System
Sub-Model
Data
Function
External Systems
Structure
Application Management Model
Deployment Model
...

32. Service Level Agreements
SLAs, SLOs and Policy
Contractual – Based on Business
Process and requirements
Service Level Agreements
Manual Translation
Incorporates
Service Level Objectives
Service Level Metrics
Service Level Policy Specification
Service Level Objectives
Service Level Metrics
Common expression and Metrics
Enforces
Policy Refinement
Decompose service into elements
Element Policy
Element Policy
Create, Update, Maintain
Model, schema, access methods,
Error detection, recovery, creation
Deletion, mod, security, etc.
Policy
Management

33. Policy Why is Policy important
automation – encapsulating management tasks, expressing a desired state or result to be achieved.
Policy can be used to express quality of service parameters to meet required service levels.
Model developed by DMTF Policy and Service Level Work Group
New work includes
Generic conditions (query based)
Generic actions
Issues
Aggregation and disaggregation
Language as an alternative to models.

34. Behavior and State Objective State and State Control
Extend CIM to allow expressing behavior, behavior control, and interobject behavior
State and State Control
Allow model to define states and to define allowable state transitions
Provide means for Actions on other components of the model to be defined as part of state transition (Actions)
Definition of interopbject Actions
Possibly common with Policy
B&H work group in DMTF today. In process of defining mechanisms for state transition and actions definitions as extensions to CIM model.

35. The AQRM Functional Model
Resources
Control
Decision
Process
Monitor

36. Growth of the Information model to a Management model
Managed Services
From Information model
To information and behavior
model
Management Services
Managed Services Model
(tomorrow)
Managed
Services
Model
Manageability Objects
(Today)
Manageability
Model

37. The Object Model Policy This will be a Key interface Between the
QOS objects
And the resource
Objects. Typically
The resource
Objects will be
Dynamically
Created and deleted
And the QOS
Objects must
Support this.
QOS Management
Model
Detailed Resource Management Objects
(NOTE: This is effectively the majority of the
Current CIM model)
Resources

38. Some Characteristics of the AQRM model
AQRM Decision Making
Based on abstractions that support the QOS concepts and define policies that operate on the controls based on the monitors.
Policy Objects
Scripts
State management
AQRM Objects
Represent concepts like;
Capacity
Throughput
Latency
Queue Length.
In effect a network of queues
Every step up through the model we are abstracting the information required for QOS. Note that the relationships is the way this is accomplished.

39. The Model Components for AQRM
Objective Policy (SLO, etc)
Action Policy
Map Policy to Resource
Performance
Resource Layer
Manageability
Service Layer
Application
Model
Current CIM Model(s)
SNMP
SNMP
Resources
Resources

40. Conclusions AQRM is based on CIM and will extend CIM models
AQRM depends on the existence of widely used common instrumentation implementations that interoperate

41. Other DMTF WGs, Oasis WSDM, …
Working Together
OpenGroup
AQRM WG
Application model
SLAs, Service Approach
DMTF Application WG
DMTF Utility WG
DMTF Policy WG
Other DMTF WGs, Oasis WSDM, …
DMTF Behavior
and State WG
Policy and SLA

42. Next Steps
Continue working with these groups to develop the components needed by AQRM
Define preliminary models for AQRM concepts to allow us to demonstrate better what we are trying to accomplish
Join Us

43. AQRM Application Quality / Resource Management and The Open Group
Home
About
Membership
List of Members
Forums
Enterprise Mgmt
ARM
AQRM

44. Questions? ? ? ? ? ?