Before you begin planning the actual system migration steps, you must understand your current system configuration and the system requirements that led you to that configuration. Also, before planning begins, you should review prior system plans for goals that have not yet been met. Assessing the priority of the goals or why they were not met can influence how you will conduct the current system migration.
Similarly, while the configuration worksheets in this book are generally not required for performing a software migration, there can be merit in reviewing your previous set, and possibly reviewing or completing the current worksheets. For example, this might be appropriate when evaluating the use of system partitions or coexistence in your current systems or as part of your planned migration strategy, or in determining any changes to your boot-install server configuration.
The underlying task in planning your migration is to determine where you want to be and what staging will allow you to ultimately reach that goal. There are general factors that drive the requirement for migrating to new software levels, including both advantages (such as, new function, performance) and possible impacts or disadvantages (such as, production down time, stability). The fact that you are planning a migration implies that these factors have already been considered.
Another factor that will influence your migration plans involves the dependencies and limitations that exist between applications. For example, if you plan to run the General Parallel File System licensed program, you must also run either PSSP with the Virtual Shared Disk and Recoverable Virtual Shared Disk optional components installed or you must run with the HACMP/ES licensed program. Besides co-requisite software limitations, other limitations might involve operating systems, system software, and applications which might operate in your current system environment but not in the migrated environment.
These software requirements, weighed against your SP system workload, generally drive three key components of your migration goals:
Understanding coexistence support and possibly doing some system partitioning can help you fully develop your SP system's efficiency. However, you must fully assess your system so that you will have all of the information that you need to plan the steps of your migration.
A full migration plan involves breaking your migration tasks down into distinct, verifiable, and recoverable steps, and planning the requirements for each migration step. A well-planned migration has the added benefit of minimizing system downtime.
|A migration path to PSSP 3.4 and AIX 4.3.3 or
|AIX 5L 5.1 is provided from each of the PSSP and AIX levels shown in Table 45.
|
|Table 45. Migration paths supported
| From | To |
|---|---|
| PSSP 2.4 and AIX 4.2.1 or 4.3.3 | PSSP 3.4 and AIX 5L 5.1 or AIX 4.3.3 |
| PSSP 3.1.1 and AIX 4.3.3 | PSSP 3.4 and AIX 5L 5.1 or AIX 4.3.3 |
| PSSP 3.2 and AIX 4.3.3 | PSSP 3.4 and AIX 5L 5.1 or AIX 4.3.3 |
If your SP contains a control workstation or node that is currently at a PSSP or AIX level not listed in the From column of Table 45, you must migrate to one of the listed combinations before you can migrate to PSSP 3.4. |Before you can migrate to AIX 5L 5.1, you need to migrate to |PSSP 3.4. How to actually migrate is documented in the book PSSP: Installation and Migration Guide.
Some optional components of PSSP and PSSP-related licensed programs have dependencies on certain levels of other components or programs. Be sure to read Migration and coexistence limitations in this chapter.
PSSP 3.4 is supported on AIX 5L 5.1 or AIX 4.3.3. Evaluate your installation's current operational requirements to understand your software requirements before you migrate to PSSP 3.4.
In addition to the operational requirements placed on your system software,
some IBM licensed programs also have PSSP release level dependencies.
The following table summarizes those dependencies.
|
|Table 46. Supported IBM licensed programs per supported PSSP and AIX release
| PSSP and AIX | IBM licensed programs |
|---|---|
| PSSP 3.4 (5765-D51) and AIX 5L 5.1 (or later) |
|
| PSSP 3.4 (5765-D51) and AIX 4.3.3 (or later) (5765-C34) |
|
| PSSP 3.2 (5765-D51) and AIX 4.3.3 (or later) (5765-C34) |
|
| PSSP 3.1 (5765-D51) and AIX 4.3.2 (or later) (5765-C34) |
|
See the Bibliography for other IBM documentation with information on AIX requirements for other licensed programs in the IBM RS/6000 software catalog.
Subject to your requirements, you might migrate your entire SP system or just part of it. Migration addresses upgrading the software on an existing SP system to PSSP 3.4 from the supported levels of AIX, PSSP, and PSSP-related licensed programs. IBM offers flexibility with features that help when migrating your system - coexistence and system partitioning:
Consider coexistence and system partitioning while evaluating your system requirements. Think about what applications you need to run and what levels of PSSP and AIX are needed to support those applications. Then, factoring in your current SP configuration, determine how many nodes you will need to run each type of workload. Important considerations and other relevant information on these two features is provided in Developing your migration strategy.
Some migrations have service prerequisites of program temporary fixes (PTFs) that need to be applied to your system. See the Read This First document for specific information. These services can be applied well in advance and they must be done before migrating to PSSP 3.4.
When possible, plan your migration in multiple stages, breaking them down into distinct steps that can be easily defined, executed, and verified. Plan a reasonable amount of time to complete each step, define validation steps and periods, and be prepared for recovery or to back out should a step not go as planned. Proper migration staging can better ensure an effective and successful migration, while minimizing system down time. You can also distribute system down time over a longer period by migrating a few nodes at a time, subject to your needs.
There are three main high-level suggestions for doing this:
|If you plan to run AIX 4.3.3 and not AIX 5L |5.1, first migrate AIX. Then migrate PSSP and related licensed |programs.
|AIX 5L 5.1 does not preserve binary compatibility for 64-bit |applications because it introduces a new 64-bit ABI. Therefore PSSP |3.2 and earlier releases are not supported on AIX 5L 5.1 or |later. Because of this binary incompatibility, if you want to migrate |to AIX 5L 5.1, you must migrate your control workstation first to PSSP |3.4 and AIX 4.3.3. Then you can migrate to AIX 5L |5.1. The nodes can be migrated from any supported base release |to PSSP 3.4 on AIX 4.3.3 or to PSSP 3.4 on AIX 5L |5.1 with a single nodecond operation.
|A direct migration from PSSP 2.4 on AIX 4.2.1, |which is no longer supported, to PSSP 3.4 on AIX 5L 5.1 is not |available. If you want to do that, first migrate from PSSP 2.4 |on AIX 4.2.1 to PSSP 3.4 on AIX 4.3.3 and |subsequently migrate to AIX 5L 5.1 with a second nodecond |operation.
|For example, to minimize the amount of change to your control |workstation at one time and also minimize your service window, you might want |to do the following: |
|Table 47. Suggested migration stages
| From level | Migration stage 1 | Migration stage 2 | Migration stage 3 |
|---|---|---|---|
| PSSP 3.2 | PSSP 3.4 | PSSP 3.4 | PSSP 3.4 |
| GPFS 1.3 or 1.4 | GPFS 1.3 or 1.4 | GPFS 1.5 | GPFS 1.5 |
| HACMP 4.4 | HACMP 4.4 | HACMP 4.4.1 | HACMP 4.4.1 |
| AIX 4.3.3 | AIX 4.3.3 | AIX 4.3.3 | AIX 5.1 |
| LL 2.2 | LL 2.2 | LL 2.2 | LL 3.1 |
| PE 3.1 | PE 3.1 | PE 3.1 | PE 3.2 |
| ESSL 3.2 | ESSL 3.2 | ESSL 3.2 | ESSL 3.3 |
| PESSL 2.2 | PESSL 2.2 | PESSL 2.2 | PESSL 2.3 |