Xsan 2 Administrator Guide - Planning Considerations and Guidelines

Chapter 2

Planning a Storage Area Network

27

How Should Users See Available Storage?

If you want users working on a project to see a volume dedicated to their work, create
a separate volume for each project. If it’s acceptable for a user to see a folder for his or
her work on a volume with other peoples’ folders, create a single volume and organize
it into project folders.

Workflow Considerations

How much file sharing is required by your users’ workflow? If, for example, different
users or groups work on the same files, either simultaneously or in sequence, it makes
sense to store those files on a single volume to avoid having 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 application (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.

Â

See “Choosing RAID Schemes for LUNs” on page 28.
Assign your fastest LUNs to an affinity tag for the application. Assign slower LUNs to

Â

an affinity tag for less demanding applications.
To increase parallelism, spread LUNs across different RAID controllers. Xsan then

Â

stripes data across the LUNs and benefits from simultaneous transfers through two
RAID controllers.
To increase parallelism for an affinity tag assigned to relatively small LUNs (the size

Â

of one or a few drive modules), create a slice of similar size across all drives on a
RAID controller instead of creating the LUNs from one or two drive modules.
Spread file transfers across as many drives and RAID controllers as possible.

Â

Try creating slices across the drives in RAID systems, and then assign these slices
to the same affinity tag.
To increase throughput, connect both ports on client Fibre Channel cards to the

Â

fabric.
Store file system metadata and journal data 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.
Use a second Ethernet network (including a second Ethernet port in each SAN

Â

computer) for SAN metadata.
If your SAN uses directory services, mail services, or other services on a separate

Â

server, connect SAN computers to that server on an Ethernet network separate from
the SAN metadata network.

Choose a different primary metadata controller for each volume, and set up volume

Â

failover priorities to minimize the possibility of more than one volume failing over to
the same metadata controller.
If all computers on your SAN are running Xsan 2.2, 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 at least one standby metadata
controller in addition to your primary metadata controller. Also, consider setting up
dual Fibre Channel connections between each client, metadata controller, and storage
device using redundant Fibre Channel switches.

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.

Security Considerations

If your SAN supports projects that must be secure and isolated from each other, create
separate volumes for each project to eliminate any possibility of the wrong client or
user accessing files stored on a volume.

As the SAN administrator, you control which client computers can use a volume.
Clients can’t browse for or mount SAN volumes on their own. You use Xsan Admin to
unmount a volume on clients that shouldn’t have access to it.

You can also set up access control lists (ACLs) in Xsan Admin or assign user and group
permissions to folders using standard file access permissions in the Finder.

Choosing 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 your storage pools and volumes. Before you
set up a SAN, you use the RAID system configuration or administration application to
prepare LUNs based on specific RAID schemes.

WARNING:

If a LUN belonging to an Xsan volume fails and can’t be recovered, all

data on the volume is lost. It is 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.

28

Chapter 2

Planning a Storage Area Network

Chapter 2

Planning a Storage Area Network

29

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

Deciding on the Number of Volumes

A volume is the largest unit of shared storage on the SAN. If your 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, one way to control client access is to create separate
volumes and unmount volumes on clients that shouldn’t have access to them.

For a more typical balance of security and shared access, a flexible compromise is to
create one volume and control access with folder access privileges or ACLs in Xsan
Admin (or in Mac OS X Server’s Server Admin).

Deciding 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 Xsan Admin.

You can assign folders to specific storage pools using affinities. For example, you can
create a folder for data that requires fast access and assign that folder to your fastest
storage pool.

Assigning LUNs to Affinity Tags

When you create a volume using a preset volume type that fits your SAN scenario,
Xsan Admin sets up storage pools and affinity tags for best performance. All you do
is assign LUNs to each affinity tag. Xsan Admin determines the optimal number of
storage pools to create, based on the volume type and the number of LUNs you assign
to each affinity tag.

For best performance, assign LUNs in the multiples shown below. These multiples
apply to affinity tags used for user data, not to the Metadata and Journal affinity tag,
which needs just one LUN.

For this volume type’s affinity tags used for
user data

Assign LUNs in multiples of

General File Server

2

Home Folder Server

2

Mail Cluster

1

Podcast Producer Cluster

4

Standard Definition Video

4

Uncompressed High Definition Video

4

Assign LUNs that have the same capacity and performance characteristics to each
affinity tag.

LUNs that you assign to an affinity tag should have the same capacity, because Xsan
provides high performance by using the RAID 0 scheme to stripe data across the LUNs
in each storage pool. This striping scheme can use available space on each LUN equal
to the capacity of the smallest LUN in a storage pool.

If a storage pool’s LUNs vary in size, this can result in wasted capacity. For example,
if a storage pool has a 240 GB RAID array and a 360 GB RAID array, 120 GB of the larger
array won’t be used. By assigning LUNs with similar capacities to an affinity tag, you
avoid wasting available storage.

If you’re using a volume type with multiple affinity tags for user data, assign your
fastest LUNs to the affinity tag associated with folders whose contents benefit most
from extra performance. Assign slower LUNs to an affinity tag associated with folders
whose contents don’t have critical performance requirements.

You can also increase the performance of an affinity tag’s storage pools by assigning
that affinity tag a combination of LUNs that are hosted on different drive modules
and different RAID controllers. This strategy increases performance by increasing the
parallelism of data transfers.

Deciding Which Clients to Mount a Volume On

If you create multiple volumes, decide which volumes should be mounted on which
clients. A new volume is initially mounted on all clients. You can use Xsan Admin to
unmount a volume from selected clients.

Choosing Metadata Controllers

You must choose at least one computer to be the SAN metadata controller, the
computer that 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. For more information, see “Storing User Data with Metadata
and Journal Data” on page 31.

30

Chapter 2

Planning a Storage Area Network

Chapter 2

Planning a Storage Area Network

31

If high availability is important, use at least two metadata controllers: one as the
primary controller and one as a standby. You can specify additional metadata
controllers as needed, and set each volume’s failover priorities to determine the order
in which the controllers are tried if a volume’s primary controller stops responding.

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.

Choosing Standby Controllers

To be sure that SAN volumes are always available, set up at least one standby
metadata controller that can take over if your primary metadata controller fails.

Storing User Data with Metadata and Journal Data

The metadata and journal data that describe a volume are stored not on the volume’s
metadata controller, but on the volume. They’re stored on the first storage pool in the
volume.

Preset volume types set up a separate storage pool used only for metadata and journal
data. If you use Xserve RAID systems for storage, make sure that the LUNs you assign
to the metadata and journal storage pool are connected to a different RAID controller
than the LUNs you assign to affinity tags for user data.

If you set up a custom volume with more than one storage pool, you can choose
whether the metadata and journal storage pool is allowed to store user data. You
might get adequate performance by combining metadata and journal data on the
same storage pool as user data, but for better performance, use a separate storage
pool for metadata and journal data.

Estimating Metadata and Journal Data Storage Needs

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.

Choosing an Allocation Strategy

If you choose a preset volume type when you set up a volume, Xsan Admin sets its
volume allocation strategy for you. Later, you can change the allocation strategy by
editing volume settings with Xsan Admin. The allocation strategy you choose for a
volume determines the order in which its storage pools are filled with data. You can
choose round robin, fill, or balance:

Â

If you choose round robin, Xsan writes data to each storage pool in the volume in
turn. This is normally the best choice for performance.

Â

If you choose fill, Xsan writes data to the first storage pool in the volume until that
storage pool is full, and then moves to the next storage pool. This is a good choice
to keep a specific storage pool unused as long as possible.