Xserve Raid with fibre switch - it's time

There are many caveats here, so be careful.

For a start you cannot just plug multiple hosts into the RAID (via the switch) and expect it to work. XSAN (or a similar SAN arbitrator) is required, and that's not necessarily rivial, even if the components are bundled in Lion Server.

Just as long as you realize that, though, you should be OK.

As for cabling, that's largely up to you (and the Sanbox). Fiber Channel interfaces come in many flavors and can use either copper or optical cables. What you choose is up to you. Copper is usually cheaper, but optical cables can run greater distances, so location is going to be a factor.

Along with the cable media there are also different connectors, so you'll need to make sure which type the sanbox supports. SFP is probably the commonest, but there are others such as HSSDC, HSSDC2 and DBm. I don't know that particular fiber channel switch but I'll guess it's SFP.

In that case you're probably looking for 2Gb/sec SFP-SFP cable.

If you need cables longer than 10 metres (the copper limit) then you'll need optical SFP mini-GBIC transciever modules and a string of fiber optic cable to run between them.

Note that the XServe RAID has 2GB fiber channel ports, but they're generally compatible with the faster speeds now supports (including 4- and 8GB/sec ports) if your switch supports that.

It's also possible to mix and match cables - you could use copper cables between your XServe RAID and the switch, with optical cables running out to the host system(s), if that's the way your network is setup.

As for whether the switch will work without much hassle, that depends a lot on its current configuration. If it's used then you don't necessarily know how the previous owner configured it, so you might need to clear its current configuration.

It was a typo - I meant that implementing XSAN is not a trivial task.

All of this is spelled out in detail in the Xsan_2_Admin_Guide_v2.3.pdf. You might consider reading what a clustered file system is (google it), specificially the shared disk variety.

The XSan requires a specific topology called a fibre channel fabric. This means fibre channel cards for all computers directly accessing the SAN, and the fabric is made up of fibre channel cables going from computers and fibre channel arrays to a fibre channel switch. One metadata controller is required. A standby is considered a good idea and is recommended. This fibre channel network is what provides block level device access to the arrays for all computers. There is no file system at all at this point, just raw device access to arrays.

You need at least one metadata controller (primary), best practices calls for a standby as well. Lion Server can be setup as an Xsan metadata controller, obviously it will need a fibre channel card. It is recommended that the filesystem metadata is carried over its own private ethernet network isolated from other network traffic. That's one reason why towers and xserves have two ethernet ports. But with some sacrifice to performance it is possible for the xsan file system metadata to be carried over the same ethernet connection as internet, printing, file sharing, etc. Lion client contains the support needed to present the xsan file system to each computer connected to fibre channel arrays as locally attached disks. Only logical volumes are presented, not the entire available storage. One of the things you do with the metadata controller is add arrays to storage pools, then from storage pools you create one or more logical volumes and it is those logical volumes the end user sees on clients.

Anyway, this is very well spelled out in the admin guide.