Planning considerations for your Xsan SAN design
The following considerations might help improve your SAN design decisions.
How much storage?
Because it’s easy to add storage for user data to an Xsan SAN, you only need an adequate starting point. You can add storage later as needed.
However, you can’t add storage for journal data, so try to allocate enough space for journal data right from the start.
You can add an entire storage pool for metadata and another storage pool for journal data.
Workflow considerations
How much file sharing is required by your users’ workflow? For example, if different users or groups work on the same files, simultaneously or in sequence, store those files on a single volume to avoid needing to maintain or hand off copies. Xsan uses file locking to manage shared access to a single copy of the files.
Performance considerations
If your SAN supports an app (such as high resolution video capture and playback) that requires the fastest possible sustained data transfers, design your SAN with these performance considerations in mind:
Set up the LUNs (RAID arrays) using a RAID scheme that offers high performance.
To increase parallelism, spread LUNs across RAID controllers. Xsan then stripes data across the LUNs and benefits from simultaneous transfers through two RAID controllers.
To increase throughput, connect both ports on client Fibre Channel cards to the fabric.
For clients using Xsan 5 and DLC, real-time operations should be done over a Fibre connection.
Store file system metadata on a separate storage pool from user data and make sure the metadata LUNs aren’t on the same RAID controller as user data LUNs.
You can use a separate storage pool for journal data when you create a new volume. This significantly improves performance for some operations, such as creating and deleting files.
Use a second Ethernet network (including a second Ethernet port for each SAN computer) for SAN metadata.
If all computers on your SAN are Mac computers, enable Extended Attributes for your volumes to eliminate the overhead of file information being stored in multiple hidden files.
Availability considerations
If high availability is important for your data, set up multiple metadata controllers to accommodate metadata controller failover. Also, consider setting up dual Fibre Channel connections between each client, metadata controller, and storage device using redundant Fibre Channel switches.
Security considerations
If your SAN supports projects that must be secure and isolated from each other, create separate volumes for each project and set appropriate ACLs on the volume to eliminate any possibility of the wrong client or user accessing files stored on a volume.
As the SAN administrator, you control which computers are SAN clients. Users whose computers aren’t SAN clients or controllers can’t browse for or mount SAN volumes.
However, you can’t control which Xsan computers can use a volume. Users whose SAN computers have macOS or macOS Server can mount all SAN volumes themselves.
You can also set up access control lists (ACLs) in the Server app or assign user and group permissions to folders using standard file access permissions in the Finder.
Choose RAID schemes for LUNs
Much of the reliability and recoverability of data on a SAN is provided not by Xsan, but by the RAID arrays you combine to create storage pools and volumes. Before you set up a SAN, use the RAID system configuration or administration software to prepare LUNs based on specific RAID schemes.
WARNING: Losing a metadata controller without a standby can result in the loss of all data on a volume. A standby controller is strongly recommended.
WARNING: If a LUN in the metadata storage pool fails and can’t be recovered, all data on the volume is lost. It’s strongly recommended that you use only redundant LUNs (LUNs based on RAID schemes other than RAID 0) to create Xsan volumes.
LUNs configured as RAID 0 arrays (striping only) or LUNs based on single drives are difficult or impossible to recover if they fail. Unprotected LUNs such as these should be used only in storage pools that store scratch files or other data that you can afford to lose.
Most RAID systems support all popular RAID levels. Each RAID scheme offers a different balance of performance, data protection, and storage efficiency, as summarized in the following table.
RAID level | Storage efficiency | Read performance | Write performance | Data protection |
|---|---|---|---|---|
RAID 0 | Highest | Very High | Highest | No |
RAID 1 | Low | High | Medium | Yes |
RAID 3 | High to very high | Medium | Medium | Yes |
RAID 5 | High to very high | High | High | Yes |
RAID 0+1 | Low | High | High | Yes |
Decide on the number of volumes
A volume is the largest unit of shared storage on the SAN. If users need shared access to files, store those files on the same volume. This makes it unnecessary for them to pass copies of the files among themselves.
However, if security is critical, remember you can’t control client access by unmounting volumes on Xsan clients. Users whose computers have macOS or macOS Server can mount SAN volumes themselves.
For a typical balance of security and shared access, create one volume and control access with folder access privileges or ACLs the Server app.
Decide how to organize a volume
You can help users organize data on a volume or restrict users to specific areas of the volume by creating predefined folders. You can control access to these folders by assigning access permissions using the Server app.
Choose metadata controllers
You must choose at least one computer to be the SAN metadata controller, the computer which is responsible for managing file system metadata.
Note: File system metadata and journal data are stored on the SAN volume, not on the metadata controller itself. See “Store user data with metadata and journal data” below.
If high availability is important for your data, set up multiple metadata controllers to accommodate metadata controller failover.
If performance is critical, don’t run other server services on the metadata controller and don’t use the controller to reshare a SAN volume using AFP or NFS.
Estimate metadata and journal data storage needs
The metadata and journal data that describe a volume are stored not on the volume’s metadata controller, but on the volume. Metadata is stored on the first storage pool in the volume. Journal data can be stored on any storage pool in the volume. You must have only one storage pool with journal data.
To estimate the amount of space required for Xsan volume metadata, assume that 10 million files on a volume require approximately 10 GB of metadata on the volume’s metadata storage pool.
The journal requires between 64 KB and 512 MB. Xsan configures a fixed size when you create a volume. Due to the small size, you can use a single RAID 1 LUN for the journal storage pool. To maximize the performance benefit of a separate journal storage pool, dedicate entire physical disks to the RAID 1 LUN.
Store user data with metadata and journal data
Although it’s possible to create a volume with only one storage pool (containing metadata, journal and user data), it isn’t recommended if performance is of concern.