What is Fabric-Attached MetroCluster?
A Fabric-Attached MetroCluster configuration can be implemented for distances greater than 500 meters connects the two storage nodes by using four Brocade or Cisco Fibre Channel switches in a dual-fabric configuration for redundancy. Each site has two Fibre Channel switches, each of which is connected through an inter-switch link to a partner switch at the other site.
The inter-switch links are fibre connections which extend the storage fabric path so that it provides a greater distance between nodes than other HA pair solutions. By using four switches instead of two, redundancy is in place to avoid single-points-of-failure in the switches and their connections.
The advantages of a fabric-attached MetroCluster configuration over a stretch MetroCluster configuration include the following:
- Increased disaster protection via nodes being in separate geographical locations
- Disk shelves and nodes are not connected directly to each other, but are connected to a fabric with multiple data routes ensuring no single point of failure.
The disadvantage is that there’s more cabling and there’s more components involved in the way of fibre switches.
Fabric MetroCluster requirements
The requirements for Fabric MetroCluster extends those of a stretch MetroCluster by adding extra requirements pertaining to fibre channel needs.
- Each site of the MetroCluster configuration requires two fibre switches.
- Switches must be either a supported Brocade or Cisco model supplied by NetApp.
Customer-supplied switches are not supported. - The two switches within the fabric must be the same model and must be licensed for the same number of ports.
- All four switches for a particular fabric-attached MetroCluster configuration must support the same maximum speed.
- Switches must be running the required firmware version
For the most up-to-date switch information and interoperability make sure to look over the MetroCluster Compatibility Matrix on the NetApp Support site.
Due to the increased distance between the controllers in a Fabric MetroCluster the write performance can be expected to decrease by 6% to 10%. Reads can increase by between 20% and 50% provides reads are enabled on both plexes.
FAS Controller Fabric MetroCluster Compatibility
The nodes in a MetroCluster must be one of the following system models configured for mirrored volume use; each node in the pair must be the same model.
- 30xx systems, except for the FAS3050 and 3020 systems
- 31xx systems
- 32xx systems
- 60xx
- 62xx systems
Anatomy of a write
A MetroCluster uses SyncMirror which enables synchronous writes to both sides of the cluster. As part of the write process the NVRAM is also mirrored across the cluster interconnect to ensure that there is no data loss and that all writes are committed to disk to ensure no data loss during outages. MetroCluster provides a true synchronous write. The two writes are carried out by one controller. It doesn’t pass off the write to a remote node to perform the write at that site.
It’s worth understanding how data is written to disk to get a better idea of how Fabric MetroCluster works. In the above image we can see a write request come into a storage node in site 1.
- Write request enters controller from end user
- The write request is put into NVRAM
- This is mirrored across the cluster interconnect to site 2 controller NVRAM to ensure no data loss
- Acknowledgement is sent back to user that write has been committed
Once enough blocks are written to create a Consistency Point in NVRAM the data is written to the local volume in local Plex and the Plex mirror on remote site at the same time