There are a lot of people who keep saying that StorNext is the same thing as Xsan. StorNext is similar to Xsan, but not identical. Apple makes their own changes to the StorNext code before recompiling and shipping. One need only look at the output of a cvlabel command on each to see this very quickly. The similarities mean that you can mix and match Xsan clients to StorNext controllers and match up StorNext controllers to Xsan clients (although you can’t match StorNext controllers to Xsan controllers). The differences mean that you might have a tiny amount of work on your hands to get the mix and matched controllers/clients to work with one another. But they do work.
Some time ago I did an article for Xsanity outlining how to add a Redhat Enterprise client to an Xsan. But I haven’t written anything about going the other way: an Xsan client in a StorNext environment. So here we go. In this article we’re going to assume that you have a standard StorNext environment (3 and up) and have installed the Xsan software on clients, but not done any configuration of the client yet.
Once the Xsan client has been installed and updated, you’ll want to document the IP addresses and order that the IP addresses appear in the fsnameserver file on the StorNext clients. Next, we’re going to open Xsan Admin, click on Create a New SAN and then provide a serial number, skipping volume creation. Next, close Xsan Admin. If you then go to /Library/Filesystems/Xsan/config you should see a file called fsnameservers (if not, create it). This file should mirror the one that you documented from your StorNext clients. In this same directory, there is a hidden file called .auth_secret. Delete it:
sudo rm /Library/Filesystems/Xsan/config/.auth_secret
Now reboot.
Before we start trying to mount anything let’s check that our LUNs are all present. Compare the output of cvlabel to the output from a metadata controller (creates a file with label information from the Xsan client):
sudo cvlabel -c > Xsanclient_cvlabel
Provided all the LUNs are present it’s time to see if the volumes are visible with cvadmin:
sudo cvadmin
Then, from the interactive shell, type select to see if the volumes are all present. Provided they are, it’s time to mount the volume. For this example, we’re going to have a volume called seldon. First, create a directory in Volumes (much like if you were mounting an afp share via the command line):
sudo mkdir /Volumes/seldon
Now let’s mount it up using the mount command:
xsanctl mount seldon
Or:
mount -w -t acfs seldon /Volumes/seldon
And then viola, you should have your volume mounted. A script to do this would be (with the volume name as position 1):
mkdir /Volumes/$1
xsanctl mount $1
That would be helpful if you were using a single LaunchDaemon to start, let’s say, 5 or 6 volumes. When you unmount the volume, the entry in /Volumes might not disappear. Ergo, once you verify you get an error when attempting to traverse it:
rmdir /Volumes/seldon
I’ve written a little AppleScript that is a manual mounter/unmounter and I’ll try and post it when I make sure no one will make fun of the remedial code used.