|
| |
| Sun Java System Application Server Enterprise Edition 7 2004Q2 System Deployment Guide | |
Chapter 3
Selecting a TopologyAfter estimating the factors related to performance as explained in Chapter 2, "Planning your Environment," you should decide the topology that you will use to deploy Sun Java™ System Application Server 7 Enterprise Edition.
A topology is the schematic arrangement of Application Server components (machines, application server instances, and HADB nodes), and the communication flow between these components.
This chapter describes the following two recommended topologies:
Both the topologies have common building blocks—multiple application server instances that 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.
This chapter describes the following topics:
Common RequirementsThe following topics in this section describe the requirements that are common to both the topologies:
General Requirements
- Machines that host HADB nodes must be provided in pairs.
- Each DRU must have the same number of machines. You must 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. These machines should be as identical as possible 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 Sun Java System Application Server Administration Guide.
- The machines hosting the application server instances should 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 you have machines of different classes hosting instances, then the load will not be balanced in the most optimum way across these machines.
- Each DRU should preferably have a separate Uninterruptible Power Supply (UPS).
HADB Nodes and Machines
Each DRU contains a complete copy of your data and can continue servicing requests in a degraded (that is, 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 your data is lost. For this reason, it is important that you do not set up your system such o that both DRUs can be impacted by a single failure, such as a power failure or disk failure.
- To increase capacity and throughput, add nodes in pairs with one node for each DRU.
- Assume that each machine in your configuration runs N data nodes. The failure of a single machine brings down N nodes. Therefore, for each DRU you should have N spare nodes.
- You must run the same number of HADB nodes on all machines and thereby balance load as evenly as possible.
Load Balancer Configuration
Both the topologies comprise application server instances in a cluster. These instances persist session information to the HADB. You must 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 it, see Sun Java System Application Server Administration Guide.
Co-located TopologyIn 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 lesser numbers of machines as compared to 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.
A minimum of two machines are required for this topology. To improve throughput, more machines can be added in pairs.
Note
The co-located topology is a good fit for large, Symmetric Multiprocessing (SMP) machines as you can take full advantage of the processing power of these machines.
Reference Co-located Topology
Figure 3-1 shows a reference co-located topology.
Figure 3-1 Reference
Co-located Topology
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 comprises two machines: SYS0 and SYS2. HADB Node active 0 is on the machine SYS0. HADB Node spare 2 is on the machine SYS2.
DRU1 comprises two machines: SYS1 and SYS3. HADB Node active 1 is on the machine SYS1. HADB Node spare 3 is on the machine SYS3.
Configuration Settings for Reference Co-located Topology
Use the clsetup command for configuring the cluster (as part of the cluster configuration, the clsetup command creates an HADB database and sets up the JDBC connection pool and the JDBC resource for the HADB). For information on using clsetup, see Sun Java System Application Server Installation Guide.
The clsetup command uses the following input files:
Changes to clresource.conf File
For configuration related to the topologies described in this guide, the following properties should be changed in the clresource.conf file:
- hosts: A comma separated list of host names for the machines that host HADB active nodes. For each HADB active node, include the host name of the machine. Therefore, if a machine hosts two HADB nodes, the host name of the machine must appear twice.
- steadypoolsize: The value of the steadypoolsize property is calculated using the following formula:
8*(number of HADB nodes)/(number of application server instances)
If the resulting number is a decimal, round it off to the next even number.
- maxpoolsize: The value of the maxpoolsize property is calculated using the following formula:
16*(number of HADB nodes)/(number of application server instances)
Table # describes the changes needed to the clresource.conf file for the reference co-located topology. The left column lists the section in the file where the property to be changed is listed, the middle column lists the property name, and the right column lists the value of the property
Changes to clinstance.conf File
In the clinstance.conf file, include information for each instance. For detailed information, see Sun Java System Application Server Installation Guide. This applies to both topologies and their variations.
Variation to Reference Co-located Topology
For better scalability and throughput, you can increase the number of application server instances and HADB nodes by adding more machines.
For example, you can add two machines, each with one application server instance and one HADB node. Make sure that you add the HADB nodes in pairs, assigning one node for each DRU. This configuration is shown in Figure 3-2.
Figure 3-2 Variation to Reference Co-located Topology
In this variation, the machines SYS4 and SYS5 have been added to the reference co-located topology described in Reference Co-located Topology.
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 comprises 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 comprises 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.
Configuration Settings for Variation to the Reference Co-located Topology
Make the changes as described in the subsequent sections before you run the clsetup command.
Changes to clresource.conf File
Table # describes the changes needed to the clresource.conf file for the variation to the reference co-located topology as described in this section. The left column lists the section in the file in which the property to be changed is listed, the middle column lists the property name, and the right column lists the value of the property. For more information on the values of these properties, see Changes to clresource.conf File.
Changes to clinstance.conf File
In the clinstance.conf file, include the information for each instance. For more information, see Sun Java System Application Server Installation Guide.
Separate Tier TopologyIn 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.
Reference Configuration
Figure 3-3 shows the reference separate tier topology.
Figure 3-3 Reference Separate Tier Topology
In this reference topology, the 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 comprises 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 comprises 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 becomes unavailable, the complete data for any DRU continues to be available on other machines.
Configuration Settings for Reference Separate Tier Topology
Make the changes as described in the subsequent sections to these input files before you run the clsetup command.
Changes to clresource.conf File
Table # describes the changes needed to the clresource.conf file for the reference separate tier topology. The left column lists the section in the file in which the property to be changed is listed, the middle column lists the property name, and the right column lists the value of the property. For more information on the values of these properties, see Changes to clresource.conf File.
Changes to clinstance.conf File
In the clinstance.conf file, include information for each instance. For more information, see Sun Java System Application Server Installation Guide.
Variation to Reference Separate Tier Topology
You can increase the number of Application Server instances by adding more machines horizontally to the configuration. For example, you can add another machine to the reference configuration by creating a new Application Server instance. Similarly, you can increase the number of HADB nodes by adding more machines to host HADB nodes. Make sure that you add the HADB nodes in pairs with one node for each DRU.
This configuration is shown in Figure 3-4.
Figure 3-4 Variation to Reference Separate Tier Topology
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 HADB nodes are on machines SYS3, SYS4, SYS5, and SYS6.
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. There are thus a total of eight HADB nodes (four active nodes and four spare nodes).
Configuration Settings for Variation to Reference Separate Tier Topology
Make the changes as described in the subsequent sections before you run the clsetup command.
Changes to clresource.conf File
Table # describes the changes needed to the clresource.conf file for the variation to the reference separate tier topology. The left column lists the section in the file in which the property to be changed is listed, the middle column lists the property name, and the right column lists the value of the property. For more information on the values of these properties, see Changes to clresource.conf File.
Changes to clinstance.conf File
In the clinstance.conf file, include information for each Application Server instance. For more information, see Sun Java System Application Server Installation Guide.
Comparison of TopologiesTable # 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
Determining Which Topology to UseYou should test the different topologies mentioned in this chapter and experiment with different combinations of machines and CPUs to determine which topology (or its variation) best meets your performance and availability requirements.
Determine what trade offs you want to make to serve your needs the best. For example, if ease of maintenance is a critical requirement for you, the separate tier topology is more suitable. However, you will have to use a higher number of machines as compared to the co-located topology.
An important factor in the choice of topology is the type of machines you have in your setup. If you have large, Symmetric Multiprocessing (SMP) machines in your system, the co-located topology is an attractive option because you can take full advantage of the processing power of these machines. If you have different types of machines, separate tier topology may 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, you can use more powerful machines for the application server instances tier and the less powerful machines for the HADB tier.
