Chapter 3 Selecting a Topology

After estimating the factors related to performance as explained in Chapter 2, "Planning your Environment," decide the topology that you will use to deploy the Application Server. A topology is the schematic arrangement of Application Server components (machines, application server instances, and HADB nodes), and the communication flow between these components.

Both topologies have common building blocks, multiple application server instances, which form a cluster, a mirrored set of HADB nodes, and HADB spare nodes. Both of them require a set of common configuration settings to function properly.

Common Requirements

This section describes the requirements that are common to both recommended topologies:

General Requirements

Machines that host HADB nodes must be provided in pairs.

Each DRU must have the same number of machines. Create the HADB database in such a way that the mirrored (paired) nodes are on a different DRU than the primary nodes.

Each machine that hosts HADB nodes must have local disk storage, which is used to store all persisted information in the HADB.

Machines that host the HADB nodes must run the same operating system. It is best to use identical or nearly identical machines, in terms of configuration and performance.

For HTTP and SFSB session information to be persisted to the HADB, the application server instances must be in a cluster and satisfy all related requirements. For more information on configuring clusters, see the Sun Java System Application Server Administration Guide.

Machines hosting the application server instances must be as identical as possible, in terms of configuration and performance. This is because the load balancer plug-in uses a round-robin policy for load balancing, and if machines of different classes host instances, then the load will not be balanced in the most optimum way across these machines.

Preferably have a separate Uninterruptible Power Supply (UPS) for each DRU.

HADB Nodes and Machines

Each DRU contains a complete copy of your data and can continue servicing requests in a degraded (non-fault-tolerant) mode if the other DRU becomes unavailable. However, if a node in one DRU and its mirror in another DRU fail at the same time, some portion of data is lost. For this reason, it is important that the system is not set up, such that both DRUs can be affected by a single failure, such as a power failure or disk failure.


Note	Each DRU must run on a completely independent, redundant system.

To increase capacity and throughput, add nodes in pairs with one node for each DRU.

Assume that each machine in the configuration runs N data nodes. The failure of a single machine brings down N nodes. Therefore, for each DRU have N spare nodes.

Run the same number of HADB nodes on all machines and thereby balance load, as evenly as possible.



Caution	Do not run nodes from different DRUs on the same machine. If you must run nodes from different DRUs on the same machine, ensure that the machine can handle any single point of failure (for failures related to disk, memory, CPU, power, operating system crashes, and so on).

Load Balancer Configuration

Both the topologies comprise application server instances in a cluster. These instances persist session information to the HADB. Configure the load balancer to include configuration information for all the application server instances in the cluster.

For more information on setting up a cluster and adding application server instances to clusters, see the Sun Java System Application Server Administration Guide.

Co-located Topology

In the co-located topology, the application server instance and the HADB nodes are on the same machine (hence, the name co-located). This topology requires fewer machines than the separate tier topology, explained later in the chapter. The co-located topology also offers improved effectiveness of CPU utilization—an application server instance and an HADB node share one machine and the processing is distributed evenly among them.

This topology requires a minimum of two machines. To improve throughput, add more machines in pairs.

Example Configuration

Application Server instance A is on machine SYS0, Application Server instance B is on machine SYS1, Application Server instance C is on machine SYS2, and Application Server instance D is on machine SYS3.

These four instances form a cluster that persists information to the two HADB Data Redundancy Units: DRU0 and DRU1.

DRU0 is comprised of two machines: SYS0 and SYS2. HADB Node active 0 is on the machine SYS0. HADB Node spare 2 is on the machine SYS2.

DRU1 is comprised of two machines: SYS1 and SYS3. HADB Node active 1 is on the machine SYS1. HADB Node spare 3 is on the machine SYS3.

Variation of Co-located Topology


Note	The co-located topology is a good fit for large, symmetric multiprocessing (SMP) machines, since you can take full advantage of the processing power of these machines.

For better scalability and throughput, increase the number of application server instances and HADB nodes by adding more machines. For example, two machines, each with one application server instance and one HADB node, can be added. Make sure that the HADB nodes are added in pairs, assigning one node for each DRU. Figure 3-2 illustrates this configuration.

In this variation, the machines SYS4 and SYS5 have been added to the example co-located topology described in Example Configuration.

Application Server instance A is hosted on machine SYS0, Application Server instance B is hosted on machine SYS1, Application Server instance C is hosted on machine SYS2, Application Server instance D is hosted on machine SYS3, Application Server instance E is hosted on machine SYS4, and Application Server instance F is hosted on machine SYS5.

These instances form a cluster that persists information to the HADB Data Redundancy Units DRU0 and DRU1.

Data Redundancy Unit DRU0 is comprised of machines SYS0, SYS2, and SYS4. HADB Node active 0 is on the machine SYS0. HADB Node active 2 is on the machine SYS2. HADB Node spare 4 is on the machine SYS4.

Data Redundancy Unit DRU1 is comprised of the machines SYS1, SYS3, and SYS5. HADB Node active 1 is on the machine SYS1. HADB Node active 3 is on the machine SYS3. HADB Node spare 5 is on the machine SYS5.

Separate Tier Topology

In this topology, Application Server instances and the HADB nodes are on different machines (hence the name separate tier).

This topology requires more hardware than the co-located topology. This topology may be a good fit if you have different types of machine—you can allocate a different set of machines to the Application Server instance tier and to the HADB nodes tier. For example, you can use more powerful machines for the Application Server instances tier and less powerful machines for the HADB tier.

Example Configuration

In this topology, Application Server instance A is hosted on machine SYS0 and the Application Server instance B is hosted on the machine SYS1. These two instances form a cluster that persists session information to Data Redundancy Units DRU0 and DRU1.

The Data Redundancy Unit DRU0 is comprised of two machines: SYS2 and SYS4. The HADB Node active 0 is on machine SYS2 and the HADB Node spare 2 is on machine SYS4.

The Data Redundancy Unit DRU1 is comprised of two machines SYS3 and SYS5. The HADB Node active 1 is on machine SYS3 and the HADB Node spare 3 on machine SYS5.

All the nodes on a DRU are on different machines, so that even if one machine fails, the complete data for any DRU continues to be available on other machines.

Variation of Separate Tier Topology

As a variation of the separate tier topology, increase the number of Application Server instances by adding more machines horizontally to the configuration. For example, add another machine to the example configuration by creating a new Application Server instance. Similarly, increase the number of HADB nodes by adding more machines to host HADB nodes. Recall you must add the HADB nodes in pairs with one node for each DRU.

In this configuration, each machine hosting Application Server instances has two Application Server instances. There are thus a total of six Application Server instances in the cluster.

The Data Redundancy Unit DRU0 comprises two machines: SYS3 and SYS5. HADB Node active 0 and the HADB Node active 2 are on machine SYS3. HADB Node spare 4 and the HADB Node spare 6 are on machine SYS5.

The Data Redundancy Unit DRU1 comprises two machines SYS4 and SYS6. HADB Node active 1 and HADB Node active 3 are on machine SYS4. HADB Node spare 5 and HADB Node spare 7 are on machine SYS6.

Each machine hosting HADB nodes hosts two HADB nodes each. This means that there are a total of eight HADB nodes (four active nodes and four spare nodes).

Comparison of Topologies

Table 3-1 presents a comparison of the co-located topology and the separate tier topology. The left column lists the name of the topology, the middle column lists the advantages of the topology, and the right column lists the disadvantages of the topology

Table 3-1 Comparison of Topologies
Topology	Advantages	Disadvantages
Co-located Topology	Requires fewer machines than separate tier topology. Because the HADB nodes and the application server instances are on the same tier, create an application server instance on each spare node to handle additional load. Improved CPU utilization. Processing is distributed evenly between an application server instance and an HADB node sharing one machine. Useful for large, Symmetric Multiprocessing (SMP) machines since it takes full advantage of their processing power.	Increased complexity of maintenance. For example, to perform maintenance tasks (that require shutting down of machines) on HADB nodes, the application server instances on the machine hosting HADB nodes also become unavailable while the machine is unavailable.
Separate Tier Topology	Easier maintenance. For example, perform maintenance tasks for the machines that host application server instances without having to bring down HADB nodes. Useful in situations where you have different types of machines. Allocate a different set of machines to the application server instances tier and to the HADB tier. For example, use the more powerful machines for the application server instances tier and the less powerful machines for the HADB tier.	Requires more machines than the co-located topology. Because application server instances and HADB nodes are located on separate tiers, application server instances cannot be located on the machines that host the HADB spare nodes. Reduced CPU utilization. The tier consisting of application server instances and the tier consisting of HADB nodes will likely have uneven loads. This is more significant with a small number of machines (four to six).

Determining Which Topology to Use

Test different topologies mentioned in this chapter and experiment with different combinations of machines and CPUs to determine which topology (or its variation) best meets the topology plan’s performance and availability requirements.

Determine what trade offs are required to meet the plan goals. For example, if ease of maintenance is critical, the separate tier topology is more suitable. The trade off is that more machines are required than the co-located topology.

An important factor in the choice of topology is the type of machines in the setup. If the system contains large, Symmetric Multiprocessing (SMP) machines, the co-located topology is attractive because you can take full advantage of the processing power of these machines. If the system contains various types of machines, the separate tier topology can be more useful because you can allocate a different set of machines to the application server instances tier and to the HADB tier. For example, it is possible to use more powerful machines for the application server instances tier and the less powerful machines for the HADB tier.

Previous Contents Index Next
Sun Java System Application Server 8.1 2004Q4 Deployment Planning Guide