ZFS snapshotting and mirroring

June 2nd, 2008

Although ZFS seamlessly will support synchronous mirrors over multiple backend storage arrays, there are some advantages in keeping the mirror process asynchronous.
Read the rest of this entry »

ZFS haul-over in the face of a box shutdown.

May 6th, 2008

I’m now using default zpool paths (which implies an automatic import and mount on reboot).

I just imported the bb-archive.isys zpool onto the first host, then rebooted it. After it had shut down, I forcibly imported the zpool onto the second host. Now waiting for the first to come back up. It should, perhaps, complain that the zpool is owned by someone else, but should not do a forcible reimport…

And alas, that’s not what happens. So:

I’m going to use altroots for all zpools. Unfortunately, this forces the subdirs to appear only mounted under the altroot. Not quite the combination I was after.

Networker, zfs.

May 6th, 2008

OK, so nsr picks up the filesystems to try to save from /etc/vfstab. Fine, except that (a) that means it tries to back up the contractfs(!) and (b) ZFS doesn’t use vfstab entries for its filesystems.

Solution: specify the service IP address explicitly together with a bunch of paths under the networker configuration.

Mapping MPxIO paths into something sane (array & LUN ids)

April 24th, 2008

OK, so MPxIO “Just Works”. I exposed a small number of LUNs (four, to be precise) from each of a pair of SataBeasts. One of those had something on it: to wit, a prototypical “bb-archive” zpool.

zpool status etc. will show the MPxIO devices that comprise the particular zpool in question – but what about the other seven LUNs? And what about when it comes to stiching LUNs together, and so on? This is going to turn into a cross-referencing nightmare!
Read the rest of this entry »

Multipathing success.

April 24th, 2008

# mpathadm list lu
/dev/rdsk/c7t6000402001FC19CA6E9E7EFE00000000d0s2
Total Path Count: 2
Operational Path Count: 2

… and so on :-)

NFS machine HBAs turned up at last.

April 24th, 2008

OK, so we’ve been waiting for these for weeks. D*ll kept on pushing the dates back. For a pair of HBAs, FFS!

Order went into Redstor last night at 4pm. They were here this morning by 9am.

Spot the difference.

MBS (deployment) work.

April 24th, 2008

I’ve decided to bring this forward a bit. This is somewhat motivated by the need to get spam[34] up and running so that Adam can start to move his build scripts to target the MBS deployment infrastructure.
Read the rest of this entry »

OAS. It’s not great.

April 16th, 2008

And by default it’s worse than that. Lesson is, if you want it configuring, do it yourself.

Personally, I don’t want it configuring, so it can sit and rot. Fuggit.

Deployment work, up and coming.

April 10th, 2008

I’ve just physically plumbed in to the deployment & management network two new boxes, spam3 & spam4. These will be targeted by an MBS instance for deploying SpamAssassin (& co) configurations onto.

There’s finally a light at the end of the tunnel with the filestore work. Once the HBAs turn up I’ll be putting a new NFS server in place. This impacts on the appinf work in two major ways:
Read the rest of this entry »

Post-Easter catch up.

March 26th, 2008

Well, that’s been a busy day. New SataBeasts arrived, they’ll be installed not a moment too soon.

I’ve rebuilt the first NFS node (munter) and captured the rest of the configuration alterations. Getting it all down in a series of Makefiles has certainly paid off.

There’s news on alternative machine rooms; so now at least we have something to aim at.