We have at this time Oracle RAC environments with GPFS 3.3 (22.214.171.124) release installed.
We planned to migrate directly from 3.3 to 3.5 release. So as I read, we need to stop all the cluster nodes to make this upgrade (no rolling upgrade supported).
As some of these environments are production environments, we want to prepare this upgrade before on Dev environments to be sure of all the tasks and the time needed for these operations. So during the preparation tasks, we want to be able to revert to the previous level of GPFS, in order to replay multiple times and entirely this process of upgrade.
As I understand, after the installation of the new release 3.5 and the last fix on each node of the cluster, if we complete the operation with the mmchconfig release=LATEST command and the mmchfs -V full, the only way to be able to revert to previous release 3.3, is to do an mmexportfs of the FS before reinstalling the 3.3 release and a mmimportfs after the re-creation of the cluster? Is this right?
Are there some cases where we need to backup all the data before this operation, and then after recreating the cluster, we need to restore the data, or can we just import the FS with mmimportfs?
If we use the mmmigratefs command, is it possible to revert in the same manner with mmexportfs and mmimportfs after recreating the cluster?
Thanks for your help.
Another question :
After we shutdown GPFS on all the nodes,do we need to uninstall the 3.3 release before installing the 3.5 release? I didn't see anywhere that is is required, except when we want revert to the previous release.
Can you confirm me that we can just update the new release on the top of the current release?
Pinned topic migration from 3.3 to 3.5 questions
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-02-26T18:59:59Z at 2013-02-26T18:59:59Z by SystemAdmin
gcorneau 0100003X4E149 Posts
Re: migration from 3.3 to 3.5 questions2013-02-26T16:51:29ZThis is the accepted answer. This is the accepted answer.> We planned to migrate directly from 3.3 to 3.5 release. So as I read, we need to stop all the cluster nodes to make this upgrade (no rolling upgrade supported).
Correct, all nodes will have to migrate in one outage. No rolling upgrade for N-2 releases.
> if we complete the operation with the mmchconfig release=LATEST command
This step will enable the "new" cluster capabilities in the GPFS daemons, including the ability create/update existing file systems to the latest levels.
> and the mmchfs -V full
This command will update the existing file system designated to use the new structures.
Please note that the "mmmigratefs" command will have to be run to enable the "fastea" capabilities.
> the only way to be able to revert to previous release 3.3, is to do an mmexportfs of the FS before reinstalling the 3.3 release and a mmimportfs after the re-creation of the cluster? Is this right?
Once you've run the mmchfs -V full command against a given file system, it will NOT be able to be mounted on the older release.
The "mmchconfig release=LATEST" only affects the currently running cluster. If you revert the software back to V3.3,
then the release level reverts back to the previous release.
If you want to test the "mmchfs -V full" step, then you'll have to backup the file system and re-create on the older level.
mmexportfs/mmimportfs won't change the file system version.
It's always a good idea to have current backups. While upgrading (and running the mmchconfig/mmchfs commands) is pretty stable (I've not seen any problems with it using V3.5), there's always the possibility of other errors (oops!, I ran mmcrnsd or mmcrfs!)
You can mmexportfs the file system, migrate the software, then mmimportfs if you want. I don't see a reason to do this.
You'd still need to run the mmchfs command after the import to upgrade the file system version.
Hope this helps.
IBM Power Systems Advanced Technical Skills
SystemAdmin 110000D4XK2092 Posts
Re: migration from 3.3 to 3.5 questions2013-02-26T18:59:59ZThis is the accepted answer. This is the accepted answer.You could use the approach described in your note, but why? You can do a rolling upgrade (one node down for upgrade at a time) from 3.3 to 3.4 and then either stay on 3.4 or perform an upgrade to 3.5. You don't have to commit to the the new level (by running mmchconfig release=LATEST and/or mmchfs -V) right away. You really only need to run those commands if you want to use new function. If you're OK with the existing level of function, and just need a file system for Oracle RAC with a supported level of GPFS, you can run with new code levels for days/weeks/months before committing the upgrade. If the new code level appears stable, you can commit, if not, you can simply re-install old code.
mmexportfs/mmimportfs would help with recovery from a premature mmchconfig release=LATEST, but there's no way to undo a premature mmchfs -V.