IBM Books

Planning Volume 2, Control Workstation and Software Environment

Question 7: What are your reliability and availability requirements?

What are your reliability and availability requirements? Who is going to use the SP? For some users reliability is not worth the cost. For others it is worth any cost and extremely important to keep the production system up and running. Two of the functions in PSSP that assist in reliability and availability are the High Availability Control Workstation and SP system partitions.

Systems that use a switch for connectivity also offer enhanced availability.

High Availability Control Workstation

One function providing enhanced reliability is the High Availability Control Workstation (HACWS). It supports a second control workstation that effectively eliminates the control workstation as a single point of failure. When the primary control workstation becomes unavailable, either through a planned event or a hardware or software failure, this SP high availability component detects the loss and shifts the workload off that component and to a backup control workstation.

To provide this extra reliability and eliminate the control workstation as a single point of failure, you need both extra hardware and software as summarized in Table 7.

Table 7. Requirements for the High Availability Control Workstation

Software An additional AIX license
The HACWS optional component of PSSP
2 licenses for the HACMP program
Hardware A second control workstation
HACWS Connectivity Feature

Planning and using the HACWS component of PSSP will be simpler if you configure your backup control workstation identical to the primary control workstation. Some components must be identical, others can be similar. Wait until the last question about control workstation hardware and software to specify the components. For now, you need only decide if you need HACWS support. For more information and usage restrictions, see Chapter 4, Planning for a high availability control workstation.

SP system partitions

Partitioning your SP system can aid in system availability. This support lets you logically divide the SP system into non-overlapping groups of nodes called system partitions. You can then use one system partition, for example, to test new levels of AIX, PSSP, licensed programs, application programs, or other software on an SP system that is currently running a production workload in another system partition, without disrupting that workload. The partitioning solution assumes that you have nodes available for another system partition. A minimum system partition consists of at least two drawers (or four slots). If you do not partition your SP system, everything is considered to be in one SP system partition.

|System partitioning is not supported in systems with the SP Switch2 |nor with clustered enterprise server systems that do not use the SP |Switch. |

You might not have to partition your system just for installation and testing. Coexistence support, which allows you to migrate one node of your system at a time, also promotes system availability. With coexistence, you are permitted to have multiple levels of PSSP operating within a single SP system partition. However, limits and restrictions do apply. There are issues particularly involving security support. See Chapter 11, Planning for migration to help you decide whether coexistence alone is right for you.

A good use for system partitions is to create multiple production environments with the same non-interfering characteristics that benefit a testing partition. With system partitions the environments are sufficiently isolated so that the workload in one environment is not adversely affected by the workload in the other. They might be especially useful to isolate services which have critical implications to job performance, for example the switch. System partitions let you isolate switch traffic in one system partition from the switch traffic in other system partitions.

You might consider partitioning your SP system if you need a strong security policy for part of your SP system, but you do not want the overhead of enforcing that security policy on the entire system. Whatever your purpose for having SP system partitions, the same set of authentication methods for security must be enabled on all nodes within one SP system partition. Keep in mind that any system partition with a node running at a level earlier than PSSP 3.2 must have Kerberos V4 configured and enabled as an authentication method for AIX remote commands while the compatibility mode must be enabled for use by SP trusted services.

Remember, initially the system is a single partition. The number of system partitions you can define depends upon the size of your SP system. See Chapter 7, Planning SP system partitions for more information and rules about system partitions. If you decide you want system partitions, study that chapter before completing your system plan. For now, you only need to decide if it is something you want and how many system partitions you think you'll need. You can return and modify these answers if you find other information that affects your decision.

Table 8. Function checklist

Check Function

Do you want the redundancy of a High Availability Control Workstation?

How many system partitions do you want?
  • Will you run PSSP 3.4?

  • Will you run PSSP 3.2?

  • Will you run PSSP 3.1?

Review coexistence limitations in Chapter 11, "Planning for migration" to help you decide if you need to partition your system.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]