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 ”
The approach to this section of the chapter is as
Web servers (thin versus thick models)
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.
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
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
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.
The first question
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.
Figure 5-5 illustrates the issues associated with a thick frontend Web server (running WebSphere) talking to a backend application server and database tier.
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
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
For this reason, my recommendation is to use a thin Web server environment and use the WebSphere HTTP plug-in to route
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.
The second question relates to security ”
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.
Figure 5-7: A 3-tier firewall topology
These types of firewalls are typically used to house 3-tier and
In the high-level diagram in Figure 5-7, there are clearly three "tiers" of servers separated by various firewalls and a single
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.
Many organizations make use of third-party content providers to host
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
This question relates to proper network design but it's something you need to consider
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.
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
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
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.
This question relates to the preferences of your organization's CIO in terms of server models. Some companies prefer the many, smaller or
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
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
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
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.
The single-channel topologies are the most simplistic of all WebSphere topologies. The term
refers to the primary
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.
The most simplistic single-channel WebSphere topology that should be
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.
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
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
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
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:
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
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:
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
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.
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
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
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
Figure 5-11 shows an example of this topology.
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:
In the plug-in file, you'll configure each of these URLs in such a way that has them
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
results in your being able to use the application directly on the port allocated to
. This is not of much consequence in single server, single instance
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,
would be configured in the
DNS zone files to point the "www" to a host name. In the example here, the host
In this case, the Web server first
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
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.
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
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
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
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.
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.
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
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
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.
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
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!
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.
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
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-
If the configuration had been set up to accommodate session persistence, the two JVMs would be
With this ability to
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
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
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
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
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
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
Overall System Load = ([ x · Nj ] — [ Nj — 1.1])
This formula adds
As I noted earlier, if you're running single or dual CPU systems for your application server,
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
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
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
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
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.
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
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
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.
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.
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.
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
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.
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.
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.
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.
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.
A term I've used several times in this chapter and haven't discussed in much detail in previous chapters is
"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
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.
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
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
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
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.
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
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).
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
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
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.
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.
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.).
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
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.
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.
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
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.
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
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.
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.
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.
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
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.
It should now be clear that WebSphere is a very powerful application platform when it comes to distributed applications. This topology starts to
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
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.
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
At the same time, IBM WebSphere versions 4 and 5 are, after all, just software. Like any software, they're susceptible to glitches and
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
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 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
In this part of the chapter, you'll explore the major components of several topological architectures that are based on a multichannel model.
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.
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.
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.
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
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.
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,
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.
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.
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.
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
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
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.
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
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.
As you've seen, the use of multiple JVMs within WebSphere application servers serving the same application provides a very
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.
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.
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
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.
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' "
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
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
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
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.
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
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.
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.
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
If one JVM exhausts all of its available pooled connections, it doesn't affect the operation of the other application instances.
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.
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.
Although the topology isn't dissimilar to the previous topology in the way of net redundancy, the introduction of the additional JVMs does further
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.
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.
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
For the majority of all WebSphere environments that I deal with
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.
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.
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)
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.
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).
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 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
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.
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
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).
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
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.
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
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.
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.
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,
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
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.
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.
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,
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
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
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.
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
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
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.
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.
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-
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
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.