0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 0.1 0.2 0.3 0.4 0.50.6 0.70.8 0.91.0 0.5 1.0
(a) The Cobb-Douglas function (ESDα
1 × ESD 1−α 2 ) with α = 0.5. 0.10.2 0.3 0.40.5 0.6 0.7 0.8 0.9 1.0 0.1 0.2 0.3 0.4 0.50.6 0.70.8 0.91.0 0.5 1.0
(b) The perfect substitutes plot (αESD1+ βESD2) with α =
β = 0.5. 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 0.5 1.0
(c) The perfect complements plot (min(αESD1, βESD2))
with α = β = 0.5. Figure 6.1: The plots of ESD functions.
buffer management [FS05].
6.2
Online Feedback-based Automatic Resource Configuration
The Online Feedback-based Automatic Resource Configuration (OAC) approach relies on the flexible execution model that we have introduced in Chapter 4 and the middleware AA we have introduced in Chapter 5. The application needs to be an adaptive application, which is able to autonomously balance the computational load over resources when the execution environment changes. The AA uses this approach to automatically configure the execution environment to run the application.
Figure 6.2 shows how the AA collaborates with underlying resource management infrastructure and interacts with the application to automatically configure the virtual machine, or the Resource Configu- ration (RC) (a set of hosts where an application runs). The application and the AA have different level functions. The application is responsible for making full use of the allocated resources (RC) by load balancing or migration, as well as reporting ESDs. Meanwhile, the AA takes charge of the intelligent
6.2. Online Feedback-based Automatic Resource Configuration 77
AA
Co m putatio nal grids (re so urc e e nviro nm e nt)
Re so urc e Co nfiguratio n (RC) Re po rt ESD
ac quire /re le ase re so urc e s le arning Tune RC A pplic a tion adaptation 1 10 2 3 4 5 6 7 8 9 Process 1 Process 2 Process 3
1 10 2 3 4 5 6 7 8 9 Process 1 Process 2 Process 3
Figure 6.2: How the AA performs the OAC.
resource management to create an optimal execution environment. Initially, the AA randomly selects some hosts to run the application. During the execution, the application periodically (e.g. every n itera- tions) reports a ESD value to the AA. The AA learns the relationship between the execution behaviour and the resource characteristics based on the reported ESD feedbacks and resource allocation history. The AA keeps updating the information every time a report is made and uses the history gathered to adapt its resource management policy. Once resources are added/replaced/deleted, the application will be notified and will reform itself to adapt to the current RC in order to fully exploit the benefits of pro- vided resources. In most cases, if the RC is better (e.g. including more fast hosts), the performance will improve. Gradually, the AA tunes the RC to a satisfaction level that is able to fulfil user’s execution QoS requirements.
The AA uses the embedded learning and resource tuning policy to intelligently configure the RC. In the following we will introduce two policies (the Utility Classification and the DPPE) for the AA to gather the necessary information and tune the RC based on the on-line and interactive way.
6.2.1
Implementation
In this section we introduce how we extended the AA architecture and API to support the OAC approach.
6.2.1.1
The AA Side
In order to provide the automatic resource tuning service, we introduce another daemon called the Automatic Resource Tuner (ART) to replace the control process of the application and take charge of all the resource management issues (Figure 6.3). If programmers set the second parameter of the function AA(arge, 1) as 1, the AA will start the ART daemon on the computer where the master process is - nor- mally the local computer. The ART relies on the reported ESD values to automatically generate resource requests. The requests will be sent to the RD daemon which in turn will contact the underlying DRMs to request resources. Once a process is deployed on a new resource, the host addition notification will be reported first to ART, which will use the host information to calculate further RC tuning. ART will then generate a process addition notification and pass it to the application. When ART decides to kill a certain resource, it will first send a PROCESS KILLING notification to the related process. Upon receiving the
6.2. Online Feedback-based Automatic Resource Configuration 78
mas ter/c o ntro l p ro c es s P MW C o mm P ro c es s R D AR T lo c al c o mp uter C on ta ct D RMs commu n ica te with oth er p rocesses
Figure 6.3: This diagram shows how the ART collaborates with other daemons to perform the automatic resource configuration. A solid arrow indicates an ESD reporting. A double-line arrow indicates a resource request to the RD. A dotted arrow indicates other processes or PMWComm daemons notifying a process addition/releasing to the ART.
the process. Note users can also manually add or delete resources by AddP rocess() or KillP rocess(). Manual actions will also be notified to ART to calculate future RC configuration. Different from other daemons, ART is implemented as a special user-level process based on the AA library. The communi- cation between ART and other daemons and processes is managed by the AA communication services (LComm, PMWComm).
6.2.1.2
The Application Side
As we stated above, in the AA model only a single process runs on each resource. The addition/re- lease/replacing of a resource is associated with the addition/release/replacing of a process. After each action, the AA only needs to inform the result of the action to the application. On the other hand, the application checks if any actions are performed by using GetNotification(int tag). Two types of tag PROCESS ADDED and PROCESS KILLING/PROCESS KILLED are respectively used to check if a new process is added or a process is killed. Adding a host is straightforward: after added a host, the AA sends the PROCESS ADDED notification to the application, which can unpack the notification mes- sage by Upk*() and then migrate load to the new host to make use of the host. Releasing a host is a three-phase process:
• 1. Before killing a process, the AA sends a PROCESS KILLING notification to the application to indicate its desire to kill the process.
• 2. Upon receiving the notification, the application vacates the process, and sends a
READY FOR KILLING notification to the AA by invoking ReadyforKilling() to indicate that
the process is ready to be killed.
• 3. Upon receiving the READY FOR KILLING notification, the AA kills the process and releases the related host. The AA sends a PROCESS KILLED notification to the application to indicate that the process has been removed.
The replacement process is decomposed to an addition of new process and a killing of the replaced process. A notification message which includes the target process UPID and basic host information such
6.2. Online Feedback-based Automatic Resource Configuration 79 1 . D e plo yP ro c e s s () 2 . G e tN o tific atio n() 3 . R e po rtESD () AA C o ntro l pro c e s s
L iste n the killing signa l L oa d migra tion, e tc ...
R e a dyforK illing() C o m puting pro c e s s
L iste n the killing signa l L oa d migra tion, e tc ...
R e a dyforK illing() C o m puting pro c e s s
L iste n the killing signa l L oa d migra tion, e tc ...
R e a dyforK illing() C o m puting pro c e s s L iste n the killing signa l L oa d migra tion, e tc ...
R e a dyforK illing() C o m puting pro c e s s
K illing s ignal P ro c e s s adde d/kille d no tific atio n
Figure 6.4: The automatic resource configuration: application code structure.
as processing speed and CPU load are returned when GetNotification() returns true. Application reports ESDs via API ReportESD().
An AA-enabled application should have a control/master process, which is responsible for listening for the process addition notification and reporting the ESD; and a number computation processes which computes the real problem. The master process could also be one of the computation processes. For example, here we have an adaptive application which is developed based on a local load balancing algorithm. When a new process is generated, the master tells the related process that a new neighbour has been added. The process then migrates its load to the new added neighbour. Gradually, the load of all the processes will be balanced through the periodical balancing. Figure 6.4 shows the code structure. Listing 6.1 and 6.2 show code fragments.
Listing 6.1: Master process code
/ / s t a r t t h e AA and e n a b l e t h e a u t o m a t i c r e s o u r c e c o n f i g u r a t i o n s e r v i c e . AA a a = new AA( a r g e , 1 ) ; / / T e l l t h e AA t h e p r o c e s s name t o add / d e l e t e . aa−>D e p l o y P r o c e s s ( ” Worker ” ) ; w h i l e ( t r u e ) { / / A p r o c e s s / r e s o u r c e i s a d d e d .
i f ( ( aa−>G e t N o t i f i c a t i o n ( PROCESS ADDED ) ) > 0 ) { i n t u p i d = aa−>U p k I n t e g e r ( ) ; f l o a t p = aa−>U p k F l o a t ( ) ; f l o a t l o a d = aa−>U p k F l o a t ( ) / / t e l l r e l a t e d p r o c e s s e s a new n e i g h b o u r ( UPID ) i s a d d e d . . . . } / / A p r o c e s s / r e s o u r c e i s r e l e a s e d .
i f ( ( aa−>G e t N o t i f i c a t i o n ( PROCESS KILLED ) ) > 0 ) { }
/ / M o n i t o r ESD a c c o r d i n g t o a ESD f u n c t i o n . . . .
6.3. The Utility Classification Policy 80