Deploy a J2EE app with TSAM extensions

Securely deploy a three-tier enterprise application to the cloud

IBM® Tivoli® Service Automation Manager (TSAM) 7.2.2 introduces the concept of extension, a set of TSAM software components that can implement a new IT service automation solution (known as a service definition) or add capabilities to existing service definitions. In this article, the authors define a scenario in which the desired result is to securely deploy a three-tiered enterprise application (in this case J2EE) to the cloud. They demonstrate how to set up and provision extensions in TSAM as the first step to accomplishing this task.

Share:

Michele Crudele (michele.crudele@it.ibm.com), Software Architect, IBM

Michele Crudele is a software architect working in the IBM Software Group's Tivoli Lab in Rome. He has 20 years of IT experience, mostly focusing on the development of systems management products and solutions. Michele has broad technical experience from working on different disciplines, such as change configuration management, monitoring and availability management, IBM autonomic computing technologies, and digital asset management for the publishing industry sector. Currently Michele is focusing on cloud computing solutions and is the lead architect of the TSAM extensions.



Fabio Cerri (fabio.cerri@it.ibm.com), Software Designer, IBM

Fabio Cerri is a software designer working in the IBM Software Group's Tivoli Lab in Rome. He has 12 years of IT experience, mostly focusing on the development of systems management products and solutions. Fabio has broad technical experience from working on different disciplines, such as change/configuration management, software license management, and cloud computing solutions as the lead designer of the TSAM network and storage extensions.



26 January 2012

Also available in Chinese Japanese

Tivoli Service Automation Manager (TSAM) 7.2.2 introduces the concept of extension, a set of TSAM software components that adds more capabilities to the TSAM platform. An extension usually (but isn't limited to):

  • Can implement a new IT service automation solution, which in TSAM is called service definition; for example, a storage-as-a-service solution to offer home directories to the students of a university.
  • Can add capabilities to existing service definitions; for example, extend TSAM out of the box as a service solution enabling it to attach extra disks to virtual machines in addition to the boot disk.

Extensions are developed and released outside the development cycle of TSAM by IBM or by Customer Services Teams. Extensions developed by IBM are released on Integrated Service Management Library free of charge for TSAM customers; they come with installation and configuration documentation, and a user's guide that follows IBM standards. IBM Tivoli Service Automation Manager Information Center is the entry point for online documentation of the extensions released by IBM. (See Resources.)

Among others, IBM has released two extensions that allow managing the configuration of network devices for adding security, scalability, and redundancy to projects of virtual servers created with TSAM:

  • IBM Tivoli Service Automation Manager 7.2.2 extension for Juniper SRX Firewall
  • IBM Tivoli Service Automation Manager 7.2.2 extension for F5 BIG-IP Load Balancer

The Juniper SRX Firewall extension delivers the possibility to automatically confine the virtual servers provisioned with a TSAM project in a VLAN/subnet protected by the Juniper SRX enterprise firewall using a set of default rules. Firewall rules can be further refined by the cloud administrators during the life cycle of the project using a service offering provided by the Modify Firewall Rules extension.

The default rules can be customized during the initial setup of the extension, based on the customer's needs (see Figure 1).

Figure 1. Extensions for firewall and load balancer
Extensions for firewall and load balancer

The extension for F5 BIG-IP Load Balancer delivers the possibility to put a "virtual load balancer" in behind the virtual servers provisioned with a TSAM project to augment the scalability and redundancy of the applications installed on the servers. An application can be advertised at a public Virtual IP address (VIP) in the TSAM project's VLAN/subnet by creating a load balancer policy.

A load balancer policy is identified by the VIP:Port to reach the application and by the cluster of virtual servers of the TSAM project that run the application (see Figure 1).

These features enable the ability for an enterprise customer to provision tiered business applications (like a J2EE application) to his branch offices, business partners, and clients in a fast, reproducible, secure, scalable, and redundant way.

This article describes how a J2EE three-tiered application can be provisioned leveraging the out of the box capabilities of the TSAM extensions for firewall and load balancer: it examines a typical use case. TSAM may or may not provide the tools to tailor a custom solution to handle a customer's needs. This article concentrates on the out of the box capabilities to demonstrate how a customer can quickly set up a private cloud solution using the TSAM platform.

The scenario

The customer ABC is an enterprise who is operating a private (on-premise) cloud solution based on TSAM 7.2.2 and the extensions for Juniper SRX Firewall and BIG-IP F5 Load Balancer. ABC provides services to branch offices, business partners, and clients through the TSAM platform. In particular, ABC heavily counts on the out of the box capabilities of the platform to provision web applications to clients accessible over http/https standard protocols.

A typical web application ABC uses is a three-tier J2EE application with an http server, application server, and database server. In a traditional deployment, these servers are logically isolated from each other by routers and firewalls that limit the network connectivity and access to the servers. The database server usually accesses its data from a secure storage zone (see Figure 2).

Figure 2. The typical J2EE application deployment
Typical J2EE application deployment

Without downloading the extensions for firewall and load balancer, ABC would have to set up its own processes for isolating the servers on different network segments and for balancing the requests to the application servers which are usually deployed to form a cluster. But ABC is a wise customer so, since it already has BIG-IP F5 and Juniper SRX network devices, it decides to set up the TSAM extensions in order to standardize the layout of its web applications (as displayed in Figure 3).

Figure 3. The standardized model of J2EE application deployment
Standardized model of J2EE application deployment

In the standardized model:

  • All the servers are provisioned as part of a TSAM Virtual Servers Project, based on different virtual images — application server and database server.
  • The database server is configured on the internal VLAN/subnet which is unique in the ABC network since it is not routable and firewall protected. It is also provisioned with a vNIC in the storage VLAN/subnet to access the data disks.
  • The application servers are configured on a VLAN/subnet automatically reserved when creating the TSAM project that hosts the web application: The project VLAN/subnet. When creating the TSAM project, a VIP for the web application is also reserved on the project VLAN/subnet and default firewall rules are also set to isolate it from other network segments. Only http traffic from DMZ is allowed. Everything is automatically done by the TSAM extensions for firewall and load balancer.
  • The application servers are also provisioned with a vNIC on the internal VLAN/subnet where the database server resides.
  • Finally, note that there is no need to deploy load balancing software appliances: BIG-IP F5 is used instead and automatically configured during the provisioning of TSAM project.

Anytime ABC must deliver a new application XYZ to its clients, as result of development and quality assurance activities, the QA team prepares the virtual images for the database and the application server (by capturing the virtual images from physical server) and registers them with TSAM (details of this activity are explained later in this article): XYZ database server, XYZ application server.

Note: There is the possibility to set up a virtual development and QA environment using the same TSAM instance leveraging the multi-tenancy capabilities. ABC could create a tenant (called a customer in TSAM terminology) for hosting internal development and test projects. The TSAM extension for Juniper SRX Firewall automatically creates a security zone on the firewall to shield all the development projects from the external world and from production projects, the Internet-facing ones. With such a setup, the QA team would simply promote the virtual images to, let's call it, the production tenant. From that point on, the XYZ database server and XYZ application server virtual images are ready for the next step.

Once the virtual images have been properly set up, the web application XYZ can be requested through TSAM standard service offerings as follows:

  • Request a project of virtual servers named XYZ application and add the database server based on the virtual image, for example, Linux® Red Hat, DB2®, XYZ database instance pre-configured software stack.
  • Once the request is fulfilled (the project VLAN/subnet is reserved and properly configured on the firewall and the database server is provisioned), add one or more virtual servers to the XYZ application project based on the XYZ application server image.
  • Finally, once the request is fulfilled (the applications servers are provisioned), advertise the XYZ application to the web by creating a load balancer policy, VIP:Port, associated with the XYZ application servers provisioned.

And that is what is covered in detail in the remaining sections of the article. First let's discuss the network, security, and scalability and redundancy designs.

Network design

The proposed network design is a common pattern for deploying multi-tiered application; its goal is to maintain a good level of isolation among the different components implementing the tiers and to effect the ability to configure each component with its own specific network connections.

The enterprise network is divided in five main areas hosting different services and implementing different connectivity and security requirements. They are designed to not communicate with each other because of the router and firewall configuration. The network areas represent five different bus services. When a client requires a service from the area, then it has to configure a vNIC into the area bus.

Here are the specifications of the five network areas:

  • DMZ. This network area isolates the Internet from the internal enterprise network and it includes the routing to the Internet. All the clients able to connect to the DMZ can then access the Internet.
  • Public network area. This network area is routed to the DMZ and then to the Internet. The main difference with the DMZ is that this network area includes VLAN/subnets to be used with TSAM projects to control their Internet access by means of a dedicated firewall. The design assumption is to assign a dedicated VLAN/subnet to each TSAM project.
  • Private network area. This network area is not routed to the DMZ; it grants access to critical and sensible data. The design assumption is to configure a single VLAN/subnet for all the clients accessing the private area. As a consequence, the virtual servers provisioned by TSAM and requiring private bus access will have a vNIC in that single subnet even if they belong to different projects.
  • Storage network area. This network area is not routed to the DMZ; it grants access to the storage services. It's a common pattern to have a dedicated storage network because it allows better control for access and usage of to the storage resources and because of the storage network's unique requirements for performance. The design assumption is to configure a single VLAN/subnet for all the database servers accessing the storage area.
  • Management network area. This network area is required by TSAM to access the manageable entities; the hypervisor, the virtual servers, and the firewall and load balancer devices have to be connected to the management network. This network area is not routed to the DMZ. The design assumption is to have a couple of routable VLANs/subnets building the network area: The first VLAN/subnet is dedicated to configure all the static devices (TSAM server, load balancer, firewall, and the hypervisors); the second VLAN/subnet is designed to host all the provisioned servers.

By including the management elements, this completes the picture of the standardized model of deployment you saw in Figure 3. Figure 4 shows that completion.

Figure 4. Complete network design of the TSAM solution to deploy a standardized J2EE application
Complete network design of the TSAM solution to deploy a standardized J2EE application

It's important to note that the out of the box solution leverages the network resources (subnets, VLANs, etc.) to deploy and configure the multi-tiered application but does not provision them. The subnets and the VLANs must be pre-configured in the network infrastructure and then registered with TSAM on behalf of the solution.

This is not the only option allowed by TSAM. It is possible to exploit TSAM by extending it and plugging in custom code to dynamically allocate and register such resources. That's beyond the scope of this article.

Table 1 summarizes the routing between the different subnetworks.

Table 1. Summary of the routing between the different subnetworks
SubnetsPublicPrivateManagementStorageDMZ (Internet)
PublicYESNONONOYES
PrivateNOYESNONONO
ManagementNONOYESNONO
StorageNONONOYESNO
DMZ (Internet)YESNONONOYES

Table 2 summarizes the network interfaces (IPs on the subnetworks) required by each component of the solution.

Table 2. Network interfaces required by each component
Application serverDatabase serverTSAMFirewallLoad Balancer
PublicYESNONOYESYES
PrivateNOYESNONONO
ManagementYESYESYESYESYES
StorageYESYESNONONO

Finally, Figure 5 represents the physical configuration to implement the described the network design.

Figure 5. Physical network layout
Physical network layout

Security design

The security design of the solution mainly applies to the control and management of the network traffic in and out of the subnets hosting the web application servers.

In the network design section, we identified five different network areas representing "network domains" where different services are available. The assumption is to have such network areas not communicate with each other. A client can access the services provided by a network area only by having a vNIC connected to it (an IP in one of the subnetworks representing the area as described in Table 2).

This security requirement can be achieved in different ways:

  • Configuring the routers of the network infrastructure to not route among the areas.
  • Using the firewall to enforce segregation among routable areas.

Depending on the actual network design, some combination of the two options will be the optimal choice. We used the firewall to enforce segregation among the network areas.

Once they are defined, the security requirements of the solution can translate the five network areas in five different security zones as show in Figure 6. This illustrates the mapping between security zones and network areas and highlights how rules can be defined to control traffic between a pair of zones.

Figure 6. Five security zones
Five security zones

A security zone defines a boundary where traffic is subjected to policy restrictions as it crosses to another region of the network. More specifically, a security zone is a collection of one or more network segments requiring the regulation of inbound and outbound traffic through policies. Zones always work in pairs since control is established on the traffic moving from a zone to another.

To simplify the solution, we assume that the boundaries between the DMZ and the public network area are critical to enforce a good level of security. It's also relevant to allow us to easily and frequently change the configuration of the traffic rules between these two zones in order to satisfy requirements for different web applications.

However, we also thought that all the other zones could be statically configured with a pre-defined set of traffic rules that we would only modify on a rare occasion — in other words, use both methods where they make the most sense. This method allows us to submit to the control of the TSAM firewall extension in only the zone pair of the public network area and the DMZ.

You can overcome this simplification by submitting the other zone pairs to the control of the TSAM firewall too. The configuration of these zones follow the same steps described for the simplified case.

Scalability and redundancy design

A common use for multi-tiered applications is to implement Internet services. The scalability and redundancy are key requirements for applications advertising an Internet service and there are different common design patterns widely accepted to implement them.

There are different components of a multi-tiered solution when designing for scalability and redundancy — the most important two are the persistence layer (mainly the database) and the business logic layer (mainly running on an application server).

We're going to focus on the business logic layer which usually executes expensive and performance-demanding operations.

Once again, we refer to a common pattern widely used in real scenarios: A load balancer front end is accepting incoming requests from applications, forwarding them to the business logic layer. The business logic layer is then implemented by more nodes, each one a virtual server running the same software stack (including the application server and the specific application software).

While Internet users access public URLs of the application pointing to the public IP advertised by the load balancer (VIP), the load balancer itself can spread the requests over the multiplicity of the virtual servers.

The TSAM extension for Load Balancer supports the design and implementation of a scalable and redundant multi-tiered application, automating the task of deployment of the load balancer tier of the application; a load balancer policy is created from TSAM UI to accomplish this task.

Critical parameters influencing the requirements are:

  • List of hosts registered to the policy. This is the list of virtual servers used by the load balancer to spread requests. This list can be changed dynamically by adding and/or removing entries without stopping the application.
  • An algorithm to be used for load balancing, like round-robin, workload, etc.
  • Persistence of the established connections. Once connected to a virtual server, the communication will continue on this channel.
  • Monitoring the components for failure detection.

Setup

Now we're going to describe the one-time step to configure the TSAM platform and the network extensions in order to implement the design solution. The explanation mainly focuses on the extensions' configuration, leaving you to access the TSAM documentation for further details about the basic configuration.

Under the assumption that either the network extensions and the automation packages for F5 load balancer and Juniper SRX firewall have been installed on top of TSAM 7.2.2, the following summarizes the order and the operations required by the configuration steps:

  1. Create the DCM file (Data Center Model) including the network resources (subnetworks, VLANs) used configure the connectivity of the provisioned servers.
  2. Import the network resources into TSAM.
  3. Create the DCM file to register the firewall and load balancer devices to be managed by TSAM.
  4. Import the network devices into TSAM.
  5. Create the TSAM network template describing the designed network and all the involved resources.
  6. Import the network template into TSAM.
  7. Configure the network connectivity for the images of the application server and the database server.

The Data Center Model (DCM) is a Tivoli Provisioning Manager component leveraged by TSAM as data model to maintain the resources. The data can be imported into the DCM by means of XML files describing the resources. Let's go into more detail about DCM files.

Network resources DCM file

This file contains the pool of VLANs/subnets making up the five network areas previously described. Any time a new TSAM project is created to host a business application, a VLAN/subnet is reserved from the public VLANs/subnets pool. Any time a new application server is requested for the project, an IP address from the VLAN of the project is reserved.

The same happens for the private VLAN/subnet: Any time a new database server is requested for a project, an IP address from the private VLAN/subnet is reserved.

The network devices other than the firewall and the load balancer must have been configured in advance with the VLANs/subnets. This aspect is not a part of the TSAM extensions subject of this article.

The DCM network resources file does not include the definition of the five areas, but it's simply a list of the VLANs/subnetworks composing them. The DCM lets you describe the building blocks of the network design while the structure of the network will be described in the network template.

These files in NetworkResources.zip in the download section associated with this article contains information pertinent to this topic:

  • The ManagementSubnetworks.xml file describes the management subnetworks. The default route is used to allow routing of traffic to the base management network.
  • In a different vein, the public subnetworks come one per project; the DCM file will include all the resources required for the provisioning of the planned projects. This is described in the file named PublicSubnetworks.xml.
  • The private and storage subnetworks are defined in the file named BaseSubnetworks.xml.

Assuming that all the network resources have been described in the DCM files, then they have to be imported into DCM from TSAM UI as follows:

  1. Login to the TPAE UI as administrator.
  2. Access the Cloud Network Administration application (path is Go To > Service Automation > Configuration).
  3. Select the Import DCM Network Objects and import the DCM files describing the VLANs/subnetworks.

Network devices DCM file

The load balancer and firewall are managed by TSAM extensions leveraging the APIs implemented by the automation packages (F5 BIG-IP, Juniper SRX) imported into the system. To enable the use of those APIs, the firewall and load balancer devices have to be defined in the DCM and must be linked to the specific set of APIs. Again, NetworkResources.zip contains all the files mentioned in this section:

  • The DCM_F5_BIGIP.xml file contains the definition of the load balancer used in the solution: The device is declared to implement the CLF5BIGIPLoadBalancer model in order to link it to the set of APIs previously imported. Note that the file contains two definitions of load balancer devices because of the optional high availability configuration which is handled internally to the F5 BIG-IP Automation package.
  • The DCM_Juniper_SRX.xml file contains the definition of the firewall used in the solution: The device is declared to implement the CLJuniperSRXFirewall model in order to link it to the set of APIs previously imported.

To import the devices, configuration must follow the same steps executed to register the network resources:

  1. Login to the TPAE UI as administrator.
  2. Access the Cloud Network Administration application (Go To > Service Automation > Configuration).
  3. Select the Import DCM Network Objects and import the DCM files describing the network devices.

Network template

The design solution is supposed to address enterprise network requirements. It does not consider TSAM built-in features as multi-tenancy which mainly applies to service provider's scenarios (multi-customer environments). Starting from this assumption, we consider a single customer, the default one named PMRDPCUST configured into TSAM; the network template will describe the designed enterprise network as the network associated the default customer.

The network template describes the structure of the designed network in a way that the TSAM platform and the extensions can consume. It combines the resources defined in the DCM files, highlighting their relationships and collaboration to support the TSAM scenarios. The NetworkConfiguration.xml file provides a sample network configuration for the designed solution.

Figure 7 depicts the hierarchical structure of the network template (or, the network configuration); the figure reports only the elements relevant to the network design of the solution.

Figure 7. The hierarchical structure of the network template, the network configuration
The hierarchical structure of the network template, the network configuration

The network configuration is made of a list of network segments and a list of ANY sections (generic XML entities). The network segment holds all network-related configurations for a single network interface of a virtual server. It describes a part of the network having common requirements such as security and balancing enforced by same firewall and load balancer.

The network template for the designed solution will have four network segments describing the different network areas — management network, public network, storage, and private networks.

The ANY section contains extensions-specific data related to the general configuration of the firewall and load balancer devices. More devices of the types load balancer and firewall can be defined in the network configuration to represent a complex network deployment. Also, each network segment can be managed by a single firewall and a single load balancer; the gateway element of the template is used to represent the devices.

The list of subnetwork elements defined in a network segment represents the pool of subnetworks composing the network area implemented by the network segment (for example, the public subnetworks to be associated to the provisioned TSAM projects).

Finally the Firewall section in the segment describes the configuration of the managed firewall to control the network traffic on the subnetworks belonging to the segment:

  • The Interface represents the device interface to connect the VLAN/subnetwork of the provisioned projects.
  • The Security policy represents the configuration of the traffic rules for the VLAN/subnetwork of the provisioned projects.

Figure 8 is an excerpt from the NetworkConfiguration.xml file describing the definition of the default firewall rules between the public zone and the "untrusted" (DMZ) zone, either inbound or outbound: The specific configuration admits traffic only on ports 80 and 443 (http, https).

Figure 8. Definition of the default firewall rules between the public zone and DMZ zone
Definition of the default firewall rules between the public zone and DMZ zone

To import the network template:

  1. Login to the TPAE UI as administrator.
  2. Access the Cloud Network Administration application (Go To > Service Automation > Configuration).
  3. Select Import Network Template xml and import the XML files describing the network template.
  4. Select the imported template and change the status of the attribute Status of this Network Configuration to ACTIVE.

Once the network template has been imported, you have to create an instance of that template to represent the enterprise network. This is done by assigning the template to the default customer PMRDPCUST as follows:

  • PMRDPCUST must be enabled in order to start working with TSAM, then login to the TSAM self-service UI as cloud administrator.
  • Select the Create Customer offering to enable the default customer.
  • Assign the imported network template as the network configuration for the customer.
  • Submit the request.

Provisioning

This section details the steps for provisioning the XYZ web application, which must be performed any time the ABC customer has to deliver a new web application to his clients.

Step 1: Configure the virtual images for network connectivity

The first thing to do for delivering a new standardized web application is to register the virtual images with TSAM, as mentioned in the section on the scenario. This is done using the Register Image service offering of TSAM. Since the most critical aspect of registering a virtual image is to correctly set up the network interfaces, this section concentrates on that specific process, referring the reader to the TSAM documentation for the overall task.

The objective for the cloud administrator who is registering a virtual image is to define the number and the type of the vNICs that must be configured on a virtual server provisioned from the virtual image as per the network design (Figure 4). Then, the job of the requestor of the virtual server is to appropriately select the network segment on which a vNIC must be configured; he then does that for each vNIC defined.

TSAM helps the cloud administrator to simplify the job of the cloud requestor by classifying network segments and associating a class of segments to vNICs when the virtual image is being registered. The cloud requestor is then directed to the selection of the right network segment, limiting the possibility of errors.

TSAM defines four types of network segments: Management, Storage, Customer, and Backup&Restore. You must classify each network segment in the network configuration file with one of these types.

In addition, a network segment can be further classified with what TSAM calls usages. The usage is a filter usually defined by extensions to qualify segments of the networks that they manage in some way. A network segment can be qualified with one or more usages. The extension for Firewall and the extension for Load Balancer define firewall_extension and loadbalancer_extension usages respectively.

Table 3 describes the type and usage specified for the network segments defined in the network template proposed in this article.

Table 3. Type and usage specified for the network segments
NameTypeUsage
Public-networkCustomerfirewall_extension
loadbalancer_extension
Private-networkCustomer
Management-networkManagement
Storage-networkStorage

Notice that only the public-network segment is managed by the extensions: The firewall extension configures rules with respect to the DMZ and the load balancer extension reserves the VIPs from the segment. The private-network, where the database servers reside, is not managed by the extensions.

Finally, Table 4 describes how the cloud administrator should configure the virtual images to match the network design.

Table 4. Configure the virtual images to match the network design
TypeUsagevNIC on application server imagevNIC on database server image
Customerfirewall_extension
loadbalancer_extension
YESNO
CustomerYESYES
ManagementYESYES
StorageNOYES

Taking as example the application server image, the requestor of such a virtual server must configure three vNICs — one of type "Management" and two of type "Customer."

Since TSAM presents as possible choices only the network segments matching the type and usages associated with the vNICs, then the requestor is forced to select the Management-network segment for the first network interface, the Public-network segment for the second, and finally he is presented with a choice of Public-network and Private-network for the last interface. These are offered because the last vNIC is tagged as Customer type and both segments match that type. So, for the last interface, the requestor has to select Private-network to enable the connectivity with the database server.

Step 2: Create the TSAM project provisioning the database server

The goals of this task are to create a TSAM project to host the web application, configure the firewall to administer the network traffic of the web application, and provision the database server. To accomplish this task:

  • Log into the self-service UI as administrator (cloud or customer/tenant administrator).
  • Select the Create project with VMware servers offering (all types of servers supported by TSAM can be chosen).
  • In the Project Details pane, provide the name of the project (for example, Reimbursement expenses), the team accessing the project, and the time frame for the lifetime of the project representing the application.
  • In the Requested image pane, specify the resource group to be used for the provisioning and the registered image for the database server of the application. Select to provision one single server.
  • In the Server details pane, specify the server resources to support the performance requirements of the database.
  • Depending on how the middleware is deployed and configured on the database image, the Additional software pane can require input parameters to be provided before moving on the next pane.
  • In the Network configuration pane, resolve the network connectivity requirements specified for the database server. As depicted in Figure 9, the three different vNICs are bound to the appropriate network areas specifying the associated network segments.
    Figure 9. vNICs are bound to the appropriate network areas
    vNICs are bound to the appropriate network areas
  • In the Network advanced pane (Figure 10), specify the expected number of virtual servers that will be provisioned into the project: This information is used to select the size of the subnet to be reserved for the project from the Public network pool.
    Figure 10. Expected number of virtual servers that will be provisioned
    Expected number of virtual servers that will be provisioned
  • Check the Enable load balancing check box and then specify to reserve a single VIP to create later the load balancer policy advertising the application.
  • Submit the request.

Step 3: Provisioning of the application servers

The goal of this task is to deploy the application servers required to add the business logic layer to interact with the database. The application server is deployed into the same project hosting the database.

Following is how you accomplish the task:

  1. Login to the self-service UI as administrator (cloud or customer/tenant administrator).
  2. Select the Add VMware servers offering.
  3. Select the just created project (Reimbursement expenses).
  4. In the Requested image pane, specify the resource group to be used for the provisioning and the registered image for the application server of the application. Select to provision the number of server initially required to sustain the foreseeable application requests (we provisioned three servers).
  5. In the Server details pane, specify the server resources to support the performance requirements of the application server.
  6. Depending on how the middleware is deployed and configured on the database image, the Additional software pane can require input parameters to be provided before moving on the next pane.
  7. In the Network configuration pane, resolve the network connectivity requirements specified for the application server. As depicted in Figure 11, the four different vNICs are bound to the appropriate network areas specifying the associated network segments.
    Figure 11. vNICs are bound to the appropriate network areas
    vNICs are bound to the appropriate network areas
  8. Submit the request.

Step 4: Creating the load balancer policy to advertise the application

The goal of the task is to create a load balancer policy on the reserved virtual IP to deploy the http server and load balancing layers of the web application. To accomplish this task:

  1. Login to the self-service UI as administrator (cloud or customer/tenant administrator).
  2. Select the Create Load Balancer Policy offering (Figure 12).
    Figure 12. Create Load Balancer Policy
    Create Load Balancer Policy
  3. From the first pane, select the project just created (Reimbursement expenses) and then click Next.
  4. In the Main settings pane, provide the configuration information of the policy:
    1. Provide a meaningful policy name.
    2. Select the virtual IP from the list of the reserved ones (in this case, just a single IP has been reserved).
    3. Select the class of performance parameters of the policy such as the server type, the connection pool, and the session persistence.
    4. Finally define the health monitor parameters.
  5. Select the list of the virtual servers to be included in the load balancing for the policy. For each virtual server can be specified a port different from the one used by the policy to advertise the web application.
  6. Submit the request.

You'll get a response like that in Figure 13; the list of virtual servers included in the policy for load balancing of the web application.

Figure 13. The list of virtual servers included in the policy for load balancing of the web application
The list of virtual servers included in the policy for load balancing of the web application

In conclusion

The TSAM Extensions for Juniper SRX Firewall and BIG-IP F5 Load Balancer provide you with the ability to deploy complex topologies on TSAM 7.2.2 and thereby achieve security, scalability, and redundancy objectives. After having designed the layout of your network and standardized the topology of your business applications, you are able to quickly advertise those applications to your clients in few steps.

Look for a companion article that explains the following (and more) details of how to manage the life cycle of the business applications:

  • Adding servers as the workload increases.
  • Tuning the policy of the load balancer.
  • Modifying the firewall rules.

Download

DescriptionNameSize
Sample files for this articleNetworkResources.zip6KB

Resources

Learn

Get products and technologies

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, Tivoli, Java technology
ArticleID=788598
ArticleTitle=Deploy a J2EE app with TSAM extensions
publish-date=01262012