Server topologies
Single-server topology
Provides an application server and a Web site. Initially, a single instance is configured to use an internal database. Convert to a cluster or server farm to improve capacity and availability. WebSphere Portal, WAS, and the database are all installed on the same server.
Optionally configure a Web server, with IBM WAS's HTTP plug-in to...
- Serve static resources
- Provide plug-in point for a corporate SSO agent in the event that WebSphere Portal participates in a global SSO domain
Standalone server topology
The stand-alone scenario is different from the single-server since the database server, LDAP server, and Web server software are installed on different physical servers than the IBM WebSphere Portal. This configuration enables you to distribute the software in the network and therefore distribute the processing load.
For a stand-alone configuration, we can use an existing, supported database in the network and an existing, supported LDAP directory. Configure IBM WebSphere Portal to authenticate with the LDAP server. The following illustration displays a common topology for a stand-alone server. The HTTP server, (also referred to as Web server) is installed on a server in a protected network. The LDAP server and database server are also installed on different servers. WebSphere Portal and WAS are installed on the same server.
Choose this topology if you do not require a robust clustered environment. We can also use this option to examine and test functions and features to decide how to accomplish the business goals. We can add this stand-alone production server to a federated IBM WAS Network Deployment cell. It creates a federated, unclustered production server.
Clustered servers topology
IBM WebSphere Portal uses a dmgr server type for clustering portal servers. All portal instances share the same configuration, including...
- database
- applications
- portlets
- site design
Clusters also provide a shared domain in which session and cache data can be replicated. The cluster provides an application synchronization mechaniso that ensures consistent application management (start, stop, updates.) across the cluster.
The HTTP Server plug-in balances user traffic across all members of the cluster. Session affinity ensures that a user remains bound to a specific cluster instance for the duration of their session. When cluster member is down, workload management will route traffic around it.
IBM WebSphere Virtual Enterprise provides dynamic clusters to dynamically create and remove cluster members based on the workload. The On Demand Router has all of the features of the HTTP Server plug-in with the additional ability to define routing and service policies. It is possible to deploy multiple portal clusters in a single cell.
Vertical cluster topology
A vertical cluster has more than one cluster instance within a node. A node typically represents a single physical server in a managed cell, but it is possible to have more than one node per physical server. It is very simple to add additional vertical clusters to a node, using the dmgr console, as each additional vertical cluster instance replicates the configuration of the first instance; no additional installation or configuration is necessary.
How many vertical instances that can be created in a single node depends on the availability of physical resources in the local system (CPU and memory). Too many vertical cluster instances could exhaust the physical resources of the server, at which point it is appropriate to build horizontal cluster instance to increase capacity if necessary.
The following diagram illustrates a vertical cluster. A single node has multiple instances of IBM WebSphere Portal installed. The node is managed by the dmgr. Each instance on the node authenticates with the same LDAP server and store data in the same database server. Although not depicted in the illustration, the database and LDAP servers could also be clustered if needed for failover, increased performance, and high availability.
Combination of horizontal and vertical clusters
Most large-scale portal sites incorporate a combination of horizontal and vertical clustering to take full advantage of the resources of a single machine before scaling outward to additional machines.
Multiple clusters
With multiple clusters, where each cluster is in a different cell...
- One cluster can be taken out of production use, upgraded and tested while leaving other clusters in production, achieving 100% availability with no maintenance windows.
- We can deploy clusters closer to the people they serve, improving the responsiveness of the content.
For the most part, each cluster should be seen as a totally isolated system, administered independently, with its own configuration, isolated from the other clusters. The only exception is with the sharing of the following portal database domains...
- Community
- Customization
These domains store portal configuration data owned by the users themselves.
Each cluster can be deployed within the same data center, to help with improving maintainability and improve failure isolation, or across multiple data centers, to protect against natural disaster and data center failure, or to simply provide a broader geographical coverage of the portal site.
The farther apart the clusters are, the higher the impact network latency may have between clusters and thus the less likely you will be to want to share the same physical database between clusters for the shared domains and will want to resort to database replication techniques to keep the databases synchronized.
Typically, in a multiple portal cluster topology, HTTP Servers are dedicated per cluster, since the HTTP Server plug-in's configuration is cell-specific. To route traffic between data centers (banks of HTTP Servers), a separate network load-balancing appliance is used, with rules in place to route users to specific datacenters, either based on locality or on random site selection, such as through DNS resolution. Domain, or locality, based data center selection is preferred because is predictably keeps the same user routed to the same datacenter, which helps preserve session affinity and optimum efficiency.
DNS resolution based routing selection can cause random behavior in terms of suddenly routing users to another datacenter during a live session. If this happens, the user's experience with the portal site may be disrupted as the user is authenticated and attempts to resume at the last point in the new site. Session replication and/or proper use of portlet render parameters can help diminish this effect.
| active/active | All portal clusters receive user traffic simultaneously from network load balancers and HTTP Servers. If maintenance on one cluster is required, all production traffic is switched to the other cluster. |
| active/passive | Production traffic is routed to a subset of the available portal clusters (e.g. 1 of 2, or 2 of 3). There is always one cluster not receiving any traffic. Maintenance is typically applied first to the offline cluster, and then it is brought into production traffic while each of the remaining clusters are taken out and maintained in a similar fashion. |
As an alternative to deploying multiple portal clusters where each cluster is in a different cell, it is also possible to deploy multiple portal clusters in the same cell. Different cells give you total isolation between clusters, and the freedom to maintain all aspects of each cluster without affecting the other. Different cells, however, require different dmgrs and thus different Administration Consoles for managing each cluster. Multiple clusters in the same cell reduces the administration efforts to a single console, but raises the effort level to maintain the clusters since there is a high degree of resource sharing between the multiple clusters.
While multiple portal clusters in a single cell has its uses, especially in consolidating content authoring and rendering servers for a single tier, it does increase the administrative complexity significantly. IBM recommends that multiple portal clusters be deployed in multiple cells, to keep administration as simple as possible.
Single-server topology for WCM
Organizations that only need a small web site or intranet site could implement a single server topology for Web Content Manager. In a single server configuration, authoring and delivery occur on the same server.
This configuration is not recommended for organizations that need a larger Web site or intranet site.
The following topology diagram illustrates a single-server configuration for WCM. A Web server routes incoming requests from browser clients. Web Content Manager, IBM WebSphere Portal, and IBM WAS are installed on the same server. The LDAP server that stores authorized user information is installed on a dedicated server. The database that stores content is also installed an a dedicated server. Although this diagram does not illustrate a cluster configuration, the Web Content Manager server could be clustered. Similarly the LDAP and database servers could be clustered for failover.
The following actions occur on the single server:
- Create drafts
- Approve drafts
- Test changes
- Publish changes
- Host content
Hardware and resource considerations
- Authoring and delivering content within the same environment is resource intensive, so the type of environment you deploy needs to be robust enough to allow authoring and delivery to occur at the same time. Using clustered servers is a common solution for a single-server configuration.
- Content can be delivered using either a web content viewer portlet, the web content servlet or a pre-rendered site.
Dual-server configuration for WCM
Organizations that need a large website with heavy traffic on that have multiple users authoring content should implement a dual-server configuration. In a dual-server configuration authoring is conducted on one server, or server cluster, and content is delivered to a different server, or server cluster. Authors access and work on the authoring server while website users access the delivery server. This option reduces the load on each server and allows us to locate the authoring environment behind a firewall.
This diagram illustrates a dual server environment for Web Content Manager. Both the delivery and authoring server access the same LDAP and database server in order to access common users, users groups, and content. Using the same LDAP configuration is critical for WCM. Website users access the site through a web server that directs the user to the delivery server. On the delivery server we can use either the web content viewer, as illustrated in the diagram, a web content servlet, or a pre-rendered site. New content is syndicated or published to the delivery server.
On the authoring server the following actions occur:
- Create drafts
- Approve drafts
- Test changes
- Publish changes
- Syndicate changes to the delivery server
On the delivery server the following actions occur:
- Host content
- Subscribe to content changes
Hardware and resource considerations
- An authoring environment would normally be a clustered environment to cope with a large number of website creators and web content authors.
- The delivery environment can be a:
- Web content delivery server or cluster that subscribes to the authoring environment. Content can be delivered using either a web content viewer portlet, the web content servlet or a pre-rendered
site.
- Local WebSphere Portal production environment that subscribes
to the authoring environment and delivers web content using a web content viewer.
- Remote WebSphere Portal production environment that uses WSRP and a web content viewer to display content from the authoring environment.
- Web content delivery server or cluster that subscribes to the authoring environment. Content can be delivered using either a web content viewer portlet, the web content servlet or a pre-rendered
site.
- A firewall is not depicted in this illustration, but could exist between the authoring and delivery server if required.
Syndication options
There are two syndication to consider:
- Automatic one-way syndication
- With this option, changes made in the authoring environment are automatically syndicated to the delivery environment. You would implement this option when you want changes to the content to constantly be updated on the live site.
- Manual one-way syndication
- With this option, changes made in the authoring environment are syndicated to the delivery environment in a single batch. You would implement this option when you only want to update the live site on set dates. The changes made on the authoring server gradually accumulate until we are ready to go live with those changes.
Related:
Design servers
Web content authoring environments
Web content delivery environments
Staging-server topology for WCM
To deliver large complex web sites with a large number of site users and content creator, implement a staging server configuration. Implementing a staging server provides an environment for checking for accuracy, issues with the design, and performance. With a staging server configuration authoring, staging and delivery are separated onto different servers. The staging environment can be used for testing or to allow changes from the authoring environment to accumulate prior to syndicating the changes to the delivery environment in a single batch.
The following diagram illustrates a staging server topology. There is a different server, or cluster of servers, for the delivery, staging, and authoring environments. The delivery, staging, authoring environment all access the same LDAP. If needed the LDAP and database servers can be clustered too. web site users access the delivery server through the web server. Authors access the authoring server and content is syndicated to the staging server for quality assurance verification before it is published to the delivery server.
On the authoring server the following activities occur:
- Create drafts
- Approve drafts
- Test changes
- Publish new and changed content
- Syndicate content to the staging server
On the staging server the following activities occur
- User assurance testing
- Performance testing
- Syndicate content to the delivery server
On the delivery server, the following activities occur:
- Host content for web site users
Hardware and resource considerations
- An authoring environment would normally be a clustered environment to cope with a large number of web site creators and web content authors.
- The staging environment can consist of:
- A web content delivery server or cluster that subscribes to the authoring environment. This would be used when to allow changes from the authoring environment to accumulate prior to syndicating your changes to the delivery environment in a single batch.
- A complete replica of the delivery environment. This type of environment would be used for system UAT to ensure that the web site being delivered is accurate, error-free and can perform under load.
- A web content delivery server or cluster that subscribes to the authoring environment. This would be used when to allow changes from the authoring environment to accumulate prior to syndicating your changes to the delivery environment in a single batch.
- The delivery environment can consist of:
- A web content delivery server or cluster that subscribes to the staging environment. Content can be delivered using either a web content viewer portlet, the web content servlet or a pre-rendered site.
- A local WebSphere Portal production environment that subscribes
to the staging environment and delivers web content using a web content viewer.
- A remote WebSphere Portal production environment. In this scenario a web content delivery server subscribes from the staging environment, and the remote WebSphere Portal production environment uses WSRP and a web content viewer to display content from the web content delivery server.
- A web content delivery server or cluster that subscribes to the staging environment. Content can be delivered using either a web content viewer portlet, the web content servlet or a pre-rendered site.
Syndication options
- Automatic one-way syndication from the authoring environment to the staging environment.
- Manual one-way syndication from the staging environment to the delivery environment.
Parent: Server topologies
Related:
Single-server topology
Standalone server topology
Clustered servers topology
Portal farm topology
Single-server topology for WCM
Dual-server configuration for WCM
Parent: Plan
Cluster considerations
Database considerations
Install multiple clusters in a single cell on AIX
Install multiple clusters in a single cell on IBM i
Install multiple clusters in a single cell on Linux
Install multiple clusters in a single cell on Solaris
Install multiple clusters in a single cell on Windows
Install multiple clusters in a single cell on z/OS
Server topologies
Parent: Plan
Related:
Increasing the number of servant regions
Single-server topology
Provides an application server and a Web site. Initially, a single instance is configured to use an internal database.
Convert to a cluster or server farm to improve capacity and availability.
The following illustration displays a common topology for a single server environment. Only one server is needed. WebSphere Portal, WAS, and the database are all installed on the same server.
Optionally configure a Web server, with IBM WAS's HTTP plug-in to...
- Serve static resources
- Provide plug-in point for a corporate SSO agent in the event that WebSphere Portal participates in a global SSO domain
Parent: Server topologies
Related:
Standalone server topology
Clustered servers topology
Portal farm topology
Single-server topology for WCM
Dual-server configuration for WCM
Staging-server topology for WCM
Standalone server topology
The stand-alone scenario is different from the single-server since the database server, LDAP server, and Web server software are installed on different physical servers than the IBM WebSphere Portal. This configuration enables you to distribute the software in the network and therefore distribute the processing load.
For a stand-alone configuration, we can use an existing, supported database in the network and an existing, supported LDAP directory. Configure IBM WebSphere Portal to authenticate with the LDAP server. The following illustration displays a common topology for a stand-alone server. The HTTP server, (also referred to as Web server) is installed on a server in a protected network. The LDAP server and database server are also installed on different servers. WebSphere Portal and WAS are installed on the same server.
Choose this topology if you do not require a robust clustered environment. We can also use this option to examine and test functions and features to decide how to accomplish the business goals. We can add this stand-alone production server to a federated IBM WAS Network Deployment cell. It creates a federated, unclustered production server.
- z/OS only: Federated unclustered deployment
- Install a federated, unclustered production server if you require the robustness of a WAS Network Deployment cell but do not require a clustered environment. We can also use this option to examine and test functions and features in a managed but unclustered node. After determinine that the functions and features work in a managed, unclustered node, we can create a clustered environment.
T install the federated, unclustered production server deployment option, we can only install one node, referred to as the primary node. We cannot install any additional portal nodes.
Parent: Server topologies
Related:
Single-server topology
Clustered servers topology
Portal farm topology
Single-server topology for WCM
Dual-server configuration for WCM
Staging-server topology for WCM
Clustered servers topology
IBM WebSphere Portal uses a dmgr server type for clustering portal servers. All portal instances share the same configuration, including...
- database
- applications
- portlets
- site design
Clusters also provide a shared domain in which session and cache data can be replicated.
The cluster provides an application synchronization mechaniso that ensures consistent application management (start, stop, updates.) across the cluster.
The HTTP Server plug-in balances user traffic across all members of the cluster. Session affinity ensures that a user remains bound to a specific cluster instance for the duration of their session. When cluster member is down, workload management will route traffic around it.
IBM WebSphere Virtual Enterprise provides dynamic clusters to dynamically create and remove cluster members based on the workload. The On Demand Router has all of the features of the HTTP Server plug-in with the additional ability to define routing and service policies.
It is possible to deploy multiple portal clusters in a single cell.
See
Parent: Server topologies
Related: Single-server topology
Standalone server topology
Portal farm topology
Single-server topology for WCM
Dual-server configuration for WCM
Staging-server topology for WCM
Cluster considerations
Vertical cluster topology
A vertical cluster has more than one cluster instance within a node. A node typically represents a single physical server in a managed cell, but it is possible to have more than one node per physical server. It is very simple to add additional vertical clusters to a node, using the dmgr console, as each additional vertical cluster instance replicates the configuration of the first instance; no additional installation or configuration is necessary.
How many vertical instances that can be created in a single node depends on the availability of physical resources in the local system (CPU and memory). Too many vertical cluster instances could exhaust the physical resources of the server, at which point it is appropriate to build horizontal cluster instance to increase capacity if necessary.
The following diagram illustrates a vertical cluster. A single node has multiple instances of IBM WebSphere Portal installed. The node is managed by the dmgr. Each instance on the node authenticates with the same LDAP server and store data in the same database server. Although not depicted in the illustration, the database and LDAP servers could also be clustered if needed for failover, increased performance, and high availability.
Parent: Clustered servers topology
Combination of horizontal and vertical clusters
Most large-scale portal sites incorporate a combination of horizontal and vertical clustering to take full advantage of the resources of a single machine before scaling outward to additional machines.
This graphic depicts two horizontal cluster members, node A and B. Both node A and B have 3 vertical cluster members.
Parent: Clustered servers topology
Multiple clusters
With multiple clusters, where each cluster is in a different cell...
- One cluster can be taken out of production use, upgraded and tested while leaving other clusters in production, achieving 100% availability with no maintenance windows.
- We can deploy clusters closer to the people they serve, improving the responsiveness of the content.
For the most part, each cluster should be seen as a totally isolated system, administered independently, with its own configuration, isolated from the other clusters. The only exception is with the sharing of the following portal database domains...
- Community
- Customization
These domains store portal configuration data owned by the users themselves.
Each cluster can be deployed within the same data center, to help with improving maintainability and improve failure isolation, or across multiple data centers, to protect against natural disaster and data center failure, or to simply provide a broader geographical coverage of the portal site.
The farther apart the clusters are, the higher the impact network latency may have between clusters and thus the less likely you will be to want to share the same physical database between clusters for the shared domains and will want to resort to database replication techniques to keep the databases synchronized.
Typically, in a multiple portal cluster topology, HTTP Servers are dedicated per cluster, since the HTTP Server plug-in's configuration is cell-specific. To route traffic between data centers (banks of HTTP Servers), a separate network load-balancing appliance is used, with rules in place to route users to specific datacenters, either based on locality or on random site selection, such as through DNS resolution. Domain, or locality, based data center selection is preferred because is predictably keeps the same user routed to the same datacenter, which helps preserve session affinity and optimum efficiency.
DNS resolution based routing selection can cause random behavior in terms of suddenly routing users to another datacenter during a live session. If this happens, the user's experience with the portal site may be disrupted as the user is authenticated and attempts to resume at the last point in the new site. Session replication and/or proper use of portlet render parameters can help diminish this effect.
| active/active | All portal clusters receive user traffic simultaneously from network load balancers and HTTP Servers. If maintenance on one cluster is required, all production traffic is switched to the other cluster. |
| active/passive | Production traffic is routed to a subset of the available portal clusters (e.g. 1 of 2, or 2 of 3). There is always one cluster not receiving any traffic. Maintenance is typically applied first to the offline cluster, and then it is brought into production traffic while each of the remaining clusters are taken out and maintained in a similar fashion. |
As an alternative to deploying multiple portal clusters where each cluster is in a different cell, it is also possible to deploy multiple portal clusters in the same cell. Different cells give you total isolation between clusters, and the freedom to maintain all aspects of each cluster without affecting the other. Different cells, however, require different dmgrs and thus different Administration Consoles for managing each cluster. Multiple clusters in the same cell reduces the administration efforts to a single console, but raises the effort level to maintain the clusters since there is a high degree of resource sharing between the multiple clusters.
While multiple portal clusters in a single cell has its uses, especially in consolidating content authoring and rendering servers for a single tier, it does increase the administrative complexity significantly. IBM recommends that multiple portal clusters be deployed in multiple cells, to keep administration as simple as possible.
Parent: Clustered servers topology
Related:
Database considerations
Install multiple clusters in a single cell on AIX
Install multiple clusters in a single cell on IBM i
Install multiple clusters in a single cell on Linux
Install multiple clusters in a single cell on Solaris
Install multiple clusters in a single cell on Windows
Install multiple clusters in a single cell on z/OS
Single-server topology for WCM
Organizations that only need a small web site or intranet site could implement a single server topology for IBM Web Content Manager. In a single server configuration, authoring and delivery occur on the same server.
This configuration is not recommended for organizations that need a larger Web site or intranet site.
The following topology diagram illustrates a single-server configuration for WCM. A Web server routes incoming requests from browser clients. Web Content Manager, IBM WebSphere Portal, and IBM WAS are installed on the same server. The LDAP server that stores authorized user information is installed on a dedicated server. The database that stores content is also installed an a dedicated server. Although this diagram does not illustrate a cluster configuration, the Web Content Manager server could be clustered. Similarly the LDAP and database servers could be clustered for failover.
The following actions occur on the single server:
- Create drafts
- Approve drafts
- Test changes
- Publish changes
- Host content
Hardware and resource considerations
- Authoring and delivering content within the same environment is resource intensive, so the type of environment you deploy needs to be robust enough to allow authoring and delivery to occur at the same time. Using clustered servers is a common solution for a single-server configuration.
- Content can be delivered using either a web content viewer portlet, the web content servlet or a pre-rendered site.
Parent: Server topologies
Related:
Single-server topology
Standalone server topology
Clustered servers topology
Portal farm topology
Dual-server configuration for WCM
Staging-server topology for WCM
Dual-server configuration for WCM
Organizations that need a large website with heavy traffic on that have multiple users authoring content should implement a dual-server configuration. In a dual-server configuration authoring is conducted on one server, or server cluster, and content is delivered to a different server, or server cluster. Authors access and work on the authoring server while website users access the delivery server. This option reduces the load on each server and allows us to locate the authoring environment behind a firewall.
This diagram illustrates a dual server environment for IBM Web Content Manager. Both the delivery and authoring server access the same LDAP and database server in order to access common users, users groups, and content. Using the same LDAP configuration is critical for WCM. Website users access the site through a web server that directs the user to the delivery server. On the delivery server we can use either the web content viewer, as illustrated in the diagram, a web content servlet, or a pre-rendered site. New content is syndicated or published to the delivery server.
On the authoring server the following actions occur:
- Create drafts
- Approve drafts
- Test changes
- Publish changes
- Syndicate changes to the delivery server
On the delivery server the following actions occur:
- Host content
- Subscribe to content changes
Hardware and resource considerations
- An authoring environment would normally be a clustered environment to cope with a large number of website creators and web content authors.
- The delivery environment can be a:
- Web content delivery server or cluster that subscribes to the authoring environment. Content can be delivered using either a web content viewer portlet, the web content servlet or a pre-rendered
site.
- Local WebSphere Portal production environment that subscribes
to the authoring environment and delivers web content using a web content viewer.
- Remote WebSphere Portal production environment that uses WSRP and a web content viewer to display content from the authoring environment.
- Web content delivery server or cluster that subscribes to the authoring environment. Content can be delivered using either a web content viewer portlet, the web content servlet or a pre-rendered
site.
- A firewall is not depicted in this illustration, but could exist between the authoring and delivery server if required.
Syndication options
There are two syndication options to consider:
- Automatic one-way syndication
- With this option, changes made in the authoring environment are automatically syndicated to the delivery environment. You would implement this option when you want changes to the content to constantly be updated on the live site.
- Manual one-way syndication
- With this option, changes made in the authoring environment are syndicated to the delivery environment in a single batch. You would implement this option when you only want to update the live site on set dates. The changes made on the authoring server gradually accumulate until we are ready to go live with those changes.
Parent: Server topologies
Related:
Single-server topology
Standalone server topology
Clustered servers topology
Portal farm topology
Single-server topology for WCM
Staging-server topology for WCM
Design servers
Web content authoring environments
Web content delivery environments
Staging-server topology for WCM
To deliver large complex web sites with a large number of site users and content creator, implement a staging server configuration. Implementing a staging server provides an environment for checking for accuracy, issues with the design, and performance. With a staging server configuration authoring, staging and delivery are separated onto different servers. The staging environment can be used for testing or to allow changes from the authoring environment to accumulate prior to syndicating the changes to the delivery environment in a single batch.
The following diagram illustrates a staging server topology. There is a different server, or cluster of servers, for the delivery, staging, and authoring environments. The delivery, staging, authoring environment all access the same LDAP. If needed the LDAP and database servers can be clustered too. web site users access the delivery server through the web server. Authors access the authoring server and content is syndicated to the staging server for quality assurance verification before it is published to the delivery server.
On the authoring server the following activities occur:
- Create drafts
- Approve drafts
- Test changes
- Publish new and changed content
- Syndicate content to the staging server
On the staging server the following activities occur
- User assurance testing
- Performance testing
- Syndicate content to the delivery server
On the delivery server, the following activities occur:
- Host content for web site users
Hardware and resource considerations
- An authoring environment would normally be a clustered environment to cope with a large number of web site creators and web content authors.
- The staging environment can consist of:
- A web content delivery server or cluster that subscribes to the authoring environment. This would be used when to allow changes from the authoring environment to accumulate prior to syndicating your changes to the delivery environment in a single batch.
- A complete replica of the delivery environment. This type of environment would be used for system UAT to ensure that the web site being delivered is accurate, error-free and can perform under load.
- A web content delivery server or cluster that subscribes to the authoring environment. This would be used when to allow changes from the authoring environment to accumulate prior to syndicating your changes to the delivery environment in a single batch.
- The delivery environment can consist of:
- A web content delivery server or cluster that subscribes to the staging environment. Content can be delivered using either a web content viewer portlet, the web content servlet or a pre-rendered site.
- A local WebSphere Portal production environment that subscribes
to the staging environment and delivers web content using a web content viewer.
- A remote WebSphere Portal production environment. In this scenario a web content delivery server subscribes from the staging environment, and the remote WebSphere Portal production environment uses WSRP and a web content viewer to display content from the web content delivery server.
- A web content delivery server or cluster that subscribes to the staging environment. Content can be delivered using either a web content viewer portlet, the web content servlet or a pre-rendered site.
Syndication options
- Automatic one-way syndication from the authoring environment to the staging environment.
- Manual one-way syndication from the staging environment to the delivery environment.
Parent: Server topologies
Staging-server topology for WCM
To deliver large complex web sites with a large number of site users and content creator, implement a staging server configuration. Implementing a staging server provides an environment for checking for accuracy, issues with the design, and performance. With a staging server configuration authoring, staging and delivery are separated onto different servers. The staging environment can be used for testing or to allow changes from the authoring environment to accumulate prior to syndicating the changes to the delivery environment in a single batch.
The following diagram illustrates a staging server topology. There is a different server, or cluster of servers, for the delivery, staging, and authoring environments. The delivery, staging, authoring environment all access the same LDAP. If needed the LDAP and database servers can be clustered too. web site users access the delivery server through the web server. Authors access the authoring server and content is syndicated to the staging server for quality assurance verification before it is published to the delivery server.
On the authoring server the following activities occur:
- Create drafts
- Approve drafts
- Test changes
- Publish new and changed content
- Syndicate content to the staging server
On the staging server the following activities occur
- User assurance testing
- Performance testing
- Syndicate content to the delivery server
On the delivery server, the following activities occur:
- Host content for web site users
Hardware and resource considerations
- An authoring environment would normally be a clustered environment to cope with a large number of web site creators and web content authors.
- The staging environment can consist of:
- A web content delivery server or cluster that subscribes to the authoring environment. This would be used when to allow changes from the authoring environment to accumulate prior to syndicating your changes to the delivery environment in a single batch.
- A complete replica of the delivery environment. This type of environment would be used for system UAT to ensure that the web site being delivered is accurate, error-free and can perform under load.
- A web content delivery server or cluster that subscribes to the authoring environment. This would be used when to allow changes from the authoring environment to accumulate prior to syndicating your changes to the delivery environment in a single batch.
- The delivery environment can consist of:
- A web content delivery server or cluster that subscribes to the staging environment. Content can be delivered using either a web content viewer portlet, the web content servlet or a pre-rendered site.
- A local WebSphere Portal production environment that subscribes
to the staging environment and delivers web content using a web content viewer.
- A remote WebSphere Portal production environment. In this scenario a web content delivery server subscribes from the staging environment, and the remote WebSphere Portal production environment uses WSRP and a web content viewer to display content from the web content delivery server.
- A web content delivery server or cluster that subscribes to the staging environment. Content can be delivered using either a web content viewer portlet, the web content servlet or a pre-rendered site.
Syndication options
- Automatic one-way syndication from the authoring environment to the staging environment.
- Manual one-way syndication from the staging environment to the delivery environment.
Parent: Server topologies
Related:
Single-server topology
Standalone server topology
Clustered servers topology
Portal farm topology
Single-server topology for WCM
Dual-server configuration for WCM