Sun Microsystems Portal Server 6 2005Q1, Planning Manual

Page: 84 / 192

Portal Server and High Availability
84 Portal Server 6 2005Q1 • Deployment Planning Guide
The section “Working with Portal Server Building Modules” on page 89 , discusses
an approach to a specific type of configuration that provides optimum
performance and horizontal scalability.
Portal Server and High Availability
High Availability ensures that your portal platform is accessible 24 hours a day,
seven days a week. Today, organizations require that data and applications always
be available. High availability has become a requirement that applies not only to
mission-critical applications, but also to the whole IT infrastructure.
System availability is affected not only by computer hardware and software, but
also by people and processes, which can account for up to 80 percent of system
downtime. Availability can be improved through a systematic approach to system
management and by using industry best practices to minimize the impact of
human error.
One important issue to consider is that not all systems have the same level of
availability requirements. Most applications can be categorized into the following
three groups:
• Task critical . Affects limited number of users; not visible to customers; small
impact on costs and profits
•
Business critical
. Affects significant number of users; might be visible to some
customers; significant impact on costs and profits
•
Mission critical
. Affects a large number of users; visible to customers; major
impact on costs and profits
The goals of these levels are to improve the following:
• Processes by reducing human error, automating procedures, and reducing
planned downtime
• Hardware and software availability by eliminating single-point-of-failure
configurations and balancing processing load
The more mission critical the application, the more you need to focus on
availability to eliminate any single point of failure (SPOF), and resolve people and
processes issues.
Even if a system is always available, instances of failure recovery might not be
transparent to end users. Depending on the kind of failure, users can lose the
context of their portal application, and might have to login again to get access to
their Portal Desktop.