Attention: I don’t grant any liability for the text below. If you try any of the steps described here, on your own, I can’t guarantee that it works for you. So better do this in a test environment. If you do this in a production environment, make sure you got a recent backup of all your data and a time window big enough to recreate your setup incl. the restore of your data.
Since Apple has discontinued the Apple Xserve in January 2011, there seems to be a growing need for rack mountable server hardware in the Apple world, which is more powerful than the Mac mini Server and takes less rack space and consumes less power than the Mac Pro.
If you want to run file services, directory services, software update services, and other services for Macs, Windows, and Linux clients, you’ll find both Linux and Windows based solutions to do just that. On the other hand, the Mac Pro and the Mac mini Server seem to be great systems to serve many of these things, too.
Yet, if you read the announcement of ActiveSAN, it seems as if there was a high demand for a 1U rack mountable metadata controller for Xsan environments.
What the guys at ActiveStorage seem to do is build great server hardware incl. nice monitoring and setup tools, which make it easy to set up a Quantum StorNext metadata controller to handle your Mac-based Xsan clients.
If you are an Xsan or StorNext pro anyway and work in the command line most of the day, you can even replace your existing Apple Xserve MDC with a Linux-based StorNext MDC with a minimal downtime of your Xsan volume. This is what you need:
- Server hardware which is able to run a recent Linux version. Make sure you add enough RAM, redundant drives for the boot disk, a nice and OS supported FC card, dual Gigabit Ethernet. Note: You can also use a Windows OS instead, which is nice if you integrate with Active Directory, but whatever you do, make sure, the OS of choice supports the LUN size you use in your Xsan setup. The ActiveSAN hardware looks like a very nice solution to this.
- I would go for CentOS as the MDC’s OS, as it’s officially supported by Quantum and doesn’t cost you money. If you need support, I would go for RedHat. See http://downloads.quantum.com/SNMS/4.1/StorNext%204.1%20Supported%20Platforms_V2.pdf for a list of supported MDC platforms.
- Make sure to integrate your MDC into your directory environment. Both Active Directory and Open Directory are supported. You will need this to use ACLs (the only way to properly deal with permissions in most Xsan environments).
Before you start buying the hardware to build the new MDC, you need to make sure, that you don’t have named streams enabled in your existing Xsan environment.
To actually migrate the volume from the Xsan MDC to the SNFS MDC, roughly follow these steps:
- Make sure to use matching filesystem versions in the Xsan environment and on your StorNext controllers.
- Run cvfsck -w on the Xsan volumes.
- On the primary Xsan metadata controller, save the folder /Library/Filesystems/Xsan/config to a place we can access easily later on, like a USB stick, e.g.
- Shut down the Xsan metadata controllers.
- Set up the StorNext controllers. The easiest way is to use the same IP addresses as for the Xsan metadata controllers.
- After installing the StorNext filesystem and -optionally- the Storage Manager, copy our Xsan volume’s config file into the StorNext controller’s config folder.
- Open the config file and delete the lines with the options “NamedStreams”, “EnableSpotlight”, and “SpotlightSearchLevel”.
- Optionally, make the volume managed by adding the appropriate option to its config file.
- Make sure to run
chown www:adicon the config file as well as
- Run cvfsck on the volume.
- Start the volume and mount it.
- You are done.
If you want to add Xsan clients to your StorNext controller, you find a nice article at http://krypted.com/xsan/adding-xsan-clients-to-stornext-environments/.
While this migration is something that can be done very easily, you need to consider, that StorNext currently doesn’t support Spotlight searches, so you can’t easily use the Finder to search for content. If your users navigate through the filesystem or use a DAM like Final Cut Server, this is not an issue at all. (On the other hand, the StorNext MDC catches all filesystem events, so I guess it should be possible to write a client, which collects these events and tells a dedicated Mac machine to add new files to the filesystem’s central Spotlight DB).
Another caveat is that the automatic HSM process in Storage Manager, which moves data to tape and restores them to disk as needed, restores data whenever a file gets invoked by a client. You either need to turn off previews in Finder to prevent constant restores, or you better hide the filesystem from the Finder and let your users access the filesystem through FCSvr and its edit-in-place option only.
One of the best things that come with the migration from Xsan to StorNext is that you can add additional functions (part of SNFS and/or SNSM) like filesystem replication, Distributed Data Mover, HSM functionality, writing to tape, etc.
In addition, SNFS has documented optimization settings for image sequences, which is very interesting for film production.
On the other hand, if you already own an Xserve which runs your Xsan, I would say that this is a great hardware to do just that.
Although I have done the migration described here in the lab, and found it reasonably easy, I am curious to see ActiveSAN as soon as it’s there, because it looks like they made the process of building a new Xsan/StorNext environment so much easier.