Table of Contents
Advertisement
failure and issue the TAKEOVER HADR command. There is no requirement to configure it to
do any disk takeover, IP address takeover, or anything else, so the configuration is
straightforward. When it detects that the Primary has failed, HACMP or TSA will run the
TAKEOVER HADR ON DATABASE prod BY FORCE command, which will cause the Standby
to become the Primary. Client requests are automatically redirected to the new Primary
server using the Automatic Client Reroute (ACR) capability in the DB2 Client.
The real difference between instance failover and HADR failover is the time taken to be back
up and running after a failure. With HADR, this can be under 30 seconds, but with HACMP
instance failover, this is typically around one to two minutes.
Data redundancy is an additional benefit of deploying HADR when compared to HACMP
instance failover alone. If the primary storage fails in a HADR configuration, failover can occur
to the redundant storage. In the case of just HACMP, loss of the shared storage means
catastrophic failure, with the only course of action being the restoration from a previous
backup. Any incremental data will be lost.
2.8 Portal planning recommendations
As acknowledged at the beginning of this chapter, WebSphere Portal Server architectures
come in many shapes and forms. A common requirement of any implementation, therefore, is
the amount of attention and detail given to adequately planning such a project. Indeed, in
order to minimize implementation risk, good planning is essential; failing to plan is planning to
fail.
2.8.1 Recommendations for a successful implementation
We strongly recommend that a WebSphere Portal Server based implemention is treated as a
complex infrastructure project from the outset. For anything other than an out-of-the-box
implementation, which only encompasses laying down the core WebSphere Portal Server
runtime, the complexity and length of time a project will need will grow significantly as more
products or integration points are introduced. For example, an architecture incorporating an
External Security Manager, such as Tivoli Access Manager, will demand extra resources with
the appropriate skill set and additional time to both plan and implement.
In large WebSphere Portal Server solution projects, as with any other large scale based
projects, it is crucial to have proper project management and governance mechanisms in
place. Beside the large amount of work that is caused by the various workstreams, the
demands in managing such undertakings are increased dramatically.
Assemble a multidisciplinary team
It takes a multidisciplinary team to successfully deploy a large scale WebSphere Portal
Server implementation. As such, the two most important leaders on a delivery project are the
Solution Architect and Project Manager. It should further be recognized that while the
Solution Architect remains ultimately responsible for the overall solution design, it is possible
that there are other architects under his or her command. For example, it is not uncommon
that there is an architect assigned to each of the following categories: application, enterprise,
integration, information, infrastructure, and operations.
Adoption of a methodology, pattern, or reference architecture
Although not mandated by any means, the adoption of a methodology, pattern, or reference
architecture is strongly recommended when setting out on a WebSphere Portal Server
Chapter 2. Architecture and planning
51
Advertisement
Table of Contents
Troubleshooting
