Posts Tagged ‘nexsan’

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.

More SATABeast multipathing…

Tuesday, March 4th, 2008

Zoning changes get picked up properly…

Bugger, it “Just Works”

Monday, March 3rd, 2008

Due to the unfortunate ability of the SATABeast to receive and process requests on all four controllers, failing the NFS array over to the second controller makes no discernible difference to the host: it can still talk to c0, alas.

So the only way we’re going to test this is with some brutal combination of FC zone modification and/or controller shutdown.

Multipathing progress…

Monday, March 3rd, 2008

This is looking better. Note in the previous post, the scsi_vhci.conf entry conforms to the scsi_inquiry format: that is, eight characters are used for the vendor ID (NEXSAN followed by two spaces), with the product ID appended.

Now the scsi devices appear under /devices/scsi_vhci. However, cfgadm still only shows the first path (ie, the first controller) as configured for each SATABeast; “cfgadm -c configure c4” still fails.

Solaris/amd64, SATABeast, the story so far.

Monday, March 3rd, 2008

Looks like multipathing via the generic scsi_vhci may be possible. Thus far:

Add this to /kernel/drv/scsi_vhci.conf:

device-type-scsi-options-list = "NEXSAN SATABeast", "symmetric-option";
symmetric-option = 0x1000000;

Currently cfgadm -c configure c4 is failing, complaining about being unable to create device nodes.

Having said that, the single-pathed zpool create Just Works.

Work progresses…