Teach you to use Tsam extensions to manage Java EE applications

The Tivoli Service Automation Manager 7.2.2 introduces the concept of extension, a set of Tsam software components that can add more functionality to the Tsam platform. An extension is usually (but not limited to) the following features:

A new IT service Automation solution can be implemented, known as a service definition in Tsam; for example, a storage-as-service solution can provide a home directory for students in a university.

You can add functionality to an existing service definition, for example, extending the out-of-the-box Tsam to a service solution that enables it to connect more disks than the boot disk to the virtual machine.

These extensions were developed and released by IBM or the customer service team outside the Tsam development cycle. Extensions developed by IBM are published in the integrated Service Management Library, which is provided free of charge to Tsam customers, with installation and configuration documentation and an IBM-standard user Guide. IBM Tivoli Service Automation Manager Information Center is the entry point to get the online documentation for these extensions from IBM.

Of the many extensions that IBM publishes, two extensions allow you to manage the configuration of network devices, adding security, scalability, and redundancy to virtual server projects 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 function of the Juniper SRX Firewall extension is to automatically limit the virtual servers configured in the SRX project through a set of default rules in vlan/subnets protected by the Juniper Tsam Enterprise firewall. During the life cycle of the project, cloud administrators can further optimize firewall rules through a service provided by the Modify Firewall rules extension. During the initial setup of the extension, the default rules can be customized according to the customer's requirements.

The extension of the F5 Big-ip load balancer can put a "virtual load balancer" into a configured virtual server in the Tsam project to enhance the scalability and redundancy of the applications installed on the server: by creating a Load balancer Policy, you can Publish the application in the public Virtual IP address (VIP) of the vlan/subnet of the Tsam project. The Load balancer Policy can be identified by a vip:port that is connected to the application, or by a virtual server cluster that runs the application's Tsam project.

These features enable enterprise customers to provide tiered business applications (such as Java EE applications) to their branch offices, business partners, and customers, and the process is fast, secure, repeatable, scalable, and redundant.

A scenario defined in deploying the Java-EE application using the Tsam extension is the goal of securely deploying a three-tier Java EE application into the cloud and demonstrating how to set up and configure the extensions in Tsam to complete the deployment; We recommend that you read this article to get a more complete picture of the methods described in it.

This article describes how to adjust the load balancer's policies based on your system requirements, how to add and remove application servers when the workload of business applications changes, how to modify firewall rules, and why you need to do so.

Quick Scene Review

Customer ABC is an enterprise that runs private (enterprise-internal) cloud solutions, based on Tsam 7.2.2, Juniper SRX Firewall extensions, and Big-ip F5 Load balancer extensions. ABC provides services to branch offices, business partners and customers through the Tsam platform. ABC relies heavily on the out-of-the-box features of the platform, providing WEB applications to customers through the HTTP/HTTPS standard protocol.

A typical WEB application used by ABC is a Java EE application with HTTP servers, application servers, and database servers. In traditional deployments, these servers are logically isolated from each other through routers and firewalls, and routers and firewalls restrict network connectivity and access to the server. The database server typically accesses data from a secure storage area.

If you do not download the Firewall and Load balancer extensions, ABC will have to establish its own process to isolate servers on different network segments and to balance requests to application servers, which are typically deployed as a cluster. But ABC is a sensible customer, and because it already has big-ip F5 and Juniper SRX network devices, it has decided to set up a tsam extension to standardize the layout of its Web applications.

Now let's explore load balancing and network firewall rules.

Introduction to load Balancing

The Tsam extension of the Big-ip F5 Load Balancer provides a number of services that balance workloads between application servers in business applications. The sister article of this article describes the steps required to achieve this during initial deployment (where the Java application is deployed using the Tsam extension), but the article does not detail the properties of the load Balancer policy.

Although you retain the default values when you deploy your business application in your test lab, you need to better understand the implications of these properties when deploying it to clients, because choosing the right load balancer policy can have a significant impact on performance and resource consumption.

So let's start by learning how to customize the load Balancer policy.

Custom Load Balancer Policies

After the initial deployment is complete, you can use the Modify load Balancer Policy service to modify the load Balancer management workload at any time, and the service actually needs to use the same parameters as the Create load Balancer Policy (different is the policy's name and Vip:port properties cannot be modified.

The Load balancer policy is an internal artifact defined by the Big-ip F5 load Balancer Tsam extension that contains the information needed to implement the optimal configuration for the BIG-IP device. Its responsibility is to simplify as much as possible the task of the business application requester, and then hide the complexity of the BIG-IP device into several intuitive parameters that allow the extended code to automate BIG-IP configuration steps.

Considering that the requester of a business application needs to perform operations without using the Load Balancer policy abstraction, you can think of a configuration file as a setup container that defines the behavior of network traffic in a BIG-IP device (for example, HTTP), and each setting supports a specific attribute. Examples of these features include:

To insert a header into an HTTP request

Compress HTTP Server response

Application authentication

Connection pool, etc.

The Load Balancer Policy abstraction automatically identifies the configuration file that best fits the BIG-IP device based on the following:

Traffic type (protocol 1 in Figure 1): HTTP, HTTPS, TCP, and UDP.