05 Dec 07 Setting Up a 2-node Fail-over Cluster with OES 1

Preamble: This is a post on documenting the steps that I took to deploy a 2-node fail-over cluster for a client. No identifying information specific to the client is contained in this post. The deployment was done in August 2007 and I’m only posting it in December, nearly four months since the date I said I would put it online. Well, now that Open Enterprise Server (OES) 2 is already available, this post might not be that useful to others. Nevertheless, perhaps this will help someone somewhere out there

Setup

The objective is a 2-node cluster to serve iPrint and iFolder services with fail-over capability. In my particular deployment, there were two Dell rack servers and a SAN storage server. To deploy this setup, the multipath tool had to be used to be able to address the SAN storage partitions over optics. I’m not familiar with SAN – the knowledge that I have is based on information I get from the Internet.

Step 1: Install OES on Both Servers

I used OES1 SP2 on CDs (4 x SP2 and 3 x core) to install OES on both servers. Note that the servers have to be patched before doing anything to cluster them together. Below are the things to note.

Important! Do not install Novell Storage Services (NSS) or Novell Cluster Services (NCS) during the installation – the multipath-tools package should be installed and then configured in order for the shared storage (the SAN) to be recognised by NSS. And multipath-tools can only be configured after the installation. The multipath-tools package is required because the SBD (Split Brain Detector) partition is needed to create the cluster, and the SBD must be created on the SAN partition.

When I went through the documentation, I was puzzled because it didn’t say explicitly that the multipath-tools has to be configured AFTER installation. Although it seems rather obvious here, believe me, when you are caught in the thick of things, simple logic can be very complicated to the puzzled mind.

Configure OES services during installation.

Step 2: Patch the Systems

Do NOT patch the system in one shot! The first time I did this, I had to download a whopping 2GB worth of patches – and they didn’t work! Patching everything in one shot actually kills the systems – which means you have to reinstall.

The correct way to go about doing this is to install patch-11371 and then patch-11461 before the rest of the patches. The effect of applying the first patch (11371) is it helps remove a large part of the patches that have to be downloaded. In my case, instead of 2GB, I only needed about 900MB of patches. After applying this patch, restart the Red Carpet daemon. The commands to do so are described below:

#Displays the services

rug sl

#If not available from the output from above, add the service

rug sa https://update.novell.com/data

#activate the product

rug act -s 1 123465879 admin@company.com

#displays available channels

rug ch

#subscribe to the channel 'oes'

rug sub oes

#displays all available patches (installed and non-installed)

rug pl

#install patch-11371

rug pin patch-11371

#after the patch is applied successfully, restart the daemon

rcrcd restart

After the daemon is restarted, install patch-11461. This is a security patch.

rug refresh

rug pin patch-11461

#it is better to restart the daemon again

rcrcd restart

Finally install the rest of the patches. In my case, the patches took four hours at around 50kbps.

#the listing of patches is so much smaller now compared to before

rug refresh

rug pl

#finally, update the system

rug pin --entire-channel oes

Once the patching is complete, reboot the system. This is needed because there might be kernel updates which require a reboot.

In my case the update did not complete successfully as there was an error about restarting the daemon, which I suspect is referring to the Red Carpet daemon. I was unable to verify this but after rebooting, the system turned out fine.

For more information, refer to Novell’s TID #3739116

Step 3: Install Multipath-tools

This tool is required to handle multipathing on the storage side.

Each of my servers only has one Host Bus Adapter (HBA) card with one port. However at the storage side there were two paths to the storage. As a result Linux showed two sets of the same storage (e.g. sdb-sdc-sdd and sde-sdf-sdg).

Install the package from the software management option from YaST. After installing you should be looking at Red Carpet for patches. This time, you can use the Red Carpet GUI (ZENworks Linux Management).

To use ZENworks Linux Management, first refresh the channel for any new patches. The filter should show you the patches for the multipath tools. Install those patches.

Then run the multipath programs:

#makes the following programs run at boot time

chkconfig boot.multpath on

chkconfig multipathd on

#start the programs NOW

/etc/init.d/boot.multipath start

/etc/init.d/multipath start

#check that the services are indeed started at boot time

chkconfig -l | grep multi

Take note that the chkconfig commands might not work correctly – double check that the services are started at boot time. If they are not (which was the case with boot.multipath for me), use the GUI tool from YaST to enable it.

Once boot.multipath has started running, the device mapper will create a directory /dev/disk/by-name with the WWN names of the storage LUNs in there. These names will be the means how the storage devices are accessed.

At this time you can invoke the following command to see if the LUNs are detected.

multipath -l

What I encountered was that the devices are detected but are not active yet. As I mention above, there are two paths to the device so at least one should be active. After invoking the commands above, the two paths to the device are shown as “enabled” but not active. I’d not found any faster way to make the path active other than rebooting.

Of course you KNOW that you need to install multipath-tool on both servers

Pages: 1 2 3

Tags: oes1