Two Optimization Techniques for Component-Based Systems Deployment M. Cecilia Bastarrica
Rodrigo E. Caballero
DCC, Universidad de Chile Av. Blanco Encalada 2120, Santiago, Chile
[email protected]
United Technologies Research Center 411 Silver Lane, MS 129-85, E. Hartford, CT 06108, USA
[email protected]
CS&E, Univiversity of Connecticut 191 Auditorium Rd., U-155, Storrs, CT 06269, USA
[email protected]
CS&E, University of Connecticut 191 Auditorium Rd., U-155, Storrs, CT 06269, USA
[email protected] and MIT Lab for Computer Science 545 Tech. Sq., NE43-316, Cambridge, MA 02139, USA
Steven A. Demurjian
Abstract
Performance of a distributed system can be greatly affected by the deployment of the system components over the nodes of the target network. Performance evaluation and tuning after deployment is generally expensive and risky because redeploying the system is a complex task. We present two approaches to optimizing deployment of component-based systems: a binary integer programming model (BIP) and a multiobjective niching genetic algorithm (MNGA). We demonstrate the two approaches by using them to deploy instances of an implementation of a distributed replicated data service called Eventually Serializable Data Service (ESDS). The interesting aspect of the work is that while BIP model guarantees the optimal deployment according to the chosen criterion, a good GA solution can be obtained in a much shorter time.
1. INTRODUCTION
Deploying component-based systems in the target networked environments is a dicult e ort that substantially a ects the performance (e.g., latency, throughput, fault tolerance or communication eciency) of the working system. The optimization of the deployment is subject to multiple, often con icting, objectives that need to be considered simultaneously, while satisfying constraints related to hardware characteristics and deployment requirements. There are many ongoing e orts in this research area. In [10], processing and communication costs are modeled using a graph, from which the cost-minimizing deployment is calculated. Combining several metrics into
Alex A. Shvartsman
one, as in [18], is dicult and may also be counterproductive, since speci c system settings may call for di erent priorities to be assigned to individual performance measurements. In [15], Petri nets are used to model the component-based system deployment problem, but no speci c optimization method is proposed. In our work [2], we developed a binary integer programming model for optimizing component-based systems deployment by minimizing remote communication throughput. The model works well for its objective, but it requires a substantial amount of low level information about the system interactions not usually available at design time. In evaluating the performance of a distributed system one important factor is the number of remote messages in the system. The number of remote messages is a simple and meaningful performance indicator that is directly impacted by the deployment of the system's communicating components over the target network. In this paper, we present two complementary approaches for the optimization of componentbased systems deployment based on the number of remote messages: a binary integer programming (BIP) model and a multiobjective niching genetic algorithm (MNGA). Why two di erent approaches? The reason is that while the BIP model guarantees optimality, in practice, this approach is limited by the number of software components and hardware nodes involved in the component-based systems deployment. Conversely, the MNGA approach, even though it is a new approach towards optimization and more experimentation is needed, seems to work well for practical applications, but does not guarantee optimality and gives
only an improved result over some initial deployment assumptions. Our experience shows that this result can be obtained in a reasonable time. Our focus of this paper is to consider these two approaches for deployment optimization, BIP and MNGA, for a single, common application, namely, the implementation of an eventually serializable data service (ESDS) [4]. ESDS is a replicated data service de ned by Fekete et al. [12]. ESDS deals with replicated objects that allow the clients of the service to relax consistency requirements in return for improved responsiveness, while providing guarantees of eventual consistency of the replicated data. The ESDS implementation includes parameterizable numbers of client, front-end and replica components that have di erent communication patterns and that can be individually deployed in a target network. ESDS is a good candidate for our study since it admits many possible deployments within a particular network. Both BIT and MNGA are well known optimization techniques but we show an interesting application and an eciency comparison between them. Each approach can model and determine a deployment for ESDS by attempting to minimization the remote messaging in this system. BIP of course will guarantee optimality, while MNGA will not. However, as we illustrate in this paper, for the considered instances of the ESDS application, the MNGA results are in fact optimal, and align with the BIP results. The key issue is that there is a signi cant time di erence in the execution of the algorithms for the two approaches. Thus we can hope that in considering larger instances of the application, MNGA will obtain improved solutions in tractable time. The parameters for instantiating both optimization models are derived from our earlier work on I 5 [1], a ve-level speci cation framework that includes both software and hardware elements. The remainder of this paper is organized as follows. For background purposes, Section 2 brie y reviews the I 5 speci cation framework and the ESDS application. Section 3 describes critical assumptions. Sections 4 and 5, contain, respectively, our BIP and MNGA approaches for component-based systems deployment. Section 6 details the deployment using the BIP and MNGA approaches. Finally, in Section 7, we conclude this paper.
2. THE I 5 FRAMEWORK AND ESDS
I 5 is a ve level speci cation framework for archi-
tectural speci cation of distributed systems [1]. Each level addresses di erent aspects of the speci cation in a decreasing level of abstraction including both software
and hardware features, and using either graphical or textual notation. The graphical notation is based on customized UML implementation diagrams [11], and the textual notation is based on the Z speci cation language [19]. The levels of I 5 are Interface, Implementation, Integration, Instantiation, and Installation. Figure 1 shows the ve speci cation levels included in a I 5 with their software and hardware parts, and the dependencies among them. SOFTWARE
HARDWARE
COMPONENT TYPES
NODE TYPES
INTERFACE
1
1
IMPLEMENTATION NODE IMPLEMENTATION CLASSES
COMPONENT IMPLEMENTATION CLASSES
2
2
INTEGRATION 3
3
IMPLEMENTATION INTEGRATION
COMPONENT INSTANTIATION
NODE INSTANTIATION
4
INSTANTIATION
4
4
APPLICATION INSTANTIATION 5
6
INSTALLATION INSTALLATION REQUIREMENTS (together, separated)
INSTALLATION REQUIREMENTS (fixed components)
7 7
7
FINAL INSTALLATION
Figure 1. The hardware and software levels of I 5.
We illustrate I 5 using an implementation of a replicated data service called Eventually Serializable Data Service (ESDS) [4, 12]. ESDS deals with replicated objects and it trades short-term consistency of the objects for performance while guaranteeing eventual consistency of the replicated data. The main idea used by ESDS is that the replicas maintain an order on the data operations they know about. A known pre x of the order at each replica is such that it is consistent with the eventual total order on operations. Replicas are implemented as individually deployable components that periodically exchange their knowledge in gossip messages. ESDS also includes client components that are responsible for interacting with the users of the service, and front-end components that broker the communication between multiple clients and speci c replicas. Client implementations depend on the speci c datatype being implemented by the replicas, while frontends are generic and replicas can be parameterized by the spe-
ci c data type. (To avoid a complete restatement, we refer the reader to [12] for a detailed description of the algorithm [4].) We now present the ve speci cation levels of I 5 and illustrate them using the ESDS example. Interface. This rst level of I 5 de nes the component types of the application, and the node and connector types of the target network. For every component type, the Interface speci cation provides a name, a set of interfaces, and a set of calls to interfaces in other component types. Interface inheritance is also speci ed at this level. For its Interface, ESDS has three component types (modeled in UML): Client, FrontEnd, and Replica, that interact as described in Figure 2. The
on Unix systems. FrontEnds are general for all the applications, and only one class exist, a XFrontEnd. The implementation classes for the Replica type are the ones that actually handle the data service for each application. There is only one class that realizes each Replica: Counter. Figure 4 shows the actual class interaction for the counter application. Note that we created UML \stereotypes" for the component classes and we show them as shaded boxes. There is only one implementaPCCtrCl
response
XCtrCl
response
request XFrontEnd receive
response
Client
receive
Counter
gossip
request FrontEnd
receive
Figure 4. Counter Implementation Classes. receive Replica gossip
Figure 2. ESDS Software Interface Speci cation.
data service runs on a network of Sun/Unix workstations and some clients can run on Intel Pentium PCs. MPI is use to communicate among the Sun workstations, and the PCs communicate with Sun workstations using sockets, as shown in Figure 3.
tion class for each type of node and one implementation class for each connection type. Figure 5 shows the re nements of the node and connector types into classes using UML deployment diagrams in its type version. MPI
Sockets Intel Pentium
SUN
MPI_Impl
MPI CSockets SUN OS 4.1.4
Sockets SUN
Win95
Intel Pentium
Figure 3. ESDS Hardware Interface Speci cation.
Implementation. This level of I 5 deals with the de-
nition of implementation classes. Each component, node or connector type in Interface may be realized by zero or more classes in the Implementation. Component classes preserve the interfaces of the types they realize. Implementation inheritance is de ned at this level. The importance of the Implementation level is more apparent when di erent implementations are provided for the same component type. We focus on the counter application developed with ESDS [4]. It has two Client classes: PCCounterClient , intended to run on PCs, and XCounterClient that run
Figure 5. Node and Connector Implementation.
Integration. This level de nes the dependencies that
exist between component and node classes for deployment: a node class supports a component class, meaning that instances of a component class may be deployed to instances of a node class. These dependencies correspond to hardware requirements of the component classes. In ESDS, some clients need to run on PCs, while all other component classes are intended to run on Unix machines. Figure 6 illustrates these dependencies; the stereotyped dependency hhsupports ii represents the supports relationship. Instantiation. In this level, the instance components, nodes and connectors that form part of the actual sys-
XCtrCl
PCCtrCl
receive
ct1:Counter
XFrontEnd
Counter
gossip
request
c1:PCCtrCl
receive receive
response
ct2:Counter gossip
SUN OS 4.1.4
fe1: XFrontEnd
Win95
c2:PCCtrCl
response
receive
ct3:Counter gossip receive
c3:PCCtrCl
response
c4:XCtrCl
response
request
receive
Figure 6. Integration dependencies.
receive
tem are de ned. Only instances of the classes de ned in the Implementation level can be de ned and they must follow the same communication patterns. Instances are named with an underlined lower case name, a colon and the name of the class they instantiate, as is standard in UML. For ESDS, we focus on an instantiation for the system with 4 clients, 2 front ends and 6 replicas, as shown in Figure 7. Three of the client instance components belong to the PCCounterClient class and one to the XCounterClient class. Two of them communicate with one XFrontEnd and the other two with the other XFrontEnd. There are two XFrontEnd instances, and since each communicates with only one replica, the other replicas that do not have a front end, only get the information through the gossip mechanism. The messages generated by the clients depend on the particular usage, but they determine the communication frequency between the front ends and the replicas: the total communication received by a front end equals the total communication sent to the replicas. The answer messages have the same frequency as the requests. Gossiping occurs at regular intervals; here we assumed it was 5 times per unit of time. Table 1 summarizes the communication frequency between client and front end component instances in the ESDS. The network Class
inst id
XFrontEnd
fe2
PCCounterClient PCCounterClient PCCounterClient XCounterClient XFrontEnd
c1 c2 c3 c4 fe1
inst call
fe 1 7! receive fe 1 7! receive fe 2 7! receive fe 2 7! receive ct 1 7! receive c 1 7! response c 2 7! response ct 4 7! receive c 3 7! response c 4 7! response
ct4:Counter
gossip
freq 10 2 10 5 12 10 2 15 10 5
Table 1. Clients and Front Ends Instantiation.
is formed by 10 Sun workstations connected with MPI and 4 PCs connected with sockets. The actual network topology is given in Figure 8. Installation. This last level de nes the complete de-
ct5:Counter fe2: XFrontEnd
gossip receive
ct6:Counter gossip
Figure 7. ESDS Software Instantiation. pc1:Win95
sock1
sun1: SunOS4.1.4
pc2:Win95
pc3:Win95
pc4:Win95
sock2
sock3
sock4
sun2: SunOS4.1.4
sun3: SunOS4.1.4
sun4: SunOS4.1.4
sun5: SunOS4.1.4
sun9: SunOS4.1.4
sun10: SunOS4.1.4
mpi1
sun6: SunOS4.1.4
sun7: SunOS4.1.4
sun8: SunOS4.1.4
Figure 8. ESDS Hardware Instantiation.
ployment of instance components of the distributed application to instance nodes in the target network in two parts: installation requirements and the complete installation. Every instance identi ed in the Instantiation must be part of the Installation. Installation requirements such as xing the location of certain components, or prescribing that two components must be deployed to the same or di erent nodes, are also de ned at this level. For ESDS, we only include the requirements as part of our speci cation because the complete installation is obtained from the optimization process to be described in Section 4. Replication is used for improving performance by having a copy of the target component in a near site, and for increasing fault tolerance, so replicas are deployed to di erent node instances. Besides, the front end components are completely general, and thus shared by di erent applications; we assumed that fe 1 and fe 2 are already deployed to nodes sun 2 and sun 3, respectively. So we have the following installation requirements: separated = x =
ffct 1 ct 2 ct 3 ct 4 ct 5 ct 6gg f(fe 1 7! sun 2) (fe 2 7! sun 3)g ;
;
;
;
;
;
3. DEPLOYMENT ASSUMPTIONS
This section contains our assumptions regarding our model as presented in Section 2. Component instances are the only distributable units, and they are all assigned once to node instances. Messages are the only type of communication considered. The total number of messages depends on the frequency for each kind of message at runtime and the number of hops they have to travel to reach their destination. The frequency corresponds to the average number of times the message is sent per time unit; frequencies during system initialization may be di erent, but optimization is based on a stable state situation. Local communication is formed by the messages sent between components deployed to the same node. It is not considered for the minimization because we assume that it is faster and cheaper than remote communication, so the bene t of minimizing it is negligible. Thus optimization tends to co-locate components that have heavy communication in the same node. Node instances have di erent classes, and thus some component classes may be deployed only to certain class of nodes. Connectors are hyperlinks, they link sets of node instances, not just pairs of nodes. Communication occurs through network connectors, either directly whenever there is a connector between the pair of instance nodes, or through a series of hops. Even though the distance between pairs of nodes may be di erent, we consider each message hop between a connected pair of nodes as one countable remote message. Network is de ned as a connected hypergraph [9] in terms of the instance nodes and instance connectors. Our requirements for deployment are as follows: Every instance component must be deployed to one and only one instance node. Components can only be deployed to nodes whose class supports the component class. Communication between two components takes as many hops as the distance between the nodes where they are deployed. There may be some component instances whose location is xed before starting the optimization process. Some others may be required to be located either together or separated.
4. BIP DEPLOYMENT APPROACH
A binary integer programming system is a linear programming system where all variables are required to be either 0 or 1. The formulation of the problem
includes a set of constraint equations and an objective function. The solution is derived by applying branch and bound instead of the simplex method applied to regular linear programming problems [14].
Parameters The I 5 speci cation, including the frequency of each
message at runtime, provides all the data necessary to instantiate the BIP model. The classes of both components and nodes, provided in the Implementation level are used in the Integration level to determine the supports relation; this relation is essential for calculating some parameters of the model. The information included in the Instantiation level is the most relevant; here the actual components to be deployed are de ned as well as the instance nodes and connectors of the network. Instance connectors are used for determining the paths between pairs of nodes and this is used to count the number of hops a message should travel. The frequency of each call is used to calculate the total communication between components. Supports: The Integration level of I 5 states the dependencies between component classes and node classes; the supports relation establishes the need for certain component classes to run on certain node classes (see Section 2). So these constraints about where components can be deployed must be followed. We de ne an array of binary values SUPP with dimensions C N , where C is the number of instance components in the application and N is the number of instance nodes in the network, so that SUPP (i ; j ) is 1 if component i may run on node j , or O otherwise. Messages: The total number of messages sent between any pair of instance components per time unit is the sum of the frequencies of all of the instance calls to every interface implemented in the destination component. MSGS is an array of C C , where the rst dimension is the source and the second one the destination of the communication. The data for computing MSGS is taken from the software Instantiation speci cation. MSGS (a ; b ) is the summation of the frequencies of all of the messages originated in a and whose destination is b . Hops: Communication takes place only through physical network paths between the instance node where the source component is deployed and the instance node where the destination is deployed. Our network is assumed to be connected, so there is always a path between source and destination. We are interested in the number of hops the message needs to travel. We de ne the integer array HOPS of dimensions N N as the number of connectors a message should travel from source to destination. We can calculate the shortest
path from the Instantiation speci cation, that is the set of all instance connectors that form the actual network; the path could also be obtained from routing tables [6, 7]. We de ne HOPS (i ; j ) to be 0 if i = j and the length of the path between nodes i and j otherwise. The breadth rst search (BFS) algorithm can be used for calculating the shortest path between all pairs of nodes in the network [8]. Its complexity is O (N 2 ). SUPP , MSGS , and HOPS are all the parameters needed for instantiating the equations in the BIP model.
nodes. It is necessary for the objective function. We de ne them as follows:
variables, xi ;j , are de ned as follows:
Objective Function
Variables and Equations Decision variables: Our primary binary decision xi j = ;
( 1 if instance component i
is deployed to instance node j 0 otherwise
There are C N primary decision variables. Completeness: Every instance component must be deployed to one and only one instance node of the network. So, the summation of all of the nodes where component i is located is exactly 1. Supportability: All instance components should be deployed to instance nodes that support their class. If a component i is deployed to a node j (xi ;j = 1), it is necessary that the node supports it (SUPP (i ; j ) = 1), but even if the node supports the component, it is not necessary to deploy it there, so xi ;j SUPP (i ; j ). Deployment requirements: There may exist three kinds of deployment requirements: x, together and separated, where some instance components have their location pre xed, or they are prescribed to be deployed either together with some other components or separated, respectively. Fixing a component location is just assigning a value 1 to a certain variable, e.g. x2;7 = 1. Stating that a set T of components must be deployed together can be stated as follows. The product is 1 just for one node. N Y X
(
j =1 a 2T
xa j ) = 1 ;
And for stating that a set S of component instances must be deployed to di erent nodes, we need that the summation of all components in S deployed to a certain node is less or equal to 1; that is, each node has at most one component of the set. Auxiliary decision variables: We also need some auxiliary variables ya ;i ;b ;j to express the condition of having a pair of components deployed to a pair of
8 1 if instance component a is deployed to > < instance node i and instance component ya i b j = b is deployed to instance node j > : 0 otherwise ; ; ;
There are C 2N 2 of these auxiliary variables. There exist a relationship between the x s and the y s : xa ;i xb ;j = ya ;i ;b ;j . This equation is not linear, but it can be restated in terms of three linear inequalities (recalling that the variables are binary): ya ;i ;b ;j xa ;i , ya ;i ;b ;j xb ;j , and 1 + ya ;i ;b ;j xa ;i + xb ;j . 0
0
The objective function minimizes the number of remote messages sent per time unit. We only want to consider remote messages, that is when origin and destination are di erent (i 6= j ). However, we just add up all the messages sent in the system because those sent locally will add 0 because of the value of HOPS . Z=
C X C X N X N X a =1 b =1 i =1 j =1
M SGS (a ; b ) HOP S (i ; j ) ya ;i ;b ;j
5. GA DEPLOYMENT APPROACH Genetic Algorithms (GAs)[13] are stochastic search methods inspired by the evolution theory. A GA is a directed random search technique that can nd the global optimal or near optimal solution in complex multi-dimensional search spaces. The GA uses genetic operators such as selection, crossover, and mutation to manipulate the individuals in the population in order to gradually improve their tness. The GA successively processes a population of chromosomes, typically represented as bit strings that encode candidate solutions in the search space. The population is replaced in each generation based on the tness of each chromosome| a function that determines how well the chromosome solves the problem. However, as with other stochastic methods, GAs do not guarantee that an optimal solution will be found. In this section, we present our multiobjective niching genetic algorithm (MNGA) approach for deployment of component-based systems. Decision variables: The genetic algorithm uses a similar formulation of the problem presented in Section 4, but in this case the variables are integers. The decision variables in this case are k 2 N, that de ne the network instance node where instance component k is deployed. There are C decision variables. Genetic algorithms [13] work with a coding of the objective variables into chromosomes. In our model,
if i = 1 then Fi (x ) = Ze( (x )) else if gi ( (x )) 0 then Fi (x ) = 0 else Fi (x ) = gi ( (x )) endif endif 0
0
Figure 9. Calculating the tness value.
a chromosome is the concatenation of C binary segments, each of which corresponds to an objective variable k represented in Gray code with arbitrary precision. We introduce a multiobjective niching GA that is based on the deterministic crowding GA [17]. Deterministic crowding in its original form is a single- objective optimization algorithm. To solve multiple objective problems, we propose the use of selection by switching objective [20]. This method randomly selects, in each generation, an objective function to determine the tness of every element in the population. The probability of selection for each objective can be varied in order to assign di erent relative importance to the optimization criteria [16]. In constrained search spaces, the problem constraints are handled as objective functions, as suggested in [5]. Let Ze : NC ! R denote the objective function to be minimized. Ze (~) =
XXXX
i 2N j 2N a 2C b 2C j 6=i a =i b =j
M SGS (a ; b ) HOP S (i ; j )
Let gj : NC ! R, denote a set of q constraints of the form gj (~) 0 8 j 2 [2; 1 + q ]. Let h : NC ! R, denote a set of m constraints of the form hj (~) = 0 8 j 2 [q + 2; q + m + 1]. Let g : NC ! R, denote the union of the original set of q inequality constraints and 2m constraints resulting from rewriting hj in the form of gj (expanding each equality constraint in two inequalities). Given a population P of the GA, and a decoding function : P ! NC that decodes the individual x into the corresponding vector of decision variables ~. Let the transformation Fi : P ! R; i 2 [1; q + 2m + 1], denote the tness value of a population element according to the i -th objective function taken from the union of the original objective function Ze , and the q + 2m problem constraints g . Then the tness value Fi , according to the i -th objective, is determined using the algorithm in Figure 9. Let the transformation i : P P ! P denote a tournament according to the i -th objective, such that the population element i (x ; y ) is the winner of the 0
if Fi (x ) < Fi (y ) then i = x else if Fi (x ) > Fi (y ) then i = y else if j fj 2 [1; q + 2m + 1] : j (x ; y ) = x ; 8 j 6= i g j> j fj 2 [1; q + 2m + 1] : j (x ; y ) = y ; 8 j 6= i g j then i = x else if j fj 2 [1; q + 2m + 1] : j (x ; y ) = x ; 8 j 6= i g j< j fj 2 [1; q + 2m + 1] : j (x ; y ) = y ; 8 j 6= i g j then i = y else select i from fx,yg with probability 0.5. endif endif endif endif
Figure 10. Selecting the winner between individuals x and y .
repeat for G generations do j P j =2 times: Select a random active objective function i in the interval [1, q+2m+1] Select two parents p1 and p2 , randomly, without replacement Apply crossover, resulting c1 and c2 Apply mutation, resulting c1 and c2 if [Distance(p1,c1 ) + Distance(p2, c2 )] [Distance(p1,c2 ) + Distance(p2, c1 )] Replace p1 with the winner of the tournament i (p1 ; c1 ) Replace p2 with the winner of the tournament i (p2 ; c2 ) else Replace p1 with the winner of the tournament i (p1 ; c2 ) Replace p2 with the winner of the tournament i (p2 ; c1 ) endif enddo endrepeat 0
0
0
0
0
0
0
0
0
0
0
Figure 11. Multiobjective niching genetic algorithm.
tournament between individual x and individual y . i (x ; y ) is determined by the algorithm in Figure 10. Finally, given a population P that evolves during G generations, the algorithm in Figure 11 describes the multiobjective niching genetic algorithm.
6. ESDS DEPLOYMENT We applied both approaches, BIP and MNGA, for nding deployments of ESDS instances. We searched for the deployment that minimizes the number of messages and also looked at other factors such as the search time. Recall that while BIP will obtain an optimal result, MNGA does not have such guarantee.
6.1. BIP Optimal Deployment The data for instantiating the optimization model can be obtained from the I 5 speci cation as explained in Section 4, however we show the actual matrices because getting these data needs some processing. The matrices are a way of rearranging some of the I 5 information in a way useful for the BIP model. Supports. From the Integration speci cation we derive the SUPP matrix as shown in Table 2. Clients c1 c2 c3 c4 fe1 fe2 ct1 ct2 ct3 ct4 ct5 ct6
sun1 0 0 0 1 1 1 1 1 1 1 1 1
sun10 0 0 0 1 1 1 1 1 1 1 1 1
pc1 1 1 1 0 0 0 0 0 0 0 0 0
pc2 1 1 1 0 0 0 0 0 0 0 0 0
pc3 1 1 1 0 0 0 0 0 0 0 0 0
pc4 1 1 1 0 0 0 0 0 0 0 0 0
Table 2. SUPP (i ; j ) , i :class supports j :class
c 1, c 2 and c 3 can only run on PCs, while all the remaining instance components must run on sun workstations. Messages. There is only one kind of messages between every pair of component instances in our example, so the value of MSGS is just the value of the freq for that message. Table 3 summarizes these values. Hops. The network topology is simple and it is easy to calculate the minimum number of hops between every pair of nodes by looking at the diagram in Figure 8. Table 4 shows the HOPS matrix. BIP makes an exhaustive search using the branch and bound algorithm. The complexity for the optimal deployment problem is O (N C ) [2]. We built a C program to execute this search and it got to the optimum in about two hours. We also tried the GAMS [3]
c1 c2 c3 c4 fe1 fe2 ct1 ct2 ct3 ct4 ct5 ct6
c 1
c 2
c 3
c 4
0 0 0 0 10 0 0 0 0 0 0 0
0 0 0 0 2 0 0 0 0 0 0 0
0 0 0 0 0 10 0 0 0 0 0 0
0 0 0 0 0 5 0 0 0 0 0 0
f e 1
f e 2
10 2 0 0 0 0 12 0 0 0 0 0
0 0 10 5 0 0 0 0 0 15 0 0
c t 1
0 0 0 0 12 0 5 5 5 5 5 5
c t 2
0 0 0 0 0 0 5 5 5 5 5 5
c t 3 0 0 0 0 0 0 5 5 5 5 5 5
c t 4
0 0 0 0 0 15 5 5 5 5 5 5
c t 5
c t 6
0 0 0 0 0 0 5 5 5 5 5 5
0 0 0 0 0 0 5 5 5 5 5 5
Table 3. MSGS(i,j) - messages between i and j . sun1 sun2 sun3 sun4 sun5 sun6 sun7 sun8 sun9 sun10 pc1 pc2 pc3 pc4
s u n 1 0 1 1 1 1 1 1 1 1 1 1 2 2 2
s u n 2
1 0 1 1 1 1 1 1 1 1 2 1 2 2
s u n 3 1 1 0 1 1 1 1 1 1 1 2 2 1 2
s u n 4
1 1 1 0 1 1 1 1 1 1 2 2 2 1
s u n 5 1 1 1 1 0 1 1 1 1 1 2 2 2 2
s u n 6
1 1 1 1 1 0 1 1 1 1 2 2 2 2
s u n 7 1 1 1 1 1 1 0 1 1 1 2 2 2 2
s u n 8 1 1 1 1 1 1 1 0 1 1 2 2 2 2
s u n 9 1 1 1 1 1 1 1 1 0 1 2 2 2 2
s p u c n 1 10 1 1 1 1 1 1 1 1 1 0 2 2 2 2
1 2 2 2 2 2 2 2 2 2 0 3 3 3
p c 2
p c 3
p c 4
2 1 2 2 2 2 2 2 2 2 3 0 3 3
2 2 1 2 2 2 2 2 2 2 3 3 0 3
2 2 2 1 2 2 2 2 2 2 3 3 3 0
Table 4. HOPS (i ; j ) - path between nodes i and j .
package but its closed structure did not allow us to include heuristics, and the execution time was too long; we cancelled the execution after a whole day without results. Figure 12 shows the resulting optimal deployment graphically using a UML deployment diagram. Note that Z , the total communication, is optimally determined at the value of 194.
6.2. MNGA Deployment For the MNGA algorithm as described in Section 5, we ran ten experiments with di erent random seeds. In all experiments, the MNGA found a solution in less than 104 tness evaluations. On the average, the rst solution was found in generation 29, with standard deviation 6.6. This represents a major speed up when compared with experiments in Section 6.1. In a single run, the MNGA successfully found multiple results (due to the problem symmetry) with 194 messages, which match the optimal BIP results. In order to evaluate the impact on the system of the number of software components and the size of the network, we performed three series of ten experiments using a modi ed version of the original ESDS system described in Section 2. In the rst scenario, the six original instances of Replica were duplicated, resulting in a total of 18 instance components (C = 18). We preserve the constraint that copies must be de-
Component Node c1 c2 c3 c4 fe1 fe2 ct1 ct2 ct3 ct4 ct5 ct6
pc2 pc2 pc3 sun3 sun2 sun3 sun2 sun1 sun4 sun3 sun5 sun6
c1 c3 c2 pc3
pc2
pc1
pc4
sock3 sock1
sock4
sock2
c4 fe1
fe2
ct1 sun1
ct5
ct3
ct2 ct4 sun2
sun3
sun4
sun5
mpi1
sun7
ct6
sun8
sun9
sun10
sun6
Figure 12. Optimal Deployment for the ESDS System. Z = 194. (gossip calls are not included in the diagram)
ployed separated from each other. The application was deployed over the original network composed by 14 instance nodes (N = 14). In the second scenario, the network was duplicated, resulting in 28 nodes (N = 28), and the software components were kept constant (C = 12). For this scenario, as well as for the previous one, the GA evolved a population of 100 elements during 100 generations. Finally, in the third scenario both the network and the components were duplicated (C = 18; N = 28). In the experiments for this case, the GA evolved 200 individuals during 200 generations (this because the algorithm did not nd the global optima using smaller values). Table 5 summarizes the number of generations and the execution time required to nd the rst global solution. The table also illustrates the total execution time for each of the four scenarios, for the experiments ran on a Pentium II 300Mhz with 64MB RAM.
have shown that for small problem instances, MNGA is able to nd optimal solutions. While this provides no evidence that for larger instances the MNGA approach may be able to nd good solutions, one can use MNGA to establish improved initial deployment con gurations. We note that BIP can be used e ectively to play what-if games with large application instances when only few components remain to be deployed. Thus it is interesting to pursue the deployment strategy where MNGA is used to establish an initial deployment of the system, and BIP is used for adding new components or redeploying some components.
7. CONCLUSION
References
Formal system architectural de nitions, such as I 5 , allow for most of the necessary information to be extracted for optimizing the distributed system deployment over the target networks. In out case we instantiated two optimization models, using BIP and MNGA. The BIP model yields optimal deployment solutions, but the running time of nding solutions is intractable when the scale of the system grows beyond few components and nodes. On the other hand MNGA does not guarantee the optimal solution, but it can obtain a solution in a reasonable time even for a substantial greater number of components and nodes. We
Acknowledgements. The research of the fourth au-
thor was supported in part by the NSF CAREER Award CCR-9984778 and by the NSF Grant CCR9988304.
[1] M. Cecilia Bastarrica, Steven A. Demurjian, and Alex A. Shvartsman. I 5 : A Framework for Architectural Speci cation of Distributed Object Systems. In Proceedings of the 3rd International Conference On Principles Of DIstributed Systems, OPODIS'99, Hanoi, Vietnam, October 1999. [2] M. Cecilia Bastarrica, Alex A. Shvartsman, and Steven A. Demurjian Sr. A Binary Integer Programming Model for Optimal Object Distribution. In Proceedings of the 2nd International Conference On Principles Of DIstributed Systems, OPODIS'98, Amiens, France, December 1998.
Problem C=12, N=14 C=18, N=14 C=12, N=28 C=18, N=28
GA Finds rst global solution Execution Number of Generation Std. Deviation Time (sec.) Time (sec.) Messages 29 61.9 50.4 106.8
6.6 6.2 10.8 22.6
3.8 20.1 19.9 184.2
13.1 32.5 39.4 345
194 644 194 764
Table 5. GA Solution for Di erent Sizes of the Problem. [3] Anthony Brooke, David Kendrick, and Alexander Meeraus. GAMS. A user's guide. The Scienti c Press Series. Boyd and Fraser publishing company, 1992. [4] Oleg M. Cheiner and Alex A. Shvartsman. Implementing and Evaluating an Eventually-Serializable Data Service as a Distributed System Building Block. DIMACS Series in Discrete Mathematics and Theoretical Computer Science, 45, 1999. [5] C. Coello. Treating Constraints as Objectives for Single-Objective Evolutionary Optimization. Engineering Optimization, 32(3):275{308, 2000. [6] Douglas E. Comer. Internetworking with ICP/IP. Principles, Protocols and Architecture, 1, 1991. [7] Douglas E. Comer. The Internet Book. Everything you need to know about Computer Networking and how the Internet works. Prentice-Hall, Inc., 2nd. edition, 1997. [8] Thomas H. Cormer, Charles E. Leiserson, and Ronald L. Rivest. Introduction to Algorithms. The MIT Electrical Engineering and Computer Science Series. The MIT Press, 8th edition, 1992. [9] Reinhard Diestel. Graph Theory. Graduate Texts in Mathematics. Springer-Verlag, 1997. [10] L. Dunning and S. Ramakrishnan. A Heuristic Cost Estimation Method for Optimizing Assignment of Tasks to Processors. In Proc. of the 15th ACM Symposium on Applied Computing, pages 358{364, 1999. [11] Hans-Erik Eriksson and Magnus Penker. UML Toolkit. John Wiley and Sons, Inc., rst edition, 1998. [12] A. Fekete, D. Gupta, N. Lynch, V. Luchangco, and A. Shvartsman. Eventually-serializable data services. Theoretical Computer Science, 220:113{156, 1999. [13] D. Goldberg. Genetic Algorithms in Search, Optimization and Machine Learning. Ad. Wesley, MA, 1989. [14] Frederick S. Hillier and Gerald J. Lieberman. Introduction to Operations Research. Holden-Day, Inc., fth edition, 1995. [15] W. El Kaim and F Kordon. An Integrated Framework for Rapid System Prototyping and Automatic Code Distribution. In N. Kanopoulos, editor, Proc. of 5th Int. Workshop on Rapid System Prototyping, pages 52{ 61, Grenoble, France, June 1994. IEEE Press. [16] F. Kursawe. A Variant of Evolution Strategies for Vector Optimization. In H. Schewefelb and R. Manner,
[17] [18] [19] [20]
editors, Parallel Problem Solving from Nature. Proc. of the 1st. Workshop PPSN, pages 193{197, 1991. S. W. Mahfoud. Niching Methods for Genetic Algorithms. PhD thesis, University of Illinois at UrbanaChampaign, Urbana, IL, May 1995. S. Purao, H. K. Jain, and D. Nazareth. E ective distribution of object-oriented applications. Communications of the ACM, 41(8), August 1998. J. M. Spivey. Understanding Z. Cambridge Tracts in Theoretical Computer Science 3. Cambridge University Press, 1995. E. Zitzler. Evolutionary Algorithms for Multiobjective Optimization: Methods and Applications. PhD thesis, Swiss Federal Institute of Techology, Zurich, November 1999.
