Apple Knowledge Base's picture

Xsan 2 and Xsan 3: Some administrative operations require computers to be online (Apple KB)

When using Xsan Admin with Xsan 2 or Xsan 3, some administrative operations can occur only when computers in the SAN are online. Learn which operations require client and metadata controller computers to be online.

Read more:

Apple Knowledge Base's picture

Xsan: How to repair the filesystem (Apple KB)

Learn how to repair Xsan filesystems using cvfsck.

Read more:

Apple Knowledge Base's picture

Xsan: Can't change role of Xsan client to metadata controller (Apple KB)

In some Xsan configurations, you may be unable to change the role of an Xsan client to metadata controller if it is running Mac OS X (client).

Read more:

Apple Knowledge Base's picture

Xsan: Finder may not immediately display directory contents when accessing StorNext 4.x volumes (Apple KB)

Directories on a StorNext 4.x volume may appear to have no contents when viewed in the Finder from an Xsan client that is using OS X Lion or Mountain Lion. The contents eventually appear, and they appear immediately when using the ls command in Terminal.

Read more:

Apple Knowledge Base's picture

Xsan: Volumes may not mount at startup if no user logs in (Apple KB)

Under some circumstances, Xsan volumes configured to mount automatically at startup may not mount until a user has logged in. Volumes mount correctly once a user logs in to the affected client.

Read more:

Apple Knowledge Base's picture

Xsan: Do not share a specific directory from multiple fileservers (Apple KB)

You should not share a specific directory from multiple fileservers.

Read more:

Apple Knowledge Base's picture

Auffinden der AppleCare-Registrierungsnummer (Apple KB)

Sie benötigen Ihre AppleCare-Registrierungsnummer, um einen kürzlich erworbenen AppleCare-Vertrag zu registrieren, falls dieser noch nicht registriert wurde.

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!

Apple Knowledge Base's picture

Xsan, multimedia apps: Troubleshooting dropped frame issues (Apple KB)

Learn how to troubleshoot situations in which dropped frames occur when video is stored via Xsan media. "Dropped frames" refers to frames of video that are unintentionally skipped during capture, editing, or playout.

Read more:

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.


Subscribe to Xsanity RSS