|
Role(s):
Service Provider
Component(s):
SLA Negotiator
SLA Repository
SLA Manager
SLA Monitor
SLA Evaluator
SLA Monitoring Daemon
License:
GPLv3
The SLA Management
Framework comes for two software platforms, .Net and GT4 (Java).
There fore, the installation section will consist of two parts, one
for .Net and another one for GT4. If you are installing under a GT4
platform go directly to section B.2.2.
Usage Instructions
SLA
Management
Installation .Net
SLA Management Installation GT4
Usage Instructions
The SLA Management
Framework has following features:
·Negotiation
of Service Level Agreements (SLAs)
·Interaction
with the resource management to check for available resources during
negotiation
·Evaluation
of Ganglia monitoring data and
·Reporting
of SLA violations via a Notification Server
The current
implementation of the SLA Negotiator agrees if resources are
available without making a counter offer. The availability of
resources is checked by asking the SRLM. The SLA that the potential
customer sends as input to the SLA Negotiator has been retrieved
from the service discovery server, where the service provider has
stored the SLA templates that describe the available quality of
service. The customer receives a quote ID in response to the SLA
Negotiator. When the customer has decided to buy a service they send
the QuoteID to the Contract Commitment Support service to actually
agree on the negotiated SLA. This would trigger the start of the SLA
monitoring, but currently this has to be done by the use of the SLA
Monitoring Daemon.
After the contract with
the customer has been established, the SLA Manager would start the
process of monitoring and evaluating the service performance. At
this stage the Contract Commitment Support is not integrated with
the SLA Management Framework so the command line tool SLA Monitoring
Daemon has to be used to start the SLA Monitor. In case of SLA
violations the SLA Evaluator reports service failures by use of a
Notification Server.
Storyboard:
The interaction with
the SLA Management Framework performs two main actions. These are:
·
Negotiation of Service Level
Agreements (SLAs)
§
Involved Components:
SLA Negotiator, SLA Repository, SRLM
§
Input/Output:
The customer sends an SLA Template with the desired quality of
service values to the SLA Negotiator and receives in return a
QuoteId if the service with that QoS is available.
·
Monitoring of the agreed Quality of
Service
§
Involoved Components: SLA
Repository, SLA Monitoring Daemon, SLA Monitor, SLA Evaluator,
Notification Support
§
Input/Output:
The QuoteId from the previous step is used to initiate the
monitoring phase. The possible outputs of this phase are
notifications of potential violations of the SLA.
Installation Windows .Net
Installation Requirements
·Windows
Server 2003 / XP or higher
·.NET
Framework 3.5 or higher
·MS
SQL or compatible database system
Deployment Tips
When
deciding where in the hosting environment to deploy components
general considerations of scalability and security apply. These are:
(a) Secure communication between two components adds a
processing overhead and may also require the use of additional
components, e.g. the Gateway component
may be used for in- and out-going messages that have to be secured.
(b)
Components that interact closely and cause a huge amount of traffic
between them may be hosted on the same machine if scalability
permits.
(c)
For scalability reasons more than one instance of a component may be
created.
Components that may require a secure communication with another
component are:
·
The SLA Negotiator, because it interacts with the customer, which
clearly is external to the service provider and because of the
confidential nature of the business relationship, this communication
clearly has to be done is a secure manner.
·
The SLA Evaluator may require a secure communication if the
interaction with either the SLA Monitor or the Notification Support
server goes across organizational domain boundaries that can't be
regarded as safe per se.
Components that may be instantiated multiple times:
·
Depending on the number of machines hosting the actual services it
might be required to have more than one instance of the SLA Monitor.
·
Also the SLA Evaluator is a potential candidate that may require
multiple instances. This depends of course on the CPU load caused by
the individual instance.
The SLA
Repository is an internal component that acts as a front end to the
actual database. So security as well as scalability issues may apply
to this service. The decision on whether to use security and/or
create multiple instances depends on the actual use.
The SLA Manager will
probably be instantiated only once, because the management
interactions when initiating, configuring and terminating the SLA
Management process are not very CPU intensive. Also as an internal
component it will probably not require a secure communication to
execute its task.
Software Installation
Download and execute
the .Net "BREIN_SLAManagement_Framework.msi" installer in the server
you wish to install the "Management Framework".
The installer by
default will create a "virtual" directory in the IIS (vdir) called "SLAManagement".
The SLAManagement vdir will contain the sub directories:
·
SLAEvaluator
·
SLAManager
·
SLAMonitor
·
SLANegotiator
·
SLARepository
By opening the IIS
Management Console you will have to make these sub directories
application directories. Otherwise the services are not accessible
with the Windows authentication mode.
The services should be accessible
locally at the following URLs:
http://localhost/SLAManagement/SLAEvaluator/SLAEvaluatorService.asmx
http://localhost/SLAManagement/SLAManager/SLAManager.asmx
http://localhost/SLAManagement/SLAMonitor/SLAMonitorService.asmx
http://localhost/SLAManagement/SLANegotiator/SLANegotiatorService.asmx
http://localhost/SLAManagement/SLARepository/SLARepositoryService.asmx
Note:
The installation will create the
directory: C:\Brein. Log-files of the services will be created in
the respective sub-directories. The user guide will be installed
there.
Installation
GT4
·
Windows Server 2003 / XP or higher
·JDK
1.5 or higher
·
Ant 1.7.1
·
GT4 WS Core 4.0.8 environment (
Globus Toolkit 4.0.8 Download. [Online]
http://www.globus.org/toolkit/downloads/4.0.8/)
·
MySQL database 5.0 or higher
Deployment Tips
When
deciding where in the hosting environment to deploy components
general considerations of scalability and security apply. These are:
(a)
Secure communication between two components adds a processing
overhead and may also require the uses of additional components,
e.g. the Gateway component (see Messaging Infrastructure Framework
Installation Manual) may be used for in- and out-going messages that
have to be secured.
(b)
Components that interact closely and cause a huge amount of traffic
between them may be hosted on the same machine if scalability
permits.
(c)
For scalability reasons more than one instance of a component may be
created.
Components that require a secure communication with another
component are:
·
The SLA Negotiator, because it interacts with the customer, which
clearly is external to the service provider and because of the
confidential nature of the business relationship, this communication
clearly has to be done is a secure manner.
·
The SLA Evaluator may require a secure communication if the
interaction with either the SLA Monitor or the Notification Support
server goes across organizational domain boundaries that can't be
regarded as safe per se.
Components that may be instantiated multiple times:
·
Depending on the number of machines hosting the actual services it
might be required to have more than one instance of the SLA Monitor.
·
Also the SLA Evaluator is a potential candidate that may require
multiple instances. This depends of course on the CPU load caused by
the individual instance.
The SLA Repository is an internal component that acts as a front end
to the actual database. So security as well as scalability issues
may apply to this service. The decision on whether to use security
and/or create multiple instances depends on the actual use.
The SLA Manager will probably be instantiated
only once, because the management interactions when initiating,
configuring and terminating the SLA Management process are not very
CPU intensive. Also as an internal component it will probably not
require a secure communication to execute its task.
A.1.1.3. Software Installation
The SLA Management
components are provided by a binary distribution with an installer,
which works under Windows.
Download the installer
"SLAManagement_setup.exe"
Firstly download the
installer "SLA_Management_setup.exe".
Before executing it the
following three steps are required:
1, Install GT4 WS Core
under C:\ws-core-4.0.8 and set "GLOBUS_LOCATION" as a System
variable to the absolute path of the directory where Java WS Core is
installed:
2.Install Ant 1.7.1
under C:\apache-ant-1.7.1 and set "ANT_HOME" as a System variable to
the absolute path of the directory where ANT is installed.
Furthermore, the following values ":C:\apache-ant-1.7.1\bin" should
be added at the end of the System variable "PATH" of your Windows:
3. Create environment
variable for JAVA_HOME to the absolute path of the directory where
JDK is installed.
Then reboot your
computer, the following System variables can be found on your
Windows environment variable tab:
|
Variable |
Value |
|
JAVA_HOME |
C:\Program Files\Java\jdk1.6.0_11 |
|
ANT_HOME |
C:\apache-ant-1.7.1 |
|
GLOBUS_LOCATION |
C:\ws-core-4.0.8 |
;
After the above steps
are finished, you can execute the installer
"SLA_Management_setup_v2.exe". To install the SLA components, it is
required to accept the license Agreement.
Figure
58:
SLA Management Setup Wizard – License Agreement
After then you can chose the SLA components,
which are needed to be installed.
Note: It is highly recommanded that, SLA
Evaluator and SLA Monitor are installed on different machines or the
same machine with different GT4 container, in order to prevent the
potential library conflict between GT4 and the other libraries,
which are provided by other partner for supporting the
functionalities of SLA management Framework.
Figure
59:
SLA Management Setup Wizard – chose SLA components
SLA Management components will be deployed on
GT4 container automatically, if all the above mentioned environments
are available.
Figure
60:
SLA Management Setup Wizard - SLA components deployment
Before calling any
service, the GT4 container should be started with the following
command on your command line:
C:/ws-core-4.0.8/bin/globus-start-container
-nosec
The services should be accessible
locally at the following URLs:
http://localhost:8080/wsrf/services/Brein/sla-neglotiation/AgreementFactory
http://localhost:8080/wsrf/services/Brein/sla-neglotiation/Agreement
http://localhost:8080/wsrf/services/Brein/sla-repository
http://localhost:8080/wsrf/services/Brein/sla-monitor
http://localhost:8080/wsrf/services/Brein/sla-evaluator
Note:
GT4
installation:
http://www.globus.org/toolkit/docs/4.0/admin/docbook/;
Ant Installation: http://ant.apache.org/manual/install.html
The installation will create the directory BreinLogs. Log-files of
the services will be created in the respective sub-directories.
SLA Monitor
Prerequisites
The SLA Monitor relies
on four necessary components for a successful operation. They are,
the SLA Repository, a resource monitor and the SLA Evaluator. Among
them resource monitor is from the external Toolkits.
Installation
The SLA Monitor must be
deployed on a GT4 WS Core Container.
The SLA Monitor service has configuration values which can be
specified in the server configuration file (%GLOBUS_LOCATION%/etc/brein_monitor/-server-config.wsdd)
as shown below:
<deployment: name="defaultServiceConfig">
<parameter name="sla.reposiotry.url "
value=
"http://localhost:8080/wsrf/services/Brein/sla-repository" />
<parameter
name="sla.evaluator.url"
value=" http://localhost:8081/wsrf/services/Brein/sla-evaluator" />
<parameter name= "rmserver.url"
value="pcsiset.edx"/><parameter name=
"rmserver.url.port"
value="8085"/>
<parameter name=
"srlm.url"
value="autonomic.ac.upc.edu:18080/SrlmWsit/SrlmService?wsdl"/>
</deployment>
Standard deployment leads to the service being available on the
local host under the following address:
http://localhost:8080/wsrf/services/Brein/sla-monitor
SLA Evaluator
Prerequisites
Necessary components for a successful operation of the SLA Evaluator
are depended on a deployed SLA Repository Service and a deployed
Notification Broker Service.
Installation
The SLA Evaluator must
be deployed on GT4 WS Core Container.
The service endpoints of the SLA Repository service, the
Notification Broker Service shall be specified in the serverconfig
file
(%GLOBUS_LOCATION%/etc/brein_evaluator/server-config..wsdd)
as
shown below:
<deployment: name="defaultServiceConfig">
<parameter name="SLARepositoryServiceURI"
value="http://localhost:8080/wsrf/services/Brein/sla-repository">
<parameter
name="NOTIFICATION_BORKER_URL"
value=" http://150.254.173.199:18001/" />
</deployment>
Standard deployment leads to the service being available on the
local host under the following address:
http://localhost:8080/wsrf/services/Brein/sla-evaluator
SLA Negotiator
Prerequisites
During
operation, the provider-side SLA Negotiator needs to communicate
with the SRLM, the SLA Translator, the SATSLA Repository and the SLA
Repository service. Therefore it is required to install and run
these four services before deploying the SLA Negotiator.
Installation
The SLA Negotiator
must be deployed on GT4 WS Core Container.
The address of the
Resource Management service (SRLM), SATSLA Repository Service, SLA
Translator and the SLA Repository service need to be specified in
the server config file
(%GLOBUS_LOCATION%/etc/brein_negotiation/server-config..wsdd),
for example like shown below.
<deployment: name="defaultServiceConfig">
<parameter name="sla.repository.url "
value=
"http://localhost:8080/wsrf/services/Brein/sla-repository" />
<parameter name="sla.translator.url "
value= "http://localhost:8085/SLATServlet-2.0/slat"
/>
<parameter name="sat.sla.repository.url"
value= "http://thrym.atosorigin.es/SATSLARepository/SATSLARepositoryService.asmx"
/>
<parameter name=" srlm.url"
value=" http://autonomic.ac.upc.edu:18080/SrlmWsit/SrlmService?wsdl"
/>
</deployment>
Standard deployment leads to the services being available on the
local host under the following addresses:
http://localhost:8080/wsrf/services/Brein/sla-neglotiation/AgreementFactory
http://localhost:8080/wsrf/services/Brein/sla-neglotiation/Agreement
SLA Repository
Prerequisites
The SLA Repository
relies on a MySQL database.
Installation
The SLA Repository must
be deployed on GT4 WS Core Container.
The SLA Repository relies on a MySQL database. The configuration of
the database shall be specified in the serverconfig file
(%GLOBUS_LOCATION%/etc/brein_repository/server-config..wsdd)
as shown below:
<deployment: name="defaultServiceConfig">
<parameter name="database.driver " value= "com.mysql.jdbc.Driver"
/>
<parameter name="database.user " value= "root" />
<parameter name="database.password " value= "root" />
</deployment>
Before
using the service the operation initRepository() must be called,
which sets up the database tables.
Standard deployment leads to the service being available on the
local host under the following address:
http://localhost:8080/wsrf/services/Brein/sla-repository
SLA Manager
Prerequisites
During
operation SLA Manager needs to communicate with SLA Monitor and SLA
Repository. It is required to install the two SLA components before
deploying the SLA Manager.
Installation
The SLA Manager must be
deployed on GT4 WS Core Container.
The Service endpoints of the SLA Repository service and the SLA
Monitor Service need to be specified in the server config file
(%GLOBUS_LOCATION%/etc/brein_nanager_airport/server-config..wsdd),
the default setting are shown below.
<deployment: name="defaultServiceConfig">
<parameter name="sla.repository.url "
value=
"http://angelina.hlrs.de:8080/wsrf/services/Brein/sla-repository" />
<parameter name="sla.monitor.url "
value= "http://angelian.hlrs.de:8080/wsrf/services/Brein/Airport/sla-monitor"
/>
Standard deployment leads to the services being available on the
local host under the following addresses:
http://localhost:8080/wsrf/services/Brein/Airport/sla-manager
|
