Rolling upgrade of a running RH 4 Linux cluster

[Steven E. Protter]

I recently upgraded a two node cluster with no down time.

I had the ISO images on an NFS server with full r/w access.

Here is the procedure:

NFS
1) boot of cd-rom 1
2) linux askmethod
3) choose NFS
4) Set IP address netmask gateway so that networking will work (best to look at the server ifcfg files before starting.
5) NFS give ip address of nfs server and directory of iso (showmount –e ip_address_of_nfs_server) will show the available mount points(prior to install or on another machine.
6) GUI comes up, choose upgrade, it will upgrade all it can
7) After boot copy all three kernels to a directory on the box. (Disk 2)
8) Install each kernel one at a time
9) service rgmanger stop
10) service fenced stop
11) service cman stop
12) service ccsd stop
13) Mount the rpms or cd for clustering
14) rpm –Fvh *.rpm
15) After next boot chkconfig lock_gulmd off
16) Boot again
17) Cluster will function in mixed mode. The clustat output is slightly altered.

Go back to step 1 and do the second node

I know this is pretty cutting edge, but in the past if I'd had the RHCS (Red Hat Cluster Suite) iso image on the NFS mount point, which I did not the first time around, would the cluster suite software be upgraded as well, or must I use my procedure again.

SEP

[Ivan Ferreira]

Is good to know that this worked, but as far I know, this is not a supported method for upgrading a Red Hat Linux, the only supported method is by using up2date. Would you do or recommend this procedure to a customer with a production environment on cluster? What if there is a problem?

You can also create a local yum repository for the packages and configure /etc/sysconfig/rhn/sources to use a yum repository for updating the system.

[Steven E. Protter]

Look Ivan,

I've used it on a cluster and all services remained active throughout the upgrade.

I hate to use up2date because its structured to force users to pay for software, even though RH says they are buying support. We also have security issues and closed networks that actually prevent the use of upd2date.

So we needed another way.

I suppose we could build a local up2date server and point up2date at that, unless as revenue producing software it wont let us.

I'm going to do it on a play cluster at home during the next two days and more stringently test it. Its HP hardware btw. wink wink.

SEP

[Ivan Ferreira]

I agree with you about the "forced" subscription to the Red Hat Network. If your customer agrees with your procedure, I think that is perfect. It's just important to let the customer know that even when it will work, is not officially supported, you won't be fingered if a problem occurs.

[Steven E. Protter]

So far the customer is internal and they trust me.

Cest la vive. If I really hate the RH procedure I can use Centos.

SEP