[pca] Cluster, zones, noreboot. - Checking System Consistency

[David Stark]

Hi Don.

I tried ppc a while ago (I think you'd mentioned it on the PCA list 
before). It's a bit noisy (especially with non-bootable zones (like 
failover zones on a cluster :) )), but should be handy. Haven't found 
any real problems with it yet, but then I haven't had any problems 
patching yet either...

Cheers.

Dave

On 13/07/2010 16:58, Don O'Malley wrote:
> Hi David,
>
> Ronan O'Connor on our team has developed a tool called the Patch
> Pre-Flight Check tool, that will check a system is in a healthy state
> prior to beginning a maintenance session.
>
> See http://blogs.sun.com/patch/entry/patching_pre_flight_checks_ppc for
> more details on the tool.
>
> The tool itself can be downloaded from the Sun Patch Forum post at
> http://forums.sun.com/thread.jspa?threadID=5404908&tstart=0.
> (Note: See
> http://blogs.sun.com/patch/entry/patch_forums_now_available_for for
> details of how to register for the Patch Forum.)
>
> I've attached a copy of the ppc tool and the associated pdf manual for
> those not on registered on the Patch Forum.
>
> Best,
> -Don
>
>
> David Stark wrote:
>> Hi Dave.
>>
>> On 13/07/2010 14:30, French, David wrote:
>>> I can't speak to Sun's Cluster software but here we use Veritas VCS and
>>> do update on attach. The advantage is not as much time as being able to
>>> schedule the work. For example, if you patch them all at once, they are
>>> all down while this is being done. If you migrate zones to another
>>> system, leaving just the global zone on one of the systems, you can
>>> patch that system. Then when it has been rebooted and checked out, you
>>> can migrate systems as needed using update on attach, until they have
>>> all been updated. Then patch the other node that has just a global and
>>> roll back some of the zones to that box.
>> >
>>> This may cause a 2-3 reboots for some zones depending on where they
>>> live, but zones usually boot fast compared to actual HW. Just to give
>>> you an idea, a system needing a hundred patches may take> 1 hr to
>>> patch. An update on attach will run in a fraction of that time. It
>>> also allows you to schedule the time with your customer instead of
>>> requiring they all be down for hours at the same time. I find people
>>> are more apt to accept quick reboots and the short time for an update
>>> on attach than accept being down for an extended period while you patch
>>> everyone.
>>
>> Ah, excellent. Anything that reduces downtime on the zones would be a
>> win for us.
>>
>>> But if all zones are related then having them down at the same time may
>>> not be an issue and a parallel patch may be more acceptable.
>>
>> Yeah, most of our clusters are single-application, but then there's
>> the dreaded 'Unix Consolidation Cluster' with 20-odd business units'
>> stuff on it. I have a feeling Update on Attach will come in handy.
>> Unfortunatley, I'll have to do an old-school patch run to get Update
>> On Attach installed :( .
>>
>>> Now, I will say this. Before patching validate the current packages and
>>> patches. I mention this as I ran into an issue on one of my systems
>>> (non cluster, but global and 4 container/zones) where the SUNWcsl
>>> package was missing pkginfo under /var/sadm/pkg/SUNWcsl. Not only did
>>> it cause patch issues, but it also broke update on attach so much that
>>> the only option I had was to rebuild the zones. Sun (at the time)
>>> wasn't much help. The issue was deeper than just the pkginfo file but
>>> also the version of that file and the files in the package used in
>>> patching the zones. The patch utilities mangled them and I didn't
>>> catch it before patching.
>>
>> Yeesh. Broken core libs package? Ouch.
>>
>>> I mention this as the version you are running is in the period I was at
>>> when there were issues with the pkg/patch utilities, so better to check
>>> in advance.
>>
>> We've been OK so far (4 clusters patched already). Fingers crossed.
>>
>>> --Dave
>>
>> Cheers.
>>
>> Dave
>>>