Originally posted by: yogeen

Dear all,

We have 3 no. of p520 servers running different dedicated services and a 4th spare/development server. For applying patches to production systems we usually switch the service to the backup system by restoring mksysb. After applying patches we revert to the original system. This is our legacy method.

With advances in technology in recent years, we are exploring a better alternative for applying patches without switching over to backup system. What would be the best choice for our scenario ? Using Multibos, WPAR or LPAR (we dont have HMC but we can use IVM to create and manage LPAR's). Apart from applying patches, if we get better hold over the technique we can also look at services consolidation on a single server.

Please suggest a suitable method.

regds
-yogeen

Originally posted by: unixgrl

Use multibos if you don't have spare disk in the system but do have free space in rootvg.

Use alt_disk_copy method if you have spare disk or can break a root mirror to create a spare disk. Been using this method for years and its very reliable.

The nice thing about either method is that you can patch the night before and reboot to make them take affect or you can copy rootvg beforehand and patch the running system and reboot.

Originally posted by: orphy

Does sound quite legacy!

For starter, does the 4th server have everything you need to validate changes (e.g. patches) before rolling into production? If you can validate patches on the 4th, you might be better off testing out patches there and then apply them to the 3 production servers. This method should have very little risk, assuming that you can test out the services before applying the same patches to production. Should something go wrong in production, it also has very little recovery/rollback time. What you should do is install the patches in an "APPLIED" state, by setting "COMMIT software updates?" to "no" in SMIT. Should the need arise to roll back, simply reject the applied software updates, reboot, and you should be back in business. To be extra safe, you can also do some mksysbs before applying patches to production. This is something you should always do anyway. I don't recommend it but if your can't test out patches on the spar server and you can take some risks and possible downtime with the production environment, you can just take some mksysbs, APPLIED (DO NOT COMMIT) the patches to production, test, and turn it over to users. The rollback would be the same.

Now, if getting a better replacement server is doable, you might consider creating the production LPARs on the physical server and another set (one with all services if system resources are limited) so that you can test patches in this 2nd set of server(s).

There are other ways to do this but it's more difficult to suggest the best method without knowing more about your environments, applications, SLA, RTO/RPO, etc. That's what consulting is for! :)
Orphy