Model based transaction-aware cloud resources management case study and methodology
-
Upload
leonid-grinshpan-phd -
Category
Technology
-
view
529 -
download
1
description
Transcript of Model based transaction-aware cloud resources management case study and methodology
![Page 1: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/1.jpg)
<Insert Picture Here>
Model-based transaction-aware cloud resources management: case study and methodology
Leonid Grinshpan, Ph.D.Consulting Technical Director
![Page 2: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/2.jpg)
2
Disclaimer
The views expressed in this presentation are the author’s own and do not reflect the views of the
companies he has worked for neither
Oracle Corporation.
All brands and trademarks mentioned are the property of their owners.
![Page 3: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/3.jpg)
3
Presentation’s goal
The presentation includes:
- A case study when a number of database servers was brought down from 40 to 21 while deploying an enterprise application for one of Oracle customers
- An outline of a model-based transaction-aware cloud management methodology that made possible such minimization of hardware
![Page 4: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/4.jpg)
4
Presentation’s structure
Section 1
Subject
Section 2
Transaction-aware servers allocation
Section 3
How to implement model-based transaction-aware management?
![Page 5: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/5.jpg)
5
Section 1
Subject
![Page 6: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/6.jpg)
6
Deployment of enterprise application on a network of functional clusters
![Page 7: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/7.jpg)
7
Load balancing algorithms
1. Round robin
2. Algorithms based on assessment of hardware metrics (CPU utilization, etc)
A load balancing approach discussed in the presentation is based on
business transaction metrics
![Page 8: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/8.jpg)
8
Definitions 1
• Transaction - a request from an EA user to be processed by system.• Transaction (response) time - time to process transaction by
application.• Transaction rate - a number of transaction requests submitted by one
user during one hour.• Transaction service demand - time interval a transaction was
processed by particular component of infrastructure (network, hardware appliance, hardware server).
• Transaction profile - a set of Transaction service demand s for system resources needed to process transaction
![Page 9: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/9.jpg)
9
Definitions 2
• Workload - a flow of transactions generated by EA users. • Workload characterization - specification of workload that includes three components:
List of business transactions. Transaction rate. Per each transaction a number of users requesting it.
• Transaction stretch factor - a parameter defined by a formula:
Scalable system has the stretch factors equal to 1
for all transactions
![Page 10: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/10.jpg)
10
Sizing project requirements. System architecture
![Page 11: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/11.jpg)
11
Sizing project requirements. Number of users and SLA
• Provide an estimate of the number of hardware servers on each layer and a number of CPUs on each server for architecture presented on previous slide for anticipated workload from 400 business users.
• Service level: transaction time degradations while increasing a number of users up to 400 are acceptable if they do not exceed 7%.
![Page 12: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/12.jpg)
12
Sizing project requirements. Workload characterization
Transaction nameAverage transaction time for single user (seconds)
Transaction rate Number of users executing each transaction
OLAP maintenance small 10 1 14
OLAP maintenance medium 10 1 2
OLAP maintenance large 10 4 1
OLAP restructure small 60 1 2
OLAP restructure medium 600 1 1
OLAP restructure large 3600 2 1
OLAP update small 10 1 12
OLAP update medium 10 1 11
OLAP update large 10 3 6
OLAP calculation small 500 2 187
OLAP calculation medium 2250 3 34
OLAP calculation large 10000 5 6
Maintenance report small 15 1 60
Maintenance report medium 25 8 9
Maintenance report large 200 9 1
Update report small 10 1 8
Update report medium 10 3 6
Update report large 10 3 1
Sales report small 15 3 30
Sales report medium 25 4 7
Sales report large 200 12 1
![Page 13: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/13.jpg)
13
Sizing project requirements. Transaction profile (time in seconds)
Transaction nameAverage
transaction time for single user Time on Web/App
server Time on OLAP
serverTime on RDBMS
server
OLAP maintenance small 10 1 7 2
OLAP maintenance medium 10 1 7 2
OLAP maintenance large 10 1 7 2
OLAP restructure small 60 1 56 3
OLAP restructure medium 600 1 595 4
OLAP restructure large 3600 1 3594 5
OLAP update small 10 1 7 2
OLAP update medium 10 1 7 2
OLAP update large 10 1 7 2
OLAP calculation small 500 1 496 3
OLAP calculation medium 2250 1 2245 4
OLAP calculation large 10000 1 9995 5
Maintenance report small 15 3 11 1
Maintenance report medium 25 6 17 2
Maintenance report large 200 49 147 4
Update report small 10 1 8 1
Update report medium 10 1 8 1
Update report large 10 1 8 1
Sales report small 15 3 11 1
Sales report medium 25 6 17 2
Sales report large 200 49 147 4
![Page 14: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/14.jpg)
14
What-if scenarios
• A few what-if scenarios with different numbers of servers on each layer were modeled
• All analyzed deployments indicated a sufficiency of one Web/Application and one RDBM servers
• There were analyzed configurations with different numbers of OLAP server.
![Page 15: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/15.jpg)
15
Architecture with 40 OLAP server and original workload
This architecture keeps transaction time deterioration for 400 users under 7% …
… but it featured low utilization of each OLAP server (only 36%)
It was obvious to check server utilizations for deployments with fewer OLAP servers. We did just that for 34 servers and the result contradicted SLA- an increase of some transaction times was reaching unacceptable 18%
![Page 16: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/16.jpg)
16
Transaction time degradation under original workload
Transaction
1 user 400 users
Stretch factor
40 OLAP servers, CPU utilization of each one
36%
34 OLAP servers, CPU utilization of each one
42%
OLAP maintenance small 10.0 10.68 1.07 1.18
OLAP maintenance medium 10.0 10.68 1.07 1.18
OLAP maintenance large 10.0 10.68 1.07 1.18
OLAP restructure small 60.0 60.68 1.01 1.03
OLAP restructure medium 600.0 600.68 1.00 1.00
OLAP restructure large 3600.0 3600.66 1.00 1.00
OLAP update small 10.0 10.68 1.07 1.18
OLAP update medium 10.0 10.68 1.07 1.18
OLAP update large 10.0 10.68 1.07 1.18
OLAP calculation small 500.0 500.66 1.00 1.00
OLAP calculation medium 2250.0 2250.66 1.00 1.00
OLAP calculation large 10001.2 10001.66 1.00 1.00
Maintenance report small 15.0 15.68 1.05 1.12
Maintenance report medium 25.0 25.68 1.03 1.07
Maintenance report large 200.0 200.67 1.00 1.01
Update report small 10.0 10.68 1.07 1.18
Update report medium 10.0 10.68 1.07 1.18
Update report large 10.0 10.68 1.07 1.18
Sales report small 15.0 15.68 1.05 1.12
Sales report medium 25.0 25.68 1.03 1.07
Sales report large 200.0 200.67 1.00 1.01
![Page 17: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/17.jpg)
17
What causes degradation of transaction time ?
• The cause of degradation of short transactions is waiting in server’s queues until long transactions (like OLAP calculation) release a CPU.
• This observation leads to a hypothesis that segmentation of transactions based on hourly service demand by different groups and processing of each group in dedicated OLAP servers might minimize total number of OLAP servers.
Transaction hourly service demand = = time a single transaction spends in a server * number of transactions per hour per user * number of transaction's users
![Page 18: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/18.jpg)
18
Low and high demand workloads
Transaction nameTransactio
n rateNumber of users executing each
transaction
Time on OLAP Server
Hourly service demand for OLAP server from
each low demand transaction
Hourly service demand for OLAP server from
each high demand transaction
OLAP maintenance small 1 14 7 98
OLAP maintenance med. 1 2 7 14
OLAP maintenance large 4 1 7 28
OLAP restructure small 1 2 56 112
OLAP restructure medium 1 1 595 595
OLAP restructure large 2 1 3594 7188
OLAP update small 1 12 7 84
OLAP update medium 1 11 7 77
OLAP update large 3 6 7 126
OLAP calculation small 2 187 496 185504
OLAP calculation medium 3 34 2245 228990
OLAP calculation large 5 6 9995 299850
Maintenance report small 1 60 11 660
Maintenance report med. 8 9 17 1224
Maintenance report large 9 1 147 1323
Update report small 1 8 8 64
Update report medium 3 6 8 144
Update report large 3 1 8 24
Sales report small 3 30 11 990
Sales report medium 4 7 17 476
Sales report large 12 1 147 1764
![Page 19: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/19.jpg)
19
Architecture with segmented workload
This configuration delivered the same transaction times and stretch factors as a system with 40 OLAP servers handling non-segmented original
workload.
1 OLAP server processing low demand workload
20 OLAP servers processing high demand workload
![Page 20: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/20.jpg)
20
Take away from case study
•The presentation describes a method of servers allocation based on business transaction metrics. The method minimizes a number of servers assigned to application without compromising transaction times
•The approach assumes classification of transactions by groups depending on their hourly service demand and processing of each group in dedicated servers
•Transaction- aware cloud management might deliver significant improvement of cloud profitability without any additional investments in hardware platform
•Further research of cloud management based on business transactions metrics is worthy of consideration as it might bring significant economical benefits to the cloud providers and to the customers
![Page 21: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/21.jpg)
21
Section 3
How to implement model-based transaction-aware management?
![Page 22: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/22.jpg)
22
What is needed?
• Application model
• Workload specification
• Transaction profiles
• Model solver
![Page 23: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/23.jpg)
23
Mapping application into queuing model
Hardware server representation
Total time in node = time in waiting queue + time in processing unit
![Page 24: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/24.jpg)
24
Mapping application into queuing model (cont 2)
![Page 25: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/25.jpg)
25
Mapping application into queuing model (cont 3)
The relationships between the components of a real system and the components of its model
Component of application Matching object in queuing model
Users Node “Users”
Web server Node “Web server”
Application and Database server
Node “A&D server”
Requests from users Cars
![Page 26: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/26.jpg)
26
Transaction response time and transaction profile
Transaction time is a time spent in “cloud”
![Page 27: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/27.jpg)
27
Transaction response time and transaction profile (cont 2)
Active resources Passive resources
•CPU time (data processing)•I/O time (data transfer)
•Web server connections•Database connections•Software threads •Storage space•Memory space
![Page 28: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/28.jpg)
28
Model’s input data
List of business transactions Number of users per each business transaction Per each transaction a number of transactions per user per hour
(transaction rate).
Transaction name Number of users Transaction rate
Report ABC 20 12
Business Rule X 10 8
Consolidation Y 5 3
1. Workload characterization
![Page 29: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/29.jpg)
29
Model’s input data (cont 2)
2. Transactions profiles
Transaction profile in this example s comprised of the time intervals a transaction has spent in system servers it has visited when application was serving only that single transaction
Transaction name Service demand (seconds)
Web server A&D server
Report ABC 0.5 0.5
Business Rule X 0.5 2.5
Consolidation Y 0.5 9.5
![Page 30: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/30.jpg)
30
Workload segmentation
Transaction hourly service demand = = time a single transaction spends in a server *
number of transactions per hour per user * number of transaction's users
Transaction-aware management is based on classification of transactions by groups depending on their hourly service demand
and processing of each group in dedicated servers
![Page 31: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/31.jpg)
31
How to obtain workload characterization and transaction profiles?
•Analysis of business process – creating process flowcharts based on interviews of key process participants
http://www.wikihow.com/Analyze-a-Business-Process
•Business transaction management software - tracking transaction across application http://en.wikipedia.org/wiki/Business_transaction_management
•Application instrumentation on software development stage – making application manageable
http://en.wikipedia.org/wiki/Instrumentation_(computer_programming)
•Big data analysis – forensic analysis of transactional data collected over time
http://en.wikipedia.org/wiki/Big_data
![Page 32: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/32.jpg)
32
Application instrumentation is the most potent technology
• Transactions are defined at application development stage
• It is possible to assign unique ID to each transaction
• Unique transaction ID enables tracking transaction path among servers
•Unique transaction ID enables measurement of each server passive and active resources allocated to transaction
•Unique transaction ID enables logging in file information on all executed transactions with their parameters
![Page 33: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/33.jpg)
33
Parameters of a transaction saved in log file
• Unique transaction ID
• ID of a user who initiated transaction
• Transaction start and stop date and times
• Transaction total execution time
• Per each server :
time transaction entered server
time transaction exited server
time transaction spent in server
![Page 34: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/34.jpg)
34
Transaction profile data generated by instrumented application
Qty of passive resource 1Qty of passive resource 2
…Qty of passive resource M
(transaction ID)(server 1) (server 2) … (server N)
CPU timeI/O time
![Page 35: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/35.jpg)
35
Application instrumentation technologies
• Application Response Measurement – ARM https://collaboration.opengroup.org/tech/management/arm
• Apache Commons Monitoring http://commons.apache.org/sandbox/monitoring/instrumentation.html
• Tracing and Instrumenting Applications in Visual Basic and Visual C#
http://msdn.microsoft.com/en-us/library/aa984115(v=vs.71).aspx
• Systemtap for Linux http://sourceware.org/systemtap/tutorial.pdf
• Java Management Extension (JMX)
http://docs.oracle.com/javase/tutorial/jmx/index.html
![Page 36: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/36.jpg)
36
Application instrumentation is must-have component of efficient cloud management
transaction profiles transaction log files
Instrumented application provides transaction profiles and transactional log files
Big data analysis - extracting workload characterization from transactional log files
Application queuing models generate estimates of system performance for different what-if scenarios
Cloud management implements the best scenario
![Page 37: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/37.jpg)
37
Research areas
• Enterprise application instrumentation as a provider of transactional data
• Big data analysis delivering transactional workload characterizations and workload variability patterns for proactive cloud management
• Queuing models of enterprise applications enabling analysis of different what-if scenarios
![Page 38: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/38.jpg)
38
To learn more about queuing models of enterprise applications check
author’s book
“Solving Enterprise Applications Performance Puzzles: Queuing Models to the Rescue”
(available in bookstores and from Web booksellers)
http://www.amazon.com/Solving-Enterprise-Applications-Performance-Puzzles/dp/
1118061578/ref=sr_1_1?ie=UTF8&qid=1326134402&sr=8-1
https://www.amazon.com/author/leonid.grinshpan
Contact Leonid Grinshpan at:
![Page 39: Model based transaction-aware cloud resources management case study and methodology](https://reader036.fdocuments.in/reader036/viewer/2022062418/5564188cd8b42a0d0c8b5a03/html5/thumbnails/39.jpg)
39