Posts Tagged ‘solaris’

Solaris cluster, MPxIO, Zpools.

Friday, June 26th, 2009

This is remarkably straightforward.

Two nodes, alike in dignity. We preconfigured MPxIO on them prior to installing the cluster software. We also allocated a small LUN that was visible to both nodes prior to the installation, and made sure they could see it: this was intended to act as a quorum device.

ZFS snapshotting and mirroring

Monday, 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.

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

Tuesday, 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.

Tuesday, 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)

Thursday, 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!

Multipathing success.

Thursday, April 24th, 2008

# mpathadm list lu
Total Path Count: 2
Operational Path Count: 2

… and so on :-)

python expect, pexpect, from inside solaris cron

Wednesday, March 19th, 2008

Small issue: solaris cron doesn’t set up much of an environment, and /dev/tty won’t show up.

Why Solaris isn’t always my favourite operating system.

Tuesday, March 18th, 2008

So, we’re on day two now and I’m about at the point where I have a working software stack that’ll let me start to build heartbeat.

This is not productivity.

Productivity is typing apt-get install heartbeat and, 20 seconds later, worrying about the configuration.

OpenSolaris is promising better things with package management. 15 years too late, perhaps, but thank Christ.

Update: NFS multilevel service progress via trusted extensions. Or rather, lack of it.

Friday, March 7th, 2008

I can’t even tell from the docs if I should expect TSOL NFS to do what I’m after – irritating when reading the source is actually looking like a faster way to find out the answers. Certainly I’m unimpressed thus far with the multilievel stuff. Bah.

Solved: should read the SB docs more closely

Wednesday, March 5th, 2008

OK, now I know why this isn’t working. Basically any array (Nexsan speak for Raid Group) is owned by only one controller at once – and its LUNs are only delivered via a single controller.

If we’d used QLE2462s and dual-attached the X4100 then we’d see multiple paths to LUN20, but they’d all go via SB c0. If the array is failed over to SB c1 then they’d show up there instead.

What I now need to do is to set up MPxIO, configure the first paths to the LUN, then try administratively failing its owning array over to the other controller. It remains to be seen whether this will “just work” or whether I need to further configure MPxIO to know that both results are basically one and the same thing (or even if that’s actually possible).

In any regard, this is looking very good.

At the other end of the problem, we installed the trusted extensions to Solaris which appear to permit multiple NFS views. We’ll confirm or deny this shortly. TSOL is a bit of a pain to configure – hopefully we can keep the setup requirement to a minimum – if Solaris 10 grows zonable NFS service (or I build a userland NFS server which I can configure myself) this might become more straightforward.