2.7 Sample physical architectures

Sample physical architectures

In this section, we look at physical architectures that you can use to build the Lotus Web Content Management infrastructure.

Attention: You can use the architectural designs described in this section to build out any of the environments described in the previous section. In practice, you combine a number of these architectures across the various environments.

In real-world installations of Lotus Web Content Management, a variety of common infrastructure designs are in place. The primary differences in these designs are due to variations in several basic assumptions:

Site size and complexity: For a relatively small Web site, it might not be necessary to have individual servers dedicated to all four types of Lotus Web Content Management environments.
Funding: In many cases, there is a limitation in regard to the funding provided to build out the Lotus Web Content Management infrastructure. In these cases, you must construct your environment as soundly as possible within the budget. However, the budget is likely to force you to reduce the infrastructure.

Corporate standards: Your company standard might not allow for the creation of certain types of servers. For example, it is quite common for smaller companies to omit the staging environment because it requires time and resources to perform the content review in this stage.

Important: As you look at these various architectures, remember that these are only representative architectures based on practical experience in deploying Lotus Web Content Management. Many other architectural combinations can be built based on your organization’s needs. Use these architectures as a baseline from which to build your environment.

Basic architecture

The basic architecture (illustrated in the following figure) is the smallest acceptable design for an IBM Lotus Web Content Management infrastructure.

Sample architecture – Basic

In the basic architecture, a single Lotus Web Content Management server is responsible for all Lotus Web Content Management activities. Site visitors access this single server for content when they visit the Web site.

An HTTP server is placed in the DMZ to receive all requests for site content. This HTTP server acts primarily as a proxy to shield the Lotus Web Content Management server from direct access. If you use IBM HTTP Server (or Apache), the WebSphere Portal and Lotus Web Content Management server can generate an HTTP plug-in to ease configuration of the HTTP server.

While this architecture is technically feasible, there are a variety of issues that make it suboptimal.

Design advantages

Design advantages include simplicity. This design is simple to implement due to the limited number of components that are involved.

Design disadvantages

This architecture has the following design disadvantages:

Failover or redundancy: This environment has no failover or redundancy in any layer. If any one part of the system fails, then the entire site appears to be down.
Load balancing: This environment has no load balancing capabilities. There is only one Lotus Web Content Management server, and it must handle the entire workload at all times.
Maintenance: To perform site maintenance, the site must be unavailable.

Intermediate architecture

The intermediate architecture (illustrated in the following figure) attempts to correct the primary run-time deficiencies of the basic architecture.

Sample architecture - Intermediate

In the intermediate architecture, multiple Lotus Web Content Management servers share the responsibility for Lotus Web Content Management activities. Site visitors can access any of these servers for content when they visit the Web site.

Multiple HTTP servers are placed in the DMZ to receive requests for site content. These HTTP Servers perform two primary functions:

Proxy: The HTTP servers act as a proxy to shield the Lotus Web Content Management servers from direct access. If you use IBM HTTP Server (or Apache), the WebSphere Portal and IBM Lotus Web Content Management server can generate an HTTP plug-in to ease configuration of the HTTP Server.
Load balancing: The HTTP plug-in can be configured to provide load balancing based on a variety of algorithms. If your Lotus Web Content Management servers are not similar in processing capabilities, you can set up the plug-in to load balance traffic according to server capacity.

While this architecture improves upon the basic architecture, still several issues make it suboptimal for larger environments.

Design advantages

The intermediate architecture has the following design advantages:

Simplicity: This design is simple to implement due to the limited number of components that are involved.
Load balancing and redundancy: If you are using IBM HTTP Server (or Apache), this environment has basic load balancing capabilities. Because there are duplicates of all components, a basic level of redundancy exists in this design.
Maintenance: With multiple servers available to deliver content, site maintenance can be performed without the entire site becoming unavailable.

Design disadvantages

The intermediate architecture has the following design disadvantages:

Administration: As more Lotus Web Content Management servers are added to the infrastructure, the maintenance effort to make changes increases in a linear fashion. Changes must be manually made to each server because the servers are not clustered in this design.
Failover: While we have redundancy with this design, there is no automated failover in the event that a specific component fails. If any one part of the system fails, there is a likelihood that the site is down to some subset of the users.

Advanced architecture planning

The intermediate architecture still contains one major deficiency. That is, there is no failover within the environment. To resolve this issue, we look at building a slightly more complex infrastructure that includes clustering some of the servers.

WebSphere Portal and Lotus Web Content Management integrated

In the WebSphere Portal and Lotus Web Content Management integrated architecture, we continue to enable Lotus Web Content Management on all of the WebSphere Portal servers. However, unlike the intermediate architecture, in this environment, we cluster the portal servers as illustrated in the following figure.

WebSphere Portal and Lotus Web Content Management integrated

When you cluster WebSphere Portal servers, they share an identical configuration. This configuration is managed from a WebSphere Deployment Manager server (not pictured). The Deployment Manager is responsible for synchronizing the WebSphere Portal configuration across all servers in the cluster. Thus, when you deploy a Lotus Web Content Management portlet or create a new portal page, the Deployment Manager synchronizes all servers in the cluster, which is a reduction in administrative time and effort.

In addition, when you cluster the WebSphere Portal servers, the Deployment Manager can create a plug-in for IBM HTTP Server and Apache that allows the HTTP servers to gracefully failover in the event that one of the portal servers stops functioning. While setup and maintenance of a cluster take time and effort, this effort is typically small compared to the ongoing benefits provided to the infrastructure.

Design advantages

The WebSphere Portal and Lotus Web Content Management integrated architecture has the following design advantages:

Load balancing and redundancy: If you are using IBM HTTP Server or Apache, this environment has basic load balancing capabilities. Because there are duplicates of all components, a basic level of redundancy exists in this design.
Failover: With the addition of a cluster, the HTTP Server can provide failover for the WebSphere Portal servers. If any one part of the system fails, the entire site does not appear to be down.
Maintenance: With multiple servers available to deliver content, site maintenance can be performed without the entire site becoming unavailable.
Local rendering portlet: If IBM Lotus Web Content Management is running on all portal servers, you can use the Local Rendering Portlet. By not having to communicate with an external Lotus Web Content Management server (as required with the Remote Rendering Portlet), you eliminate a potential performance bottleneck.
Administration: As more IBM Lotus Web Content Management servers are added to the infrastructure, the maintenance effort to maintain the infrastructure does not increase significantly. Changes to server configurations are performed from the central Deployment Manager console.

Design disadvantages

The WebSphere Portal and Lotus Web Content Management integrated architecture has the following design disadvantages:

Complexity: This design is fairly complex. The learning curve for installing and administering a clustered environment servers should not be underestimated.
Cost: Enabling Lotus Web Content Management on every WebSphere Portal server quickly increases your infrastructure cost.

WebSphere Portal and IBM Lotus Web Content Management separated
In the WebSphere Portal and IBM Lotus Web Content Management separated architecture, we no longer enable Lotus Web Content Management on all of the WebSphere Portal servers. Instead, we create a separate tier of servers with the sole task of serving Lotus Web Content Management content as illustrated in the following figure.

Lotus Web Content Management and WebSphere Portal on separate servers

As with the other advanced architecture, this configuration clusters the portal servers. However, in this configuration, we create a separate cluster for the Lotus Web Content Management servers.

When you cluster the WebSphere Portal or Lotus Web Content Management servers, they share identical configurations within their respective cluster. This configuration is managed from a WebSphere Deployment Manager server (not pictured). The Deployment Manager is responsible for synchronizing the configuration across all servers in each cluster. This means that, when you deploy an updated Lotus Web Content Management portlet or create a new portal page, the Deployment Manager synchronizes all servers in the appropriate cluster, resulting in a reduction in administrative time and effort. In addition, when you cluster the WebSphere Portal or IBM Lotus Web Content Management servers, the Deployment Manager can create a plug-in for IBM HTTP Server or Apache that allows the HTTP Servers to gracefully failover in the event that one of the portal servers stops functioning. This is how both sets of HTTP Servers can provide failover for WebSphere Portal and Lotus Web Content Management requests.

Note: It is technically possible to have a single set of HTTP Servers act as the front end for all IBM Lotus Web Content Management and WebSphere Portal servers. This requires a manual modification to the plug-in that combines elements from the plug-ins created by each cluster. Because there are duplicates of all components, a basic level of redundancy exists in this design.

Design advantages

The WebSphere Portal and IBM Lotus Web Content Management separated architecture has the following design advantages:

Failover: The addition of a cluster allows the HTTP Server to provide failover for each cluster. If any one part of the system fails, the entire site does not appear to be down.
Maintenance: With multiple servers available to deliver content, site maintenance can be performed without the entire site becoming unavailable.
Administration: As more WebSphere Portal or IBM Lotus Web Content Management servers are added to the infrastructure the maintenance effort to maintain the infrastructure does not increase significantly. Changes to server configurations are performed from the central Deployment Manager console.

Design disadvantages
The WebSphere Portal and IBM Lotus Web Content Management separated architecture has the following design disadvantages:

Complexity: This design is fairly complex. The learning curve for installing and administering a clustered environment servers should not be underestimated.

Remote Rendering Portlet: If IBM Lotus Web Content Management is running on a separate set of servers all portal servers, you must use the Remote Rendering Portlet. Because this portlet communicates with an external IBM Lotus Web Content Management server, there is a potential performance bottleneck if the network connection is poor.

Note: There is a cost-benefit analysis with regard to clustering stand-alone Lotus Web Content Management servers. The Deployment Manager automatically creates the plug-in for the HTTP Server. This plug-in makes for easy setup of failover within the Lotus Web Content Management tier. If the clustering issues have you leaning toward not clustering the Lotus Web Content Management servers, other techniques can provide failover for the Lotus Web Content Management server tier. For example, several vendors make hardware that can perform this task. Of course this hardware has additional costs and configuration issues. No single answer will work in all scenarios.