Avoid Ignite upgrade and QPK together- Advise Please

[brian_31]

Team:

Please voice your opinion. Our is a Production environment where we have 0 outages for the past 6 months or so. We are going to upgrade OS patch (QPK) and Ignite. My opinion is since we are dealing with more than a changed kernel in installing these QPK Bundles, we should not install Ignite and QPK together.The better approach would be take a ignite backup, install qpk and then at the next oppurtunity install/upgrade the Ignite. Please share your thoughts..

Thanks

Brian

[Darrel Louis]

Hi,

We've done both on the same day, that's due to the time window we've for maintenance.

But your wright, never perform two changes on the same day.

But infact a Ignite upgrade should be no problem.

Darrel

[James R. Ferguson]

Hi Brian:

Installing a new version of Ignite does not require a reboot.

Hence, you could upgrade your Ignite version; perform a 'make_tape_recovery' (for example) and then install your QPK.

If you are more comfortable, perform an Ignite 'make_tape_recovery' with your *current* Ignite; install the new version of Ignite; amke another 'make_tape_recovery' image and then install the QPK.

Regards!

...JRF...

[brian_31]

We have 7 machines to deal with and considering the change window time it wd take i tght i would not do these two together.

Thanks

Brian

[James R. Ferguson]

Hi Brian:

The Ignite upgrade takes but a few minutes!

Once you have download a new version, copy it to each of your servers.

Outside of the downtime, do your Ignite upgrades.

Regards!

...JRF...

[John Payne_2]

I never say "do not do two changes at once" for things like upgrades and patching. That is a phrase I reserve for incident response and repair.

The phrase I use for upgrades is "Throughly test the changes before deploying to production." You may not have machines to test on, so this may not work for you. With properly tested changes there shouldn't be a problem making multiple changes at once.

Anyhow, I don't know your window, can't you be doing more than one machine at a time? A large portion of the process is installing the patches waiting for the reboot...

Hope it helps.

John

[A. Clay Stephenson]

You are now in an area where a Sandbox is essential. You then know all your answers before you you have to deploy to production. A sandbox is one of the best investments your company can make if uptime is important to you. An older, cheap used box makes an excellent Sandbox.

Sadly, the only way to really test an Ignite backup is to Ignite a system --- and that is not the ideal solution if all you have are production boxes.

If you have some spare disks then my method that adds a layer of comfort above Ignite is a lifeboat. The idea is that you use dd to make rdsk copies of your existing boot disk(s). If anything goes wrong, you simply remove the boot disk(s) and insert the lifeboat disk(s) into the boot disk slot(s) and power up. You are back exactly as you were before the patch. Since this is a "hot" backup the filesystems are dirty but the automatic fsck's will clear this up. I refresh my lifeboats at least once a week when the systems are quiet and before any patch. It's very comforting to know that you can get your boxes back in a fraction of a time that Ignite takes --- and being paranoid, I do Ignite backups as well.

Lifeboats protect you from things that Mirrors do not (and I use them as well): 1) your own stupidity 2) really, really bad patches.

[Darrel Louis]

Brian,

We've a Test and Production environment which or identical.
At least 4 weeks before we install anything in production we install it in the test environment.
In this case we don't have any surprises during the rollout in production.

Darrel