This section discusses how you can use the optional NetApp SyncMirror product to implement RAID mirroring for redundancy. Customers who choose to use SyncMirror typically have two storage subsystems and cannot tolerate any down time. Depending on your requirements, you might use SyncMirror alone or in conjunction with MetroCluster (see SyncMirror with MetroCluster).
SyncMirror cannot be used with the GF270c.
Note
The focus of this section is to help you plan for SyncMirror setup specific to a gFiler. See the Data ONTAP 6.5 Data Protection Online Backup and Recovery Guide for details about SyncMirror and the gFiler Gateway Series Getting Started Guide for information about the hardware configuration for a MetroCluster deployment.
A license is required to use SyncMirror. If you are using MetroCluster with SyncMirror, you must also have a license for MetroCluster.
If you are using SyncMirror, when you configure disk (LUN) ownership information on a gFiler, you must correctly configure the pool parameter so that RAID mirroring works correctly.
The SyncMirror software creates two physically separated copies of the volume, called plexes. The plexes are simultaneously updated; therefore, the two copies of the data are always identical. The following illustration shows two different plexes of a volume. (Data ONTAP automatically names the plexes.)
If a failure occurs, the unaffected plex continues to serve data while the cause of the failure is fixed. After the problem that caused a failure is fixed, the two plexes can be resynchronized and the mirrored relationship reestablished.
The physical separation of the plexes protects against data loss if
Plexes are not created during the disk (LUN) ownership assignment process. They are created after you complete the disk (LUN) ownership process and then create a mirrored volume, as described in What else you need to do to use SyncMirror with a gFiler.
Note
SyncMirror requires twice as much storage space on a mirrored volume as you would need on an unmirrored volume. Each of the two plexes requires enough space to accommodate the data to be stored. For example, you need 200 GB of disk space to mirror a 100 GB volume, 100 GB for each plex of the mirrored volume.
One plex of a volume must reside on each of the storage subsystems so that the data can be mirrored. The scheme that Data ONTAP uses to specify the location of the plexes is through the assignment of pools. In Data ONTAP, pools are used to split a set of disks (LUNs) into two groupings so that the two groupings do not share common single points of failure. When you configure the disk assign command on a gFiler on which you are going to use SyncMirror, you must specify the pool parameter correctly. Your goal when you specify the pool parameters is to group the LUNs belonging to the two subsystems into two pools, so when you later create a mirrored volume, the LUNs for one plex are derived from the same pool.
The following illustration shows the relationships of plexes and pools--one plex is associated with pool 0 and one plex is associated with pool1. The number 0 is typically associated with the local pool and the number 1 is typically associated with the remote pool. For performance reasons, you want reading to and from the local pool--pool 0--thereby avoiding reads over long distances.
The following illustration shows a deployment with a gFiler cluster and two storage subsystems. For simplicity, assume that each gFiler has only one volume and one switch. Your goal is to mirror each gFiler's volume by the way that you configure the pools on the gFiler.
As the preceding illustration shows, for gFiler 1, one plex of the volume, pool 0, the local pool, is be on the Storage Subsystem A. The other plex of the volume, plex 1, pool 1, is be on StorageSubsystem B. Similarly, for gFiler 2, one plex of its volume, pool 0, is on Storage Subsystem B and the other plex of the volume, pool 1, is on Storage Subsystem A.
The goal when you use SyncMirror is for the data to be mirrored exactly on the two storage subsystems. Then, if one storage subsystem becomes unavailable, all data can continue to be served.
If you use SyncMirror with gFilers, you must configure the pool parameters on all the gFilers when you configure the disk assign commands, and ensure that they are configured correctly. The disk assign command includes a -p parameter (where -p means pool). For LUNs for which you assign gFiler ownership during initial setup, you use the disk assign command with the -p parameter through the gFiler boot menu Maintenance option. After initial setup, you use the disk assign command with the -p parameter from the command line interface (CLI).
Caution
If you incorrectly configure the -p parameter when you configure disk ownership, you might not be able to create a mirrored volume. The mirror creation will not allow you to have mixed pools within a plex.
If you incorrectly configure the-p parameter, you can lose data if a disaster occurs that makes one storage system unavailable.
The following illustration provides a conceptual view of the configuration of the pools on the gFilers. The full command used on the gFiler for assigning disk (LUN) ownership is discussed in Actual commands. The following illustration shows the actual parameter for pool, -p, however.
Notice that in the previous illustration the two storage subsystems, StoreA and StoreB, each made four LUNs available to the gFilers.
Now notice the way disk ownership is configured on each of the gFilers in relation to the exported LUNs on each storage subsystem. In this scenario, gFiler1 and gFiler2 are each configured to own two LUNs on each storage subsystem. In reality, each gFiler could be assigned to own fewer or more LUNs. The only restriction is that only one gFiler can own a specific LUN.
Look at how the pool (-p) parameters were configured on each gFiler. Pool 0 is typically assigned to the local pool and pool 1 is assigned to the remote pool.
As a result of the configuration of the -p parameter, each storage subsystem has a copy of each volume.
Let us look at this same scenario as in the previous illustration showing the actual commands that you would enter on each of the gFilers. The command for disk (LUN) ownership is named disk assign. When configuring the gFiler for SyncMirror, you must include the pool parameter
(-p) with the disk assign command. (The -p parameter is not required when SyncMirror is not deployed.) You do not need to enter the disk assign command separately for each LUN ownership assignment, as was implied in the illustration. The actual commands for gFiler1 in the previous illustration are as follows:
disk assign storeAlun1 storeAlun2 -p 0
disk assign storeBlun1 storeBlun2 -p 1
The result of this configuration is that gFiler1 now owns four disks (LUNs), two on each storage subsystem.
The actual commands for gFiler2 in the previous illustration are as follows:
disk assign storeAlun3 storeAlun4 -p 1
disk assign storeBlun3 storeBlun4 -p 0
The result of this configuration is that gFiler2 now owns four LUNs, two on each storage subsystem.
Assigning the pools correctly during the disk ownership configuration in the setup program is only one part of preparing your gFilers for using SyncMirror. To use the SyncMirror feature, you must do the following on each gFiler participating in mirroring:
Let us use the previous scenario to illustrate how to create a mirrored volume. In the previously-described scenario, the following was configured on gFiler1 for disk ownership, with the -p parameter configured to support SyncMirror:
disk assign storeAlun1 storeAlun2 -p 0
disk assign storeBlun1 storeBlun2 -p 1
The result of this configuration was that gFiler1 owns four LUNs. To create a mirrored volume (after installing the license), you would enter
vol create mirrorvol -m 4
The mirrorvol command creates a mirrored volume with two plexes of two disks (LUNs) each. One plex contains the LUNs on storeA and the other plex contains the LUNs on storeB. The creation of the plexes does not allow mixing pools within a given plex.
After creating a mirrored volume on the first gFiler, you would create a mirrored volume on the other gFiler, using the same command. Creating mirrored volumes provides the maximum amount of fault isolation for handling the failures of the gFiler or either storage subsystem.
The SyncMirror chapter in the Data ONTAP Data Protection, Online Backup, and Recovery Guide provides detailed information about various tasks associated with using SyncMirror.
With a gFiler, SyncMirror is typically used in a MetroCluster deployment. The primary goal of a MetroCluster is to provide redundant storage services to mission-critical applications in case of site-specific disasters (for example, in the case of fire or long term power loss). The MetroCluster feature requires SyncMirror and a gFiler cluster configured for mirrored volumes to build a system that provides continuous updating of data and data protection over a distance.
Note
MetroCluster and SyncMirror cannot be used with the GF270c.
The following illustration shows an example of a simple MetroCluster deployment. The pools are configured for the MetroCluster in the same way as described in gFiler-specific configuration requirements for SyncMirror.
In a MetroCluster deployment with gFilers
A neighborhood is the number of nodes that can see each others' LUNs. A neighborhood is created on the storage subsystem by putting these nodes in each other's fabric. Because of the gFiler disk (LUN) ownership scheme, gFilers cannot write over each others' LUNs.
Copyright © 1994-2004, Network Appliance, Inc. All rights
reserved.
Part No. 210-00661
File: plannin6.htm
Last updated: 04/13/04 09:26:38