Operational Architectures; Adopting A Tiered Architecture; Addressing Scaleability And High Availability - IBM BS029ML - WebSphere Portal Server Self Help Manual

Self help guide
Table of Contents

Advertisement

2.3 Operational architectures

Increasingly, WebSphere Portal Server customers are interested in deploying a Portal in a
business critical environment. However, such a requirement raises the question about how
best to address such needs in terms of selecting the most appropriate operational
architecture. Fundamentally, these are all aspects that should be defined under the
non-functional requirements of a solution. For example, availability requirements should be
captured and agreed upon, as early on in a project as possible, as they dictate the
high-availability and recovery aspects that an architecture must meet.
The purpose of this section, therefore, is to take a look at how a business critical deployment
can be accomplished using today's WebSphere Portal Server V6.0.1 product, and the
advantages and disadvantages of each architectural design. It should be noted that
regardless of the operational architecture chosen, that there are also a number of
high-availability considerations regarding the associated database backup/replication,
maintenance procedures, etc. which must be considered in developing a complete
operational solution for a WebSphere Portal Server deployment.

2.3.1 Adopting a tiered architecture

A common architectural principle is that of adopting a tiered or segregrated topology. This well
practiced approach is in keeping with the J2EE mandate that prescribes the separation of
applications into client, presentation, business, and enterprise system tiers. The approach is,
however, most beneficial in terms of overall enterprise security and performance optimization.
As such, it is strongly suggested that a n-tier approach is adopted as the topology of choice
for all high-volume WebSphere Portal Server deployments. This is regardless of the selected
platform. Differentiating between the functional components of the solution allows each
physical server to be specifically sized to the task in hand. For example, placing the Web
server on a separate physical machine from the WebSphere Portal Server allows each
machine to run with different OS characteristics. The same holds true for other server types,
such as database servers.

2.3.2 Addressing scaleability and high availability

A major concern with any architecture is the ability to address the needs of scalability and
redundancy. Furthermore, it is important to recognize that the operational aspects of just such
an architecture, such as availability, also influence the overall design of a solution.
The ability to scale WebSphere Portal Server V6.0.x, or any other WebSphere Application
Server for that matter, is essentially achieved by clustering. Clustering allows requests to be
Workload Managed (WLM'ed) between a number of cloned copies of the concerned
application. In addition, when architected correctly, clustering addresses redundancy and
fault tolerance.
The most important factors of a mission-critical production environment are redundancy and
fault tolerance, ensuring that there is no single point of failure in an architecture. The most
important aspect of fault tolerance is to have at least two of members or replicas of each
component. These can either be in a primary-to-backup formation or a peer-to-peer
configuration. This thought can even be extended to the data center itself.
Chapter 2. Architecture and planning
21

Advertisement

Table of Contents
loading

This manual is also suitable for:

Websphere portal v6

Table of Contents