Hello

The Novell documentation says that a mixed OES 1 and OES 2 Linux cluster
is supported and this will enable you to perform a rolling upgrade of all
the nodes gradually.

I tried this out in a lab (upgrading one OES 1 node to OES 2 and leaving
the other intact) and was really impressed at how well it works, and the
lab was quite scrappy in many ways!

Unfortunately when I came to do this on the live system it worked
appallingly. Both cluster nodes seemed totally confused about each
other's presence and this resulted in the resources being listed as
"comatose" on one server and "running" on the other. And although the NSS
volumes were mounted on the "running" server they were not bound in NCP
server and so were inaccessible to users over NCP. This state of affairs
persisted with the online status of resources flapping every hour or so.
I'm puzzled why it went so well in the lab? The upgrade had proceeded
without a single error and so I had assumed I was going to have a short
day - how stupid of me!

Anyway if anyone has any light to shed on this I'd much appreciate it.
But otherwise just take it as advice to avoid such a scenario.

To save anyone wasting time suggesting silly stuff: eDirectory is totally
healthy (according to all standard health checks), timesync all good,
hardware fine, both servers can see the SAN, patch levels right up to
date. The production OES1 servers _were_ functioning all very well (apart
from the occasional NSS related kernel panic/oops - which is why I was so
keen to move to OES2 in the first place).

Simon

Here's the kind of errors I was seeing on the OES2 box in NSSCON.

Jun 14, 2008 6:25:44 am NSS<ZLSS>-4.10a-xxxx: zlssMSAP.c[1899]
MSAP: Pool "VOL1" ownership lost, pool may have been corrupted
by being activated from two servers at the same time.


Deactivating pool "VOL1"...

I haven't done one you way, but where we have migrated from OES to OES2
there have proven to be some major issues if SLP, LUM and LDAP are not
100% right. Where we have added in a new OES2 node to an existing
cluster (that we built) it has functioned like your lab - really rather
nicely. The one time we rushed it (and the original was not our
deployment) we saw more of what you seem to have done.

Sorry I can't tell you what is broke - but those are the areas I would
look in.

--
HTH

Tim
___________________
Tim Heywood (SYSOP)
NDS8
Scotland
(God's Country)
www.nds8.co.uk
___________________

In theory, practice and theory are the same
In Practice, they are different

Hi Tim

But LUM, SLP and LDAP are all totally healthy as far as I can see. When I
did the upgrade I initially didn't let the OES2 node rejoin the cluster
until it had been fully patched and all systems (such as edir, LDAP,
timesync, LUM and SLP) were totally OK. Only then did it go back into the
cluster, which happened very smoothly but half an hour or so later chaos
ensued?

Simon

On Sun, 15 Jun 2008 08:26:41 +0000, Simon Tideswell wrote:

> Hi Tim
>
> But LUM, SLP and LDAP are all totally healthy as far as I can see. When
> I did the upgrade I initially didn't let the OES2 node rejoin the
> cluster until it had been fully patched and all systems (such as edir,
> LDAP, timesync, LUM and SLP) were totally OK. Only then did it go back
> into the cluster, which happened very smoothly but half an hour or so
> later chaos ensued?
>
> Simon

I upgraded both of clusters with a rolling OES1 -> OES2 upgrade. I took
each OES1 server out of the cluster & tree and did a fresh OES2 install
and put it back into the cluster. It went very smoothly and we were in a
mixed configuration for less than a week.

Josh

Hello

I think the advice I gave about avoiding mixed clusters is BOGUS. I have
upgraded the second node now and the "thing" is is still a basket case!!!
There must be some other reason for the issues I am experiencing, only
wish I knew what it was?

Simon