WebSphere Topological Architecture Blueprints


Now you've learned some of the key elements associated with topological architecture considerations. In this section, you'll move on to look at some blueprints for WebSphere topological design, their pros and cons, and where you might choose to use one of them. I also discuss the configuration aspects of each topology that you need to consider. Remember, your application architecture must marry up with the topological architecture ” neither of the designs can be done in isolation.

The approach to this section of the chapter is as follows . First, I discuss some key points that are common to both single and multichannel environments. Following that, I discuss the factors associated with either a single-channel or a multichannel system. Each subsection has information that you should read if you're considering either of the solutions.

Common Elements to Consider in Your Topological Architecture

In the next few sections, I discuss some high-level design attributes common to all topologies, including the following:

  • Web servers (thin versus thick models)

  • Application servers

I should also point out that in this chapter, I'm making an assumption in all the topologies that you'll be operating a firewall environment (of at least two tiers). Therefore, all topologies will be based on environments in which firewalls exist. I also discuss and lay out the various topologies based on real-world use cases. There are several other combinations of WebSphere topology that you can use, but those topologies I present here are the most common and provide the best features.

Web Server

The Web server in any topology can be implemented in one of two configurations, from a component delivery point of view. First, it can be installed as simply a Web server configured with the WebSphere HTTP plug-in. Second, it can be "fattened" to also run WebSphere and serve presentation components such as JSPs, servlets, and static HTML content, while the application server also operating on WebSphere facilitates connectivity to backend or legacy systems and runs more advanced J2EE components such as EJBs.

The choice of whether you opt for a "thin" or "thick" Web server should be based on several considerations:

  • How strict are your firewall rules?

  • Is security a big concern for your application environment?

  • How much static content are you likely to be running?

  • Is your firewall located in a separate location from your backend application and database servers?

  • Do you have an operational preference for server sizes and configurations? (That is, do you prefer to operate large processing application servers versus many smaller servers?)

  • Does your application architecture have any special considerations for protocols or logic between the Web container (presentation components) and the application server (business components)?

Let's look at those questions in more detail.

How Strict Are Your Firewall Rules?

The first question relates to your corporate security policies for your firewalls. This question attempts to derive the sort of firewalls you have in place. I've worked with the most basic of firewalls, which are simply Network Address Translation (NAT) firewalls (if they can be called that), up through to the more complex four- tier firewalls. Your WebSphere platform needs to be architected differently for each, and each is driven by the protocols and transaction rate between presentation components and the business components.

For example, you would notice a performance impact on your application if you were running a heavy firewall configuration and had a thick Web server running WebSphere for presentation components (JSPs, servlets, etc.) in the first or second tier of your firewall, yet your backend application servers were residing out on your corporate network.

For most medium- sized and larger WebSphere application environments, the transaction rate between the presentation tier and the business tier will be high. With servlets and JavaBeans communicating to backend JavaBeans and EJBs, as well as other service provider types, the applications' overall performance will be impacted by the translation and interrogation conducted by the various firewalls.

Figure 5-5 illustrates the issues associated with a thick frontend Web server (running WebSphere) talking to a backend application server and database tier.

click to expand
Figure 5-5: Overhead associated with communications via a firewall for heavy transaction data

As you can see, each hop through the firewalls may introduce an additional 2 to 5 milliseconds of latency. By the time the packets get to the backend, they may have had an increase in latency of up to 30 milliseconds , and if each transaction is consuming some 100 network I/Os, this becomes expensive (network payload-wise).

The network diagram in Figure 5-5 shows a somewhat "heavily engineered" firewall environment. Although the network addressing in the example is cumbersome (in reality, a more efficient network address design would be used), the firewall layout is one that isn't uncommon in larger environments. Consider that at each level there would be virtual LANs (VLANs) and other demilitarized zones (DMZs) hanging off the various firewall tiers. This may not always be an issue for all sites. Typically, this is the case for medium-to-large organizations that may have quite complex firewall requirements and many tens or hundreds (or thousands) of servers to protect. In these cases, the firewalls will be several tiers deep.

You may also find that, depending on how you communicate between your frontend and backend tiers, firewalls may not be able to route the traffic correctly. An example of this is Internet Inter-ORB Protocol (IIOP) and RMI-IIOP. These are what I term intelligent protocols, as they aren't simplistic like HTTP and HTTPS. IIOP-like protocols typically carry source and/or requester address information in their payload and the destination system receiving the protocol data will typically attempt to do something intelligent with the return protocol based on the contents of the payload, rather than simply follow standard IP source and destination headers.

For this reason, my recommendation is to use a thin Web server environment and use the WebSphere HTTP plug-in to route requests from the Web server in the firewall out to the backend application servers. Figure 5-6 highlights this recommendation.

click to expand
Figure 5-6: A thin Web server configuration

As the HTTP plug-in communicates via pure HTTP, it's easy to route and handle through firewalls.

Is Security a Big Concern for Your Application Environment?

The second question relates to security ” essentially , this is in line with the first question relating to firewalls. The answer to this question may simply back up the answer to the first question.

The stricter your corporate security is, the further away from the public Internet you would want your business logic and data tiers. For example, you wouldn't want to house your Web, application, and data tiers all within the first tier of a firewall, which is typically known as the demilitarized zone (DMZ). This type of data housed on the database servers is typically sensitive in nature, so having it close to your Internet borders is risky because there's only one firewall to traverse to obtain access to that data. This reinforces the notion of a thin Web server redirecting traffic via the HTTP plug-in to backend application and database servers.

Some sites go so far as to place firewalls between each of their tiers. That is, the setup looks something like Figure 5-7.

click to expand
Figure 5-7: A 3-tier firewall topology

These types of firewalls are typically used to house 3-tier and n-tier applications, but they do have the capability to fast-track the request through the firewall tiers through the use of networking solutions such as VLANs.

In the high-level diagram in Figure 5-7, there are clearly three "tiers" of servers separated by various firewalls and a single choke , which is a scaled-down firewall that typically operates on access control lists (ACLs).

How Much Static Content Are You Likely to Be Running?

If your application is Web based and is delivering a lot of static content, it maybe worth considering housing a small WebSphere or static HTTP server environment on tier 1 of your firewall to reduce the HTTP I/O rate between the frontend and backend components.

Note  

Many organizations make use of third-party content providers to host noncore content such as static HTML and images.

Some Web-based applications have many GIFs, JPEGs, and static HTML included within the output that is being delivered to the customer's screen. If this is the case, the I/O rate on incorrectly sized backend servers can sometimes create large amounts of overhead, as each connection request for a particular image or HTML file generally spawns a new HTTP thread on the WebSphere backend. For this reason, if the content is truly static, consider housing it on the Web server on the frontend.

Is Your Firewall Located in a Separate Location from Your Backend Application and Database Servers?

This question relates to proper network design but it's something you need to consider alongside the system architecture for your backend application server(s). If your site is highly distributed, most likely geographically , then this is an important point.

In some situations, it may be worth considering having the backend application server simply processing business logic requests such as JDBC database and EJB type requests. If you're able to push the content delivery closer to your customers, then this creates a less expensive infrastructure model to operate. That said, you need to weigh the cost and security pros and cons associated with having possibly too much "logic" on the frontend Web servers.

As I discussed in relation to the first question, best practice states that no business logic should ever be directly accessible by customers. The best situation is for your application architecture to have an abstraction layer between the Web tier and the application/business tier. This provides the ultimate level of application security, while at the same time allowing for you to push nonbusiness logic (i.e., presentation logic) to the frontend Web servers. Figure 5-8 shows an example of how this abstraction layer model could work.

click to expand
Figure 5-8: Abstraction layer for the Web tier

As you can see, the initial request that comes into the Web server from the customer is routed by the plug-in to a WebSphere application server, which is running a lightweight servlet process. The request is processed by a servlet that somewhat proxifies the customer request, rewrites it into an application-native message request, and delivers it to the appropriate backend services. The middle firewall tier may operate a secondary application proxy, or the WebSphere instance operating on the first tier, the HTTP server, can be installed on the middle firewall tier, replacing the "application proxy." This prevents customers from hijacking the Web server and pushing requests through the firewall, which may have previously been plain native HTTP requests.

In this example, the Web server, operating WebSphere, takes the requests within a servlet and proxies the request to the backend application servers in a form not readable by the clients or anyone else in between. An example of this may be to encapsulate all the requests into hashcode with some identifier codes within the request that follow a paired-key approach to ensure that the backend application servers know that the inbound request is in fact legitimate and from the frontend server.

Caution  

No amount of clever logic within an application is better than solid firewall and security. Eight times out of ten, security break-ins to applications are due to poor or insufficient security infrastructure rather than application design.

The outcome of this question is this: If your WebSphere-based application is heavily made up of static content, then consider placing the static content on the frontend Web server or WebSphere application server (under the defaultApp, for example). If, however, your application doesn't have many static images and components, and/or many of those components are dynamically generated by business logic, then consider the thin Web server approach.

Do You Have an Operational Preference for Server Sizes and Configurations?

This question relates to the preferences of your organization's CIO in terms of server models. Some companies prefer the many, smaller or blade approach, whereas other companies prefer the fewer, more consolidated server approach, which may follow some type of utility model. WebSphere can operate all its major application components on a single node, or it can be distributed to a very fine level.

One way to quickly answer this question is to understand what your application processing demands are. If your application requires a lot of "processing horsepower" to compose output, result sets, and so forth, the answer to this question may be that you need to operate large servers on your backend rather than more, smaller servers.

If, on the other hand, your application is lightweight and isn't processing intensive , then the more, smaller servers approach may be the best option for you here. In this case, with regard to your Web server, you need to understand that whatever option you go for, you should consider how the previous four questions may affect the server model you use.

Note  

I discuss the application server processing demands and what the considerations are in the next section.

Generally speaking, however, Web server models suggest that the optimal approach is to use the more, smaller model. In this section, though, we're focusing only on the single-channel approach ”the basic building block or model should remain the same.

Does Your Application Architecture Have Any Special Considerations for Protocols or Logic Between the Web Container (Presentation Components) and Application Server (Business Components)?

This last question ties in closely with the first question in the discussion about traversing your firewall environment with weird and exotic protocols. If your firewall policies are well tied down, then you may not be able to get anything more than SMTP and HTTP over your firewall. In this case, having a thin frontend Web server is possibly the only model that you can use without a redesign of your firewall.

If, however, your firewall does allow for changes and sometimes nonstandard protocols, and your application requires unusual protocols to go from the frontend to the backend, then it's an either/or question that should be answered with the help of the other five questions.

The reason for this line of thought is that firewalls typically only allow a handful of protocols to traverse them. Nowadays, the list commonly contains HTTP and sometimes HTTPS, SMTP, and some form of VPN or encrypted tunnel protocol such as SSH or IPSec. This isn't to say that other protocols can't traverse firewalls; rather, the point here is that if you're communicating from a non-thin Web server operating WebSphere on the frontend to a backend WebSphere application server using something other than one of the aforementioned or other similar simple protocols, you may find that there are compelling reasons to go back to a thin model.

In the thin model, all the traffic from the Web server operating a HTTP WebSphere plug-in (to provide routing and context management rules) to the backend WebSphere application server(s) will communicate via plain HTTP. This makes for a simple and easy-to-manage configuration for your firewalls. In this model, however, all your exotic protocols would operate on the backend server environment.

From this, you should be able to see the emerging power of technologies such as SOAP and Web Services. These application protocols allow you to communicate between disparate, diverse, and distributed systems over plain protocols such as HTTP and HTTPS, using a controlled and managed application protocol framework. The remote systems communicate via a standard, exposed "context" within your WebSphere application server. The requests from the remote systems are routing via the HTTP plug-in on the frontend Web application server ”like any other application context request ”and are routing through to the WebSphere application server on the backend for processing.

Single-Channel Topologies

The single-channel topologies are the most simplistic of all WebSphere topologies. The term channel refers to the primary path available between tiers. With a single-channel topology, the Web server(s) tier communicates to a single WebSphere application server and a single database server. Figure 5-9 highlights this concept at a high level.

click to expand
Figure 5-9: An example high-level single-channel topology

As you can see, traffic is restricted to one WebSphere application server instance on the application server and only one database server exists.

This single-channel topology is unlike a dual or multichannel topology, in which multiple independent paths are available between the various tiers. Typically, this involves two or more Web servers, two or more application servers, and two or more database servers. As you can imagine, it's a far more complex design, but it does provide a higher availability guarantee, better scalability, and generally a better performing system.

Single Web Server, Combined WebSphere Application and Database Server

The most simplistic single-channel WebSphere topology that should be considered for a production environment is a single Web server, either thick or thin, and a combined WebSphere application and database server.

I have a few initial points to make about this topology. First, you should only consider this topology if ”and only if ”you're 100 percent sure that your database load will be minimal to none. As I discussed earlier in the book, database and WebSphere processing characteristics are quite different, meaning that you can't tune or specify your server based solely on one or the other. Given this, having both components operating at the same time will undoubtedly cause you performance issues of several types.

That said, some application architectures just may not require large amounts of database I/O; therefore, this model is quite possibly sufficient for smaller environments. It does not, however, follow what I'd classify as a best-practice design approach of compartmentalizing all of your differing application services into separate server tiers ”that is, Web server services in their own server, application-processing services in the application server, and a dedicated database server.

Figure 5-10 illustrates this most basic form of WebSphere topological architecture.

click to expand
Figure 5-10: A high-level, single-channel, 2-tier topology

Figure 5-10 highlights a high-level 2-tier WebSphere topology. As you can see, it quite clearly has a stand-alone Web server, operating in a thin mode, and a combined backend WebSphere application server and Oracle database server.

Let's take a look at each major section in more detail. First, you'll notice that in this single Web server topology, only a single HTTP Web server instance exists. This can be an HTTP Web server operating Microsoft IIS (for Windows platforms), Apache, IBM HTTPD, or iPlanet/SunOne Web server.

As I discussed in previous chapters, in this thin Web server model, your Web server is just providing you with a redirection layer. This is facilitated by a WebSphere HTTP plug-in that operates within the HTTP Web server process space. The plug-in is configured and tuned via a file known as the plugin-cfg.xml file and it's hand editable. This plug-in configuration file maps out what and how requests will be routed through to backend WebSphere application server instances. As you'll see in later sections, this plug-in provides a good level of WebSphere-aware load balancing or workload management.

The second major component in this topology is the combined WebSphere application server and database server. The database server software can be running any of the major Relational Database Management System (RDBMS) packages such as DB2 and Oracle, and it's used, depending on which version of WebSphere you're running, primarily for two purposes. First, in a WebSphere version 4 world, the database is used for the administration repository. This is where WebSphere deployed applications' configuration and setup information is stored. Remember that in WebSphere version 5, the repository has been replaced through facilitation of XML configuration files resident on each of the WebSphere application servers and managed through a series of WebSphere components such as the Deployment Manager. The second use for the database server is for the storage of application data. Anything that your applications may need to persist or store on a database would be stored here. Customer data, profile information, logging, and transaction information are some examples of what may be stored here.

In this simple 2-tier WebSphere topology, you must assume that there won't be any "smarts" behind the database server, such as clustering and hot standby.

The WebSphere application server, operating on the same physical node as the database, is where all the applications are deployed. In this topology, the configuration of this WebSphere application server is very straightforward and doesn't maintain clones or clustered application instances, and is therefore low in complexity. This is the most basic of all WebSphere configurations, short of housing the Web server on the same node as the WebSphere and database services.

Advantages

We need to put a stake in the ground and assume that this topology is only used by very small production environments or, more likely, development and testing environments. The advantages of this topology are as follows:

  • Low cost: There's little cost associated with this deployment because there are no complex components such as shared storage or clustered database servers. The fact that there are only single instances of applications running infers that there isn't a lot of memory or CPU power required and, as such, a dual CPU machine with 2GB to 4GB of memory would be sufficient for something of this size. Ironically, as you'll see in the next section, splitting out the database and WebSphere components into dedicated servers will result in a similar overall net size of environment processing and memory capacity.

  • Low complexity: As only one application instance is running at any time and there aren't any high-availability requirements associated with this topology, the database and WebSphere configurations are simple, which keeps down deployment, integration, and operational management costs.

  • No need for load balancing: This topology reduces costs by removing the need to run additional load-balancing hardware on the frontend of the firewall.

Disadvantages

The disadvantages of this topology are as follows:

  • Little or no redundancy: Because so much of the application is residing on a single backend combined WebSphere and database server, there's little redundancy available to these components in the event of a hardware failure. A hardware failure of almost any type on any of the server tiers will result in a complete application outage .

  • No service compartmentalization: If the database server starts to grind the backend server to a halt through a database-intensive process (e.g., archiving), this will affect the rest of the overall application by having a direct effect on the WebSphere applications.

  • Low scalability: With the backend server assumed to be small (you probably wouldn't purchase a single large system in place of a cluster of smaller systems!), there's little or no scalability available in this topology.

  • Updates and upgrades require outages: Any upgrades to hardware, application software, or capacity will result in an application outage, as there is only one instance of anything operating at any one time.

  • Possibly low in performance: With a system of this size, you could assume that the performance may be suitable for a fixed small number of users; however, any wayward processes would instantly impact the overall application performance. Then again, the system may be so small that the usage and utilization of the environment is minimal, and the impact between multiple sessions may go unnoticed.

Final Considerations

The only additional recommendation that I can make about this topology to try and help mitigate some of the risks associated with it would be to consider ensuring that your servers in each of the tiers are internally redundant. Servers of the size that would typically be housed in this kind of topology won't provide redundant, hot-swappable CPUs and memory, so the best you'll be able to do is to use mirror disks (stripped for the database files), redundant network interface cards, and redundant disk controllers. If the vendor of your hardware choice offers it, opt for redundant power supplies and cooling systems too.

In summary, this topology should only be used for small, non-business-critical production systems or for development environments. If you use this topology, I advise that you either invest in hot-standby servers or plan to upgrade to a multiserver 3-tier environment down the track.

Single Web Server, Single Application Server Topology

As you've seen several times throughout this book, these are the key components of a WebSphere physical implementation. In this configuration, physically separate servers are operated that distribute the frontend Web server, the WebSphere application server itself, and the database server. This is different from the first topology you looked at in which the database and WebSphere application server reside on the same physical server. In this topology, the database server sits by itself out on its own dedicated hardware.

Figure 5-11 shows an example of this topology.

click to expand
Figure 5-11: A high-level, single-channel, 3-tier topology

As you can see in Figure 5-11, this topology quite clearly shows the 3-tier model: physically separated and dedicated Web, WebSphere, and database servers. The Web server and WebSphere application server interact in the same manner in this 3-tier model as in the first 2-tier topology you examined. Traffic or customer requests are routed through from the Web server HTTP plug-in to the WebSphere application server instances.

Let's take another look at how this plug-in would work in a 3-tier environment. Putting this into context, on your WebSphere application server, you may be running three J2EE-based applications (three EARs):

  • A portal application providing basic login screens and navigational logic

  • An interactive application for sales and order management

  • A customer self-service administration application for customers to update and alter their personal settings, details, and preferences

These three application components, all operating in their own separate JVM or WebSphere application server instance, are configured with their context within the HTTP WebSphere plug-in on the Web server. The context is essentially the URL after the host URL component. That is, with the URL of http://www.mydomain.com/someContext , your context would be /someContext . This element is used to "route" the customer request to the appropriate application server instance on the WebSphere application server.

You may (and do in this example) have three contexts:

  • /applicationPortal

  • /theApplication

  • /selfServiceManagement

In the plug-in file, you'll configure each of these URLs in such a way that has them coupled with a "route group " to identify to the plug-in to which you eventually send the request. In your basic 3-tier server model, you have only one server of choice to "route" the request through to. However, the way in which J2EE application servers function in this form is to operate the HTTP interfaces to JVMs on separate TCP ports.

So, with your three WebSphere J2EE-based application servers (i.e., the portal, the sales and order management application, and the customer administration application), you have three ports configured within WebSphere. Let's assign the ports as follows:

  • /applicationPortal as port 10000

  • /theApplication as port 10001

  • /selfServiceManagement as port 10002

If you want to, you can access the applications directly on these ports by pointing your browser to the WebSphere application server and the port number directly. For example, pointing your browser to http://myWASbox. somedomain.com:10000/applicationPortal results in your being able to use the application directly on the port allocated to /applicationPortal . This is not of much consequence in single server, single instance implementations but, as you'll see in the next section, it has a major effect on what gets load balanced and how it gets load balanced.

To conclude the overview of the operations of the plug-in file, the final step is to attempt to access the applications via the global domain, which you've allocated and configured on the frontend Web server. That is, www.mydomain.com would be configured in the mydomain.com DNS zone files to point the "www" to a host name. In the example here, the host name may be "myHTTPbox"; therefore, pointing the browser to www.mydomain.com or myHTTPbox.mydomain.com will result in the request being sent to the Web server running on the frontend Web server instance.

In this case, the Web server first passes the request through to the HTTP plug-in to determine whether the context in the user 's request matches any of the configured contexts in the plugin-cfg.xml configuration file. If it does, the plug-in redirects the request to the server and port, as configured in the plugin-cfg.xml file.

Back on the 3-tier model itself, generally the choice of this model will be the result of one or two things. Either the risks or disadvantages of the shared infrastructure design will result in a need for an additional or dedicated database tier, or the production database transaction load will mandate a dedicated database server.

In most cases that I've seen, the resulting decision for the 3-tier versus 2-tier setup has been mostly driven by the fact that the database transaction load is too high for a shared server environment. The next section deals with that point because I've mentioned it several times now.

Database Transaction Load Considerations

Databases typically have the characteristic of high disk I/O. Because the purpose of a database is to store data and allow you to query against it, the data storage has to be done on some persisted data form via a long-term storage medium such as a hard drive.

As I discussed in the previous chapter, selecting hard disks isn't as simple as looking at capacity or RPM rates. Although these factors have a strong bearing on the final performance indices, the capability for a disk to perform is far more than that. Databases need fast, high-performing disks. As you can imagine, a database that's conducting many queries to its storage files (on the disks) will result in a high I/O rate. If you have just one disk servicing your database files, then you'll notice I/O contention on a medium to high query rate database environment. Striping disks to average down or smooth out the I/O spikes on select physical disks is one popular method of keeping this load under control.

In a shared database and WebSphere application server environment, you may be able to get away with having a separate disk controller and several disks dedicated to database I/O. The problem still remains in the areas of process space and processing capacity, however. Databases will still require memory I/O and CPU capacity to perform queries, indexes, and all the administrative functions that databases need to perform under the hood.

This goes back to what I noted earlier in this chapter about the load characteristics of a database being completely out of tune to those of a WebSphere application server. WebSphere-based applications require memory and CPU cycles ”the drivers behind this are pretty simple. Putting aside the processing overhead of the transactions themselves (e.g., a financial management system written in Java), Java/J2EE applications store objects in memory. The JVM is responsible for the management of those objects, including maintaining them, cleaning them out of memory, and accessing them.

All this requires CPU and memory capacity ”the same capacity that a database requires. Therefore, a given WebSphere application server will manage itself within its bounds and those in which it is designed to operate within, and it will have no care for the operational needs for a database server and vice versa. There will be system contention from both applications to obtain system resources, and therefore the contention is enough of a reason for not maintaining these two types of applications on the same physical server.

Because the 3-tier model is similar in internal capability to the 2-tier model, in the next sections I cover their advantages and disadvantages.

Advantages

Although the 3-tier model is similar to the 2-tier model component-wise, it has some advantages over the 2-tier model:

  • Generally low cost: Although the cost of an additional server does make this a more expensive option than the 2-tier single-channel WebSphere topology, the bang-for-your-buck factor is higher in this 3-tier topology.

  • Low complexity: Because only one application instance is running on the WebSphere application server, and because this is still a single-channel, single-JVM instance topology, it's a low-complexity option for a WebSphere topology.

  • No need for load balancing: This reduces costs by removing the need to run additional load-balancing hardware on the frontend of the firewall.

  • Limited redundancy: Although there are still single points of failure in the model due to the single-channel servers (one path), the additional tier does provide for greater redundancy.

Disadvantages

Although this topology is what I consider to be the first true production-ready model of those I discuss here, you'll still need to take the following disadvantages into account:

  • Single path point of failure : Although you've now increased the number of servers in the model by adding in a dedicated database server, you still have a single path. This model does help reduce the odds of a failure, yet the sum of the system's availability is still affected by the single point of failure within the topology.

  • Low volume-capacity management : Somewhat similar to the preceding point is the inability for this type of environment to handle unexpected peak volumes. Unless the servers in this basic 3-tier topology are specified to quite a large degree with plenty of processing overhead, they typically won't be able to handle unforeseen volumes , peak loads, or more sinister things, such as DoS attacks, with transparent ease.

  • Inability to perform upgrades that don't impact customers : This may not be a high priority on everyone's list, but some environments just can't go down, even for capability upgrades. For medical systems, global finance systems, or air-traffic management systems, taking the application offline for an upgrade is, in most cases, unacceptable. As you'll see in the next few sections, having additional channels or application paths starts to provide the ability for systems managers to deploy new capabilities without affecting existing production and, hence, existing customers. This basic 3-tier model doesn't provide this capability, so my recommendation is that you not use it for mission-critical systems.

  • System geographies : With this topology, because only one channel exists, the systems can't be geographically load balanced or distributed. This is in line with general scalability, and if your application is servicing a wide range of geographic locations, choosing this topology initially may not provide a straightforward upgrade path down the track to distribute out additional servers.

    Caution  

    If you're licensing Java from Sun, be sure to review the end-user license agreement. The Java license prohibits the use of Java in environments deemed "high risk," such as nuclear power plants, air-traffic control systems, and life-support machines.

Final Recommendations

This topology does provide a solid, albeit basic, model for smaller, less mission-critical WebSphere implementations. Use this topology if greater than 99.9 percent availability isn't required or you've purchased systems that support internal redundancy and hot-swappable components (e.g., HP Superdomes and Sun SunFire systems). Note that these classes of servers aren't cheap!

Multiapplication JVM, Single-Channel Topology

There are two primary reasons to use multiple JVMs in a WebSphere (or any J2EE server) environment. The first is to gain more processing ability. As I discussed earlier in this chapter, more JVMs means more threads can be processed, which means more customer or application transactions can take place. The second reason for using multiple JVMs is to instigate another level of redundancy. With two or more JVMs, you reduce the risk of having a single JVM application crashing and leaving you with a downed application. That said, not all applications can be simply be "cloned" to use multiple JVMs. You need to consider things such as user sessions, data persistence, transaction management, and so forth.

As I discussed earlier, your application environment may simply need more than one JVM to operate in order to gain more than the limitation of available memory per JVM. Either way, there are many sound reasons why you'd look to use this topology. Let's look at some points you'll need to consider when architecting this kind of topology.

Essentially, the key difference between this topology and the previous topologies is that it incorporates multiple JVMs for each specific application. That is, the application is "cloned" in order to meet one or both of the previous reasons for using multiple JVMs.

Figure 5-12 clearly shows the multiple JVM configuration.

click to expand
Figure 5-12: A high-level, 3-tier, multi-JVM topology

As noted in the first topology presented in this chapter, for Web-based applications that are operating within each of the JVMs depicted in Figure 5-12, requests are sent to each of the JVMs via the use of the frontend HTTP WebSphere plug-in on the HTTP server.

Up until now in this chapter, in a thin Web server configuration the HTTP plug-in has simply been routing requests through to the backend application server. For the first time in this topology, you can see how the HTTP plug-in can be used to provide a level of load balancing. Figure 5-12 shows how an inbound user request is trapped by the HTTP plug-in on the Web server. The HTTP plug-in then, based on its routing rules defined in the HTTP plug-in configuration file (also located on the Web server), will deliver the user request to the most appropriate backend application server. The request is routed based on one of several workload management policies, with the most common being to reroute presetup requests with active sessions to the original server process.

For example, say that the customer had originally logged into the Web-based application and the HTTP plug-in had decided, based on a pure round- robin load-balancing policy, to send the request to JVM A on the application server. With a concept known as server affinity being active, all subsequent requests made by that same user session (as defined or identified by the active session ID) would be delivered to the original server process which, in this case, would be JVM A.

If the configuration had been set up to accommodate session persistence, the two JVMs would be persisting the user's session object to the backend database to ensure that in the event of a JVM failure (e.g., JVM A), the subsequent user request would be routed through to JVM B and that JVM would be able to access the existing session details that JVM A persisted. The features that handle load balance and failover between differing JVM instances are typically, but not always, managed by server groups and clones in WebSphere version 4 and Dynamic Replication Service (DRS) in WebSphere version 5. (Sound confusing? In Chapter 7 I discuss in detail the configuration and design considerations associated with workload management.)

With this ability to round-robin , load balance, and support failover scenarios, you have a situation now in which your topology starts to exhibit traits of redundancy and high availability. Let's examine the considerations of this topology in more detail.

Considerations for Multiple JVM Environments

As I alluded to previously, an application can't always just be incorporated into a multi-JVM architecture. You'll need to consider various design points relating to the application architecture prior to going down this path:

  • Do you need to control user sessions? That is, are your transactions sticky and, once a customer logs into the application, does the application need to track items and details about the user's session?

  • How are you going to handle transactions that span multiple JVMs?

  • Are you going to use file system-level or database-level persistence for storing certain types of data?

These questions can't typically be answered right away; however, let's briefly look at the details of each. First, session state for customers or users accessing the application may be used to store various bits of information. This may be items as straightforward as the user's login name or it may extend to information that has been retrieved from a database relating to data such as the user's past spending history. Therefore, if you're using session state to store this type of information, you'll need to ensure that if JVM A crashes or some form of load balancing pushes the customer requests to another JVM, the other JVM can access the customer's session with no or little fuss.

Second, if your application design makes use of large (long-timed) transactions that may span several JVMs, operating multiple JVMs without some consideration for the application architecture in this type of situation could result in many headaches . It's a common mistake to not design how applications are broken up at a J2EE component level early enough in the design phase of a project. Component modeling and the interaction between components within a design phase are just as important in J2EE architecture as threading design and data transformation. The output of component modeling should leave you with an application design that doesn't have an issue with transactions over multiple JVMs, thus eliminating this issue from your checklist.

Note  

Component modeling can come in many forms in the J2EE world. In this section's context, component modeling is all about what is contained within each of your J2EE packagable component types ”EARs, WARs, EJB-JARs, and JARs ”and how it is contained. Each of these components communicates to methods and interfaces with other components differently, and there are boundaries for all four components as to what and how they communicate.

The last point relates to the age-old issue of persistence. If you have multiple JVMs operating an application, how does the application operating under WebSphere manage accessing the same piece of information or data? For databases, generally speaking, this isn't as much of an issue if you're operating something fairly straightforward such as JDBC. Once you get into the world of Container Managed Persistence (CMP) and Bean Managed Persistence (BMP), however, things can get a little hairy. For file-level persistence, in which multiple JVMs may access file system-level files, for example, persistence and data integrity are almost completely in the hands of the developer. Not all application designs may incorporate or even have considered this as a factor.

The bottom line is this: If you're modifying an existing application environment to incorporate multiple JVMs, test, test, test. Speak with the application developers to ensure that this type of event is well covered. If the application is new, ensure that the integrity management of the persistence layer is well designed and tested .

Other Considerations

With additional JVMs operating, you might assume that the server load will increase. If you're performing an upgrade to a multiple JVM environment in which previously a single JVM configuration existed, you must assume that the load will be evenly split between the two JVMs, 50/50, plus a small amount of overhead. This is a straightforward concept to manage. If, however, you're adding in additional JVMs to cater for load issues, there are a few issues you need to consider.

First, you should understand what adding in the additional JVMs for a particular application instance will do to the overall load characteristics of the application environment. That is, although you may gain additional memory to be able to perform and process certain logic, this will have a direct result on your server platform. Depending on what type of server platform you have chosen or are currently using, this effect will vary somewhat. Different platform types and memory configurations will perform in different manners. I use a rough rule that says if the load of a system is x with one JVM, and that JVM is using greater than 80 percent available JVM memory, additional JVMs will introduce load to the factor of the following:

Overall System Load = ([ x · Nj ] — [ Nj — 1.1])

This formula adds roughly 10 percent additional overhead per JVM process to the overall loading of the application environment. This will vary depending on the type and version of JVM you're using, the platform type you're using, and how many CPUs you'll run.

As I noted earlier, if you're running single or dual CPU systems for your application server, carefully plan what impact running multiple JVMs will have on your overall platform. Just adding in additional load-balanced or workload-managed JVMs that are under a fair degree of load (greater than 40 percent) will make a system's performance actually go backward.

Looking back to the earlier discussion, JVMs operate and manage threads for the applications that your developers write. These threads correlate to system-based threads or kernel threads. At any one time, a finite number of threads can operate on a single CPU. If you're attempting to get 1.5 or 2 times the amount of transaction performance by adding in an additional JVM without sufficient CPU power, then all that you're doing is pushing the thread handler in your operating system's kernel harder. This will work up until a point at which, after a while, the thread manager will start to become saturated with requests and the system's performance will start to stagger . Figure 5-13 highlights how this load issue can become a problem.

click to expand
Figure 5-13: Multiple JVM transaction considerations

As you can see, up until a point, the dual JVM configuration outperforms the single JVM configuration. However, as the total threads being processed by the system's threading engine begin to near the maximum capacity of what can be pushed through the single CPU, the second JVM starts to buckle.

Though this may seem obvious to those readers who are better versed in these areas than others, it needs to be said that the performance impact could also be the result of other factors. Most of the time, the issue will come back to system load, but not all transactions are CPU-hungry and tie down clock cycles. Consider distributed transactions, network load, throughput, and other such factors. Consider the case if your JVM processes were writing to disk, and by adding in an additional JVM, the additional processing load from the additional JVM doubled the disk I/O and saturated the disk bus. Consider simple things such as network load if your application is network bandwidth intensive. I've seen sites in which an application's purpose was to obtain data from an EAI bus, massage it into HTML-based output, and deliver it to the client. The resulting output was very large, and with this type of transaction, the JVMs were well utilized transforming data off the EAI call into objects and then delivering them down to the client browser. Remember that intensive network operations will consume CPU cycles ”this consumption will result in less available computing power for your JVM(s).

Advantages

As I noted, this topology is the first that is exhibiting traits of high availability and limited application redundancy. This provides a number of advantages:

  • High application redundancy: With the capability to now load balance and round-robin, and with failover between multiple application JVM instances, you can ensure greater availability of the applications. Although this topology is limited physically to a single path, if the decision was made to purchase servers that consisted of high levels of internal chassis redundancy, with the use of multiple JVMs, the topology would be able to meet quite high availability SLAs.

  • Increased application performance: With the additional JVMs now configured and active in this topology, you can extend the available memory to by using multiple JVMs to distribute memory or object space. In turn , the JVM itself doesn't need to garbage collect as frequently ( assuming your capacity modeling is solid!), given that the object space is distributed between more than one JVM. That said, for this topology to operate efficiently and as discussed here, your system will need to be running multiple CPUs when using memoryand or process-intensive applications.

  • High application availability: Similar to the first point, with the additional JVMs that can operate within the same physical application server, it's possible to perform limited upgrades to application code while the system is still running. This is limited to certain components ”the applications operating within the JVMs will be under workload management (e.g., server groups) and, as such, will be mastered by the parent WebSphere processes. Any changes to one JVM instance can and may have an effect on the other. However, items that can be easily hot-deployed, for example, can be managed in this way and tested independently of the main production processing scope.

  • Low-cost option for medium levels of single system redundancy: Considering the low costs associated with having a basic 3-tier model, the ability to operate a multiple JVM configuration does provide a low-cost option for basic application redundancy. Don't become too complacent with this design, however ”there are still single points of failure, but it's a big step up from the previous single JVM topologies.

Disadvantages

I've discussed a few of the design considerations of this topology that could be labeled as disadvantages (i.e., multiple JVM considerations and so forth). Most, if not all, are manageable. Additional disadvantages to this topology are as follows:

  • Servers are still single points of failure: I've covered this one in all topologies so far. The same applies to this 3-tier topology in that although you have additional redundancy built into the application through the use of multiple JVMs, all it takes is a CPU to panic and you could run as many JVMs as you like yet the system and application will still fail. The only caveat here is if you're running a high-end Unix system such as a SunFire server, which is capable of hot-swapping and management of bad CPUs. In this case, the offending CPU will be deallocated from the CPU pool and the application will continue operating.

  • Lack of scalability: Once again, similar to previous topologies, the single machine model still generally lacks adequate scalability for medium to large WebSphere environments. You must not become complacent with the ability to internally scale (application vertical scaling) as a replacement or substitute for true physical scalability.

  • Single repositories and memory spaces: Because the WebSphere implementation is operating singularly, with a single series of governing administrative processes and object spaces (session stores and so on), as with the previous single-channel topologies, there is a chance the process space within WebSphere could become unstable and cause a total crash. The same applies to the fact that there is only one administrative domain (WebSphere version 4) or cell (WebSphere version 5). Given this, the applications operating within these domains and cells can in themselves suffer failures. As you'll see shortly in more advanced topologies, when you design mission-critical WebSphere topologies, you should consider splitting their infrastructure into multiple domains or cells .

Final Considerations

As you're moving through these WebSphere topologies, you should be starting to see their best practices. Although some of these topologies and concepts in theory aren't uncommon in large-scale platform engineering and architecture, they do map slightly differently to WebSphere environments due to the way in which WebSphere functions.

This 3-tier topology represents the first of what I'd class as production ready or production safe. It presents limited vertical and horizontal scaling, as well as limited application and server redundancy through the use of the multi-JVM approach.

Even if your needs don't require the use of a secondary JVM, consider this approach for redundancy purposes. As discussed, by workload managing your application into multiple JVMs, you acquire not only a performance improvement or the ability to scale, but also application redundancy.

Dual Web Server, Single Application Server Topology

The dual Web server topology is the first of the horizontally scaled topological designs. In this approach, you gain the ability to obtain performance and availability improvements on the frontend Web server, whether it is thin or thick in design.

Common uses for this topology may be to simply handle and manage requests from geographically distributed sites and route the requests to backend WebSphere application servers (see the section "Geographically Distributed Application Servers" in this chapter). Or, if your topological architecture makes use of a thick Web server model in which the Web server is running WebSphere as well as the static HTTP server, this can be a good approach to gaining server redundancy for presentation components.

Figure 5-14 shows the thin Web server model for this topology.

click to expand
Figure 5-14: The dual Web server thin model

Figure 5-14 provides an overview of how this type of topology can service the needs of geographically distributed requirements for Web serving. As you can see from this example, the model depicts two Web servers operating with the HTTP WebSphere plug-in routing requests to a backend WebSphere application server.

In this model, the Web servers can be located side by side (i.e., in the same data center), or they can be distributed at key locations on a corporate network or on the Internet. For example, if an online ordering application receives requests from Australia and the United Kingdom, design considerations may include locating each of the two servers in, say, Sydney and London.

Another consideration is to locate each of the servers at entry points into corporate firewalls or networks. For example, suppose a company based on the West Coast of the United States has its corporate firewall entry points distributed between Los Angeles and Seattle. A good design choice is to locate one server in each of the geographically distributed firewall centers to gain both sites' redundancy but also allow a level of Internet interconnection redundancy. With these types of distances, the servers aren't located far enough away that the distance (equaling latency) starts to become a problem.

The other design consideration for this topology is if your application architecture allows or requires a thick Web server model. In this case, predominantly your presentation layer is located on the Web servers and only business logic (i.e., data tier integration, EJBs, JMS, and legacy systems integration) is located on the application servers. Both tiers are operating WebSphere.

Figure 5-15 depicts a thick Web server WebSphere topology.

click to expand
Figure 5-15: The dual Web server thick model

This modified version of Figure 5-14 is the first of the topology designs that incorporates server or horizontal redundancy. In this model, the Web server operates both a static Web server application, such as Microsoft IIS or SunOne Web server, as well as the WebSphere application server for presentation layer components (e.g., JSPs, servlets, etc.). This topology provides the ability to load balance the presentation components of your WebSphere application. That is, components such as JSPs, servlets, xHTML, and so forth can be distributed for both performance and redundancy purposes.

This type of model starts to prove itself quite powerful for those application architectures that don't have a great deal of business tier components ”those components being EJBs and legacy systems integration. For example, you may have an online ordering system in which the presentation components are used to perform the interface to the backend system as well as the formatting, composition, and display of the output retrieved from the backend database and application servers.

To further illustrate this concept, Figure 5-16 places some components into the topology of Figure 5-15 that help explain what can be achieved here.

click to expand
Figure 5-16: Component mapping for a thick Web server topology

Figure 5-16 shows an architecture in which JSPs, servlets, EJBs, and JDBC integration is used. Table 5-1 discusses each of those components and how it fits into this topology in more detail.

Table 5-1: Overview of Example Components

Component Type

Example Purpose

JSP

Used to compose and display the data retrieved from servlets and, ultimately, the backend database servers. They are lightweight and highly distributable. In this application example, the JSPs format the HTML and placement of dynamic data.

Servlets

Used to perform the controlling of the data retrieval to the backend components (EJBs) and massaging of data returned from the EJBs. In the example, the servlets communicate to the EJB methods directly.

EJBs

Used to perform the workhorse functions of the application. The EJBs communicate to the database server by binding to JDBC data sources configured within WebSphere.

JDBC classes

Used to enable you to communicate from your container or application components, via JDBC. JDBC classes are simply Java classes (JDBC Type 2 or Type 4, primarily) that are provided by your database vendor. In this example, the JDBC classes are used only on the application server and are referenced indirectly by the EJBs components via the use of a WebSphere data source.

Note  

A term I've used several times in this chapter and haven't discussed in much detail in previous chapters is data source. "Data source" is typically the name given to data tier provider components. That is, ODBC or JDBC classes that are provided by your database vendor will be used to create a specific data source to your data tier. This may be an Oracle database, DB2 database, or any other of the multitude of data tier engines available on the market (e.g., RDBMS, OO-DBMS, LDAP, etc.). Essentially, a data source is a construct that you create within WebSphere that manages the pools of connections for each instance of your data tier interface for your application components. In your applications, you will typically bind to the named data source via a JNDI lookup, and WebSphere will in turn, via your configured data source components, provide your application with a pool of connections.

This type of topological architecture is a good solid design, both from an infrastructure and an application architecture point of view. The key to this topology is that components are split or tiered correctly in that presentation components are on one tier, business components are on another tier, and database services are on the data tier. This is an architectural purist's and the J2EE specification's preferred base model.

Why Split the Components into Their Own Tiers?

Apart from providing a clean design, distributing components in this fashion provides a more modular system. You can complete upgrades and software changes easily as you distribute your components more, and redundancy starts to become inherent in the design. As you'll see in upcoming sections, the more you distribute your design, the more you're able to gain performance benefits and redundancy, albeit to a point.

Also, with general J2EE design, the JSPs and servlet components are typically used more. In many cases, it may just not be necessary to use EJBs for each and every user transaction. You may only use a call to an EJB once or twice in a user's session, because it may be possible to load up the required information on the user's initial login via a call to the EJB (and hence the database). As you saw in earlier chapters, the aim in performance is to keep the loading model as a carrot or funnel, with the small or pointy end referring to the small amount of connections and transactions (the database) and the large or wide end referring to the large amount of connections and transactions (HTTP and JSP connections).

EJBs are heavyweight elements of an application. They are expensive to maintain through infrastructure; therefore, if you can ensure that the design of your topology (and your application!) only uses EJBs when required, you'll find that the platform will operate far more efficiently.

It's worth noting some further points here on the schools of thought surrounding EJBs. You may read or hear some developers or architects say, "Don't use EJBs ”they're expensive and they're kludgy." My personal opinion is that, yes, in previous version of J2EE (1.1 and, to a far smaller degree, 1.2), EJBs had some serious questionable design elements that made them almost a nightmare to deal with.

In more recent J2EE versions, such as 1.3 and 1.4, EJBs have come a long way and are now powerful components. But, like any piece of the model, they need to be used where and when appropriate. You wouldn't use them for presentation construction (don't laugh , I've seen it), and you wouldn't purposely design them in your application just because they're distributable.

The other end of the spectrum is that some people tend to use EJBs too much. I feel that many people believe that they must use EJBs because EJBs are considered to be a major part of J2EE. Again, to a degree, EJBs are a major part of J2EE, but as you learned in Chapters 2 and 3, J2EE is made up of many components and the EJB specification is just one of them.

My generalized rule is as follows: If you need to expose something, whether it be tables in a database, directories from an LDAP cluster, results from an MQ call, or data from a SAP financial system, EJBs are a very sound way to achieve this. It's technically possible to perform this via servlets and other presentation components, but EJBs were designed to provide and perform distributable business integration logic.

Advantages

As you've seen, this topology starts to show the beginnings of a sound and highly available platform design. Here are the key advantages of this platform:

  • Load-balanced frontend tier: This is a good model for thin application environments, but if your budget is constrained and your firewall and business rules allow for it, using a thick Web server model to place JSPs and servlets (under WebSphere) on dual-node Web servers provides a sound design for high availability.

  • Overall increase in platform performance: Performance improvements will start to be apparent in this design over that of the previously covered topologies. Again, based on a thick Web server model, you'll be able to operate between 70 and 100 percent more load due to the dual-node Web servers. The reason the load improvement isn't always 100 percent is that the factor of performance for your presentation components operating under WebSphere are still at the mercy of the business tier (EJBs and the like also operating under WebSphere). If every user transaction requires a database lookup, then you're limited to the performance of the backend tiers, which are single-node only. If one large transaction comes through, chances are it will have an effect on the overall performance of the application, whereas with a multinode backend system, the likely impact of an abnormally large transaction will be somewhat smoothed because of the separate physical processes.

  • More resiliency to DoS and abnormal transactions: I touched on this in the previous point. Additional servers (or single servers with multiple CPUs and multiple JVMs) can assist systems managers and capacity planners with tackling abnormal transactions. In today's software industry, regardless of how good the capacity modeling may be, there will always be a superfluous transaction that gives a server a pounding. Likewise, with worms and DoS attacks almost as common as spam e-mail, it's important to ensure that production and business-critical systems are resilient to these types of issues. Therefore, the dual frontend Web server configuration will help contain unusually large or abnormal transaction in most cases. Although there are still single nodes on the backend (application server and database), this topology does introduce a solid design principal in J2EE applications (and almost any online applications, for that matter).

  • Cost-effective availability when using the thick model: In this topology, the cost of the implementing dual backend application servers may be beyond many budgets , the reason being that in most cases, servers that operate EJB containers are typically more expensive than those that operate servlet containers. Therefore, if you use a thick Web server model, you achieve a sense of high availability with a good return on investment (see Chapter 2).

Disadvantages

You've seen that this topology does provide some solid design principals and the measurement of these is high performance and a good level of availability/redundancy. However, you're still faced with some disadvantages in this configuration:

  • Possible false sense of redundancy security: Although I've stated that this topology provides a fairly solid level of redundancy in the presentation tier, you shouldn't be too complacent and believe that this topology is completely sound from a redundancy perspective. As I mentioned earlier in this chapter, if your budget can afford it, double everything.

  • Limited scaling in the application tier: Because this topology has only a single application server, the implementation of components on the application server tier may not support high distributability. That is, although the application tier is typically associated with EJBs, not all software components on the application tier are EJBs. Don't fall into the trap of thinking that because the components are sitting on an application tier they're EJBs and/or distributable. Standard JavaBeans, serialized objects of many sorts, and other associated Java components aren't typically distributable, or at best they may require code changes to support a fully distributed platform.

  • The database tier is a single point of failure: Continuing on with the last point, the database server is still a single point of failure. It's all well and good to ensure that the presentation tier is load balanced, but my belief is that 80 to 90 percent of applications will use a database for application data storage, and for WebSphere version 4 the repository may sit on the database tier. Therefore, if the database is down, chances are that the application is down.

  • Security with a thick model: Consider the points I made about firewalls earlier in the chapter. Your application architecture and your security policies may forbid having JSPs and servlets in a DMZ in which those types of application components may need to be behind a firewall. In this case, you'll typically lean toward using a thin Web server model (there are ways around this, but moving to a thin model is the most common and recommended method).

Final Considerations

As you can see, in this chapter's coverage of topologies so far this model is the most advanced. It also offers the best availability and performance, but it still lacks, in my opinion, the true scalability, availability, and performance that medium- to large-scale mission- or business-critical applications require.

However, this topology is a very sound and well-priced model for applications that are heavily based on JSPs and servlets. If your application only accesses the backend tiers (application and database) on an infrequent basis, then this model is a good choice.

Multiapplication JVM, Dual Web Server, Single Application Server Topology

The next "step up" in topologies is to look back at the use of multiple JVMs for the various containers. When I discussed this concept earlier in this chapter, I didn't discuss at length the use of multiple JVMs in thick models. This topology explores the concept further and looks at ways of splitting up your application so that you can make better use of split JVMs.

Tip  

Remember that in most cases, the use of multiple JVMs on a single server is only beneficial if the server has multiple CPUs. Smaller environments can get away with single CPUs and multiple JVMs if the workload is low; however, as a rule of thumb, any contained application should operate on its own JVM.

Firstly, let's look at a standard application operating on a single application server. Figure 5-17 highlights a basic J2EE application design that contains both business and presentation components.

click to expand
Figure 5-17: A basic J2EE application operating under WebSphere

As you can see in Figure 5-17, a single WebSphere instance is operating, and within the singular WebSphere instance is a single J2EE application server ”a JVM. Inside the JVM is a deployed application bundled within an EAR file. That EAR file contains a WAR file containing all the JSPs, servlets, and static components (GIFs, HTML, etc.), and the EAR also contains an EJB-JAR, which contains EJBs classes and descriptor components.

The EJB and servlet containers can both use split JVMs independently of one another. That is, an application can be broken up into its Web-based and EJB-based constituents. It is then possible to run an application with two JVMs under the servlet container, operating the Web components (i.e., JSPs, servlets, etc.) and two JVMs under the EJB container operating the backend components (i.e., EJBs, standard JavaBeans, etc.).

Note  

Remember that the use of multiple JVMs should be coupled with the use of multiple CPUs. Basically, if you're considering using multiple JVMs to gain performance, you should include an application server with multiple CPUs.

This seems straightforward and, in fact, it is. When you deploy your application EARs into your WebSphere environment, the deployment tools that you're using (as provided by WebSphere) take care of scoping where the different parts of the application need to go, how they're interfaced back into WebSphere itself, and how they run.

Figure 5-18 shows a slightly different view of a standard WebSphere deployment. The difference here is that the Web and EJB components are actually deployed into different application servers, which results in the components operating in different JVMs.

click to expand
Figure 5-18: A split Web and EJB container JVM configuration

Figure 5-18 shows the concept of a split configuration for the servlet container and the EJB container. Although this alone doesn't provide a large increase in performance, it does aid in the operational management aspects of a WebSphere implementation.

Like most of the designs you've seen and the recommendations I've provided in this chapter, the more you can compartmentalize your application environment, the better. There may be some extra overhead during development to cater for this, but it's only an incremental amount, and the payoffs are great. Consider the benefits from a dual application server configuration with a split Web and EJB container configuration. The ability to mesh the communications between the multiple application servers and to turn on and off specific components and services at will makes for a resilient and manageable WebSphere environment.

What's most different in this configuration is that the deployment of the application components to WebSphere is split into two EARs. One EAR contains the application WAR file(s), and the other EAR contains the EJB-JAR and standard JAR packages that may contain standard JavaBeans and associated components. This can provide a slightly increased level of redundancy because in the event that, for example, the EJB-based JVM/application server crashes, the Web-based JVM/application server will continue to operate.

Of course, if your Web components are dependent on the backend components, then only a dual tier or redundant application servers (i.e., redundant application JVMs) will make this configuration beneficial. If this is the case, and your frontend components (e.g., JSPs and servlets) are dependent on backend components (e.g., EJBs), then the use of server groups and WebSphere clusters with multiple nodes (depending on which version of WebSphere you're operating) is a sound solution.

Let's now take a more detailed look at the dual Web, single-application server, dual JVM configuration, as shown in Figure 5-19.

click to expand
Figure 5-19: A dual Web, single application server, dual JVM topology

The most obvious difference here is with the additional JVM instances operating within the application server. In this example, the dual JVMs are operating both. So as to not confuse the differences between WebSphere 4 and WebSphere 5, this diagram doesn't show the underlying detail associated with workload management on both versions of WebSphere.

In WebSphere version 4, the multiple JVMs can be configured into a single server group and operate as clones. As I discussed in Chapter 4, server groups provide the mechanism to group multiple application servers, or clones, into a single administrative group. Primarily, server groups provide a way of implementing workload management (WLM) for J2EE applications under WebSphere. Application server clones are literally clones of one another. They coexist and operate within different JVMs and are managed by the server group WLM process (e.g., configurations, status, stop and start, etc.).

In WebSphere version 5, this concept of multiple JVMs is slightly different. The definition of a WebSphere cluster is more evident within WebSphere version 5, and it essentially replaces the concept of a server group. Node agents and the Deployment Manager are new components that join to make WLM function within WebSphere version 5.

At a high level, the way in which the two JVM application servers operate is dependent on whether the application environment is using Web-based or thick-based Java clients. Assuming for the time being that you're considering only Web-based architectures, the way in which this topology operates is simple, yet effective.

The frontend Web servers maintain a list of application servers via the implementation of the XML-based HTTP server plug-in file. This plug-in file lists multiple server entries for each available service. In a WebSphere version 4 world, the plug-in file will contain multiple Transport entries for each of the application servers or JVMs operating on the single WebSphere server. Each entry has a clone ID associated with each of the application server clones. This provides a way of allowing the plug-in logic to route the user request to the appropriate application server. If server affinity is used, the affinity is achieved by attaching the clone ID of the originating application server clone to the end of the session ID.

Tip  

Be sure that you have WebSphere generate the plug-in file and cut and paste it to the location on your Web server. Removing and or changing the names of clone IDs can result in your users' sessions being nuked.

In this fashion, the frontend Web servers will receive requests, confirm the URL context is valid (e.g., http://somesite.com/MyContext/ ), query the route path (found within the plug-in), and then deliver the request to the backend application server clone.

Note  

The plug-in allows for several methods of routing requests through to the backend application server clones. Round-robin, weighted load-balancing, and variants associated with server and session affinity are possible. Consider the selection of these carefully as each of routing types has plusses and minuses. I discuss this in more detail in Chapter 8.

WebSphere version 5 operates in a similar manner. Slight changes are evident in the plug-in file configuration (I discuss these changes in Chapter 7), but the basic concept is the same. The key difference is that the requests sent from the one of the Web servers on the frontend to the backend application servers aren't going to clones but instead are being directed to application server instances.

It's important to note that routing requests to non-Web-based components such as EJBs and so forth also fall under the WebSphere WLM system. I discuss this topic in more depth in Chapter 7, so for the purposes of covering this topic in the context of topologies, let's briefly look at non-Web-based WLM.

Non-Web-Based Workload Management Topology Considerations

For non-Web-based WLM, the differences in topology design considerations are somewhat varied. WebSphere version 4 provides WLM of non-Web-based components, such as EJBs, via the use of an ORB plug-in that understands WebSphere WLM. The ORB plug-in, like the HTTP Web server plug-in, maintains a list of available components (e.g., EJBs and JavaBeans) and directs requests to the appropriate service when requested .

WebSphere version 5 has a slightly more advanced implementation of non-Web-based WLM. Through the use of the Deployment Manager, client requests bootstrap against the Deployment Manager and within the resulting IOR exists a route table available to backend services and servers. The Deployment Manager continuously integrates the WLM-available components, such as EJBs, and maintains the list for subsequent client ORB requests.

As noted, I discuss this aspect of WebSphere WLM in greater detail in Chapter 7. For now, let's look at the advantages and disadvantages of this specific topology.

Advantages

It should now be clear that WebSphere is a very powerful application platform when it comes to distributed applications. This topology starts to open up WebSphere's powerful WLM capabilities. As you'll learn in Chapter 7, WebSphere's almost seamless integration of WLM features into the core platform makes it a market leader in the area of highly resilient and scalable application platforms.

That said, the topology you've just looked at is a solid performer in the areas of availability and potential application performance. Here are some of the key advantages of this topology:

  • High levels of availability: Through the use of WLM capabilities within WebSphere, the topology allows for a very scalable model for platform availability. The use of multiple JVMs as well as multiple entry points helps to promote very high uptimes . This topology may be able to provide greater than 99.9 percent availability with the use of high-end servers from the likes of IBM, Sun, and HP. These vendors , as you learned in Chapter 5, all offer advanced system-availability capabilities (e.g., SunFire servers from Sun). These types of systems may provide an alternative to more expensive multiapplication server topologies, which we have yet to look at.

  • High levels of performance: With the compartmentalization and splitting up of applications into multiple JVMs, you gain a level of performance over that of singular JVM applications.

  • Solid return on investment/good price for the performance: This topology provides a good baseline for performance at a reasonable price. This topology could be achieved for under US$30,000 using Intel CPU systems, assuming two Web servers, an application server with multiple CPUs, and a database, also with multiple CPUs.

Disadvantages

The disadvantages of this topology are somewhat similar to the other multiple JVM-based topologies. The extra requirement of a JVM typically means that one or more extra CPUs are required, and the architecture of your environment can quickly go down the path of a very vertically scaled solution.

This is fine from a performance point of view. An application architecture that can operate within a vertically scaled environment is good, but there are still limitations to the architecture's availability. In my view, an environment isn't designed for or capable of high levels of availability if there is limited or no use of horizontal scaling present in all tiers.

I suppose what I'm getting at is that although this topological architecture is sound, you shouldn't become complacent and believe that it's foolproof from an availability or redundancy perspective. As I've said many times before, availability and/or redundancy above 99 percent may just not be required by some installations. This specific topology will support greater than 99 percent availability, but it won't guarantee greater than 99.9 percent availability.

You may argue that if your single application server is an IBM iSeries 960 or a Sun SunFire F6800, for example, both of which have very sophisticated levels of internal hot redundancy, it doesn't matter how many servers you have in your application tier. To a point, this is correct. Where the argument breaks down is that you're still limiting yourself to a single WebSphere instance and a single physical server. A physical server can only be in one place at any one time; therefore, if that sole server is located in a site that suffers a catastrophic failure, then the application will cease to operate.

At the same time, IBM WebSphere versions 4 and 5 are, after all, just software. Like any software, they're susceptible to glitches and bugs . Therefore these versions contain within themselves a single point of failure.

Final Considerations

Like most of the multiserver topologies you've examined in this chapter, this model is well suited to implementations that require greater than 99 percent availability but don't require greater than 99.9 percent guaranteed availability. I recommend that you use this topology for non-mission-critical systems. It will work well with a small- to medium-sized production system that can get away with a few hours of possible downtime per month.

Consider using highly redundant servers for the middle tiers to help with availability. You'll find that for the price of the more sophisticated hot-replication server technologies available from companies such as HP, Sun, and IBM, you're better off for small- to medium-sized environments to go down the path of a fully scaled, fully redundant topology such as one from the upcoming sets of architectures.

Multichannel Topologies

Multichannel is the term I use for the deployment of two or more application paths within an application environment. Essentially, it refers to the paths that the application can take.

In the previous sections, you looked at single-channel and hybrid single-channel architectures in which one primary WebSphere application server operated for the business application tier. As noted, this type of single-channel configuration is fine for small- or medium-sized application environments, which may just not need the guarantees of high availability. However, for those production application environments of any size that are deemed business or mission critical, the only choice is to make use of a multichannel topology.

In this part of the chapter, you'll explore the major components of several topological architectures that are based on a multichannel model.

Multi-Web Server, Multiapplication Server Topologies

As this section's title implies, I discuss the design considerations around multiapplication server topologies in this part of the chapter.

The key difference in this topology is the inclusion of an additional server, which operates the core WebSphere application services. Not unlike a multi-JVM installation, this topology almost appears, from a WLM perspective, to be similar to a dual Web server and multi-JVM topology.

Figure 5-20 shows an overview of the architecture of a multiapplication server implementation. The most obvious feature is the second WebSphere application server, which services requests from the frontend Web server environment.

click to expand
Figure 5-20: A multi-Web server, multiapplication server topology

Traffic or user requests are routed through to one of either of the application servers, just as if they were two JVMs on a single application server. For all intents and purposes, the HTTP plug-in doesn't know the difference between the two topologies.

This topology provides a solid base for a very scalable and high-performing application server environment. With the additional application server operating, there are myriad additional operational management capabilities available to you. For example, depending on how you decide to design your end topology, it's possible to have the two WebSphere application servers operating as two independent applications, or WebSphere domains for version 4 or WebSphere clusters for version 5. That is, from a WebSphere perspective, you may have two separate WebSphere domains or clusters (WebSphere versions 4 and 5, respectively) which, although operating the same application components, don't share administrative or internal WLM space.

This is a hybrid of the multiapplication server topology that I discuss in more detail shortly. The point that I'm trying to make here is that the inclusion of an additional WebSphere server (a physical node) paves the way to a whole range of possible options in your architecture.

Let me reiterate the two primary goals for platform resiliency: remove all single points of failure and remove all interdependent components. Having a second WebSphere server (a physical server) satisfies these two goals. Figure 5-21 illustrates this concept.

click to expand
Figure 5-21: Single points of failure in a WebSphere environment

At the most simple level, if server B failed (e.g., via CPU panic or server freeze), the HTTP plug-in on both of the frontend Web servers would realize this, mark server B as dead, and push all requests through to server A. In this case, the single point of failure has been eliminated because you have a secondary server. Simple, right?

If you have the same environment as Figure 5-21, and if you're running a WebSphere version 4 cluster and the database repository on the database server became corrupted or crashed, the entire environment will fail. This highlights a single point of failure.

Split-Brain WebSphere Configuration

I mentioned earlier that you might consider splitting the environment into two separate WebSphere domains or clusters. This can introduce some extra overhead from an application development and possibly a network traffic point of view, but it does promote an ultra -high-availability environment.

Essentially, in this case, the only component that would need to be shared would be user sessions. That is achievable by still having the WebSphere servers split into separate domains and clusters, but if you need user sessions to be available from both sides of the environment, you would share the session repository database that you would create within the WebSphere main console for each WebSphere application server.

The other way to help provide this is to use sticky routing or server affinity for sessions. In this way, once a user logs onto a WebSphere application server, the user remains there until he or she logs off or until the server crashes and the request is forced over to the secondary server.

Depending on how you persist your sessions (i.e., manually, through an end-of-service update, or periodically), the session may be preserved or it may need to be re-created. If it's the latter, this typically suggests that something isn't right within your application (e.g., your application is unable to handle session failures) or the WebSphere environment isn't configured correctly.

All this depends also on how dependent your applications are on the session being up to date. Consider this situation: Your application developers may use the session to store things such as credit card information and payment details. A payment transaction is presented over several pages, and on each page more and more detail is built up about the payment transaction. If, let's say, server B fails midstream during the user clicking through to set up his or her transaction, one of the following three things will happen:

  • The entire transaction will fail because your application isn't able to handle session failures of any type.

  • WebSphere won't persist the last session update. This is configurable within WebSphere, so it may be caused by a misconfiguration, or if your site is high volume, your database server may not be keeping up with all the requests.

  • The next page presented to the customer will be slightly delayed while the WLM process kicks in and the session details are obtained by server A.

Application Server Capacity Considerations

It's all well and good to have two or more load-balanced application servers operating within your WebSphere environment, but I'd consider your design flawed if your customers are impacted by poor performance if in the event of a server failure the remaining load-balanced infrastructure is unable to keep up with the load.

The rule I always follow is this: In a high-availability environment with two servers in a singular tier, no server should ever exceed 40 percent utilization. The reason for this is that if one of the servers in your specific tier crashes and the remaining load is all placed on the other server, that other server will theoretically need to ”almost instantly ”handle twice its load. You'll need to add in some additional overhead, especially for the failover period. Therefore, if you have two servers operating at 50 percent utilization and one fails, the remaining server will need to double its load, effectively taking it over 100 percent utilization. You'll soon end up with two dead servers!

As you add in additional servers, this becomes less of a concern. For example, if you have three servers, each server should not exceed 50 percent load. This is worked out by saying, if one in three servers failed, with all servers operating at 50 percent load, then the remaining two servers would theoretically need to handle an additional 25 percent load. This would take the operating load of each server to 75 percent plus overhead.

My rule of thumb is that, in a single server environment, no OLTP or online server should ever exceed an average 60 percent utilization. Go beyond this and there's a mismatch in your capacity model. Consider upgrading to faster CPUs or adding in additional CPUs (then again, it could be that your server is swapping madly due to insufficient raw memory, and you need to upgrade your memory). When you have more than one server, such as the previous three-server example, in a failover scenario in which you may have one server crash, the remaining servers should not exceed 80 percent load.

So, stick to a threshold of less than or equal to 60 percent load for maximum average utilization for a single server and less than or equal to 80 percent load for maximum average utilization for multiple servers during a failover scenario. The 80 percent rule is only valid during unusual operating periods, such as a failover.

Caution  

The golden rule is that you should never run your system at 100 percent utilization. It amazes me how often I see sites that let their server operate at 100 percent utilization. There is a big difference between 100 percent effectiveness of your operational platform and 100 percent utilization of available resources. At 100 percent utilization, an operating system isn't doing what it should be doing, and instead it's working madly trying to handle an unworkable load with limited resources.

My guess is that during a failover situation, you'll want to focus on fixing the dead server, not trying to diagnose the load on the other remaining servers. You don't want to be at a command prompt (for Unix) or in your Services Manager (for Windows NT/2000/XP) and have to wait seconds for a response to issued commands and requests.

From a J2EE JVM perspective, remember that when a JVM conducts garbage collection and other housecleaning routines, most of the processing and thread work ceases for a second or so (depending on the size of the cleanup and the amount of memory consumed). During this time, your application will freeze until the garbage collection completes. Now consider what will happen if your JVM is attempting to contend with basic operating system threads ”we all know which process will get priority, and your application will stand still for a long time during excessively high system utilization.

Database Considerations

I discuss this in a little more detail in the upcoming sections, but just briefly, designing your WebSphere topological architecture in this fashion is only going to be worthwhile if you're able to build in some redundancy to your database server tier.

Consider hot-standby databases or database clusters in either highavailability/active-standby or active-active configurations. Failover times between active-standby servers varies, but you'll need to ensure that the failover time doesn't exceed that of any HTTP session time-out, user browser time-out, or any other form of idle or I/O time-out value.

This concept also obviously applies to the application databases. Unless you use a sophisticated database caching system or you have low-update data tables all depersisted by CMP or BMP, chances are that your J2EE applications will be unable to operate without being able to retrieve data from a database.

You'll take a more detailed look at the WebSphere database architecture at the end of this chapter.

Advantages

This topology is a true high-availability WebSphere server environment. As you've seen, at least two Web servers, two application servers, and a database server are available, all of which provide high levels of redundancy.

This topology can be extended greatly to more than two Web servers and two WebSphere application servers. Once you've designed your base architecture, adding on three or more application servers is almost trivial. Minor changes to the frontend HTTP Web server plug-in files provide the ability to scale out horizontally to any number of backend servers. Here are some of the key advantages of this topology:

  • High availability in the WebSphere application tier: The addition of a secondary WebSphere application server in the business tier helps to provide redundancy. If your topology is a thick Web environment (i.e., WebSphere operating as a Web/servlet container on the Web servers, and an EJB container operating on the main WebSphere application servers), your application environment will be highly available. Redundancy in all tiers is the Holy Grail of a J2EE application environment, and this topology comes very close.

  • The cost isn't necessarily high: If you're running a smaller production environment and you're using Intel/x86 systems for your servers, you'll find that this topology, though highly available and scalable, is in fact not overly expensive. Depending on how high you spec your servers and the level of advanced features you include in your server specifications, you could get away with a full environment of this topology for under US$30,000. Of course, if you're more inclined to build your own x86 systems (i.e., clones), then you'll be able to roll out a system like this for possibly 50 percent less.

  • Ability to conduct in place upgrades for 90 percent of your application changes: Because this topology incorporates redundancy and load balancing at both of the application logic tiers, it allows you to shut down one channel of the application environment at a time and upgrade the application on that specific channel, without impacting customers and production load. This only works, however, with two provisos: first, as long as your application logic isn't upgrading or altering the shared database application schema on the database, and second, so long as you've designed your application so that one channel can handle the entire load of the production load. As I've discussed, there's no use having a load-balanced application topology if, in the event that one channel or server goes down, the remaining infrastructure is unable to maintain the load and service level response times deemed required.

Disadvantages

Obviously, as you add in more hardware, costs are going to increase. Hopefully in the business case that you've put together, the benefits to your business and the costs associated with additional servers are outweighed by the benefits of higher availability.

The other disadvantage with this level of environment is that it starts to become more complex. You and your team will need to build up operational skills to ensure that people are aware of what to do during outage periods, to manage the system during upgrades so that there is no outage, and to ensure that everyone on your team is clearly aware of how everything hangs together. You don't want to spend a great deal of money on a high-availability WebSphere system and then find that it's coming down often because of "operator error."

Final Considerations

As with most network-based and distributed computing platforms, as you add in additional servicing components such as WebSphere applications servers, the complexity or interconnection of components increases constantly in direct proportion to the number of components. For this reason, carefully consider things such as interconnects and backup networks, and their impact on your topological architecture specific to your network topology.

It's all very well and good to have high-speed E1/T1 links and ATM-type connections for distributed systems, but if the distances involved are such that the latencies are high, no matter how many servers you have and how big they are, you'll encounter problems with so many transactions trying to go over high-latency pipes. Design your topology to be compartmentalized. Plan it as if you were designing many separate applications in different locations, and consider sending data over long distances only when or if required.

Multiple JVMs with Multiapplication Servers

As you've seen, the use of multiple JVMs within WebSphere application servers serving the same application provides a very healthy platform design of high availability. To recap, the use of multiple JVMs within WebSphere allows you to run more than one instance of your deployed J2EE application, whether it be a Web or EJB container deployment.

You'll recall that in a Web-based environment, the HTTP plug-in on the Web server tier is configured to route the user requests through to the backend Web container within the WebSphere application server, based on a predefined load-balancing setup (e.g., round-robin, session affinity, server affinity, etc.). This design allows for high levels of redundancy and performance, given that not just one virtual machine is doing all the work. Remember, though, that the use of multiple application JVMs will need to be considered along with multiple CPUs in order to gain a performance improvement.

Note  

I've also noted in this chapter and in earlier chapters that for small applications the need for multiple CPUs with multiple JVMs may not be required after you've conducted performance modeling. My rule of thumb is to always start out with the notion that for each JVM you have, you operate at least one CPU.

If you take this model for multiple JVMs a step further and apply it to the previous topological architecture that you looked at (multiple application servers), you have a recipe for a high-performing, high-availability, and high-scalability WebSphere platform. Consider Figure 5-22.

click to expand
Figure 5-22: Multiple application servers with multiple application JVMs

Figure 5-22 illustrates a topology that uses a dual thin Web server model and two backend WebSphere application servers, each operating two J2EE application server clones (in a WebSphere version 4 environment) or application servers (in a WebSphere version 5 environment) in a server group or server cluster (WebSphere version 4 and 5, respectively) configuration. The two thin Web servers are both operating static Web servers with the HTTP WebSphere plug-in. The plug-in would be configured so that it traps the configured context for the backend applications (those in the clones and or application servers) and routes the request accordingly based on whatever the chosen load-balancing rule is. The request is routed to the most appropriate backend JVM process, based on the configuration settings within the plug-in file.

In this type of configuration, you have a platform that can withstand server outages (both Web server and WebSphere), application failures (e.g., crashed JVMs), failed network components, and many other WebSphere and operating system problems.

In the upcoming chapters, I discuss the benefits of using a high-availability database. The only component missing from this topology in order to guarantee greater than 99.9 percent availability is the redundancy in the database.

Non-Web-Based Application Considerations

While continuing to focus on the Web-based aspects of WebSphere topologies, I need to keep noting the benefits associated with these topologies that are associated with the backend components such as EJBs and so forth. I discuss this in more detail in the next chapter (Chapter 8), but I'll note here that this specific type of topological architecture provides a great deal of high availability and performance benefits for non-Web-based components such as EJBs.

As I've touched on several times, EJBs' " homes " are obtained through context lookups to the WebSphere JNDI tree. The actual act of the lookup and the internal management of this "tree" is slightly different between WebSphere versions 4 and 5, but for the purposes of this section assume that a JNDI lookup for a particular EJB is not different between versions.

The key point to note here is that if you go down the path of a split-brain architecture, in which the two WebSphere instances on the two channels are independent of one another, the ability to access multiple EJB homes on different servers isn't possible within the standard framework that WebSphere provides. For that reason, using mechanisms such as multiple JVMs per WebSphere instance provides the ability to "cluster" EJB and other data tier services.

If, on the other hand, your topological design doesn't use a split-brain approach, the resulting architecture with multiple JVMs means that you can cluster EJB and data tier services across multiple physical servers. This greatly increases your business logic availability, which most of the time is critical to the application operations.

One you should remember is that EJBs are considered "heavy." That is, they exhibit a fair amount of network traffic for all the transaction setup (e.g., location of the home interface, instantiation, passivation, etc.). The more recent EJB 2.0 J2EE 1.3 specification provides a more environment-conscious EJB framework, whereas previous versions of the EJB specification (e.g., version 1.1 in J2EE 1.2) were ghastly and caused headaches for network engineers on large J2EE-based application environments.

Although things have improved, there is still a degree of transaction overhead necessary for EJBs to work. My belief is that this is just a part of the use of EJBs and therefore shouldn't pose a problem. If you need distributed components within your application architecture, then by all means, use EJBs, but use them wisely. Consider using EJB facades to standard JavaBeans if possible, which will reduce overheads.

These days, the cost of 1Gb Ethernet over that of 100Mb Fast Ethernet is trivial. For the majority of WebSphere applications, the costs associated with 1 hour of downtime due to the nonuse of EJBs, will be greater than or equal to 5 times the cost of implementing gigabit-based switches.

Extensions to This Topology

You can do a number of things to help improve the redundancy of this specific topological architecture. Consider design aspects, such as ensuring that the WebSphere application servers are themselves highly available. That is, if budgets permit or your application is truly mission critical and just can't go down, look into the advanced hardware capabilities from IBM and Sun that provide hot-swappable, hot-upgradeable, and highly redundant server chassis.

As I discussed in the previous section, split-brain or split-WebSphere-universe configurations add another few notches to your net availability. Consider the model in Figure 5-23.

click to expand
Figure 5-23: WebSphere high-availability extension

Figure 5-23 shows a topology similar to that of Figure 5-22, with the main difference being that the WebSphere repository database (for WebSphere version 4 administrative control) or the WebSphere cell (for WebSphere version 5 administrative control) is split. That is, there are two separate application environments coexisting and serving as one (as seen from the frontend Web server plug-in).

This configuration insulates the application from cascade JNDI tree failures and other forms of whole application data failures. This will only limit the impact of things such as DoS attacks ”it won't completely insulate a system from one, but it does help insulate the application from cross-contamination from misconfigurations in a server group for WebSphere version 4 or a cell or a cluster within a WebSphere version 5 environment.

Database and Other External Interface Pooling

WebSphere provides a number of connection pooling managers for various resources. These resources include JavaMail components, ODBC, and JDBC-based database interfaces.

Using multiple JVMs has an added advantage in that each additional application JVM is bootstrapped against its own instance of a pool manager. For example, if you have an application that interfaces with a relational database, you'll use a JDBC resource created within WebSphere to access the database. By using connection managers within WebSphere, you get the advantage of a whole range of features such as connection pooling, connection management, and transaction monitoring.

When you go to configure a JDBC resource, you configure a number of parameters (I discuss this in detail in Chapter 11) for settings such as the minimum number of connections in the pool, the maximum number of connections in the pool, the idle time-out, and so forth.

Note  

The reason pool managers are used for interfacing with systems such as databases is to help reduce the load and overhead associated with establishing new connections for every request. Pool managers also increase performance as the connection is already established, and therefore the time to conduct a transaction is not impacted by load or unavailable ports on your database.

Part of the tuning life cycle and your initial capacity modeling of your application environment should also include modeling how many connections your applications will need to the database. Remember, however, that at the end of the day, your database can accept a finite amount of connections and is limited by both CPU and memory in terms of how many simultaneous connections it can handle.

From time to time, however, failures in your application can occur when a database JDBC resource runs out of available connections in its pool. This causes a StaleConnectionException on your JDBC pool manager and, as such, no new connections can be established. If you happen to have only a single JVM application server running, this would cause the application to cease running until an available pooled connection becomes free.

The advantage of having multi-JVM applications is that each application JVM instance obtains its own instance of the JDBC pool manager. As such, if your JDBC resource in WebSphere was originally configured to support a maximum of 75 pooled connections, then each application instance would be provided a pool manager resource containing 75 pooled connections. This compartmentalization helps to insulate each JVM application server from resource exhaustion, which may be a result of buggy application code, excessively long transactions (caused by a badly performing database), or incorrectly modeled settings.

If one JVM exhausts all of its available pooled connections, it doesn't affect the operation of the other application instances.

Note  

Be wary of making the maximum pooled connection setting too high. Although it's tempting to set it to something high, such as 200, you'll do more damage than good with this approach. In Chapter 11, I discuss these settings and how to tune them. Note also that if you set the maximum pooled connection setting too high, you may not have enough connections on the database itself to support all the connections.

Overall, model your database requirements carefully and plan to understand what sort of transaction characteristics your applications will have. It's a costly exercise to have to go back and resize your database or trudge through Java code to fix problems after your application has gone into production.

Advantages

The advantages of this architecture should be clear as day! Although there are additional costs associated with the operational aspects of the environment due to the increased complexity, the overall benefits far outweigh those costs.

Most important, this topological architecture provides a high-performing, highly available environment. The advantages are as follows:

  • High performance: With the introduction of multiple JVMs on multiple servers, your applications' performance should be an order of magnitude higher than that of single server, single instance JVM topologies.

  • High availability: Although the topology isn't dissimilar to the previous topology in the way of net redundancy, the introduction of the additional JVMs does further reinforce the robustness of the application environment. The chances of JVMs crashing are rare these days, yet it does still happen, and other performance- related complications can be just as damaging on a systems performance and availability, as is a JVM crash (e.g., excessive garbage collection).

  • In situ upgradeability: The multiple JVMs provide a way to test and shake out application upgrades without affecting customer or user availability. Although the previous topology could also do this, the testing aspect of a multiple JVM environment wasn't possible and unforeseen complications with sessions and session failovers can cause a verification tests to be nulled.

Disadvantages

The disadvantages to the architecture simply relate to the added complexity of the topology. There should be no application architecture changes required as a result of this topology, but operations staff need to be well trained on the multiple JVM configurations and the methods by which components of an application environment such as this can be brought up and down.

There are additional costs associated with this type of architecture also. These are unlike the costs of the previous single-JVM topology because, as you have multiple JVMs, the rule of thumb states that for every application JVM operating, a dedicated CPU is required.

In a pinch , and for smaller applications, a two application-JVM based WebSphere platform could make do with each server operating just two CPUs. If your application environment is larger, you should consider one CPU for all core process functions (e.g., operating systems, core WebSphere internals, etc.) and a JVM per application.

Given this, the costs increase for CPU hardware, as do license fees for WebSphere (for the majority of cases). However, as I've noted on numerous occasions, if an application environment has been sized and modeled to need multiple JVMs, you could take a punt and say that the very driver behind needing multiple JVMs should be equally applicable to the qualification of having additional CPUs.

Final Considerations

For the majority of all WebSphere environments that I deal with personally , this is always my starting point. My experiences with WebSphere have typically involved large organizations with large customer or user bases; therefore, the needs of these higher availability requirements are fairly obvious.

The one area that you should consider for higher availability designs is the data tier. Essentially this is because, although it's all good to have umpteen levels of redundancy in your application, application servers, and network, as I discussed earlier, if the database goes down, so does the application if it is database dependent.

High-Availability Database Server Topologies

I've noted on several occasions over the past two chapters the importance of a database in a J2EE application. Of course, not all applications will talk to a database for either application- or WebSphere-orientated data, but it's common knowledge that databases are found in the majority of J2EE applications. If data-bases aren't use for data storage, they're used for persisting various objects and data such as session information or even operational auditing and logging information.

If your application just doesn't need a high-availability database, but it does need to be able to log some data, it may be most cost-effective to operate a stand-alone database environment and ensure that your application code can support and handle the various types of SQL exceptions that may be thrown from the WebSphere or your own custom pool manager. In this case, the application just keeps on operating and ignores the fact that the database is down. However, for those in the majority who need databases and whose applications are critically dependant on databases, in this section you're going to explore some of the topological considerations that are important to database tiers.

First, please note that this section doesn't attempt to explain how to configure or manage a database. Instead, I discuss various architectural considerations and best practices for databases from a high-availability point of view, as well as some of the options and features available in the leading databases available on the market.

When you talk about database services, at least from a relational database point of view, you can break them down into four primary groups of availability architecture:

  • Stand-alone (single database server)

  • Hot-standby

  • Active-standby

  • Active-active

As you can probably tell, the complexity of each of those database availability types increases (almost dramatically) as you go down the list. First, let's examine each of them at an architectural level.

Stand-Alone Databases

As its name implies, a stand-alone database server is simply a database operating by itself, on its own. This is the most simplistic view of a database installation and is the quasi-default for any database deployment. A fair majority of database installations operate within this model. It's a time-proven solution, given that the market leader databases in themselves are quite stable, and this solution will suit the purposes of approximately 80 to 90 percent of all installations.

The only issue with this configuration is that it's a single point of failure. As you've seen in previous sections, it's not much use buying several high-availability servers for your application server tiers and having a glaring single point of failure in your database tier.

My recommendation is simple: Use this topology if your application doesn't necessarily need a database to be actively running or if your application is not a mission-critical environment and the costs of something more robust aren't warranted (e.g., a single-channel topology).

Hot-Standby Databases

Again, the name is fairly self-explanatory, but the concept of a hot-standby database can come in several flavors. Essentially, the idea is that you have a two database servers: one is the master and the other is a standby. The configuration is set up as such, so that all changes to one database are synchronized with the second, hot-standby database.

This configuration is a sound solution given the robustness of databases in today's market. Quite often you'll see a database operate without problems for well over a year, with the only reason for downtime being to apply service packages and bug fixes.

The solution has a downside, however. In the event of a primary database server outage, the act of failing over to the hot-standby server is typically a manual one. More recent JDBC drivers from various vendors support connect-time failover and the like, which will connect to the primary database, and if the primary database fails, the JDBC pool manager will automatically attempt a failover connect to the standby. Different database vendors support this in various ways, so take a careful look at your vendor documentation. I discuss this in some detail in Chapter 7.

Overall, this type of configuration is sound and is suitable for production environments of any size. You'll need to consider the final synchronization, synchronization integrity, and failover times associated with a hot-standby server environment. That is, how often do you synchronize the hot-standby with the master? Consider what may happen to your application environment if the failover took place, yet the databases haven't synchronized within the last few minutes. Would this pose a problem for your application integrity and user experience? If so, then hot-standby servers may not be the best choice for your application environment.

Active-Standby Databases

Active-standby database solutions operate typically under some form of clusterware. Clusterware refers to software that manages a whole raft of system-level components such as disks, disk volumes, applications, and other various resources.

Clusters and clusterware is a complex field of software. As such, if you're considering going down this path, you'll need to ensure that your operational staff and engineers are fully trained in the ins and outs of your chosen clusterware.

From a database perspective, however, your database vendor will (or should) have specific cluster-aware versions or management agents of their database platform. In the active-standby configuration, you would typically have two (or more) database servers, each aware of the other and interfaced by private networking connections. The database platform itself would only ever operate on one node at any given time but would interface to a shared storage medium.

The clusterware keeps an eye on the life signs of the database and monitors it for problems and critical issues. If the clusterware layer recognizes a critical failure, it will shut down the suspect database instance on one server node and attempt to bring it up on the secondary node. Because the database files and medium is shared via a shared storage mechanism (or a replicated intelligent storage solution), the newly activated instance of the database should continue on from where the other database instance (the failed one) left off.

Unlike the hot-standby configuration, this model is considered a proper high-availability database architecture. The failover is mostly transparent and general failover times are in the order of 5 to 30 seconds, depending on the level of activity and possible need to shut down in-flight transactions, the load of the database instances, and the state of the overall cluster.

Figure 5-24 shows a typical database configuration when using a clustered active-standby configuration.

click to expand
Figure 5-24: An active-standby database failover

In Figure 5-24, you can see how both database instances share a common data storage device, with only one database having access to it at any one time (the active node). You can also see that there are interconnection network interfaces that are used for internal communications between the two nodes, as well as private IP or proprietary networking communications.

JDBC interfaces to databases will, the majority of the time, understand the failover mechanism and through configuration, tuning, and possibly exception handling within your application code handle the failover and reconnect to the new database instance once it becomes available. However, you'll find that in-flight transactions are generally not failed over, and neither are things such as open cursors . Any outstanding queries will be terminated , and it will be up to your application code to be able to understand the specific exceptions being thrown back and retry the SQL transaction.

This type of configuration is generally considered to provide greater than 99.9 percent availability, and this configuration is one considered valid for a business-critical applications (but not necessarily mission-critical applications).

Active-Active Databases

What I consider the pinnacle of database server technology is the relatively new emergence of true active-active database environments. If you take into account the complexity of a database engine ”transaction management, query management, data file handling, locking, I/O management, and myriad other areas of architecture under the hood of a database ”you should be able to understand why active-active databases are rare.

Oracle has had a product available for a few years now known as Oracle Parallel Server (OPS), and more recently the company has released its Oracle9 i Real Application Clusters (RAC) system. OPS is a parallel server, and although it appears to be active-active, it isn't fully active-active. Oracle9 i RAC, on the other hand, is. Through a sophisticated architecture, Oracle9 i RAC now allows systems architects to have more than one database server servicing database requests. What's very powerful about this is that the queries are load balanced against any one of many databases in the RAC cluster and, as such, if one of those nodes goes down, the outage is 99.9 percent transparent to the application. In-flight transactions, open cursors, and queries are all safeguarded, and transparent failover to another node is possible.

It probably goes without saying that Oracle9 i RAC is a truly sophisticated piece of software. Many things are different in a RAC Oracle database than in a hot-standby or active-standby configuration. The same applies for the clusterware. Clusterware is still required for RAC to operate, as the clusterware manages all the life support systems for the RAC layer (e.g., disks, volumes, resource groups, adaptors, etc.).

IBM DB2 enterprise coupled with the Parallel Sysplex provides a similar capability to the Oracle9 i RAC solution.

Figure 5-25 gives a very high-level view of how an active-active database configuration operates.

click to expand
Figure 5-25: An active-active database configuration

The database (in this example, assume it's Oracle9 i RAC) is servicing requests via both database server A and database server B. Whether you're using thick or thin JDBC drivers will depend on just how transparent this database communication is.

If you're using thick JDBC drivers, you have very little visibility regarding which database instance (which node) you're communicating. For this reason, you would consider that you're communicating with a logical database SID (let's call it MYDB1). If the database instance of database server A fails, all connections, queries, and transactions can be transparently failed over to the other instance operating on database server B. To the application, there is no impact. This configuration is tunable and based on a number of available considerations. You may decide that you don't want failover to be so transparent, because full transparency requires more hardware (because of additional load and connections).

If you're using thin JDBC drivers, you're more limited in terms of your ability to failover and load balance between nodes. However, the services still do exist, and they're almost just as transparent as in a thick connection. If you're using JDBC pool managers such the Pool Manager that comes within WebSphere (and you should!), the JDBC driver within WebSphere will throw a StaleConnectionException when the currently connected database becomes unavailable. Within a second or two, the connection is failed over to the other (or any available) remaining database instance within the RAC cluster.

As you can imagine, this configuration provides very high levels of redundancy and availability. If your WebSphere platform requires greater than 99.9 percent availability, then active-active database configurations are the way to go. If you're operating a mission-critical environment that just can't go down, then an active-active database architecture is almost mandatory.

Note  

Imagine NASA launching the space shuttle and all of its controlling systems operating under WebSphere suffer a 30 “45 freeze while the active-standby database system fails over! You'd want and expect that the database failover is completely transparent to the controlling systems.

Geographically Distributed Topologies

Because J2EE inherently is a distributed platform, it's possible to extend that concept to the n th degree. Many large Web-based applications geographically locate their systems (frontend and backend) to multiple locations in order to help distribute load, as well as provide an added level redundancy (some would say disaster recovery).

A common model is to locate servers on the West Coast and East Coast of the United States. Another model is to locate server into areas (i.e., cities, countries , and continents) in which there is a clear load distribution.

The method to which traffic is distributed is achievable via several ways. The most common method is to distribute load based on source IP. There are various lists and databases available around the Internet that provide a fairly good status of where IP ranges are allocated, such as country or company. Using this mechanism, it's possible to distribute the inbound request to the most appropriate server farm, typically the one located the closest to the requestor . Organizations such as eBay and Google make use of geographic load balancing, and although they're considered to be "mega sites," the concept is still very valid for any organization that deems it a requirement.

WebSphere itself doesn't provide the capability to do this type of traffic distribution. However, several of IBM's products can aid in the distribution of geographically load-balanced systems.

If you're looking to make use of a geographic load-balanced environment, there are some architectural considerations you need to be aware of for your environment to function properly. In the next sections you'll look at some of the aspects of WebSphere that would be affected by load balancing on such as scale and I'll discuss how and what approach should be taken in order to ensure both performance and reliability.

Multiple Web Server Topologies

Probably the most common of the all the geographically load-balanced components of a large system is the frontend Web servers. Figure 5-26 below shows a topology in which a farm of Web servers is located in London, another is located in New York, and another is located in Hong Kong.

click to expand
Figure 5-26: Geographically distributed Web servers

As an example, say that this WebSphere-based application was an online ordering system. Customers would be logging in to order products. Assume that the request rate is relatively large ”somewhere around 10,000 orders per hour. Also assume that behind each Web server farm is a WebSphere-based application server farm consisting of three WebSphere application servers and an Oracle9 i RAC-based triple-node database cluster. So the entire farm consists of the following:

  • Four Web servers per site, totaling twelve Web servers

  • Three WebSphere application servers per site, totaling nine WebSphere servers

  • Three Oracle9 i RAC servers per site, totaling nine database servers

With this model, there are several key issues to consider from a design point of view. First, how do you synchronize sessions over such long distances? Although it may not be a common task that needs to be fulfilled, in the event of a site failure, the remaining sites would need to take on board users' sessions (the sessions would contain the users' shopping baskets , login details, personal profiles, and so forth). Second, how would you synchronize the databases? Over such distances, it would be difficult to replicate the databases in order for them to be able to keep in sync.

The answers are fairly simple. Before reading on, based on what you've learned in this chapter and possibly from some personal experience, consider what you would do.

Now let's look at some ways to get around these issues. There's little need to be able to ensure 100 percent continuity between all three sites for any one customer's session. However, in the event that a site fails, you would need to cater for session failover. Therefore, you would do two things. First, if you were using WebSphere version 5, you would set up weighting rules within your HTTP server plug-in file so that the local systems would have a high weighting and other sites would have a low weighting . Second, you would configure each site's WebSphere application servers into PrimaryServerCluster within the plug-in file and all other servers at other sites in a group called SecondaryServerCluster. Setting this directive means that only servers local to the specific Web server farm will be in use. Only when all local servers are down would the Web servers attempt to redirect requests to WebSphere servers at other sites. In WebSphere version 4, this capability doesn't exist. However, through the use of a product such as IBM Edge Server and or Network Dispatcher, you're able to obtain some of this functionality.

If the entire site was down, the geographic load-balancer device would cease sending requests to the downed site until it determined that servers were up. One way to extend this is to make use of a feature in most high-end loadbalancers whereby they can periodically access specific URLs and look for positive results. A good way to take advantage of this for WebSphere version 4 would be to use the geographical load-balancer to ping a custom-built JSP or servlet. This JSP or servlet would only respond with an "OK" if the backend server was up and running. Easy solution.

Geographically Distributed Databases

Replication of database information is a hard one. Three possible scenarios exist:

  • First, the data is deemed not to be needed to be replicated.

  • Second, the data needs to be replicated, but it can be done in an asynchronous fashion.

  • Third, the data needs to be replicated in almost real time.

You can do away with the first scenario. You can achieve the second in several ways. IBM DB2 and Oracle8 i and 9 i support database replication with myriad tunable and configurable options. You can use third-party solutions such as Veritas Volume Replicator (VVR) to perform the geographic synchronization. Another alternative that I've seen work, although it's a little clunky , is to have the backend WebSphere applications duplicate all database updates, deletes, and inserts . These duplicated SQL statements are performed in another series of threads so as to not slow down the main thread of the users session.

The third way to replicate the database in a real-time fashion would be to use something such as VVR or the features within Oracle9 i RAC, which would allow asynchronous updates to be made to the remote database servers. Highspeed data pipes would be needed to make this reality ”whether it is back over the Internet via a VPN or via dedicated back-of-house data pipes to each site (or a mixture of both).

All of the options within the last two scenarios would provide session and data replication. The response time for the updates is a measure of cost for the bandwidth as well as any licensing that may be required by third-party products.

Geographically Distributed Application Servers

Consider the scenario of an application thread at one site wanting to access a method within an EJB at another site. One possible reason for this would be to send a packing request to the closest site, geographically speaking. A person who is in London may want to send a package to a friend who is located in Hong Kong. In this example, the order would be facilitated in London but either in or out of thread, a request would be made to another site to place the packing request.

This may be just a batch job, but due to the demand of the products being sold online, the company operating this WebSphere-based environment may deem it too time-sensitive. This being the case, with WebSphere version 5, dynamic data replication could be used to globally distribute packing center information or on both versions of WebSphere, a separate administration process could be set up on each WebSphere node that maintains an out-of-bounds location service daemon (LSD) or bootstrap list of where to access these highly distributed methods from.

Additional Application Server Topology Considerations

Another way to compartmentalize your application platform is to split your WebSphere application server into subtiers. I've discussed operating thick Web server models, in which the Web server operates both a static HTTP server and a Web container, processing and servicing all JSP, servlet, and other presentation based requests. You can extend this concept to support tiers such as utility or servlet/Web container tiers.

It's a computing industry dilemma: Do you make your environment more complex by compartmentalizing it but gaining performance, scalability, and availability improvements, or do you keep everything close and tightly bound? My personal preference is to keep same or similar service-based components together, but if there are differences in business logic, operational placement (e.g., utility services versus customer or user- facing services and operational characteristics such as batch versus online), then I recommend splitting them up. Figure 5-27 illustrates this concept.

click to expand
Figure 5-27: A compartmentalized server approach

As you can see from Figure 5-27, the concept of compartmentalization is obvious, with a presentation utility tier serving JSP and servlet requests, and a core application tier serving business logic requests.

Spitting up servers like this can actually make sizing them slightly easier. The theory behind this is that by planning to include all components (e.g., servlets, EJBs, JavaBeans, JSPs, etc.) into a single server, you need to be more precise about your impact calculations between all the components. Whereas, if you have your J2EE components split out to different tiers, your design calculations are easier due to the fact that you're modeling common yet compartmentalized components ”presentation versus business logic.

You may ask about additional network latency decreasing the performance. Although it's true that there will be some additional latency on the servlet container to EJB container requests, you're only talking about below 3 millisecond latency, assuming the two tiers are next to each other (i.e., they're connected via a LAN, not a WAN). At the same time, the splitting of the components into different JVMs will typically result in an increase in network latency, canceled by the decrease in processing time.

As you can see, because different types of services have the potential to work against one another (i.e., they have different load and operational characteristics), it's sometimes good practice to compartmentalize. Consider that a batch type process that goes berserk won't affect user-facing performance.




Maximizing Performance and Scalability with IBM WebSphere
Maximizing Performance and Scalability with IBM WebSphere
ISBN: 1590591305
EAN: 2147483647
Year: 2003
Pages: 111
Authors: Adam G. Neat

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net