configure XSAN 4 – Yosemite – El Capitan
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?
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.
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
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.
You might perform a quick ping test to the MDC to avoid troubleshooting later.
If you have an existing XSAN 3 configuration, you can simply copy the /Library/Preferenes/Xsan folder to the new client.
- Configure the metadata network on a free NIC
- Start a terminal window and gain root access
- Use your favorite CLI editor (nano, vi …) and create the nameservers file
- Enter the IP of the MDC:
- Save the file and quit the editor
- Create the main configuration file for the client and change the bold sections to match your environment.
<?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>
- 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.
- 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 located on 192.168.12.1:34922 (pid 10442) 2>*san-2 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
- Mount all volumes manually to test the installation
- 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.
- Configure the volumes to mount automatically
- 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
- 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