Apple Knowledge Base's picture

Xsan: Shutdown and startup order for network devices (Apple KB)

Learn about shut down and startup order for network devices.

Read more:

Apple Knowledge Base's picture

Promise VTrak: Fourth SAS-connected Expansion Chassis Only: Xsan (Data Only) configuration script (Apple KB)

This article contains a script used to configure Promise VTrak SAS-connected Expansion Chassis for Xsan. This script is used in the event that a Promise VTrak RAID Controller has already been configured for use with Xsan, and that an Expansion Chassis is being connected to the already-configured RAID Controller.

Read more:

Apple Knowledge Base's picture

Troubleshooting Xsan volume failover issues (Apple KB)

Learn about troubleshooting Xsan volume failover issues.

Read more:

Apple Knowledge Base's picture

Using QLogic switches with Apple Fibre Channel Cards (Apple KB)

Learn how to use QLogic switches with Apple Fibre Channel Cards.

Read more:

kolekole's picture

Storage space and affinities


we've got 75tb XSAN with one volume consisted of three storage pools. We've got three folders (i will name them here folderone, foldertwo and folderthree) where each folder has its own affinity. I will name pools storageone, storagetwo and storagethree here.

Storagethree has 21TB of space. Folderthree has affinity tied to this storage pool. Two days ago there was 4TB of space left on storagethree pool. After deleting more than half data from folderthree freed space in XSAN admin hasn't changed.

Ive seen threads here on this forum where people have experienced similar issues, but i wasn't able to figure whats going on still after reading them.

If free space on storagethree pool hits 0 will people be able to write to that folder?

How to fix this issue if this is an issue at all?

Thanks in advance!

wrstuden's picture

Notes on Xsan4

Notes on Xsan 4
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 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 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.

smashfacekeybrd's picture

Xsan 4


OS X 10.10 Yosemite includes Xsan 4. There are some ch-ch-changes.

xsanguy's picture

Xsan and OSX 10.9.5

Just upgraded some lab MDCs to 10.9.5. No problems to report, please chime in below with your experiences and recommendations.

abstractrude's picture

New Xsan Installs?

Haven't seen many new ones lately. There are so many options out there now, just curious what other people are doing now.

serged's picture

EOL Notice: AppleCare Xsan Support

News from Apple:

Apple is no longer selling AppleCare Xsan Support.

Existing Xsan AppleCare Support contracts are valid and will be supported by Apple until the contract expires.

I am not sure if it will still be supported with the Enterprise support..

Anybody else aware ?


Subscribe to Xsanity RSS