SLA information management through dependency digraphs: the case of cloud data services

SLA INFORMATION MANAGEMENT THROUGH DEPENDENCY DIGRAPHS: THE CASE OF CLOUD

DATA SERVICES

Katerina Stamou, Verena Kantere, Jean-Henry Morin

Institute of Services Science, University of Geneva, Switzerland and Michael Georgiou

Cyprus University of Technology, Cyprus

HICSS 47 - Secure Cloud computing security mini-track, Hawaii, USA

04/11/2023HICSS 47 - Secure Cloud computing security mini-track, Hawaii, USA

2

In a nutshell..

The term SLA data management encloses data operations that may take place before, during or after the service level agreement (SLA) and service execution.

The systematic management of SLA data is required for the automation of SLAs and of service management processes (e.g. auditing, monitoring) that generate a new cloud computing market and add business value in a service-oriented economy.

We propose that the systematic management of SLAs can be efficiently achieved using a digraph data model that perceives SLA elements and their data relations as operational pipelines.

Service Level Agreements can be formalized and processed as dependency graphs.

A dependency graph is defined as a directed graph that contains properties. Graph edges denote dependencies among connected component pairs.

The paper showcases the formalization of an SLA dependency graph for the case of an RDBMS data service.


3

Agenda

Definitions, problem description SLA formalization: anatomy, service

dependencies SLA data management requirements SLA digraph data model: WSLA [1] into a

property digraph Data service provisioning scenario: service

properties, SLA template Ongoing work: SLA representation as a triple-

store


4

Definitions, problem description

Service Level Agreements (SLAs) express mutually agreed service levels between providers and customers [1]. SLAs define quality of service (QoS) criteria, along with functional service properties.

The definition and structure of SLAs for cloud computing services are not yet standardized.

The term “systematic SLA data management” describes the process of automated SLA formulation, storage and processing according to a dynamic, adaptable data-schema and by one or more backend supporting data-stores or DBMS.

SLA data management through graph data structures allows for numerous traversal and filtering options that support the service and SLA management over distributed virtual resources that are dominated by availability and demand.


5

SLA anatomy: Web Service Level Agreement (WSLA), IBM [1]

Signatories, third parties: customer-provider pair and their connections to third party support for the service execution.

Service description: decomposition and hierarchical classification of service objects or operations, whose accumulation and/or combination constitutes the service definition.Guarantees: obligations, typically from the provider part, to fulfill agreed and promised levels or service provisioning. IBM distinguishes between measureable targets (objectives) and predefined actions that occur during the service up-time.


6

SLA formalization: service dependencies

According to Keller et al [2], service dependencies represent customer/provider relationships that are reflected to cooperating components in a distributed service management system.

The term "dependency" defines the relationship between a dependent service component that requires an operation performed by an antecedent component in order for the former to execute its function.

Service dependencies between internal SLA components can be translated as actions (rules) that are fired when a predefined condition is triggered.

Service dependencies are reflected in the SLA by: Identified relationships between SLA components of the same

service Identified hierarchies of services and service subsets within

service networks


7

SLA data management requirements

Data criteria/ SLA components

SLA paramet

er

Metrics SLOs Action guarante

es

SLA doc

example SLA mgt operations

accessibility, integrity

✖ ✖ ✖ ✖ ✖ measurement, auditing

velocity rate high high high low na real-time monitoring

replication, staging

✖ ✖ na na ✖ real-time value evaluation

dependencies ✖ na ✖ ✖ ✖ alerts, actions

cleanness ✖ ✖ ✖ ✖ ✖ auditing, guarantee evaluation

accuracy ✖ ✖ ✖ ✖ ✖ real-time monitoring,

auditing

ownership, authenticity

✖ ✖ ✖ ✖ ✖ auditing, guarantee definition

heterogeneity ✖ ✖ ✖ ✖ ✖ function definition, metric evaluation


8

SLA digraph formalization - skeleton


9

Data Service scenario (& next 3 slides)

A service provider offers deployed relational databases. The scenario assumes alternative provisioning configurations according to:

Database isolation, data sharing DB/Schema administration Storage partitioning

Exercise goal: data service profiling and provisioning metrics. Method: a data service representation as a collection of

attributes; map attributes to service provisioning semantics; generate SLA template(s).

Scenario example, 3 service types: Separate DB, Separate schema (ST1) Shared DB, Separate schema (ST2) Shared DB, Shared schema (ST3)


10

Data Service scenario infrastructure


11

Data service properties (scenario)

Resource/System characteristics

ST1

ST2

ST3

OS platform: Windows, Unix, Linux (32/64)

✔

CPU (family type/frequency)

✔

Processor (nr/frequency)

✔

Database/Schema criteria

ST1

ST2

ST3

DB instance/Schema nr. ✔ ✔

DB memory (MB) ✔

DB memory per connection (MB)

✔ ✔

DB/Schema size (MB/GB) ✔ ✔

DB/Schema growing ratio ✔ ✔

DB/Schema administration

✔ ✔

DB/Schema operations ST1

ST2

ST3

DB shutdown/start-up ✔

On-demand DB/schema/table backups

✔ ✔ ✔

DB/schema/table restores

✔ ✔ ✔

•Classification by service type to generate SLA template(s).•The three service types represent three service description branches that belong to the same SLA tree.


12

Separate DB, Separate schema SLA template example (scenario)


13

Ongoing work

SLA model representation in triple format. Advantages from SLA data management

through graphs: traversal and filtering opportunities through RDF triple stores.

AllegroGraph [3] servers on Amazon WS [4] resources to evaluate the SLA graph model for identified use cases that are positioned in the cloud computing setting.


14

On-going work: SLA graph model in the Allegro triple store

Our current experimentation uses:•AllegroGraph server instances on Amazon WS to simulate the selection and exchange of service offers through distributed RDF graph repositories.•Synthetic data taken from real service offers as advertised in Amazon WS to compose SLA data repositories for the cloud simulation.•The tests aim to evaluate the efficiency, expressiveness and usability of the proposed SLA data model by experimenting on service data management use case over virtual infrastructures.


15

Thank you!

SLA template as a property digraph can be reached at: http://thinkcloud.unige.ch/SLAgraph/ (using the NetworkX [5] programming library

Q&A: [email protected]

http://thinkcloud.unige.ch/SLAgraph/


16

References

1. H. Ludwig et al., “Web Service Level Agreement (WSLA) Language Specification,” IBM Corporation, 2003.

2. A. Keller, U. Blumenthal, and G. Kar, “Classification and Computation of Dependencies for Distributed Management,” in Proc. of the Fifth IEEE Symposium on Computers and Communications (ISCC 2000), ser. ISCC ’00. IEEE Computer Society, 2000.

3. AllegroGraph 4.12.2, http://www.franz.com/agraph/allegrograph/

4. Amazon Web Services, http://aws.amazon.com/5. NetworkX: High-productivity software for complex

networks, http://networkx.github.io/

http://www.franz.com/agraph/allegrograph/

http://aws.amazon.com/

http://networkx.github.io/

SLA information management through dependency digraphs: the case of cloud data services

Business