Chapter 4: Architecture for Performance Monitoring of Complex Information Technology (IT) Infrastructures using Petri Net

Transcription

1 Chapter 4: Architecture for Performance Monitoring of Complex Information Technology (IT) Infrastructures using Petri Net This chapter will focus on the various approaches that we have taken in the modeling and simulation of performance monitoring of complex systems using Petri Net and its extensions. This chapter will also emphasize the importance of alerting and alert management in complex systems where monitoring is being done. This chapter will be organized in a logical sequence of our work during the course of research and will put forward the underlying work achieved behind each approach taken in this work. The aim of this work is to develop a set of approaches that can be used separately of combined as an architecture/framework and modeling approach for performance monitoring of IT infrastructure components. This is done by mathematically defining the monitoring in terms of the problem that we are going to address in this work. Then mapping of the monitoring model is done on to Timed Petri Nets and further analysis has been carried out to validate the model. Petri Net Based Simulation of Performance Monitoring of IT Infrastructure Components The work outlines the utilization of Petri Nets as a modeling tool for the study of performance monitoring of IT infrastructures. Development of new monitoring models and improving existing monitoring models are some of the challenges faced by IT managers continuously. In order to make informed decisions, modeling and analysis of the performance of the underlying IT

2 infrastructure components has become an essential part. Performance monitoring modeling and analysis is performed by developing a graphical portrayal of the monitoring model and then by dynamically studying the behavior during different scenarios. In this article an overview of Petri Net based modeling and analysis of IT infrastructure monitoring is provided. Petri Net is a formal graphical modeling tool that can be efficiently utilized as a process modeling and analysis tool because it can graphically portray and dynamically simulate a process in an integrated manner[41][42][57][58]. The objective here is to highlight the symbolic graphic format and dynamic simulation capabilities of Petri Nets. The article contributes to the area of computer based decision making and provides value to practicing engineers and project managers who manage complex IT infrastructures. I. Introduction and Background of IT infrastructure Today even a small organization comprises of a variety of servers, routers, firewalls, switches, software components etc. With the dependency of modern day organizations on IT backbones for their day to day activities, the expectations on the availability, peak performance and quick response times of such IT infrastructure have increased exponentially and may be a vital ingredient of the business edge over competitors. With such great emphasis on its importance, IT infrastructure performance monitoring and management plays a vital role in organizational efficiency and hence success [47]. With the ever increasing dependency of critical organizational activities (example: planning, procurement, control, execution, follow up, inventory control, human resource management, finance & accounting, etc) on IT infrastructure components (example: computers, software, networks, printers, telephony, etc) the need for maintaining high availability and ensuring peak performance 24x7 has become ultra critical in most 2

3 organizations. When these complex IT infrastructure components break down or perform poorly, there is a virtual break down of all critical activities. The key challenge faced by the IT managers is predicting, analyzing and isolating. Hence managers of such complex IT infrastructures have to use a variety of performance monitoring (both real time and historical analysis) and modeling techniques to isolate the performance issues and failures [47]. Conventional modeling/simulation tools (Network Diagrams like PERT, CPM, PDM etc) provide limited scope for modeling such dynamic and complex IT infrastructures with application component level interdependencies [29]. In such infrastructures, a slow down/failure of one application component/tier can ripple and affect the performance of all dependent components. For example, the response time of a web server front ending a web application will be adversely affected if the database server acting as a back-end for this application is not tuned properly. Hence, modeling the interdependencies amongst the components and causeeffect relationship between them, conditional branching, hierarchical representation is an essential part of successful modeling. This is a novel effort to summarize the steps required to simulate an example of a performance issue in a simple IT infrastructure and demonstrate how Petri Net can be used to effectively model such changing environments. II. Petri Net based simulation of performance monitoring model The example below uses the attribute CPU usage on a system and alerts the user when it crosses a pre-determined threshold levels. 3

4 a. Algorithm for a simple performance monitoring model, monitoring CPU usage levels in a computer. 1. Read the acceptable threshold limit for CPU usage. 2. Read the current value of the current CPU usage on the system. 3. Check if the CPU usage value is more than the set threshold limits. 4. If CPU usage is more than set threshold then raise alert else go to next step directly. Alerts can be via , SNMP traps, sms, event logs, User interface, etc or custom/external alert interfaces. 5. Sleep until next monitoring period. 6. Go back to step 1. b. Flowchart for a simple performance monitoring model, monitoring CPU usage levels in a computer. Fig. 4 Flowchart of a simple performance monitoring of CPU usage in a computer 4

5 c. Petri Net model of simple performance monitoring, monitoring CPU usage levels in a computer. Fig. 5 Petri Net model of a simple performance monitoring of CPU usage in a computer Though the above Petri Net model demonstrates how Petri Nets can be successfully used as a modeling tool for representing and analyzing the performance of key attributes of an IT infrastructure, it represents a simple case that has been taken for ease of understanding for the reader and demonstration purposes. However, to represent a realistic IT infrastructure, this model can be further extended to model multiple components/systems/applications, each having multiple key performance attributes monitored and the overall health of the component. This can be achieved using Petri Net extensions like hierarchical Petri Nets, colored Petri Nets and stochastic Petri Nets. Taking a slightly more complex case of a web portal where a web server, application server and a database server works together. It offers an integrated framework for the web portal service. A model using hierarchical Petri Nets 5

6 is built as below. Fig. 6 represents a high level (A LEVEL 1 representation) Petri Net based performance monitoring model of the web portal depicting the web server (C1), application server (C2), and database server (C3) working together to offer the end user service. When a firing of this model happens, all the components (C1, C2, C3) in the web service are monitored for key performance attributes and then the model sleeps until the next monitoring period and continues the execution cyclically. Using hierarchical Petri Nets, each of the components C1, C2, C3 are represented in more details in the subsequent levels. For example, the web server component C1 is detailed further for the attributes to be monitored in the Level 2 model depicted in Fig. 7. It shows that to assess the health of the web server, the three attributes namely CPU (C11), memory (C12) and response time (C13) have to be monitored. How each of these attributes is monitored using Petri Nets is further detailed in the figures 8(a), 8(b), 8(c), a Level 3 hierarchical representation of the model. This detail level representation also includes an alert mechanism to alert when there is a violation of the threshold levels for each of these attributes. Similarly, detailed models can also be built using hierarchical Petri Nets to model the application server and the database server. 6

7 Fig. 6 Hierarchical Petri Net model of a Web Portal Health Status Fig. 7 Petri Net model of a Web Server Health Status 7

8 Fig. 8(a) Petri Net model of CPU performance monitoring Fig. 8(b) Petri Net model of Memory usage performance monitoring 8

9 Fig. 8(c) Petri Net model of Response Time monitoring Hierarchical Petri Nets acts as an invaluable tool for modeling of real world problems modeling them with some level of abstraction at the higher level and getting into the detailed view at the lower level, making it easier to understand and relate to. The drill down type of modeling also enables people of the related areas to focus on their areas and related to their models. In a real world scenario, as in the above example, the service manager can focus on the level 1 model for performance issues and can work with the web server expert for issues in the web server and with the DBA for the issues in the database server layer. The Web server expert can focus on his specific levels and layers in the model whereas the DBA can focus on his areas in this model. This enhances the usability and comprehension of the model simple and modeling to focus on real world responsibilities and scenarios. This can be termed as Role Based Modeling of Performance Monitoring. There are 9

10 no limits on the number of levels that could be used in the hierarchies, however, more than 5 levels may become very complex to understand and comprehend. The above models demonstrates that, in order to make informed decisions, modeling and analysis of the performance of the underlying IT infrastructure is possible by developing a graphical portrayal of the monitoring model and then by dynamically studying the behavior during different scenarios by changing the inputs to the model. Generalised Stochastic Petri Net (GSPN) Based Simulation and Modeling of IT infrastructures This work outlines the utilization of Generalised Stochastic Petri Nets as a modeling tool in general using a case of performance monitoring of IT infrastructures. The objective of the following work is to highlight the symbolic graphic format and dynamic simulation capabilities of Generalised Stochastic Petri Nets. This work contributes to the area of computer based decision making and provides value to practicing engineers and project managers who manage complex IT infrastructures. Enterprise wide IT infrastructures form the backbone of any successful organization these days. Predicting the performance of an IT infrastructure is almost always a challenging task. Such IT infrastructures usually comprises of multiple activities or processes that proceed concurrently. Because of the complexity and randomness, developing mathematical models of the system under study is usually non-trivial. Assessment of system performance is equally difficult. Models that are accurate enough to adequately represent system behavior often get too complex to be analyzed. Hence, they need usage of better modeling capabilities like abstraction, hierarchies, and role 1

11 based modeling. They also require automated modeling and simulation tools for detailed analysis and studying. This work is an effort to summarize the steps required to simulate an example of a performance issue in a simple IT infrastructure and demonstrate how Generalised Stochastic Petri Net can be used to effectively model such dynamic environments. SPN and GSPN are popular and useful tools for modeling and performance analysis of complex stochastic systems. The SPN and GSPN frameworks along with hierarchical Petri Nets provides a powerful set of building blocks for specifying the state-transition mechanism and event scheduling mechanism of a discrete event stochastic system[35][3][4]. GSPN s are well suited to represent Concurrent activities (more than one transition can be enabled in a marking), Synchronized activities (firing of a transition can cause one or more transitions to become enabled (or disabled) simultaneously), Activities with precedence relationships (transition cannot become enabled until at least one token has been deposited in each of its normal input places and all the tokens removed from each of its inhibitor input places. This deposit and removal of tokens typically occurs when one or more preceding transitions fire), Priorities among activities ( Because, normal input place for a high-priority transition can also be an inhibitor input place for a low-priority transition[4]. At a marking change, a token representing a limited system resource can be routed to the normal input place for a high-priority transition, The clock for a low-priority transition can be made to run down to zero speed whenever the marking is such that a high-priority transition is enabled), Inhibitory Arcs (Arcs from places to transitions that prevent firing of a transition if the input place is marked). 11

12 A web portal where a web server, application server and a database server works together to offer an integrated framework for the web portal service is taken and modeled with GSPN. Fig. (6) represents a high level (A LEVEL 1 representation) Petri Net based performance monitoring model of the web portal depicting the web server (C1), application server (C2), and database server (C3) working together to offer the end user service. When a firing of this model happens, all the components (C1, C2, C3) in the web service are monitored for key performance attributes and then the model sleeps until the next monitoring period and continues the execution cyclically. Using hierarchical Petri Nets, each of the components C1, C2, C3 are represented in more details in the subsequent levels. For example, the web server component C1 is detailed further for the attributes to be monitored in the Level 2 model depicted in Fig (9). It shows that to assess the health of the web server, the three attributes namely CPU (C11), memory (C12) and response time (C13) have to be monitored. The level 2 representation also includes an alert mechanism to alert when there is a violation of one the threshold levels. The highest importance is given to the CPU monitoring via an immediate transition and delays have been built into the transitions leading to monitoring of memory and response times. An inhibitor arc from alert raised is used to stop the continuation of the firing of the monitoring of memory and response times, if the CPU usage is above the threshold limits, thereby avoiding repeated alerts. Same way if one of memory or response times is beyond threshold limits inhibitor arcs prohibits further firings. How each of these attributes is monitored using Petri Nets is further detailed in the figures Fig. 9(a), Fig 9(b), Fig 9(c), a Level 3 hierarchical representation of the model. Similarly, detailed models can also be built using hierarchical Petri Nets to model the application server and the database server. 12

13 Fig. 9 Petri Net model of Web Server Health Monitoring with Inhibitor Arc Fig. 9(a) Petri Net model of CPU performance monitoring 13

14 Fig. 9(b) Petri Net model of Memory usage performance monitoring Fig. 9(c) Petri Net model of Response time monitoring 14

15 The above GSPN model demonstrates how monitoring of dependent attributes can be prohibited if one of the base attributes is not within the acceptable boundaries/levels or could not be monitored. This model also demonstrates how role based monitoring in IT infrastructures can be used effectively to optimize resource utilization. This architecture helps avoiding performance monitoring overheads and improves resource utilization in real time complex systems. Modelling Performance Monitoring of IT infrastructure components using Timed Petri Nets by mapping A variety of performance monitoring (predictive, real-time and historical) and modeling techniques are used to analyze and isolate performance issues and failures. Mapping of performance monitoring scenarios in IT infrastructures to Timed Petri Nets and its structural analysis is illustrated in this work. Performance Monitoring is one of the key activities in complex IT environments. Monitoring is checking something over a period of time in order to see how it works. Monitoring IT infrastructure components helps to make the necessary changes to improve/regulate. Monitoring IT infrastructure components is useful in predicting, analyzing and isolating etc of performance issues. These tasks are taken care of by some resources. Some of the resources are managers, agents, alert interfaces etc. There may be some orders in which these tasks are carried out. The tasks may be taken care on priority basis, which satisfies constraints. All the tasks consume time. Tasks are carried out by capable resource sets. 15

16 Timed Petri Net model of performance monitoring of IT infrastructure Performance monitoring has become ultra critical for organizations to have peak performance IT infrastructures. Vendors of hardware and software has understood this and have adopted and exposed a variety of interfaces like Simple Network Management Protocol(SNMP), Windows Management Interface(WMI), Performance Monitor (Perfmon), Java Management Extensions (JMX), Queries, Command interfaces, Custom Application Programming Interfaces (APIs) etc. Choice of the interface will depend on availability, resource overhead, depth of details needed etc. A majority of the monitoring solutions follow the manager-agent architecture. As per this architecture, software agents deployed on the various hosts of a network environment make periodic measurements that are reported to a central manager. To collect measurements the agents use various tests. The aim of this work is to develop a theoretical architecture/framework and modeling approach for performance monitoring of IT infrastructure components. First we introduce IT infrastructure components and the importance of monitoring. Monitoring will then be defined in terms of the problem that we are going to address, then we introduce Petri Nets and Timed Petri Nets, next mapping of monitoring onto timed Petri Nets is done. Finally Petri Net representation of monitoring is done by taking a small illustration. Structural analysis is done using the Petri Net analysis techniques. Mathematical Formalization and Definition of Monitoring Performance Monitoring is one of the key activities in IT environments. Monitoring is checking something over a period of time in order to see how it works. Monitoring IT infrastructure components helps to make the necessary changes to improve/regulate performance. It also helps in predicting, 16

17 analyzing and isolating etc. These tasks are taken cared by some resources. Some of the resources are managers, agents, alert interfaces etc. There may be some orders in which there tasks are carried out. The tasks may be taken care on priority basis, which satisfies constraints. All the tasks consume time. Tasks are carried out by capable resource sets. This leads to the following definition: A monitoring is a 5 tuple Mg = (T,R,PRE,TS,MT) satisfying the following requirements. 1. T is a finite set of tasks. 2. R is a finite set of resources. 3. PRE T X T is a partial order, the precedence relation. 4. TS is the time set. 5. MT (T x (R) ) / TS defines for each task t : a. The resource sets capable of monitoring task t and b. The monitoring time required to monitor t by a specific resource set. The definition specifies the data required to formulate performance monitoring of IT infrastructure. The tasks are denoted by T and the resources are denoted by R. The precedence relation PRE is used to specify precedence constraints. If task t has to be monitored before task t' then (t, t') PRE. The execution of task t has to be completed before the execution of t' may start. TS is the time set. N and R+ U {} are typical choices of TS. 17

18 Monitoring a task (MT) needs two things. 1. The resource sets capable of monitoring task t: {rs (R)/<t, rs> dom(mt)} 2. The monitoring time required to process t by a specific resource sets: MT{<t, rs>} Timed Petri Net For real systems we need to model durations and delays. So a timing concept is introduced. There are many ways to introduce time into classical Petri Net [14][64].In this paper a timing mechanism is used where time is associated with transitions. Each transition has a time delay associated with it. Because of the firing delay it takes some time before the produced tokens become available for consumption. A Timed Petri Net is a six tuple TPN = (P,T,I,O,TS,D) satisfying the following requirements, I. P is the finite set of places. II. T is a finite set of transitions. III. I T (P) is a function which defines the set of input places of each transition. IV. O T (P)is a function which defines the set of output places of each transition. V. TS is the time set. VI. D T TS is a function which defines the firing delay of each transition. 18

19 The state of a timed Petri Net is given by the distribution of tokens over the places and corresponding time stamps. Firing a transition results in a new state. A sequence of states s,s 1,s 2...s n can be generated such that s is the initial state and s i+1 is the state reachable from s i by firing a transition. Many firing sequence are possible. Let s be the initial state of a timed Petri Net. A state is called reachable state if and only if there exists a firing sequence s,s 1,s 2,s 3...s n which visits this state. A terminal state is a state where none of the transitions is enabled (a state without successors). Mapping monitoring onto Petri Nets To show that Petri Nets can be used to model and analyze monitoring problems. We provide a translation from a monitoring problem to a suitable timed Petri Net. This means that we have to map concepts such as tasks, resources and precedence onto places and transitions [61]. Given a task t we identify three stages. 1) t is waiting to be monitored 2) t is being monitored 3) t has been monitored 19

20 The Fig(1) shows how we model a tasks in terms of a timed Petri Nets. Transition st t and ct t represents the beginning and termination of t respectively. The places sm t, bm t and cm t correspond to the stages mentioned. Fig. (1) Task t Initially there is one token in sm t. The firing delay is a delay time of task t to go to the next stage. Fig. (11) Resource r: Each resource r is modeled by a place re r. Initially re r contains one token. Fig(11) shows a resource r which can be used to monitor a task t. Transition st t claims the resource when the execution of t starts, transition ct t releases the resources when t terminates. 2

21 Precedence constraints are modeled by adding extra places. Fig (12) shows the situation where task t precedes task t' (i.e.) The execution of task t has to be completed before the execution of task t'. Place pre <t,t'> prevented st t' from firing until ct t fires. Note the places are used to model the stages of a task, resources and precedence. Fig. (12) Precedence constraint <t,t'> A task with three possible resource sets. Thus far we ignored the fact that a task may be processed by one of multiple resource sets. Fig (13) shows how to model this situation. For each resource set rs capable of processing task t, we introduce a place bm <t,rs> and two transitions st <t,rs> and ct <t,rs>. Fig(13) shows that task t can be processed by one of the following resource sets {r 1 } {r 2 } and {r 1,r 2 }.note that there is only one start place sm t and one completion place cm t. 21

22 Fig. (13): A task with three possible resource sets. Mapping: Given monitoring problem Mg = (T,R,PRE,TS,MT) We define the corresponding timed Petri Net TPN=(P,T,Ī,Ō,TS,D ) as follows. 22

23 P = {bm <t,rs> /<t,rs> dom(mt)} {sm t /t T} {cm t /t T} {re r /r R} {pre <t,t'> /<t,t'> PRE} T = {st <t,rs> /<t,rs> dom(mt)} {ct <t,rs> /<t,rs> dom(mt)} and for any task t T and resource set rs (R) such that <t,rs> dom(mt). Ī (st <t,rs> ) = {sm t } {re r /r R and r rs} Ī (ct <t,rs> ) = {bm <t,rs> } Ō (st <t,rs> ) = {bm <t,rs> } {Pre <t,t'> /t' T <t,t'> PRE} Ō (ct <t,rs> ) ={ cm t } {re r /r R r rs} TS = TS D (st <t,rs> ) = MT(<t,rs>) D (ct <t,rs> ) = {pre <t,t'> /t' T <t,t'> PRE} This definition shows how to model a monitoring problem in terms of a TPN. For each task t, place sm t contains one token. For each resource r, place re r contains one token. Resources can be modeled using a specific capacity and tasks require only a part of this capacity. Place re r contains more tokens. If we allow pre-emption we have to split tasks into smaller tasks. Each sub tasks corresponds to a phase in the monitoring of task t. This can be handled by hierarchical Petri Nets. 23

24 We assume that the monitoring times are known and fixed. (i.e.,) the monitoring problem is deterministic. This can easily be extended to nondeterministic monitoring problems by using other type of Petri Net models. In this section, we provide a Petri Net representation of monitoring based on the definition and concepts defined above. The objective of the work presented in this section is to present a proof of above concept on how Petri Nets can be used to model and analyze performance monitoring of IT infrastructure components. The example taken for the case here will monitor CPU usage on a system and alerts the user when it crosses a pre-determined threshold [7]. However, in a real world scenario, for a full fledged monitoring system, a variety of parameters at different levels may have to be monitored. The example taken may be extended to accommodate more parameters as needed in a real time system. In this work, for simplicity of depiction and ease of understanding of the concepts, we have taken a single attribute CPU monitoring. The Algorithm and flow chart for the model is defined first and the Petri Net model is presented. 24

25 4.1 Algorithm for a simple performance monitoring model, monitoring CPU usage levels in a computer. 1. Agent reads the value of the current CPU usage on the system 2. Agent Sends the value to the manager 3. Manager reads the acceptable threshold limit for CPU usage 4. Check if the CPU usage value is more than the set threshold limits. 5. If CPU usage is more than set threshold then raise alert else go to next step directly. Alerts can be via , snmp traps, sms, event logs, user interface, etc or custom/external alert interfaces. 6. Sleep until next monitoring period. 7. Go back to step 1 Fig. (14) Petri Net model of monitoring CPU usage levels in a computer. 25

26 Resources: Manager, agents, alert mechanism Tasks: Reading Usage values and Thresh hold values, comparing, raising alert, initiate next monitoring. We now define the transitions and places in the Petri Net model as follows: Places p, p 8, - represents start monitoring and complete monitoring and sleep for certain period. p 1, p 3, p 5 - represents ready with the values. p 6 - alert interface triggering fact p 2 - agents p 4 - manager p 7 - alert mechanism p 2, p 4, p 7 - denotes the availability of resources Transitions t - reads CPU value t 1 - send the CPU value to manager. t 2 - manager reads threshold and calculating t 3 and t 4 - compares the values and conditions t 5 - raise alert t 6 - initiate the next monitoring 26

27 We assumed that the time delay between each transition firing is 5 ms and the sleep time between each subsequent measure is 1 minute. Firing of t 3 and t 4 gives 2 different cases. The first case use t 3 to continue and raise alarm. The second case use t 4 to show the completion of monitoring and shows the system is in the safe zone. For the above constructed Petri Net model, the reachability tree and the reachability graph are as follows. They are used for the analysis of liveness, and boundedness. Fig. (15) Reachability Tree 27

28 Fig. (16) Reachability Graph Analysis of the model At this point we are concerned with the net being bounded and live. An assessment of these properties based on the initial marking of the net can be performed by analyzing the reachability tree of the net using M as the root node as shown in Fig(15). A reachability tree is a graph representation of the markings of a net. Each node in the tree represents a marking and the edges represent a transition firing. The resulting tree is small enough to be analyzed by inspection and it can be concluded that a) The reachability set R(M ) is finite b) The number of tokens of every place in all marking is bounded ( 1- bounded) c) There are no dead transitions (all transitions can fire) 28

29 As a result it can be concluded that the net is bounded. By looking at the reachability graph of the net with initial marking M presented in Fig(16) it can be seen that there is always an active transition regardless of the state of the net and all the transitions of T are included in the graph. From this it can be concluded that the Petri Net model of performance monitoring of CPU usage levels in a computer system is bounded and live. For models with a large number of places and transitions, the reachability graph construction is not practical without the use of computer tools to automate the reachability graph generation and the assessment of properties. Structural analysis of the constructed model: Place and transition invariants are powerful tools for studying structural properties of Petri Nets. The structural behavior of the net can be assessed using the algebraic analysis of the incidence matrix (invariant analysis). The incidence matrix is defined as A= [a ij ] where a ij = aij _ aij a = w(i,j) is the weight of the arc from t i to p j and ij a = w(j,i) is the weight of the arc from p j to t i. ij The incidence matrix of the net Fig. (14) is given below; A = Fig. (17) Incidence matrix 29

30 The order of the places and transitions in the matrix are P = {p, p 1, p 2, p 3, p 4, p 5, p 6, p 7, p 8 } (columns) T = {t, t 1, t 2, t 3, t 4, t 5, t 6 } (rows) A P- invariant is a vector that satisfies the equation Ax = A T-invariant is a vector that satisfies the equation A T y= The following invariants are obtained from the incidence matrix A. P-invariants T-invariants x 1 = [1,1,,1,,1,1,,1] T y 1 = [1,1,1,,1,,1] T x 2 = [,1,1,,,,,,] T y 2 = [1,1,1,1,,1,1] T x 3 = [,,,1,1,1,1,,1] T x 4 = [,,,,,,1,1,] T A net is said to be covered by P- invariants if and only if, for each place p in the net there exist a positive P-invariant x such that x(p)>. The net is covered by P-invariants since there is a positive element on x 1 or x 2 or x 3 or x 4 for every place, e.g., x 1 (p 2 ) = but x 2 (p 2 ) = 1.In addition a net is covered by T- invariants if and only if for each transition t in the net, there exist a positive T- invariant y such that y(t)>.the net is also covered by T-invariant. A Petri Net is structurally bounded if it is covered by P-invariants and the initial marking M is finite. Furthermore, a net is live and bounded if it is covered by T-invariants which is only a necessary condition. The Petri Net Fig(14) is covered by T-invariants and P-invariants. Since the initial marking is finite, we can conclude that the Petri Net is bounded and that the necessary condition for liveness is met. 3

31 We have showed how performance monitoring problems can be modeled in terms of Timed Petri Net formalism. We have provided a mapping from monitoring to a timed Petri Net. A simple example of monitoring CPU usage is taken an example and proposed methodology was applied to it. Structural analysis is done. Web Server Performance Monitoring using Timed Petri Nets Utilization of Petri Nets as a modeling tool for performance monitoring of web server is the focus of this work. Usage of Timed Petri Nets to model Performance monitoring of a web server, mapping its different components is illustrated in this work. Performance degradation of one layer may ripple and affect the performance of other layers. Hence the chosen modeling tool chosen should allow depiction of interdependencies, cause-effect relationships, conditional branching, hierarchical representations etc for successful modeling. This paper is a novel effort to show how Timed Petri Nets can be used to model such dynamic environments. Timed Petri Net model of monitoring a web server In early 1994, when the World Wide Web emerged, it was more of an information exchange medium. Users could use their browsers to access a variety of static content including homepages, news content, informational sites etc. The infrastructure used to support such content was very simple. Users could connect directly to web servers and download the content served by the servers. Over the years, the web has evolved to support a variety of complex ebusiness applications. Online auctions, trading, banking, retail, etc 31

32 are all supported via web sites. To support their varied applications the web infrastructure has grown in complexity. The main complexity in monitoring ebusiness infrastructures arises not just because of the numerous systems that are now involved in supporting ebusiness applications. The complexity of the software components of the web infrastructure has also increased dramatically with technologies such as CGI, Servlets, JSP, ASP, XML, XSL, JDBC, etc. coming to the fore. To ensure that an ebusiness remains available twenty four hours a day, seven days a week, it is essential to monitor key performance parameters. Towards this and to operate efficiently ebusiness operators need a monitoring system. A majority of the monitoring solutions follow the manager-agent architecture. As per this architecture, software agents deployed on the various hosts of a networked environment make periodic measurements that are reported to a central manager. To collect measurements the agents use various methods. The manager is responsible for various functions like, storage of the collected measurement, analysis of the stored data, real time correlation of different problems to report the root-cause, reporting of problems via , web or page [7]. The example taken for the case here will monitor web server health status by the concept of mapping defined earlier. The example deals with resources having specific capacity and tasks requiring only a part of its capacity. Web server health portal consists of three attributes. Monitoring CPU usage, memory status and response time of the system. All the three attributes have to be monitored to monitor the web server health. In Petri Net based performance monitoring model of web 32

33 server health status all the attributes are monitored and alerts are raised when there is a violation of the thresh hold levels for each of these attributes. Then the model sleeps until the next monitoring period and continues the execution cyclically. However, in a real world scenario, for a full fledged monitoring system, a variety of parameters at different levels may have to be monitored. The example taken may be extended to accommodate more parameters as needed in a real time system. The Algorithm and flow chart for the model is defined first and the Petri Net model is presented. Algorithm for performance monitoring of web server health status 1. Agent reads the values from the system a. Read CPU usage b. Read Memory usage c. Read Response time 2. Agent Sends the value to the manager 3. Manager reads the threshold limits a. Read CPU threshold and compare b. Read Memory Threshold and compare c. Read Response Time Threshold and compare 4. Check if the Read value is more than the set threshold limits a. If CPU usage greater than CPU threshold then raise alert else go to normal status b. If Memory usage greater than Memory threshold then raise alert else go to normal status c. If Response Time usage greater than Response Time threshold then raise alert else go to normal status 5. Sleep until next monitoring period. 6. Go back to step 1 33

34 Flowchart for performance monitoring of web server health status. Fig.(18) Flowchart for performance monitoring of web server health status

35 Petri Net model of performance monitoring of web server health status Fig. (19) Petri Net model of performance monitoring of web server health status. 35

36 Resources: Manager, agents, alert mechanism Tasks: Reading CPU Usage values, memory usage value, response time and Thresh hold values, comparing, raising alerts, initiate next monitoring. Above mentioned model includes 24 places and 22 transitions. Places represent stages and transitions represent beginning and ending of the tasks. We now define the transitions and places in the Petri Net model as follows: Places p - ready to start monitoring web server health status p 1 - ready to start monitoring CPU usage p 2 - ready to start monitoring memory status p 3 - ready to start monitoring response time p 4 - agent ready with the read CPU usage value p 5 - represents resource availability (agent) p 6 - manager ready with the CPU usage value and threshold value to compare p 7 represents resource availability (manager) p 8 - manager with the compared value

37 p 9 - ready to go to alert interface p 1 - alert mechanism ready to alert p 11 resource availability (alert mechanism) p 12 - CPU checked status p 13 - agent ready with memory usage value p 14 -manager ready with the memory usage and threshold to compare p 15 - manager with compared value p 16 - ready to trigger alert mechanism p 17 - alert mechanism ready to alert p 18 - memory usage checked p 19 - agent with current response time p 2 - manager ready with current response time threshold to compare p 21 - ready with the compared time p 22 - ready to enter alert interface p 23 - alert mechanism ready to trigger alert p 24 - response time checked Transitions t - start monitoring web server health status t 1 - read CPU usage value t 2 - send it to manager t 3 - manager comparing the value with the threshold t 4 - go to alert interface (compared value exceeds threshold value) t 5 - go to checked status compared value is normal t 6 - trigger alert mechanism to raise alert t 7 - alert raised go to checked status 37

38 t 8 - read memory status t 9 - send memory status to manager t 1 - manager compares the memory with threshold t 11 - go to alert interface t 12 - go to normal mode t 13 - trigger alert mechanism t 14 - alert raised go to checked status t 15 - agent reads response time t 16 - sending response time to manager t 17 - manager compares response time with threshold t 18 - go to alert mechanism, response time exceeds threshold t 19 - response time checked, go to checked status t 2 - trigger alert mechanism t 21 - alert raised go to checked status t 22 - start next monitoring after a sleeping time We consider the delays here in this example as deterministic and the proposed model is deterministic timed Petri Net. Firing of t 4 and t 5 give two different cases. The first one uses t 4 to continue and raise alarm when the CPU usage exceeds threshold value. The second case uses t 5 to show the completion of monitoring CPU usage when it is in the normal mode. Firing of t 11 and t 12 gives two different cases. The first one uses t 11 to continue and raise alarm when the memory status exceeds threshold value. The second case uses t 12 to show the completion of monitoring memory status when it is in the normal mode. Firing of t 18 and t 19 gives two different cases. The first one uses t 18 to continue and raise alarm when the response time exceeds threshold value. The second case uses t 19 to show the completion of monitoring the response time when it is in 38

39 the normal mode. It is assumed that these cases occur with equal probabilities. Using the constructed Petri Net model of the performance monitoring of the webserver health status, minimum cycle time of the monitoring can be evaluated as follows. Calculation of Minimum cycle time of Web Server monitoring model Definition: Minimum cycle time. Minimum cycle time is the minimum time required to complete a firing sequence returning to the initial marking after firing each transition atleast once [57]. This minimum cycle time method is used to estimate the required time to monitor the web server health status for a single iteration. The P-invariants and T-invariants are two concepts in Petri Nets used in finding the minimum cycle time [57]. The invariants are found from the following incidence matrix A for the Petri Net model in Fig (19). 39

40 A= P P 1 P 2 P 3 P 4 P 5 P 6 P 7 P 8 P 9 P 1 P 11 P 12 P 13 P 14 P 15 P 16 P 17 P 18 P 19 P 2 P 21 P 22 P 23 P 24 t t t t t t t t t t t t t t t t t t t t t t t Fig. (2) Incidence Matrix The P-invariants are p p 1 p 2 p 3 p 4 p 5 p 6 p 7 p 8 p 9 p 1 p 11 p p 13 p 14 p 15 p 16 p 17 p 18 p 19 p 2 p 21 p 22 p 23 p Fig. (21) P- Invariants 4

41 The T-invariants are t t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 t 9 t 1 t 11 t t 13 t 14 t 15 t 16 t 17 t 18 t 19 t 2 t 21 t Fig. (22) T-Invariants The non-zero entries in a T invariant represent the firing count of the corresponding transition that belong to a firing sequence transforming a marking M back to M. The firing count vector Y is given by Y = ( ) T 41

42 There are six P- invariants x T 1 = [ ] x T 2 = [ ] x T 3 = [ ] X T 4 = [ ] x T 5 = [ ] x T 7 = [ ] The minimum cycle time = Max {x k T (A - ) T DY/X k T M } (X) mx1 is a P-invariant (Y) nx1 is a T-invariant (A - ) nxm is a input matrix d i is the time delay associated with transition t i,i=,1 n D nxn is the diagonal matrix of d i (M ) mx1 is the initial marking M = ( ) T 42

43 x k T M is as follows: x 1 T M =( ) ( ) T =1 x 2 T M =( ) ( ) T =3 x 3 T M =( ) ( ) T =1 x 4 T M =( ) ( ) T =1 x 5 T M =( ) ( ) T =3 x 6 T M =( ) ( ) T =3 43

44 The input matrix (A - ) T [57] a ij - = w(j,i) = is the weight of the arc to transition i from its input place j (no of tokens removed from its input place j) t t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 t 9 t 1 t 11 t 12 t 13 t 14 t 15 t 16 t 17 t 18 t 19 t 2 t 21 t 22 P 1 P 1 1 P 2 1 P 3 1 P 4 1 P P 6 1 P P P 9 1 P 1 1 P P 12 1 P 13 1 P 14 1 P P 16 1 P 17 1 P 18 1 P 19 1 P 2 1 P P 22 1 P 23 1 P 24 1 Fig. (23) The input Matrix (A - ) T 44

45 The delay matrix of Fig. (19) is a diagonal matrix as follows: D= t d 1 d r 2 d s 3 d c 4 d n 5 d n 6 d t 7 d f 8 d r 9 d s 1 d c 11 d n 12 d n 13 d t 14 d f 15 d r 16 d s 17 d c 18 d n 19 d n 2 d t 21 d f 22 d k Fig. (24) Diagonal Matrix 45

46 We have taken deterministic delays. Time Associated Transitions Delay d t d r t 1,t 8,t 15 d s t 2,t 9,t 16 d c t 3,t 1,t 17 d n t 4,t 5,t 11 t 12,t 18,t 19 d t t 6,t 13,t 2 d f t 7,t 14,t 21 d k t 22 DY = (8d 8d r 8d s 8d c 4d n 4d n 4d t 4d f 8d r 8d s 8d c 4d n 4d n 4d t 4d f 8d r 8d s 8d c 4d n 4d n 4d t 4d f 8d k ) T (A - ) T DY = (8d 8d r 8d r 8d r 8d s 24d r 8d c 24d s 8d n 4d t 4d f 12d t 8d k 8d s 8d c 8d n 4d t 4d f 8d k 8d s 8d c 8d n 4d t 4d f 8d k ) T x 1 (A - ) T DY/(x T 1 M ) =8d +8d r +8d s +8d c +8d n +4d t +4d f +8d k T x 2 (A - ) T DY/(x T 2 M ) =8d c +8d n +4d t +8d s T x 3 (A - ) T DY/(x T 3 M )=8d +8d r +8d s +8d c +8d n +4d t +4d f +8d k T x 4 (A - ) T DY/(x T 4 M )=8d +8d r +8d s +8d c +8d n +4d t +4d f +8d k T x 5 (A - ) T DY/(x T 5 M )=4d f +4d t T x 6 (A - ) T DY/(x T 6 M )=8d r +8d s 46

47 Minimum cycle time = Max {x k T (A - ) T DY/X k T M } Max((8d +8d r +8d s +8d c +8d n +4d t +4d f +8d k ),(8dc+8dn+4dt+8ds),(8d +8d r +8d s +8d c +8d n +4d t +4d f +8d k ), (8d +8d r +8d s +8d c +8d n +4d t +4d f +8d k ),(4d f +4d t ),(8d r +8d s )) (i.e) Max((8d +8d r +8d s +8d c +8d n +4d t +4d f +8d k ),(8dc+8dn+4dt+8ds),(4d f +4d t ),(8d r +8d s )) We have showed how performance monitoring problems can be modeled in terms of a Timed Petri Net formalism. We have provided a mapping of monitoring to Timed Petri Net. An example of monitoring web server health status is taken and proposed methodology was applied to it. For the model, we have taken a few key parameters; however this can be extended to other important parameters of the web server and other dependent components as well if desired. The minimum monitoring period of web server health status once is found using minimum cycle time technique of timed Petri Nets. 47