Automate virtual machine discovery and self-connectivity

Use plug-and-play to discover and connect virtual machines

In a virtual data center the deployment and the dismissal of complex appliances require that multiple configuration steps be executed. Reconfiguration requirements include establishing and removing communication between different components of the same product running in different virtual machines (VMs) as well as different products running in different VMs. Traditionally this process has been burdensomely manual or somewhat inflexible via the invoking of predefined scripts with static values. In this article, the authors propose StereoCable, automated plug-and-play support of complex virtual appliances in a virtual data center, to solve this issue. This way VMs are able to discover and automatically connect to each other based on predefined connections policies.

Share:

Giuseppe Ciano (pino.ciano@it.ibm.com), Chief Designer of Tivoli Cloud Solutions, IBM

Giuseppe Ciano joined IBM in 1997 as a software engineer in the Rome SWG Tivoli Lab. He as been working for 11 years as developer and designer of different products in the Tivoli portfolio. He is currently chief designer of Tivoli Cloud Solutions like IBM Service Delivery Manager product. He is also the designer of StereoCable.



Maurizio Simeoni (maurizio.simeoni@it.ibm.com), Staff Engineer, Tivoli, IBM

Maurizio Simeoni graduated in telecomunications engineering at the University of Roma "La Sapienza". He is a staff engineer at IBM Rome Tivoli. He currently works on IBM Service Delivery Manager. He has over 10 years of experience in developing and supporting software applications. He contributed to the design and development of StereoCable.



Alessio D'Amico, IT Architect for IBM Tivoli Services, IBM

Alessio D'Amico joined IBM in 1999 as a software engineer in the Rome SWG Lab. During his career, he gained experience in the full project life cycle from project management, business analysis, design and build through implementation. Currently he is responsible for designing and implementing the service management and cloud computing solution based on the Tivoli products portfolio. His main areas of expertise cover system management, provisioning, service management, virtualization, and cloud computing.



Dr. Antonio Perrone (antonio.perrone@it.ibm.com), Senior Software Engineer, IBM

Antonio Perrone graduated cum laude in information sciences in 1989 at the University of Bari, Italy. He joined IBM in 1990, where he has held several positions in development and support. He has been with the IBM Tivoli division since 1996, where he is currently an architect in the network performance management area. His interests include systems management, performance and availability, knowledge representation, data integration, transaction and process modeling, and software development.



Luigi Pichetti, Senior Technical Staff Member, Tivoli, SPDA, IBM

Luigi Pichetti is the Tivoli architect for CloudBurst and for IBM Service Delivery Manager, solutions that offer services and benefit of virtual appliance initiatives. He leads the image-based installation initiative which aims to leverage virtualization technologies like the Activation Engine and StereoCable as alternate, efficient means to ship products. Luigi has 19 years of experience in developing and designing enterprise applications in the system-management arena; prior to this, he was lead on the architecture team for Tivoli Configuration Manager and Common Inventory Technology componentry.



Francesco Dauri, Team Leader TWS Test L3, IBM

Francesco Dauri spent a year as DB2 consultant in the Information Management group with a focus on DB2 High Availability, data tuning, and optimization. For four years he worked as software engineer on the Tivoli Workload Scheduler product in the verification team. His skills include the Test discipline (CVT, IVT; SVT, etc.), agile methodology, usability test discipline, and user interface design focusing on the Rich Internet Application using Flex technology.



01 November 2010

Also available in Chinese Portuguese

Virtual appliances are pre-built software solutions that are comprised of one or more virtual machines that are packaged, updated, maintained and managed as a unit. Unlike a traditional hardware appliance, these software appliances let customers easily acquire, deploy, and manage pre-integrated solution stacks. This speeds up time to value and simplifies software development, distribution, and management.

Virtual appliances are changing the software distribution paradigm because they allow application builders to optimize the software stack for applications and deliver a turnkey software service to the end user.

Whereas current virtual appliances contain a single virtual machine (VM) only, modern enterprise applications model service oriented architectures (SOA) with multiple tiers in which each tier contains one or more machines. The single VM model is not sufficient for this kind of application. Distributing multi-tier services in the form of a software appliance requires a complex virtual appliance composed of more VMs that are able to cooperate.

For example, consider a typical web application that consists of three tiers. A web tier that implements the presentation logic, an application server tier that implements the business logic, and a back-end database tier. A straightforward implementation would divide this into three virtual machines, one for each tier. In this way, the application can scale from the fraction of a single physical host to three physical hosts.

In a virtual data center the deployment and the dismissal of complex appliances require multiple configuration steps to be executed in order to get the virtual appliance up and running:

  1. Reconfiguration needed to assign OS-specific parameters like network information: IP, hostname, passwords, etc.
  2. Reconfiguration to establish/remove the communication between:
    • Different components of the same product running in different virtual machines.
    • Different products running in different virtual machines.

What's an activation engine?

An activation engine is software embedded in the virtual appliance that is activated during the first boot of the appliance following deployment.

For examples that use this virtual machine activation engine concept in several technologies, take a look at:

The first problem described in the bullet point list is addressed with the activation engine technology, software embedded in the virtual appliance that is activated during the first boot of the appliance following deployment. The activation engine and customization plug-ins can be written and provided to configure the virtual appliance to the target system.

The problem described in the second bullet hasn't been addressed. Today, reconfigurations are performed manually or by invoking predefined scripts with static values in input. We propose plug-and-play support of complex virtual appliances in a virtual data center to solve this issue. In this way the virtual machines will be able to discover and automatically connect one to the other based on some predefined but more flexible connections; StereoCable is complementary to the Activation Engine and can easily coexist with it. In fact the AE can be exploited to automatically configure the StereCable at boot time.

Design principles of StereoCable

Before describing the system architecture and the flow, let's introduce a key concept of this article, the concept of StereoCable.

Defining StereoCable

StereoCable is an artifact that describes how to establish role-based cooperation between two entities running in different virtual machines, for example:

(PRODA_UI,PRODA_SERVER) ... (PRODA_SERVER,PRODB_SERVER) ... (PRODA_UI,PRODB_SERVER)

A StereoCable artifact is made of two parts (which we will refer to as roles):

  • The socket role. The socket describes the information that needs to be provided by an entity to establish cooperation with another entity. When a VM is assigned a socket role in a particular environment, it publishes the information required by the socket definition.
  • The plug role. The plug describes the actions that need to be executed by an entity in a VM to establish cooperation with another entity running in a different virtual machine When a VM is assigned a plug role in a particular environment, it:
    1. Locates a VM playing the corresponding socket role in the same environment
    2. Retrieves the published socket information
    3. Executes the action described in the plug definition.

To represent a StereoCable artifact, an XML schema has been defined. Listing 1 is an example of StereoCable information:

Listing 1. StereoCable information in XML
<StereoCable>
  <StereoCableID>StereoCableID1</StereoCableID>
    <Description>PRODA UI Automatic Reconfiguration</Description>
    <PlugSection>
      <Description>PRODA UI Server</Description>
      <PlugID>PRODA_UI</PlugID>
      <ConfigurationActions>
        <ConfigurationAction>
          <Description>Description</Description>
          <ID>ID</ID>
          <Trigger>Deployment</Trigger>
          <Action>
            <ActionType>script</ActionType>
            <ActionDetail>
              <ConfigurationParameters>
              	<ConfigurationParamter>
              		<ConfigurationName>host</ConfigurationName>
              	</ConfigurationParamter>
              	<ConfigurationParamter>
              		<ConfigurationName>port</ConfigurationName>
              	</ConfigurationParamter>
              	<ConfigurationParamter>
              		<ConfigurationName>name</ConfigurationName>
              	</ConfigurationParamter>
              	<ConfigurationParamter>
              		<ConfigurationName>user</ConfigurationName>
              	</ConfigurationParamter>
              </ConfigurationParameters>
              <Operation>/pino/driver4/scripts/PRODAUI.sh</Operation>
            </ActionDetail>
          </Action>
        </ConfigurationAction>
      </ConfigurationActions>
    </PlugSection>
    <SocketSection>
      <Description>PRODA Master</Description>
      <SocketID>PRODA_SERVER</SocketID>
      <PublishedParameters>
        <ConfigurationParameter>
          <ConfigurationName>host</ConfigurationName>
          <ConfigurationValue>nc125050.romelab.it.ibm.com</ConfigurationValue>
        </ConfigurationParameter>
        <ConfigurationParameter>
        	<ConfigurationName>port</ConfigurationName>
        	<ConfigurationValue>31117</ConfigurationValue>
                     </ConfigurationParameter>
        <ConfigurationParameter>
        	<ConfigurationName>name</ConfigurationName>
        	<ConfigurationValue>PRODA-istributed</ConfigurationValue>
</ConfigurationParameter>
        <ConfigurationParameter>
        	<ConfigurationName>user</ConfigurationName>
        	<ConfigurationValue>PRODA85mdm</ConfigurationValue>
</ConfigurationParameter>
      </PublishedParameters>
    </SocketSection>
</StereoCable>

StereoCable components

Figure 1 illustrates the components of the StereoCable system.

Figure 1. StereoCable components
StereoCable components

The StereoCable system is comprised of:

  • StereoCable Engine: A software entity loaded in the VM to process assigned roles according the StereoCable information expressed in XML format. This engine is also able to process VM events: For example, the deployment of a new VM or the removal of an already existing VM in order to take proper configuration action.
  • StereoCable Registry: A repository that keeps track of available sockets and provides them to plugs upon request (based on pre-defined constraints). This is not a mandatory element since the VMs in some vendor virtualization implementation can directly publish and share this kind of information.
  • StereoCable User Interface/Command-Line Interface: The software entity used to work with VMs, plug and socket information, and which displays their inter-relationships. The UI can access the information that connects both to the StereoCable Registry and directly to the VMs.

(The StereoCable implementation we provide in this article includes VMware support; specifically, VMware ESX 3.5 and vSphere 4. The activation engines connect using the VMware VI SDK API and the StereoCable Registry is the VMware VirtualCenter. The supported guest operating system is SLES10.)

Next we'll discuss how StereoCable processes actions.


StereoCable processing

Let's look at the two types of processes you'll encounter with StereoCable — the engine startup process and StereoCable's dynamic processing (the automation advantage that a StereoCable artifact has over the traditional VM connection discovery and reconfiguration process). For this section, we thought it would be more clear and concise to offer a series of steps and a flowchart to illustrate the process.

The main steps to StereoCable startup and dynamic processing

The Engine Startup process follows these steps:

  1. StereoCable Engine connect to the registry to retrieve the roles and the StereoCables. This step can include the Registry auto-discovery if the protocol used by the Engine allows it, like for example SLP (service discovery protocol that allows computers and other devices to find services in a LAN without prior configuration).
  2. Retrieve the VM roles and the environments the VM belongs to.
  3. Retrieve the StereoCables related to the VM.
  4. StereoCable Engine processes the StereoCables contained in the StereoCables.xml file.
  5. Disable the overall StereoCable functionality for that VM.
  6. For all the socket roles in the StereoCables.xml, if the socket role is equal to one of the VM roles:
    1. Check if dependency is OK. If not put the socket in a working queue.
    2. Retrieve the socket attributes as described in the XML file.
    3. Publish the socket attributes.
    4. Publish the information that the socket is now active.
    5. Send and event for the published socket.
    6. Put the socket in the StereoCable active table; also specify the information to which socket is connected to.
  7. Enable the overall StereoCable functionality for that VM.
  8. For all the plug roles in the StereoCables.xml; if the plug role is equal to one of the VM roles:
    1. Check if dependency is OK. If not put the plug in a working queue.
    2. Retrieve the related socket information (role, ...) described in the XML file.
    3. Discover the VMs that provide the proper socket and that belong to the same environment.
    4. For all the VMs discovered:
      1. Decide based on the rules defined in the XML file which VM will be selected if multiple VMs have been discovered.
      2. Retrieve the published socket attributes if the status of socket is active.
      3. Invoke the configuration actions; pass the information retrieved as a parameter.
      4. Publish the information; the plug is now active and also describes the information to which socket it is connected.
      5. Send an event for the published plug.
      6. Put the plug in the StereoCable active table specifying the information to which socket it is connected.
    5. If no VM is available or the VM is available but the socket is not active, put the StereoCable in the working queue for processing, specifying the roles and test environment that it needs.

The following steps (they pick up where the previous ones left off) shows how StereoCable dynamic processing works.

  1. Periodically collect StereoCable events (socket created, socket removed, socket updated) and VM-related events (VM deployment, VM dismissal) for VMs with specific roles.
  2. For all the plug roles in the working queue:
    1. If a new VM has been discovered and it publishes an active requested socket
      1. Retrieve the published socket attributes if the status of socket is active.
      2. Invoke the configuration actions, passing them as parameters, from the information retrieved.
      3. Publish the information that the plug is now active, also describing the information for which socket it is connected to.
      4. Remove the plug from the StereoCable working queue.
      5. Put the plug in the StereoCable active table, also specifying the information to which socket it is connected.
      6. Send an event for the published plug.
    2. If a VM is removed from the data center and it publishes a socket currently used by a plug saved in the StereoCable active table:
      1. Invoke the remove-configuration actions by passing the information relating to the socket as a parameter.
      2. Remove the plug from the StereoCable active table.
      3. Put the plug in the StereoCable working queue.
      4. Publish the information that the plug is now inactive and disconnected.
      5. Send an event for the un-published plug.

These steps are described in this flowchart:

How StereoCable does startup and dynamic processing
How StereoCable does startup and dynamic processing

(See a larger image of this flowchart.)

The UI and CLI display the StereoCable connections between the VMs in the data center; they also provide the detailed information about the established connections and the details about the related plugs and sockets.

About StereoCable dynamic processing

Once established, the StereoCable connections are truly dynamic due to the capability of the engine that processes events:

  • This engine is able to process events (like for example socket published or removed) in order to activate, remove, or reactivate a connection.
  • The engine also generates events when a socket is published, updated, or removed in order to notify users of the change.

Figure 2 shows how the engine processes events.

Figure 2. Processing events
Processing events

Creating a StereoCable connection

In this section we'll describe the steps for creating, deploying, establishing, and verifying a StereoCable connection between two products — the former acting as an agent and the latter as a server— installed in different virtual machines. This is just an example of a client-server connection, but StereoCable can be used also to establish server-to-server connections in complex integration scenarios.

Defining a StereoCable connection

A StereoCable connection is made of two parts, the plug and the socket, and it is specified in a XML format. Listing 2 shows the StereoCable connection definition:

Listing 2. StereoCable connection definition in XML
<tns:StereoCablesxmlns:tns="http://ibm.com/stereocables"            
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://ibm.com/stereocables StereoCables.xsd ">
    <StereoCable>
      <StereoCableID>AGENT-SERVER</StereoCableID>
      <Description>Agent Server Connection</Description>
      <PlugSection>
        <Description>Agent Plug</Description>
        <PlugID>AGENT</PlugID>
        <ConfigurationActions>
          <ConfigurationAction>
            <Description>Agent configuration</Description>
           <ID>ConfigurationActionID1</ID>
          <Trigger>Deployment</Trigger>
          <Action>
            <ActionType>script</ActionType>
            <ActionDetail>
              <ConfigurationParameters>
                <ConfigurationParameter>
                  <ConfigurationName>hostname</ConfigurationName>
                </ConfigurationParameter>
                <ConfigurationParameter>
                  <ConfigurationName>port</ConfigurationName>
                </ConfigurationParameter>
              </ConfigurationParameters>
              <Operations>
                <Operation>agent_config.sh</Operation>
                <OS>Linux</OS>
              </Operations>
            </ActionDetail>
         </Action>
       </ConfigurationAction>
      </ConfigurationActions>
    </PlugSection>
     <SocketSection>
       <Description>Server Socket</Description>
       <SocketID>SERVER</SocketID>
       <PublishedParameters>
         <ConfigurationParameter>
           <ConfigurationName>hostname</ConfigurationName>
           <ConfigurationType>ActionBased</ConfigurationType>
           <Action>
             <ActionType>script</ActionType>
             <ActionDetail>
               <ConfigurationParameters>
                 <ConfigurationParameter>
                   <ConfigurationName>hostname</ConfigurationName>
                   <ConfigurationValue>hostname</ConfigurationValue>
                   <ConfigurationType>UserDefined</ConfigurationType>
                 </ConfigurationParameter>
               </ConfigurationParameters>
               <Operations>
                 <Operation>getNetworkConf.sh</Operation>
                 <OS>Linux</OS>
               </Operations>
               <Operations>
                 <Operation>getNetworkConf.sh</Operation>
                 <OS>AIX</OS>
                </Operations>
             </ActionDetail>
           </Action>
        </ConfigurationParameter>
        <ConfigurationParameter>
          <ConfigurationName>port</ConfigurationName>
         <ConfigurationValue>2000</ConfigurationValue>
        </ConfigurationParameter>
      </PublishedParameters>
    </SocketSection>
  </StereoCable>
</tns:StereoCables>

In this example, the plug is the agent and the server is the socket.

The PlugSection specifies the actions executed by the agent/plug for connecting to the server/socket. In the example the script named agent_config.sh will be executed at deployment time taking as inputs the host name and port published by the socket.

The SocketSection describes the information published by the socket, specifically the host name and the port needed by the agent/plug. Notice that hostname is dynamically retrieved running the script getNetworkConf.sh while the port is statically defined in the XML file.

The StereoCables.xml file containing the StereoCable definition will be deployed on both the agent and server machines.

Deploying the StereoCable engines

To deploy the engines, you have to download and unzip the StereoCable Engine files into both the agent and server machine directories. It looks like Figure 3.

Figure 3. Deploying the engines
Deploying the engines

In our example the engine is configured to use a Java™ runtime under the Java directory (in this case Java 2 Technology Edition, Version 5.0, 64-bit Runtime Environment for Linux® on an AMD64 architecture). If you have a different architecture, specify the path in the conf/environment.properties file. Notice that the engine has been tested with Java 2 Technology Edition, Version 5.0 64-bit Runtime Environment for Linux on AMD64 architecture.

Deploying the StereoCables

Next, copy the StereoCables.xml file into the data directory (Figure 4).

Figure 4. Deploying the StereoCables
Deploying the StereoCables

Defining the roles

Specify the roles of each machines in the conf/stereocables.properties file.

Figure 5. Defining the roles
Defining the roles

In the server machine, edit the sockets key to reflect sockets=SERVER. In the agent machine, edit the plugs key to reflect plugs=AGENT.

Defining the environment

On both the agent and server machines, specify the same environment: environment=TEST.

Now, start your engines

To start the engines, do a series of registering them before running them.

To register the server machine:

$./vEngine.sh -reg
CTJES0003I Loading configuration.
CTJES0004I The configuration has been successfully loaded.
CTJES0001I Executing the operation: Registering the engine.
CTJES0002I Operation successfully executed: Registering the engine.

To run the server machine:

$./vEngine.sh -run

CTJES0003I Loading configuration.
CTJES0004I The configuration has been successfully loaded.
CTJES0001I Executing the operation: Run the engine.
CTJES0001I Executing the operation: Cable processing.
CTJES0005I Processing socket: SERVER.
CTJES0011I Publishing information.
CTJES0013I Sending event: Socket SERVER published.
CTJES0019I Processing event's type: STEREOCABLES_SOCKET_PUBLISHED.SERVER.
CTJES0020I Event processed.
CTJES0006I Socket SERVER successfully processed.
Socket processed:
  SERVER: Success
Plug processed:

CTJES0002I Operation successfully executed: Cable processing.

To register the agent engine:

$./vEngine.sh -reg
CTJES0003I Loading configuration.
CTJES0004I The configuration has been successfully loaded.
CTJES0001I Executing the operation: Registering the engine.
CTJES0002I Operation successfully executed: Registering the engine.

To run the agent engine:

$$./vEngine.sh -run
CTJES0003I Loading configuration.
CTJES0004I The configuration has been successfully loaded.
CTJES0001I Executing the operation: Run the engine.
CTJES0001I Executing the operation: Cable processing.
CTJES0005I Processing plug: AGENT.
CTJES0011I Publishing information.
CTJES0013I Sending event: plug AGENT published.
CTJES0019I Processing event's type: STEREOCABLES_PLUG_PUBLISHED.AGENT.
CTJES0020I Event processed.
CTJES0006I Plug AGENT successfully processed.
Socket processed:
  
Plug processed:
   AGENT: Success

CTJES0002I Operation successfully executed: Cable processing.

Verifying the connections

It is possible to list the information published and the StereoCable connections available in the environment by running the command $script/Cli.sh -list.

CTJES0003I Loading configuration.
CTJES0004I The configuration has been successfully loaded.
CTJES0001I Executing the operation: Discovery machines.
CTJES0002I Operation successfully executed: Discovery machines.

-------------------------------------------------------------------
srv.ivm.com
-------------------------------------------------------------------
guestInfo.stereocables.env = TEST
guestInfo.stereocables.status = Enabled
guestInfo.stereocables.sockets = SERVER

guestInfo.stereocables.socket.SERVER.status=Active
guestInfo.stereocables.socket.SERVER.hostname=srv.ivm.com
guestInfo.stereocables.socket.SERVER.port=2000

guestInfo.stereocables.plugs =

-------------------------------------------------------------------
-------------------------------------------------------------------
agt.ivm.com
-------------------------------------------------------------------
guestInfo.stereocables.env = TEST
guestInfo.stereocables.status = Enabled
guestInfo.stereocables.sockets =

guestInfo.stereocables.plugs = AGENT
guestInfo.stereocables.plug.AGENT.status=Active
guestInfo.stereocables.plug.AGENT.connected=srv.ivm.com:SERVER

-------------------------------------------------------------------

As you can see, in the TEST environment, the machine agt.ivm.com is plugged into the srv.ivm.com.


In conclusion

The next step

To go further with automated VM discovery, configuration, and connection, we suggest you download the StereoCable zip file and read the other two developerWorks articles mentioned in this article.

We've enjoyed showing you a new concept — a way that virtual machines in a virtual data center can discover and automatically connect to each other based on predefined connections policies — and introducing you to a project we've been working on that you can use to enable such a system.

Remember, virtual appliances have the power to change how software is distributed because they can give application builders the ability to optimize the software stack for applications and deliver a turnkey software service to the end user. One key step to achieving that level of service in a cloud application is by automating, and thereby enhancing, virtual machine connections.


Download

DescriptionNameSize
Sample code for this articlestereocable.zip10KB

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Cloud computing on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • developerWorks Labs

    Experiment with new directions in software development.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Cloud computing, Linux, Java technology
ArticleID=563130
ArticleTitle=Automate virtual machine discovery and self-connectivity
publish-date=11012010