Sun Java Enterprise System Deployment Planning Guide

Determining Availability Strategies

When developing a strategy for availability requirements, study the component interactions and usage analysis to determine which availability solutions to consider. Do your analysis on a component-by-component basis, determining a best-fit solution for availability and failover requirements.

The following items are examples of the type of information you gather to help determine availability strategies:

The availability strategy you choose must also take into consideration serviceability requirements, as discussed in Designing for Optimum Resource Usage. Avoid complex solutions that require considerable administration and maintenance.

Availability Strategies

Availability strategies for Java Enterprise System deployments include the following:

The following sections provide some examples of availability solutions that provide various levels of load balancing, failover, and replication of services.

Single Server System

Place all computing resources for a service on a single server. If the server fails, the entire service fails.

Figure 5–2 Single Server System

Shows a single server with 10 CPUs satisfying the performance

Sun provides high-end servers that provide the following benefits:

A high-end server typically costs more than a comparable multi-server system. However, a single server provides savings on administration, monitoring, and hosting costs for servers in a data center. Load balancing, failover, and removal of single points of failure is more flexible with multi-server systems.

Horizontally Redundant Systems

There are several ways to increase availability with parallel redundant servers that provide both load balancing and failover. The following figure illustrates two replicate servers providing an N+1 failover system. An N+1 system has an additional server to provide 100% capacity should one server fail.

Figure 5–3 N+1 Failover System With Two Servers

Shows two replicate servers with 10 CPUs each to satisfy
the 10 CPU performance requirement.

The computing power of each server in Horizontally Redundant Systems above is identical. One server alone handles the performance requirements. The other server provides 100% of the performance when called into service as a backup.

The advantage of an N+1 failover design is 100% performance during a failover situation. Disadvantages include increased hardware costs with no corresponding gain in overall performance (because one server is a standby for use in failover situations only).

The following figure illustrates a system that implements load balancing plus failover that distributes the performance between two servers.

Figure 5–4 Load Balancing Plus Failover Between Two Servers

Shows two servers with 6 CPUs each to satisfy the 10
CPU performance requirement.

In the system depicted in Horizontally Redundant Systems above, if one server fails, all services are available, although at a percentage of the full capacity. The remaining server provides 6 CPUs of computing power, which is 60% of the 10 CPU requirement.

An advantage of this design is the additional 2 CPU latent capacity when both servers are available.

The following figure illustrates a distribution between a number of servers for performance and load balancing.

Figure 5–5 Distribution of Load Between n Servers

Shows five servers with 2 CPUs each to satisfy the 10
CPU performance requirement.

Because there are five servers in the design depicted in Horizontally Redundant Systems, if one server fails the remaining servers provide a total of 8 CPUs of computing power, which is 80% of the 10 CPU performance requirement. If you add an additional server with a 2-CPU capacity to the design, you effectively have an N+1 design. If one server fails, 100% of the performance requirement is met by the remaining servers.

This design includes the following advantages:

However, administration and maintenance costs can increase significantly with additional servers. You also have to consider costs for hosting the servers in a data center. At some point you run into diminishing returns by adding additional servers.

Sun Cluster Software

For situations that require a high degree of availability (such as four or five nines), you might consider Sun Cluster software as part of your availability design. A cluster system is the coupling of redundant servers with storage and other network resources. The servers in a cluster continually communicate with each other. If one of the servers goes offline, the remainder of the devices in the cluster isolate the server and fail over any application or data from the failing node to another node. This failover process is achieved relatively quickly with little interruption of service to the users of the system.

Sun Cluster software requires additional dedicated hardware and specialized skills to configure, administer, and maintain.

Availability Design Examples

This section contains two examples of availability strategies based on the identity-based communications solution for a medium-sized enterprise of about 1,000 to 5,000 employees, as described previously in Identity-Based Communications Example. The first availability strategy illustrates load balancing for Messaging Server. The second illustrates a failover solution that uses Sun Cluster software.

Load Balancing Example for Messaging Server

The following table lists the estimates for CPU power for each logical Messaging Server component in the logical architecture. This table repeats the final estimation calculated in the section Update the CPU Estimates .

Table 5–6 CPU Estimate Adjustments for Supporting Components




Messaging Server(MTA, inbound) 

4 GB 

Messaging Server(MTA, outbound) 

4 GB 

Messaging Server(MMP) 

4 GB 

Messaging Server(Message Store) 

4 GB 

For this example, assume that during technical requirements phase, the following quality of service requirements were specified:

To fulfill the availability requirement, for each Messaging Server component provide two instances, one of each on separate hardware servers. If a server for one component fails, the other provides the service. The following figure illustrates the network diagram for this availability strategy.

Architecture diagram showing availability for Messaging
Server MMP, and MTA components.

In the preceding figure the number of CPUs has doubled from the original estimate. The CPUs are doubled for the following reasons:

Failover Example Using Sun Cluster Software

The following figure shows an example of failover strategy for Calendar Server back-end and Messaging Server messaging store. The Calendar Server back-end and messaging store are replicated on separate hardware servers and configured for failover with Sun Cluster software. The number of CPUs and corresponding memory are replicated on each server in the Sun Cluster.

Figure 5–6 Failover Design Using Sun Cluster Software

Architecture diagram showing Calendar Server and Message
Server storage deployed with Sun Cluster software for failover.

Replication of Directory Services Example

Directory services can be replicated to distribute transactions across different servers, providing high availability. Directory Server provides various strategies for replication of services, including the following:

Availability strategies for Directory Server is a complex topic that is beyond the scope of this guide. The following sections, Single Master Replication and Multi-Master Replication provide a high-level view of basic replication strategies. For detailed information see Chapter 12, Designing a Highly Available Deployment, in Sun Java System Directory Server Enterprise Edition 6.0 Deployment Planning Guide.

Single Master Replication

The following figure shows a single master replication strategy that illustrates basic replication concepts.

Figure 5–7 Single Master Replication Example

Diagram showing the flow of data for a single master
replication strategy.

In single master replication, one instance of Directory Server manages the master directory database, logging all changes. The master database is replicated to any number of consumer databases. The consumer instances of Directory Server are optimized for read and search operations. Any write operation received by a consumer is referred back to the master. The master periodically updates the consumer databases.

Advantages of single master replication include:

Multi-Master Replication

The following figure shows a multi-master replication strategy that might be used to distribute directory access globally.

In multi-master replication, one or more instances of Directory Server manages the master directory database. Each master has a replication agreement that specifies procedures for synchronizing the master databases. Each master replicates to any number of consumer databases. As with single master replication, the consumer instances of Directory Server are optimized for read and search access. Any write operation received by a consumer is referred back to the master. The master periodically updates the consumer databases.

Figure 5–8 Multi-master Replication Example

Diagram showing the flow of data for a multi-master replication

Multi-master replication strategy provides all the advantages of single master replication, plus an availability strategy that can provide load balancing for updates to the masters. You can also implement an availability strategy that provides local control of directory operations, which is an important consideration for enterprises with globally distributed data centers.