OS X 10.10 Yosemite and Xsan

abstractrude's picture

After spending a few days with Yosemite, I am happy to say that both OS X Server and Xsan still exist and work as expected.

Comments

11
undercover's picture

Any new numbers after "xsan"?

jegodwin's picture

I'm running Yosemite as well and we're having some issues with XSAN. How can I find out what version of XSAN Yosemite is running on my Macbook Pro?

Thanks in advance!

abstractrude's picture

Double click the computer in xsan admin. Are your controllers Yosemite?

-Trevor Carlson
THUMBWAR

jegodwin's picture

Well, I'm on a client machine, so I don't have access to the xsan admin. My IT guy is claiming that Yosemite has XSAN version 4 and that it's different than the XSAN version 3 that comes with Mavericks...is this true?

Johnny_0_o's picture

That is probably why you are having issues. If the controllers of the Xsan you are part of have an OS older then yours, then there is an incompatibility since the changes from Xsan versions are backwards compatible but not necessarily the opposite. From an older thread, you can find a supported Xsan/OS chart from this link.
http://support.apple.com/kb/HT200135

To summarize, you should always have the latest OS on the Metadata Controller of the Xsan and the same/older for connected clients.

abstractrude's picture

Your controllers need to be a newer or current to your clients. Also, you should not be running beta sofrware on a production storage network. No downgrade your system and be patient for a stable release of yosemite. If you have to use yosemite for a feature or bug fix, connect over re-share.

-Trevor Carlson
THUMBWAR

wrstuden's picture

Don't run beta software on a production SAN.

If you have a test SAN, set it up totally on Yosemite. However make sure you can log into the Xsan developer forums at Apple's web site. You can much more freely get responses to your problems there.

wrstuden's picture

A bit of follow-up. Xsan 4 uses profiles to make Xsan easier to setup and deploy. Server.app now handles controller and volume management.

metadreamer's picture

That's actually pretty good news- that they're actually "working" on Xsan and tweaking its features instead of just pushing through a simple compatibility update and upping the version number :)

dmastroluca's picture

Hopefully your MDC's won't restart after two weeks. I'm waiting at least a month before I upgrade to Yosemite.

Dan Mastroluca
Chief Engineer
KCLV-City of Las Vegas
www.kclv.tv

wrstuden's picture

As others have noted, Xsan 4's administration model is notably different from the model in all previous versions of Xsan. Here are some notes I have on the changes.

We have coined a new term, "Activation." "Upgrade" and "Migration" are two ways of taking the base operating system and configuration from a previous OS to Yosemite. "Promotion" is the act of updating Server.app to Server 4.0. We coined a corresponding term, "Activation," to describe taking an Xsan 3 or 2 configuration and moving it into Xsan 4. SAN Activation happens after Upgrade or Migration and also after Server Promotion. Activation happens first on the previous Xsan Primary MDC, and then happens on the other MDCs.

Xsan 4 no longer directly manages clients. We ran into too many issues where SAN operations would fail because one client was off-line. To address this, Xsan 4 uses ldap to store the SAN configuration. Now instead of having Xsan Admin update (push) the configuration on all machines, we have Server.app store a changed configuration in ldap and we inform all the clients that they need to re-parse (pull) the configuration.

We now run Open Directory on all the MDCs and they act as an OD cluster to replicate this information. Clients do not need to bind to these severs. If you previously had Xsan managing Users & Groups, Xsan will use that OD for its storage. If you have an external source for your Users and Groups, say AD, just use that for Users&Groups and don't worry about this OD cluster.

There are two direct consequences of this change.

First, Xsan 4 does not support Xsan 3 or earlier systems in the SAN. We do not lock them out of the fsm's, and you can perform a zero-down-time upgrade. The rub is that the older clients do not understand the messages we now send out when the configuration changes, nor do they understand the new message instructing clients to unmount a volume (as it is about to be stopped). In this respect they are akin to Linux or Windows clients in the SAN. If you want to stop a volume, these clients will not automatically unmount it. If you destroy a volume, these cients will not correctly forget it.

Second, we use Transport Level Security (TLS) in ldap when querying the configuration. As such, we need certificates to anchor the TSL trust. Certificates need DNS host names. So Xsan 4 requires DNS be configured on the Metadata Network. We expect many sites already had it, but we now will require it.

Unfortunately the error message you get today is unclear about this issue. So be forewarned.

A thrid issue is that all of the MDCs need to be in the same OD cloud. If you had a SAN before where Xsan was NOT managing users & groups but you had OD running on some of the MDCs, you need to ensure the Xsan 3 primary controller is in that OD cluster as the primary (ODM) before activating the SAN. Otherwise Xsan will see that OD is not running on the former primary, create it, and then you won't be able to activate MDCs which are in a different OD cloud; we require all SAN MDCs have the same OD master.