configure XSAN 4 – Yosemite – El Capitan

Situation

You want to connect an OSX 10.10 (Yosemite) or OSX 10.11 (El Capitan) client to your existing StorNext SAN or XSAN. Both OSX versions are XSAN 4 based.

Yosemite’s embedded XSAN version is compatible with SNFS 4.3 & 4.7.
The XSAN version within El-Capitan apparently is only compatible with StorNext 5.x but not with StorNext 4.7 as officially listed in the matrix.

I don’t claim to know it better as the officials from Quantum or Apple but if you look under the hood, the cvversion command returns a 4.3 build. Based on that and the knowledge that many other users have connected their XSAN 4 clients to a SNFS 4.7 based MDC’s without any issues of connectivity or data integrity (would be the worst case ever), it’s up to you to go that path and connect to an existing 4.7 based StorNext MDC and step outside the supported matrix.

Another thing with doesn’t really line up is that the compatibility matrix from Apple and Quantum took over 6 month to be released. El-Capitan was released before StorNext 5 has been official released, which means El-Capitan’s version was already future proofed?

Abstract

XSAN since version 2.3 comes embedded within the OS and doesn’t require a dedicated license anymore. The surprising part here is still the lack of documentation. While Apple keeps changing the configuration quite frequently, the Xsan pane which some users may have used in previous OSX releases is gone, everything will be configured with configuration profiles.

Solution

Continuing with XSAN 4 which is the current version, this blog entry follows the idea to have a complete collection of all the XSAN versions covered beginning with XSAN 1.4 over XSAN 2.3 & 3.0 and XSAN 4.

Some basics upfront:

A metadada network should always be separated (dedicated) to have a low latency communication between the clients and the SNFS/XSAN server. Usually you’d chose a different class C network and have a dedicated NIC installed on your client.

The basic commands you need to verify if the client setup should work are ping, cvadmin and cvlabel.

ping – the simple test if you have a valid IP connection
cvadmin – to verify the connection to the MDC
cvlabel – to assure that you see all the LUN’s you need to mount a volume

My MDC reports back at 192.168.12.1 and my client has the metadata IP 192.168.12.5 assigned.

XSAN 1.x – 1.4.1

The downloadable XSAN Administration Guide shows actually what needs to be done, therefore it would be redundant to write it down.

XSAN 1.4.2 – 2.x
XSAN 2.3 – 3.x (OSX 10.7 – 10.9)
XSAN 4 – Yosemite

XSAN 4.x – Yosemite / El Capitan

Installation

This version of XSAN comes with the OS and is doesn’t require any further installation or serial number. With other words, it’s free.

Configuration

You might perform a quick ping test to the MDC to avoid troubleshooting later.
ping 192.168.12.1

If you have an existing XSAN 3 configuration, you can simply copy the /Library/Preferenes/Xsan folder to the new client.

  1. Configure the metadata network on a free NIC
  2. Start a terminal window and gain root access
    sudo –s
  3. Use your favorite CLI editor (nano, vi …) and create the nameservers file
    vi /Library/Preferences/Xsan/fsnameservers
  4. Enter the IP of the MDC:
    192.168.12.1
  5. Save the file and quit the editor
  6. Create the main configuration file for the client and change the bold sections to match your environment.
    vi /Library/Preferences/Xsan/config.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
   <dict>
     <key>computers</key>
     <array/>
     <key>metadataNetwork</key>
     <string>192.168.12.n/24</string>
     <key>role</key>
     <string>CLIENT</string>
     <key>sanName</key>
     <string>MySAN</string>
   </dict>
  </plist>
  1. Restart Xsan either by rebooting the client or issuing the commands:
    launchctl unload /System/Library/LaunchDaemons/com.apple.xsan.plist
    launchctl load –w -F /System/Library/LaunchDaemons/com.apple.xsan.plist

Note: You can’t skip the “–w –F” after the any longer as the daemon won’t launch successfully.

  1. After Xsan has restarted, from a terminal run the command: /usr/sbin/cvadmin
    You should see something like:
Xsan Administrator
Enter command(s)
For command help, enter "help" or "?".
List FSS
File System Services (* indicates service is in control of FS):

1>*san-1[0] located on 192.168.12.1:34922 (pid 10442)
2>*san-2[1] located on 192.168.12.1:33142 (pid 10487)

Select FSM "none"
Xsanadmin >

The above shows there are is a connection to the MDC (192.168.12.1) with two volumes: san-1 and san-2

  1. Mount all volumes manually to test the installation
  2. mkdir /Volumes/san-1
    2. mount -t acfs san-1 /Volumes/san-1
    3. repeat as necessary, changing san-1 to the appropriate volume name
    4. run a df command to see if the StorNext volumes have been successfully mounted on the client.
  3. Configure the volumes to mount automatically
  4. Mounts in XSAN 2.3 and above are handled in the /Library/Preferences/Xsan/ automount.plist file

The following shows an example to auto mount the volume san-1:

<?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 <plist version="1.0">
   <dict>
     <key>san-1</key>
     <dict>
       <key>AutoMount</key>
       <string>rw</string>
       <key>MountOptions</key>
   <dict/>
   </dict>
     <key>san-2</key>
     <dict>
       <key>AutoMount</key>
       <string>rw</string>
       <key>MountOptions</key>
     <dict/>
   </dict>
   </dict>
 </plist>

Volumes will automatically be mounted to /Volumes/VolumeName

After saving the file, reboot the client to see if the volumes successfully mount after boot. SAN volumes should appear as desktop icons, usually a minute or so after startup

Stopping and starting XSAN from the command line:

launchctl unload /System/Library/LaunchDaemons/com.apple.xsan.plist
launchctl load /System/Library/LaunchDaemons/com.apple.xsan.plist

Troubleshooting

  • A common point of failure for mounts is the existence of /Library/Preferences/Xsan/.auth_secret If this file exists, delete it. This is a leftover if the client has been part of a XSAN MDC cluster.
  • If you are missing the config.plist or the automount.plist, /var/log/system.log may show an error of the form:

Configuration files are for an old version of Xsan; no Xsan volumes will be mounted

  • Verify if you see all required labels for a volume you want to mount.:

                 /usr/sbin/cvlabel –c | sort

  It is acknowledged by anyone who chooses to utilize this procedure that all risks taken in performing these steps are performed on your own and that I am not reliable for any damage.

3 COMMENTS

  1. James Beattie April 7, 2017 at 1:59 pm Reply

    A moment of thanks. This is clear, accurate and not documented any other place.

    Thank you.

    • rbeck April 16, 2017 at 7:02 pm Reply

      Appreciate the feedback, thanks!

  2. Lance Gropper October 3, 2017 at 5:28 pm Reply

    Hello Roger: This is absolutely great, however there is one thing missing: launchctl loads XSAN for that session. How do you make it load automatically on subsequent boots/reboots?

Leave a Reply