To provide the best application performance, reliability,
scalability, and security for J2EE applications, many large
organizations utilize network load-balancing appliances and
application switches. However, coordinating the deployment of
applications between application developers and network managers can
be a slow, painstaking process for companies choosing the many
advantages of the network-based, load-balancing switches.
By developing an application to manage the time-consuming
coordination between these two teams, developers can self-serve their
needs more quickly, network managers can save valuable time
previously spent performing manual tasks, and companies can
experience more flexible application deployment and updates.
Budget-conscious IT departments can also save enormous
amounts of scarce financial resources and time. On a network basis
alone, conservative estimates show that companies can save nearly
$20,000 per network engineer per year in time spent managing this
process by building a very basic application deployment-and-update
application. At the same time, the client experience is improved
through better orchestrated application deployment.
Summarily, an opportunity now exists to help automate the
process of deploying and updating Java applications in order to save
development time, ease frustrations of deployment, and gain
flexibility to deploy new applications on demand while offering the
best client experience.
The Current State of Enterprise Applications
It should come as little surprise to developers that as Web
applications have flourished, so have demands on the application
servers required to deliver them. The days of deploying an
application to one server and hoping it delivers performance and
reliability are a thing of the past.
As a result, applications are typically deployed in a
redundant fashion across multiple identical application servers. This
ensures that the application is available when requested, even if one
application server is out of service or experiencing technical
difficulties. Traditional "load-balancing" solutions help virtualize
a specific application IP address so that when people access a URL or
IP address, the load balancer determines which redundant server is
best suited to accept and respond to the application request.
The advantages of load balancing are significant. Most
serious Web sites and e-business applications today employ some form
of load balancing because it ensures a predictable client experience.
Load-balancing solutions also help increase application performance
by distributing requests to the best performing servers. In some
cases, they can deliver more cost-effective applications due to lower
server license costs and server expenditures.
When it comes to application reliability and load-balancing
options, companies usually consider two alternatives for increasing
the reliability and performance of their applications. One choice is
software load balancing, which is included as a feature with most
Java application servers. In this scenario, application servers help
distribute load by utilizing some form of clustering or "round robin"
load balancing. While this capability is usually included in the
price of application servers, it comes at a cost to server
performance. In many cases, software load balancing can inflict a
20-40% performance hit to each application server running the
load-balancing software.
Alternatively, companies choose hardware solutions that help
provide load balancing and more intelligent IP traffic management to
realize significant advantages while complementing their existing
software clustering. A key advantage to this is extremely high
reliability (99.999% or less than 5.3 minutes of downtime per year).
For applications utilizing HTTPS for security, these devices can also
offer performance optimization such as hardware-based SSL processing
and acceleration. These devices can also provide more intelligent
balancing schemes for complex applications using persistence. In the
event a server goes down, the user session can typically be routed to
the next available server for seamless, transparent application
continuity.
While network devices provide advantages for high
availability, reliability, and performance perspective, there's an
added benefit for application developers and network staff who are
responsible for deploying and updating applications: these devices
provide an ideal control point to help orchestrate application
updates and deployment at the ingress and egress point of all
application requests.
Application Deployment and Update Challenges in the Enterprise
Deploying or updating application components is a topic of
pain and frustration for many companies. While they desire the high
availability, reliability, performance, and security that the
combination of network load balancers and application servers
provides, orchestrating application deployment requires collaboration
between the application and network teams.
Updates require access to servers to perform application
updates and enhancements on a regular basis and usually require
manual intervention by network administrators. Typically, this
process requires application teams to request manual assistance from
the network team to stop servers for updates and then restart them
when updates are completed.
This approach has proven to be a burden for both the network
and application teams. It takes longer to complete updates. There is
an increased chance of human error and deploying new applications
takes too long. To further complicate these matters, update times
must be scheduled during periods experiencing the least amount of
application traffic - commonly 2:00 a.m. on a Saturday morning. In
almost all cases, the manual network procedures can be automated to
shorten application development life cycles, enhance developer
productivity, and roll out applications instantly for the best client
experience.
A contributing factor to this challenge is the limited
information provided by the J2EE specification. The J2EE spec, which
vendors rely upon to build application servers and developer tools,
provides guidance for installation and configuration. But it neglects
to address execution, which is left to the product provider's
platform. While many application server vendors have developed their
own update and deployment capabilities, they are usually proprietary
in nature. When combined with network devices in true enterprise
environments, the combination of limited specifications and
vendor-specific solutions can further complicate matters.
Finding the Solution
An opportunity exists to build intelligent applications that
bridge the gap between the J2EE applications, servers, and the
network that supports them.
When considering application development options, the two
most likely approaches include SNMP and Web services based on
SOAP/XML. While both offer the ability to help automate functions
necessary for deploying and updating applications, SNMP has inherent
security issues. For instance, the only access control available for
SNMP is the ability to restrict access on IP addresses and alter the
public string. Further, communications are done via clear text, which
can enable other applications to spoof addresses and requests.
Finally, SNMP requires developers to learn specialized MIB
vocabularies to develop applications.
To me, Web services via SOAP/XML appears to be a much more
viable option. Based on widespread industry support, it offers rapid
development with many different development environments and enables
the use of virtually any language to fit developer needs. Therefore,
I'll utilize SOAP for the following application example.
Application Overview
An application can be created quickly to help automate the
update process. Applications can be full-featured, Web-client
solutions that enable developers to log in and control which servers
or applications they wish to update. Or, this same functionality can
be combined with existing code management solutions to streamline the
deployment process.
For this example, I'll outline the basic building blocks that
can work for either scenario. To gracefully update application
components, the update application must locate the server resources
supporting an application, determine which servers need to be
updated, gracefully remove existing traffic and connections to the
server hosting the application, and enable the update process to
begin. After the application components are updated, initialized, and
tested, the application must also gracefully reintroduce the new
applications to client requests.
Key Terms and Definitions
While network load-balancing technologies are not new, some
of the terms and function definitions may not be familiar to
application developers. Since these terms relate to the interfaces
and methods I will be discussing in this example, here are some basic
definitions of terms common to network devices:
Node: A specific combination of an IP address and port
(service) number associated with a server in the array that is
managed by a network load balancer.
Pool: Composed of a group of network devices (called
members). The network load balancer distributes requests to the nodes
within a pool based on the load-balancing method and persistence
method you choose when you create the pool or edit its properties.
Member: A reference to a node when it's included in a
particular pool. Pools typically include multiple member nodes.
Virtual server: A specific combination of a virtual address and a virtual port associated with an application or Web service
managed by a network load balancer or other type of host server.
Connection: An active TCP connection to a specific server.
Application Description and Code Samples
For this example, the functions are relatively generic and
represent logical steps needed to deploy or update application
components on servers managed by a network load-balancing device. The
code samples, designed to provide guidance on how to build your own
application, are specific to F5's iControl API. Directions for how to
learn more about this API and obtain more samples are provided at the
end of this article. For other networking vendors, you can visit
their respective Web sites for additional information on how to use
the APIs they make available to developers.
Query for Pool Associated with Virtual Server Address
To locate the pool of nodes or members associated with a
virtual server, query the virtual server address (see Listing 1). The
response will indicate which pool(s) are available to manipulate. In
many cases, the virtual server is the primary URL or IP address
associated with a particular Web service or application.
Query Pool for Members
To determine which members (servers) are available for
application updates, query the pool associated with the virtual
server (see Listing 2). From the response, you'll have a listing from
which to choose. This will be the total collection of servers that
you will have access to when deploying new applications or updating
existing applications.
Determine How Many or Which Member(s) to Target
In many cases, this is a business-process decision. The
number or quantity of members you will want to target for updates
comes down to a simple question: How many servers can you afford to
take out of service at any given time? Your decision may be based on
a number of factors including current server load, server resources
provisioned for various peak times, or possibly something as elegant
as calculating the average number of persistent application
connections.
One option, although not defined in the article, could
include the creation of server groups to be utilized as "update
groups." These could then enable switching between groups when
updates are executed (see Listing 3).
Set State to Disable Targeted Members
Once the targeted members (servers) have been identified, the
next step is to proceed with setting the state of the members you
wish to update. This step effectively prepares the servers by
ensuring that no new client connections can be established. Further,
it ensures that no new traffic is sent to the servers. Once this
state is set, new connections and traffic will be sent to other
members in the pool, ensuring that new requests always get an active
server and not a server going through the update process.
void setNodeState(IPPortDefinition[] members, int state) {
...
// Setting method parameters
soapParams.addElement(new Parameter("node_defs",
IPPortDefinition[].class, members, null));
soapParams.addElement(new Parameter("state", Integer.class,
state, null));
// Set Call object method and parameters
call.setMethodName("set_state");
...
}
Establish When to Drop All Connections from a Member
Once the state has been set to disable targeted members, the
decision must ultimately be made as to when all remaining connections
will be disabled. There's a variety of criteria from which to choose
depending on your business needs. A good approach can include
determining the threshold of the tolerable number of connections to
drop. For example, once only two connections remain, drop them and
disable. Another alternative is using the time since the member was
disabled. A further option could include looking for connections from
specific client IP addresses. When these connections cease, disable
the server.
Once the member is disabled and all connections are dropped,
it's considered offline and ready for updates.
void setNodeAvailability(IPPortDefinition[] members, int avail) {
...
// Setting method parameters
soapParams.addElement(new Parameter("node_defs",
IPPortDefinition[].class, members, null));
soapParams.addElement(new Parameter("state", Integer.class,
avail, null));
// Set Call object method and parameters
call.setMethodName("set_availability");
...
}
Update Application Components on the Target Server
At this point, the developer has many choices as to the best
way to distribute the application. Most simply use existing component
distribution techniques that can include FTP, programmatic
deployment, or even integration with an existing code management
system.
Once the update process has been completed, appropriate steps
should be taken to initialize or register new components on the
server. It's further recommended that new component testing be
performed prior to restoring the member to an active pool.
Update Application Monitor
One feature usually deployed with intelligent network
load-balancing solutions is application health checking. Monitors
check application availability at periodic intervals based on
specified criteria. This ensures that if an application goes down, no
new client requests are routed in its direction.
If an application monitor needs to be created or has been in
use for previous versions, now is the time to create the new monitor.
Once created, it is associated with the newly updated member and the
old monitor is deleted (see Listing 4).
Set Updated Member to Receive Connections
Now that application updates are completed, the server tests
out correctly, and the monitor is set, the member is ready to be
reintroduced to the pool of servers supporting an application. The
member state needs to be set to receive connections and placed in an
enabled mode.
void setNodeAvailability(IPPortDefinition[] members, int avail) {
...
// Setting method parameters
soapParams.addElement(new Parameter("node_defs",
IPPortDefinition[].class, members, null));
soapParams.addElement(new Parameter("state", Integer.class,
avail, null));
// Set Call object method and parameters
call.setMethodName("set_availability");
...
}
Set State to Allow New Traffic
Once enabled, the member is reintroduced to the pool and can
begin allowing new client requests that will respond with the new
application just deployed.
void setNodeState(IPPortDefinition[] members, int state) {
...
// Setting method parameters
soapParams.addElement(new Parameter("node_defs",
IPPortDefinition[].class, members, null));
soapParams.addElement(new Parameter("state", Integer.class,
state, null));
// Set Call object method and parameters
call.setMethodName("set_state");
...
}
Putting It All Together
At this point, there are a variety of options for how a
member should be reintroduced to the incoming flow of requests. In
most cases, how it is reintroduced depends on factors based on
overall methodology and the process outlined for spot or rolling
updates.
For instance, an organization may want to schedule regular
updates when applications or sites have specific availability
requirements. Alternatively, this application could enable an
organization to update applications at any time, given that now
there's control of how the application is deployed, such that clients
will continue to have seamless application access throughout the
process.
One deciding factor may include whether the application is a
basic application or a more complex application using session
persistence. For basic applications, an application based on the
building blocks provided may stage blocks for updates. For example,
in a pool of six servers, the first three may be updated and upon
being reintroduced into the pool, the remaining three are removed to
follow the same update process.
For applications where persistence is a factor - particularly
long persistent sessions - a deployment strategy might include
creating a new pool for the updated servers, adding the servers to
that pool, and then remotely telling the network device to begin
directing new client requests to the newly formed pool of updated
servers. The benefit to this approach is that all remaining
persistent sessions running on servers using the old application
version can time out in their own graceful manner. This helps ensure
that client experiences go smoothly. Only after the session is
complete will the servers be cycled through the update process.
Application Benefits
By deploying this solution to ease application deployments
and updates in a J2EE environment, companies are able to increase
developer productivity, reduce deployment frustration, reduce
management overhead, and gain flexibility to deploy new applications
on demand. With this solution, the customer can:
Reduce time spent managing the deployment of applications:
Some customers have reported savings of 3-5 hours per week per
network administrator. Given only four network administrators saving
six hours per week, this could equate to a savings of 144
workdays/year. Given the cost of network management, this can relate
to significant cost savings for any organization.
Accelerate deployment of applications through automation:
Replacing manual processes with automation enables faster updates and
deployments and thus increases the developer time available to
continually improve applications. Further, it provides end users with
access to more current applications - increasing their net
productivity.
Reduce errors associated with manual intervention: Some
estimates suggest that nearly 80% of network configuration errors can
be attributed to manual, human intervention. By automating this
process, you can reduce a significant volume of configuration
problems that limit mission-critical application availability.
Related Information
For additional information and sample code to build similar
applications, please visit http://devcentral.f5.com.
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
