Let’s start out with what’s actually available in the Server Admin CLI: serveradmin. The serveradmin command, followed by settings, followed by san shows a few pieces of information: bash-3.2# serveradmin settings san san:computers = _empty_array san:primaryController = "95C99FB1-80F2-5016-B9C3-BE3916E6E5DC" san:ownerEmail = "krypted@me.com" san:sanName = "krypted" san:desiredSearchPolicy:_array_index:0 = "" san:serialNumbers = _empty_array san:dsType = 0 san:ownerName = "Charles Edge" san:managePrivateNetwork = yes san:metadataNetwork = "10.0.0.0/24" san:numberOfFibreChannelPorts = 2 san:role = "CONTROLLER" Here, we see the metadata network, the GUID of the primary (active) MDC, the name of the SAN, an array of serial numbers (if applicable – in a purely Mountain Lion/Mavericks SAN they aren’t), the owner info plugged in earlier and the metadata network interface being used. Next, we’ll take a peak at…
-
-
Changing Metadata Networks From The Command Line In Xsan
Awhile back Apple published an article on switching the network interface used in Xsan for Metadata networks. The article provides the following steps: Use Xsan Admin to stop the volumes (see below). In Xsan Admin select Overview. In the lower right corner, click the gear icon and choose “Edit SAN properties”. Select the Metadata Network that you want to use. Click Save. Restart the volumes. Note: If all controllers and clients are not on the same subnet on each network, the Save button will be dimmed. Adjust the clients and controllers so they are on the same subnets. This typically works great; except the fact that the article has been…
-
Defining MultiSAN
In Xsan 2, MultiSAN was introduced. MultiSAN allows you to assign different sets of primary, secondary and tertiary metadata controllers to volumes. This provides a performance benefit for some environments that have saturated resources on a given metadata controller. However, MultiSAN does not allow you to build separate SANs. All of the volumes are still members of that single “Xsan”, meaning that volumes can be mounted and/or controlled for any of the clients. You can have 2 volumes, each with a dedicated metadata controller, but both sharing a single backup metadata controller. You can also have 2 volumes, each with a dedicated metadata controller that fails over to the other…
-
Xsan: Ghost SymLink Killah
An Xsan issue that had disappeared for awhile but that I’ve seen a few times recently. Symptom is that you have one client that won’t mount your Xsan volume. Other clients can mount but not that one. In the logs you see errors similar to the following: (Error) Store: {channel:0x202b18fa0 localPath:’/Volumes/36Chambers’} bring up failed — will retry If all of these things are true then you likely, even without having the volume mounted will have a file in the /Volumes/ folder with the name of the SAN. If that’s the case then you have a pretty quick and easy resolution. Rename the file and see if fsm mounts the volume.…
-
Final Cut Server and Xsan Testers Needed
I’ve finally finished writing a pair of Dashboard Widgets that monitor Final Cut Server and Xsan processor and RAM intensity. A third on FileMaker Server should be complete within the next few days. If you’re interested in testing them let me know. Screens below:
-
Xsan 2: fsm and fsmpm
Go figure, they need less CPU and RAM. Very nice.