Separating the database server
WebSphere is usually configured to access the database server, for example DB2 Server Enterprise Edition or Oracle 8i, through TCP/IP. As long as the host name, port number and database ID settings are correct, WebSphere will be able to communicate with a database server located anywhere accessible through TCP/IP.
In the simple single machine configuration described in 3.4, Single machine topology, the WebSphere application database and WAS reside on the same server. However, installing the database on a different machine, creating a two-tier configuration as illustrated in Figure 3-6, represents a good practice, with several advantages.
Figure 3-6 Separating the database server
All remote database clients use a communications product to support the protocol used to access a remote database server. The protocol stack must be installed and configured before a client can communicate with a remote DB2 UDB server. For WAS, the recommended protocol is TCP/IP. See the WAS installation documentation for your platform for instructions on how to configure a remote DB2 database.
Some reasons to separate the database server are:
- Performance: less competition for resources
If both the database and appserver are placed on the same machine, then under high load, you have two resource intensive processes: the application server and the database server, competing for increasingly scarce resources (CPU and memory). So, in general, we can expect significantly better performance by separating the application server from the database server.
- Performance: differentiated tuning
By separating the servers, we can independently tune the machines that host the database server and the appserver to achieve optimal performance. The database server is typically sized and tuned for database performance, which may differ from the optimal configuration for the application server.
On many UNIX® servers, installing the database involves modification of the operating system kernel. For example, the installation and execution of Oracle 8i on Solaris requires tuning of the kernel settings to meet Oracle requirements. This database-specific tuning can be detrimental to the performance of appservers located on the same machine.
- Availability: use of already established highly available database servers
Many organizations have invested in high-availability solutions for their database servers, reducing the possibility of the server being a single point of failure in a system.
- Maintainability: independent installation/reconfiguration
Components can be reconfigured, or even replaced, without affecting the installation of the other component.
Consider the following when using a remote database server:
- Network access may limit performance
Insure that adequate network bandwidth exists between the appserver and the database server otherwise the network response time for communication between WAS and the database server may limit the performance of WebSphere. When collocated on the same server, network response is usually not an issue, instead performance and scalability is limited by resource constraints (memory and CPU).
- Architectural complexity
Hosting the database server on a separate machine introduces yet another box that must be administered, maintained, and backed up.
- Maintainability: complexity of configuration
Remote database access requires more complex configuration, setting up clients, and so on.
- Cost
The cost of a separate machine for database server may not be justified for the environment in which the WAS will be installed. However, this is typically not an issue since database servers are usually shared resources for many different applications and application clients, which may or may not be running on WebSphere.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.