Parallel Patching for Solaris 10
By chrisarmes on May 27, 2009
One of the things I said I'd try and write about are various features that you will see upcoming...and I've kind of touched on this before in the "What, no tornados?" entry, specifically Parallel Patching.
This functionality went back into build 1 of what will become Solaris 10 Update 8 later this year, so what was the problem statement and what does the project do?
When zones were introduced in Solaris 10 they stretched patching of a system to the limits. The original patching system had been designed to patch the global zone and then all non global zones sequentially. Given all the performance overheads in patching a system with a large number of zones could take 10+ hours to complete a full patching window often the window could be stretched to 30+ hours depending on the number of zones installed on a system.
The solution was to remove the sequential nature of patching. In the solution in place under the "Parallel Patch Project" a Global Zone is patched then Non Global Zones are patched in parallel. The degree of parallelization is determined by a new configuration file. The overall performance gains we saw in testing are from around 20 hours down to 6.5 hours with a value of 14 for the number of parallel patch invocations. The value 14 was based on the 14 non global zones the system had installed.
Now the really good news is that the project team managed to work their magic and you'll be able to get this functionality in the patchadd patch which you can apply to an existing Solaris 10 installation. It'll be available in the late June timeframe allowing you to take advantage of this now as opposed to waiting for the update release to ship towards the end of this year.
Whilst this may not seem like a big deal the customer impact of the current functionality limitations cannot be underestimated. I remember having a discussion with one customer after they had taken a 23 hour outage and the 200+ zones they had were still not patched.
On top of this, changes like this have to go into what we call the "install" consolidation, it contains the installer and patching to name but two a lot of which dates back to SVR4 and often earlier. The code itself is fragile and any changes have to be very carefully managed, as the risk of breakage and regressions is high. One of the reasons I've got a long list of changes I'd like my team to make to improve the customer experience in this space, but why it takes us time to get them out the door. Yet another reason why OpenSolaris and Solaris.Next will have a new installer and IPS.