Database topologies
Consider the database configuration options in relation to WebSphere Portal deployment scenario. The complexity of the network topology will increase as you scale from a proof-of-concept environment using Derby to systems using vertical and horizontal clustering techniques.
WebSphere Portal data can be configured in a single store or organized into database domains to meet different availability requirements, depending on deployment scenarios for proof-of-concept and production environments. The database domains provided by WebSphere Portal help you classify and distribute portal data. Each database domain can be placed on a separate database for efficient maintenance. Additionally, each domain can be placed on a separate database server system for maximum performance.
Figure 1. Options for setting up databases
database configuration options">
Consider whether the portal deployment requires a local database for a proof-of-concept environment; remote databases that share database domains to support normal load balancing; remote databases for high-capacity, heavy load balancing that separate data; or a combination of database configurations.
Proof-of-concept deployment using a local databaseYou can install the database server on the same server machine as WebSphere Portal. This is typically referred to as a local database. Using a local database can make administering environment easier; however, this setup is best used for proof-of-concept deployments only, as a local database competes for server resources with the portal and provides a single point of failure for entire portal environment.
Normal load balancing using one or more remote databasesYou can install the database server on a different server machine from WebSphere Portal. This is typically referred to as a remote database. Using a remote database can provide performance benefits, depending on the speed of the network. When multiple lines of production are involved and each line of production is implemented as a cluster of servers, sharing database domains ensures that the data is automatically synchronized across the lines of production. Each database domain can be placed on a separate database for efficient maintenance.
High-capacity load balancing using one or more remote databasesWhen you deploy the portal in a large-scale, high-demand environment, you can dedicate a server specifically for database transactions. As more users access the portal, the portal application becomes database intensive. Database activity can take up CPU utilization and disk I/O time. Separating the database from the server that the portal is running on increases its capacity. Each domain can be placed on a separate database server system for maximum performance.
If you install the database server on a remote system, you need to install the database client software on the WebSphere Portal system so that the portal can communicate with the remote database server.
Parent
Database considerations