Autonomous security management in the VoD use case
Problem:
A critical security update is available for the linux operating system. This alert is a security patch for a required tools of the VoD service. Normally, the system administrator will find all the computer on his network and has to install in the same time the update.
Solution:
With the the development of automation in the Pulse software and the ENERGy monitoring and reconfiguration tool, an administrator can automatically see the problem of update and choose a solution to apply.
The ENERGy console proposes some solution to this problem using Pulse. Pulse checks the network and sends the list of the servers where the security update is necessary. Then, an order is sent to the Pulse agents on each machine to download this update and update the servers.
After this, Pulse sends a status to the ENERGy console for the administrator.
Network Service Diagnostic automation
In the telecom approach of the ENERGy project, we are aiming to leverage SOA mechanisms in order to manage the Network Service Diagnostic automation.
Concepts:
BPM jointly with BRE, BAM and WS-*, are the basis to automate the dynamic management of the different network service diagnosis tests in order to compose the optimal combination of testing services to establish the final network failure causes.
Several key issues are considered: dynamic service creation based on WS-BPEL, optimal service composition thanks to the use of QoS principles, security aspects based on WS-Security, asynchronous WS invocation issues resolved through WS-Addressing, business activity monitoring based on BPEL sensors and BRE utilization in order to make BPEL more flexible and dynamic.
Main goals achieved:
Automation of service creation (it has been proved the capability of WS-BPEL in conjunction with a data and information model to automate service creation).
Distributed monitoring and security (BAM+WS-Security have been applied to obtain a monitored and securized environment).
SOA applicability for Telecom (BPM+WS-BPEL have been demonstrated as useful and powerful techniques to be applied on the domain).
Web-based management (all the services are Testing Network WS managed remotely).
Tele-Deployment and Tele-Distribution (these techniques are seamlessly integrated within the domain to manage the distribution and deployment of the different services).
MPLS Management
An MPLS network has been deployed on virtualized servers based on the Itanium-2 processor architecture. This is the first implementation of an MPLS stack on Itanium, which has required configurinf a specific Linux kernel patch. Our implementation based on virtualization has proven that the solution can be deployed in most configurations of high-performance servers.
With the development of MPLS VPNs, there is a growing need for ending MPLS paths into high performance servers. This is especially true for large data and computing centers, where hardware resources are shared among several parties.
To give the system a cognitive capability
There is no denying that without a learning and recognizing capability, the system would have been unable to perform any valuable decision. Thats why we have modelized the world (to be specific, the managed Information System) thanks to an ontology. An ontology is a data model that represents a set of concepts within a domain and the relationships between those concepts. It is used to reason about the objects within that domain. The mains concepts represented in our ontology are: the problems which could occur, the available reconfiguration actions and the state of the system or of a service. Lets have a glance:
These concepts are linked by different relationship: a problem make the system to go from a given state to another one. Moreover a problem could be solved by one or many actions
The challenge here consists in describing our system. We have proceeded iteratively, starting from basic problem and making it more and more complex.
Considering that our ontology is well described enough, a question was put on hold: how to merge the theoretical representation of our world with the real oneω
The first step consists in discovering the system capacities: all the known reconfiguration actions (in our case these actions are actually played by semantically annoted Web Services) are listed (providing that the known things are those which are described in our ontology).
Then, the business services are described. As a matter of fact a mapping is done between a business service and our modelized world. It will allow us getting linked concepts of this given service and more especially what kind of reconfiguration actions are available.
Next is the system state description: different states are listed, and a link between an action and two different states is done. Hence we know that such an action will change the system from a state to another one.
Finally when a problem occurs on the system we specify as far as possible this problem as an instance of a known problem in our knowledge base. Here the most needed information is the scope of the problem. No denying that an IPTV reconfiguration action cant solve an http server problem for instance. At that time the system is able to link a problem with the impacted service and to retrieve all the available actions if the system is in this given state.
Find the path from a system's state to a better one
Once the knowledge base is populated with available actions, known problems, possible states of the system, the problem must be solved! That is to say that a sequence of actions must be find to be able to leave from a problematic state and to move the system until a better one. At this stage an inference engine is used. Thanks to its internal backtracking ability, this kind of engine is able to test different actions and come back if it doesnt work until a correct succession of action could be found. The algorithm principle is simple: that a walk through a state graph:
Thus, the inference engine is able to find all the different paths to go from a point to another one: these paths represent the possible reconfigurations workflows.
Finally, a last processing give a note to each solution, considering different parameters like the number of required actions, the estimated time to perform such a solution or even the brought upon risk.
Running the workflow
Assuming that a solution has been previously calculated, the system must unfold the corresponding workflow. For that we are using at first a Web Service feature : the autodescription. As soon as a Web Service has been found, all the necessary information to invoke an exposed method are available. Hence the input and output parameters, the name of the method could be retrieved and finally thanks to a less known java property, namely the reflection, a Web Service could be dynamically invoked. In brief, no need to generate any static client for a Web Service, a dynamic one could be used. Two use case are mainly used in our demonstrator:
The monitoring case: in that case, all the Web Services semantically annoted as able to give monitoring information are listed. They could be simply invoked and, providing that the return parameter in a numeric one, some graphs could be automatically generated to display the performance evolution for instance.
The reconfiguration case: in that case the Web Services are semantically annoted to indicate a reconfiguration capacity. For each step of the reconfiguration workflow, such a Web Service is invoked.
The decision engine must respect the law
In addition to these reconfiguration process, a policy based management has been setup. These policies are used with two different goals:
Firstly, when an event occurs, we compare it with our predefined policy to determine if this event has to be considered as a problem or just as an information event. Consider the following event: The used bandwidth between A and B is 70. According to the preset policies this event could become a problem if the policy tells the used bandwidth must not overcome 60 These kind of policies are obviously used prior to the problem processing.
Secondly, when the decision engine whish to stop an application to install a major and severe security patch for instance, it could be compelled by a rule like the following one: A high availability service cant be stopped. As a result if the service is characterized as a very important one, the decision engine will have to find another solution...
