Daenmark: Linux Archives

October 19, 2004

Kill Bill ... starring Uma Tuxman?

Groan. Crossover culture. Love it or hate it, it brings a wry smile to the face sometimes whether you want it to or not.

Posted by daen at 12:27 AM

April 26, 2004

LVM

Using the Logical Volume Manager LG #84

Posted by daen at 03:53 PM

April 07, 2004

Installing Linux on a Dead Badger

After casemodding ... the guide to installing Linux on a dead badger by Lucy Snyder at Strange Horizons.

I'll skip the obvious high-availability puns about heartbeat failure and STOBITH (Shoot The Other Badger In The Head) ...

Posted by daen at 03:38 PM

February 09, 2004

Oracle 9i for Red Hat 9 stuff

Oracle 9i for Red Hat 9 stuff (RPMs etc)

Posted by daen at 10:23 PM

Installing Oracle 9iR2 on Red Hat 9

LinuxDevCenter.com: Installing Oracle 9iR2 on Red Hat 9 [Sep. 04, 2003]

Posted by daen at 10:17 PM

October 10, 2003

OpenGFS failover working

WARNING! I think there are some factual errors in this, so be careful - I need to check tomorrow, but the crucial point is still in making the lock server a heartbeat managed cluster resource.

I'm assuming you have two nodes (mine are called fred and barney) in the cluster, both on the LAN and also preferably with a serial connection between them (for the backup heartbeat channel). I'm also assuming you want to use Samba here, if you have a heterogeneous network.

1. The OpenGFS config file should look something like this:

# the pool device that will contain the data(the larger of the 2)
datadev: /dev/sda3
# the pool device that will contain the cluster info(the small one)
cidev: /dev/sda1
# the IP:Port of the server that is going to be running memexpd
lockdev: 192.168.1.100:15697
# the port used for callbacks between cluster nodes(no other programs on your
# network should use this port, and it should be different for each OpenGFS
# setup on your network)
cbport: 3001
# time before a node is considered dead(lower number may mean faster recovery,
# but may lead to unnecessary STOMITHing in the case of slow nodes)
timeout: 30
# method used for STOMITHing "dead" nodes
# Manual - human intervention
STOMITH: manual
# unique name for this method
name:    manual
# Node Section
# Tag:			always "node:"
# IPAddr		IP address of the node
# CID			sequential numbers starting at 0
# STOMITH Method	"SM:" followed by the name from the particular STOMITH
#				Method you are going to use
# Plug/Port		if you are using a power switch this should be the plug
#				that the node is plugged into
#			if you are using FC hardware this should be the port
#				that the node is plugged into
# A simple example used for testing
#Tag	IPAddr		CID	STOMITH Method	Plug/Port
node:	192.168.1.1	0	SM: manual
node:	192.168.1.2	1	SM: manual

Note that there are three IP addresses - one for the lockdev (also know as the "lock server"), which will also be the cluster IP address in this case, and one for each of the nodes. "What?". Well, the lock server IP address will be managed by the heartbeat mechanism - see below.

NB. Make sure the cluster IP address has a DNS entry (eg fscluster).

2. Create the OpenGFS drive, lock partition and external journal as described in the NoPool_HOWTO_build_and_install_OpenGFS document, using the above ogfscf.cf file and the sample journal file from the document. Use /ogfs as a mountpoint.

3. Install the latest heartbeat code from linux-ha.org on both nodes and test the serial connections as described in the heartbeat documentation.

4. Configure ha.cf for serial and net heartbeat (I won't do it here - see the heartbeat documentation for info).

5. Copy the ha_memexpd script from the OpenGFS source directory (under scripts, I think) to /etc/ha.d/resource.d/memexpd

6. Configure Samba with /ogfs as a public, writeable share (eg "ogfs") on both servers. Make sure smbd and nmbd aren't running yet.

7. Configure haresources. Pretty much the only thing you need to have in this file is a single line which looks something like

fred 192.168.1.100 memexpd \
Filesystem::/dev/sda3::/ogfs::ogfs::hostdata=[node IP address] smb

(The node IP address will be 192.168.1.1 on fred, and 192.168.1.2 on barney. This actually goes against the advice in the heartbeat documentation, which says that haresources should be the same on both nodes, but OpenGFS needs the IP address when mounting, in order to manage locks. There are, I'm sure, more elegant ways of passing the IP address.)

What this says is that the preferred node is fred, the cluster IP address is 192.168.1.100 and that three other resources should be managed - the locking daemon (memexpd), the mount for the ogfs device (Filesystem::...) and Samba (smb). These are actually scripts (and parameters separated by "::", in the case of Filesystem). That's why we copied the ha_memexpd script to memexpd in resource.d, because that is how heartbeat stops and starts resources, and resource.d is one of the place that heartbeat looks for scripts.

8. Make sure that the ogfs device isn't mounted on either node, and that the memexpd daemon also isn't running on either node.

9. You can now start the heartbeat service on both nodes (and make sure it's checked to start at bootup, and that you save the service configuration file!)

10. From a Windows client, you should browse for fscluster in the network neighbourhood. With luck, you should see the ogfs share and even be able to map it to a network drive.

11. Now shutdown the fred node. Within 30 seconds, barney should spot that fred is dead and should take over the lock server, mount and samba share! You will see a slight glitch in your Windows client, but after a few seconds, the share comes back.

Still a few things to iron out, but that's about it so far, folks.

WARNING! I think there are some factual errors in this, so be careful - I need to check tomorrow, but the crucial point is still in making the lock server a heartbeat managed cluster resource.

Posted by daen at 12:08 AM

October 05, 2003

OpenGFS, heartbeat and Samba

Update 9 October - it works now, although not quite as I pondered below ... See here for details

I managed to get a part of my new OpenGFS Linux file server cluster working on Thursday night. One of the servers now loads the memexp and ogfs modules, starts the memexpd lock server and mounts the ogfs drive at startup, and makes it available as a Samba share. Simple enough - I can now map a network drive to the 1.1Tb drive using Win XP.

It manages this through the heartbeat mechanism, with the two servers, fred and barney, configured so that fred is the preferred server. The bit that doesn't work yet is the failover, so that if you shutdown fred, barney should detect the heartbeat failure and take over file serving, and with only a small interruption should restart the lock server, mount the ogfs drive and make the Samba share available again. The only problem is that the ogfs mount takes a hostdata option. I currently have this set in the haresources file to be the ip address of each server, which goes against the stern advice in the haresources header to make sure that the files are the same on each cluster member.

Well, it doesn't work. If fred fails, barney can't mount the ogfs drive. I'm guessing there is some stomith/stonith stuff to be done here. do_manual, perhaps?

It only occurred to me as I was leaving the office that perhaps this hostdata parameter could be the cluster ip address, not the ip address of each individual cluster member. I'll try it tomorrow, anyway. I wonder what will happen to the lock info, though, seeing as I'm not using the -d option when I start memexp ... could be messy.

Posted by daen at 03:16 PM

September 22, 2003

OpenGFS and High Availability : the continuing story

If you've bothered to read any of this errant tosh over the last two weeks, you'll have figured out that I'm trying to do something tricksy with Linux.

Yup.

I'm trying to build a clustered file server, based around a dual hosted 1.1Tb SCSI RAID box. I want to use OpenGFS and RedHat 9.0 to do this. The problem I've had is that the RH 9.0 kernel is patched by RedHat themselves, but the OpenGFS patches expect to be applied to a vanilla kernel.

I've asked around in comp.os.linux.redhat, also Brian Jackson of the OpenGFS project. The advice was to give the RH 9.0 kernel the elbow and install a vanilla kernel. I was a bit nervous about this, but today I followed the advice and whaddyaknow ... it was a piece of cake. I downloaded 2.4.21 from kernel.org at 10am, patched it with the ogfs "big patch" and by lunchtime I had one half of an OpenGFS cluster working, and both servers up and sharing the same SCSI RAID box by 5pm. There are still some teething problems - nothing trivial I'm sure :-) - but it seems to work pretty good.

Apart from doing more tests (and getting familiar with umounting ogfs BEFORE shutdown), there remains the heartbeat monitoring to implement. BJ pointed me to this, which is ostensibly about drbd, a block device, but also contains info on nfs failover using heartbeat. Bingo!

Posted by daen at 11:50 PM

September 17, 2003

OpenGFS and aic79xx updates

Justin Gibbs website now has a 2.0.2 version of the aic79xx drivers for various Linux distros, dated 15 September (also, version 6.3.0 of the aic7xxx drivers)

Coincidentally (or is it?) there is a 0.3.0 release of OpenGFS - also dated 15 September ... spooky.

Posted by daen at 12:03 AM

September 16, 2003

Initrd.img & aic79xx as a module

Appendix A - Creating initrd.img file

From "The Linux Kernel HOWTO"

Useful for my task of configuring OpenGFS, especially §31.7 ...

Now copy into the initrd/lib/ directory the SCSI modules you require. For example, if we have an Adaptec AIC-7850 SCSI adapter, we would require the aic7xxx.o module from /lib/modules/{version}/scsi/aic7xxx.o. Then, place it in the initrd/lib/ directory.
...
The file initrd/linuxrc should contain a script to load all the modules needed for the kernel to access the SCSI partition. In this case, just the aic7xxx module (insmod can take options such as the IRQ and IO-port for the device. See Chapter 42).

Posted by daen at 10:33 PM

Danish Linux User Groups

Posted by daen at 12:10 AM

Daenmark

Being the (continuing) story of Daen's life in Denmark. Er, France. Er, California.