Dedicated metadata master or not?
metaSAN (as well as metaSAN iSCSI and metaLAN Server) relies on a floating master architecture to manage the SAN. Because metaSAN requires very little CPU to manage the SAN, it is possible to let any member act as the SAN master - there’s no need an Xserve machine to supervise HFS+ volumes, or to use computer running Windows Server OS as metadata master of NTFS volumes. But if metaSAN does not require lots of CPU, it still needs some. The use of a dedicated metadata controller is recommended in the following scenarios:
- When failover disruption is not acceptable to users (mission critical environments).
- When CPU availability of the floating master cannot be guaranteed.
- When stability of the floating master cannot be guaranteed.
- When projectStore, projectStore Pro or the Virtualization for Avid feature is used.
Here are a few observations that will help determine if you need to plan for an additional workstation or not.
- There is one (and only one) master per SAN volume.
The master is the machine that receives requests and grants permissions to other SAN members. It must be of the native file system format. For instance, a Windows machine is required to master an NTFS volume, and a Mac is required to master an HFS+ volume. As such, failover of an HFS+ volume cannot take place on a Windows machine, and vice-versa. The master requires a direct connection to the storage.
- Avoid rebooting the master.
By default, the first machine to boot becomes the SAN master. It is possible to define priorities among the various SAN members. It is also possible to assign different masters to different SAN volumes. A master remains master of the SAN until failover occurs.Failover will occur when the current master stops responding (due to a crash or shut down). Failover will cause mastership to be transferred to the next available workstation (based on assigned priorities) or to the manually selected workstation in the case of a manual promotion. Each failover occurrence will cause the SAN to become unresponsive for a few second.
- Avoid rendering on the master.
You should avoid rendering on a master machine so other members do not experience sluggishness. Rendering leaves no CPU to metaSAN. The more files a master must serve or the more fragmented a file system is, the more CPU cycles will be consumed by metaSAN to serve requests from client machines. More resources are necessary when gathering cluster chains for fragmented files or finding suitable space to allocate for new files on a fragmented file system.
- The master has no performance hit.
Prior to opening or closing a file, a client workstation must send a request to the master, and wait for the response. That arbitration process eliminates the risks of corruption when multiple computers access the SAN at the same time. However, a small delay is incurred on the transaction. The delay is near constant and is independent of the size of the file. When accessing large files, such as MPEG and QuickTime movies, the overhead is negligible. But when accessing lots of very small files, this overhead can affect performance. This is why - notwithstanding the previous points - that it can be a good idea to assign mastership to the workstation that requires fastest access to the shared storage.
As a rule of thumb, any setup with more than 4 SAN members should have a dedicated master.