IBM BS029ML Self Help Guide - Page 65

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