Availability Requirements

Availability is a crucial requirement for a portal service. In many organizations, the portal is the employee's (or the customer's) gateway to critical information that is aggregated and displayed by the portal service. If the portal services fails, the employee or customer has no other way to access the information needed to conduct business.

Portal services can be classified according to the following levels of availability requirements:

• Low availability. This level has no real availability requirements. If the system goes down, it is acceptable to take days to repair it. This level of availability is suitable for software development, unit testing, or demonstration systems.

• Service Availability. With this level, the portal service must always be accessible to users, where failures will affect the work of employees or customers.

• Session State Availability. In addition to service availability, this level requires that session state is not lost when a user is redirected to another service instance (service failover) when failure occurs. The following are two types of session state availability requirements for portal services:

  • User Session State Availability. A user is not required to log in again when service failover occurs. In other words, that user session state is preserved in case of a service failure.

  • Application Session State Availability. A user is not required to restart a business operation when service failover occurs. In other words, the session state of applications that are providing the service is preserved in case of a service failure, and the user will not notice the failure.

The Portal Service on Application Server Cluster reference configuration is designed to provide service availability with both user session state and application session state availability. However, if application session state availability and/or user session state availability are not requirements of your organization, you can choose deployment architecture options that do not include them.

The reference configuration is not designed to sustain the complete failure of a data center. To overcome such failures, the portal service needs to be distributed across multiple locations. This kind of implementation is out of scope for the reference configuration.

The availability of a system should be measured from the user's perspective. Users care about how often a system fails and how long it takes to recover. There is no difference between a system being unavailable due to a systems failure or because of a scheduled maintenance window. Consequently, when measuring availability and when designing a highly available system, both planned and unplanned downtime needs to be considered. The reference configuration is designed to have no single points of failure. If implemented in conjunction with appropriate operational procedures and staffing, the reference configuration should result in less than one hour of unplanned downtime per year (99.99 percent availability).