Lenovo ONTAP 9 User Manual

SnapMirror Configuration and Best Practices Guide for ONTAP 9

Updated for ONTAP 9.7

Abstract

This document describes information and best practices related to configuring replication in Lenovo® ONTAP.

First edition (March 2021) © Copyright Lenovo 2021. LIMITED AND RESTRICTED RIGHTS NOTICE: If data or software is delivered pursuant to a General Services

Administration (GSA) contract, use, reproduction, or disclosure is subject to restrictions set forth in Contract No. GS-35F-05925

TABLE OF CONTENTS

1 Overview ................................................................................................................................................ 1

1.1 Purpose and Intended Audience .....................................................................................................................1

1.2 SnapMirror Overview ......................................................................................................................................2

2 Lenovo Networking Basics .................................................................................................................. 4

2.1 Lenovo ONTAP Overview ...............................................................................................................................4

2.2 Intercluster Networking ...................................................................................................................................6

2.3 Intercluster Multipathing and Network Redundancy ........................................................................................6

2.4 Network Connections for Intercluster SnapMirror ...........................................................................................9

2.5 Share or Dedicate Ports? .............................................................................................................................. 11

2.6 Firewall Requirements .................................................................................................................................. 12

2.7 Licensing ................................................................ ....................................................................................... 12

3 Lenovo replication basics ................................................................................................................. 12

3.1 SnapMirror Technology ................................................................................................................................. 12

3.2 SnapVault Technology .................................................................................................................................. 14

3.3 Unified Data Protection ................................................................ ................................ ................................. 15

4 SnapMirror Configuration .................................................................................................................. 16

4.1 Cluster Peering ............................................................................................................................................. 16

4.2 SVM Peering ................................................................................................................................................. 17

4.3 SnapMirror Data Protection Relationship ...................................................................................................... 17

4.4 Protection Policies ........................................................................................................................................ 21

4.5 SnapMirror Schedules .................................................................................................................................. 24

4.6 Create a SnapMirror Relationship ................................................................................................................. 25

4.7 Baseline Transfer during Initialization of SnapMirror Relationship ................................................................ 25

4.8 Manual Update to the SnapMirror Relationship ............................................................................................ 26

5 Conversion .......................................................................................................................................... 26

5.1 Convert a SnapMirror Relationship to a SnapVault Relationship .................................................................. 26

5.2 Convert SnapMirror to Unified Replication .................................................................................................... 28

6 SnapMirror and ONTAP Feature Interaction .................................................................................... 30

6.1 SnapMirror and Snapshot Copies ................................................................................................................. 30

6.2 SnapMirror and Qtrees ................................................................................................................................. 30

6.3 SnapMirror and FlexClone ............................................................................................................................ 31

6.4 SnapMirror and Lenovo Storage Efficiency ................................................................................................... 31

6.5 SnapMirror and Volume Move ...................................................................................................................... 32

6.6 SnapMirror for Disk Shelf Failure Protection ................................................................................................. 32

6.7 SnapMirror and Volume Autosize ................................................................................................................. 32

6.8 SnapMirror and Network Data Management Protocol ................................................................................... 33

6.9 SnapMirror and Fabric Pool .......................................................................................................................... 33

7 Performance ........................................................................................................................................ 33

7.1 Calculate SnapMirror and SnapVault Throughput for Performance .............................................................. 34

7.2 SnapMirror and Network Compression ................................................................................................ ......... 34

7.3 SnapMirror Throttling .................................................................................................................................... 37

7.4 How to Change TCP Receive Buffer Size ..................................................................................................... 38

7.5 Concurrent Replication Operations ............................................................................................................... 39

7.6 Recommended Replication Intervals ............................................................................................................ 39

7.7 Network Sizing Requirements ....................................................................................................................... 39

8 Interoperability .................................................................................................................................... 40

9 Troubleshooting Tips ......................................................................................................................... 40

9.1 Troubleshooting Cluster Peer Relationships ................................................................................................. 40

9.2 Troubleshooting SVM Peer Relationships..................................................................................................... 41

9.3 Understanding SnapMirror Relationship Status ............................................................................................ 42

9.4 Troubleshooting SnapMirror Relationships ................................................................................................... 42

10 Best Practices for DR Configurations .............................................................................................. 45

11 Configuration and Failover for Disaster Recovery ......................................................................... 45

11.1 Environment Failover Requirements and Assumptions ................................................................................ 46

11.2 Preparing the Destination for Failover ........................................................................................................... 46

11.3 Performing a Failover .................................................................................................................................... 48

11.4 Post failover Volume Configuration ............................................................................................................... 49

12 Where to Find Additional Information .............................................................................................. 49

Contact Support ........................................................................................................................................ 49

Notices ....................................................................................................................................................... 50

Trademarks ................................................................................................................................................ 51

LIST OF FIGURES

Figure 1) SnapMirror replication overview. .....................................................................................................................2

Figure 2) Unified architecture flexibility. ................................................................................................ ..........................4

Figure 3) Cluster interconnect, data, and management networks. .................................................................................5

Figure 4) InterCluster network. .......................................................................................................................................6

Figure 5) Failover multipathing. ......................................................................................................................................7

Figure 6) Failover multipathing during LIF failover. ........................................................................................................7

Figure 7) Multiplexing mode. ..........................................................................................................................................8

Figure 8) LIF failover in multiplexing mode. ....................................................................................................................8

Figure 9) TCP connections with one intercluster LIF. ................................................................................................... 10

Figure 10) TCP connections with two intercluster LIFs. ............................................................................................... 10

Figure 11) SVM peering. .............................................................................................................................................. 17

Figure 12) SnapMirror cascade. ................................................................................................................................... 20

Figure 13) Update. ....................................................................................................................................................... 26

Figure 14) Creating a FlexClone volume at a SnapMirror destination. ......................................................................... 31

Figure 15) SnapMirror network compression functional diagram. ................................................................................ 35

Figure 16) Volume layout for DR. ................................................................................................................................. 47

1 Overview

Businesses can use several approaches to increase data availability in the face of hardware, software, or site failures. Data protection (DP) is one of the most critical aspects because any loss of data translates directly into lost money and time. Data protection is the process of taking data located in one location and making a copy of it in a different location to serve two use cases:

 Backup. The objective is to restore from the secondary to the primary with no intention of failing over

to the secondary. This implies that the primary purpose of the secondary is archival storage. Therefore, you might have more data in the secondary than in the primary.

 Disaster recovery (DR). An exact replica or copy is maintained in the secondary and used for

failover from the primary to the secondary if there is failure at the primary site.

Although backups allow you to recover lost data from an archival medium (tape, disk, or the cloud), mirroring is the most popular data availability mechanism for business continuity and DR, especially if you would like to minimize downtime. SnapMirror® technology offers a fast and flexible enterprise solution for mirroring or replicating data over local area networks (LANs) and wide area networks (WANs). The main advantages to using SnapMirror are as follows:

 Robust enterprise technology. SnapMirror is a mature feature of ONTAP storage systems that has

been enhanced and improved over time. SnapMirror can recover from update failures, use concurrent processes for replication processing, throttle the network bandwidth used for transfer operations, and much more.

 Speed and efficiency. Block-level logical incremental data transfer makes sure that only the data

that has changed is sent to the destination replica. SnapMirror can reduce data volume further with various storage efficiencies such as network compression to compress data as it leaves the source and decompress it at the destination, thereby improving transfer performance.

 Flexibility. SnapMirror allows you to define different synchronization schedules to better meet your

system’s needs. Using SnapMirror, you also can change the direction of the synchronization if there is a problem with the primary repository. SnapMirror can also be used to create a variety of replication topologies. Options include fan-out, in which a single volume replicates to many secondary systems, and cascade, in which the destination volume is itself synchronized to a tertiary system.

 Testability. SnapMirror destination volumes can be instantly cloned as writable volumes using

Lenovo FlexClone technology, irrespective of their size, and in a space-efficient manner, without needing to stop data being replicated from the source, and is invaluable for performing DR tests, for example.

 Failover and failback. If DR systems must be brought online, SnapMirror relationship can be broken,

which makes the destination volumes read/write and ready to use. SnapMirror allows you to resynchronize the original source with the changes made at the destination and then re-establish the original SnapMirror relationship.

 Ease of use. With ThinkSystem Storage Manager for DM Series, you can perform operations with

simplified workflows and wizard-guided walkthroughs. You can also monitor and manage all SnapMirror replication relationships in one place.

 Secure. From ONTAP 9.4 onwards, SnapMirror relationships can be encrypted natively end-to-end.

1.1 Purpose and Intended Audience

This document is intended for individuals who administer, install, or support ONTAP systems and who intend to configure and use SnapMirror technology for data replication.

This document assumes that the reader understands the following processes and technologies:  A working knowledge of ONTAP operations

 A working knowledge of features such as Snapshot™ technology, FlexVol® or FlexGroup® volumes,

and FlexClone® technology

 General knowledge of DR and data replication solutions  Familiarity with the ONTAP Data Protection Guide on the Lenovo Data Center Support site

1.2 SnapMirror Overview

SnapMirror is a replicatiofn solution built into ONTAP for business continuity and DR purposes. SnapMirror is configured through a DP relationship between data volumes (FlexVol or FlexGroup) on primary and secondary storage systems. SnapMirror periodically updates the replica to keep it up to date with changes that have been written to the primary.

This replica or mirror of enterprise data is created in a secondary storage system at a geographically remote site or in the cloud. You can fail over and serve data from the secondary in the event of a catastrophe at the primary site. After the error condition at the primary site is rectified, you can replicate any changes back to primary and start serving clients from the primary site again. With SnapMirror, you can reduce the total cost of ownership (TCO), making it easier to justify the DR investment by putting your DR site to active business use. For an overview of SnapMirror replication, see Figure 1.

Figure 1) SnapMirror replication overview.

Integrated Data Protection

DP capabilities are an integral part of ONTAP. SnapMirror integrates tightly with Snapshot technology to quickly and efficiently create on-disk replicas or point-in-time, space-efficient copies of data.

Lenovo integrated DP can be used to create a quickly accessible on-disk history of application-consistent Snapshot copies that eliminates the concept of a traditional backup window. SnapMirror then replicates the history of Snapshot copies to the destination, which can be used for backup, DR, or test and development.

SnapMirror replication is efficient because it only replicates blocks that have changed or added since the previous update. Additional efficiency is gained when SnapMirror is combined with Lenovo storage efficiency technologies. Compression and data deduplication technologies can result in significant telecommunication and storage capacity savings.

SnapMirror for Disaster Recovery

SnapMirror technology is also used as a part of DR plans. If critical data is replicated to a different physical location, a serious disaster does not have to cause extended periods of unavailable data for business-critical applications. Clients can access replicated data across the network until the recovery of the production site from corruption, accidental deletion, natural disaster, or what have you.

In the case of failback to the primary site, SnapMirror provides an efficient means of resynchronizing the DR site with the primary site, transferring only changed or new data back to the primary site from the DR site by simply reversing the SnapMirror relationship. After the primary production site resumes normal application operations, SnapMirror continues the transfer to the DR site without requiring another baseline transfer.

Disaster Recovery Testing and Application Testing and Development

FlexClone technology can be used to quickly create a read-write copy of a SnapMirror destination FlexVol volume in case you want to have read-write access of the secondary copy to confirm if all the production data is available.

Data Distribution and Remote Data Access

SnapMirror technology can be used to distribute large amounts of data throughout an enterprise, enabling access to data at remote locations. Remote data access provides faster access by clients in remote locations. It also allows more efficient and predictable use of expensive network and server resources because WAN usage occurs at a predetermined replication time. Storage administrators can replicate production data at a specific time to minimize overall network utilization.

Backup Offloading and Remote Tape Archiving

SnapMirror technology can also be used for backup consolidation and for offloading tape backup overhead from production servers. This approach facilitates centralized backup operations and reduces backup administrative requirements at remote locations. Snapshot technology eliminates the traditional backup window on the primary storage system. Therefore, offloading tape backups to a SnapMirror destination (Figure 2) dramatically reduces the overhead of backup operations on production storage systems.

Unified Architecture Flexibility

SnapMirror technology can be used between ONTAP platforms with different performance characteristics (and different costs) at the primary and DR sites. For example, depending on the capabilities required, the DR site might contain a lower-end platform, with SATA disks rather than SAS or SSD disks, or the iSCSI protocol rather than FC. Figure 2 illustrates the flexibility within a unified architecture.

Figure 2) Unified architecture flexibility.

A unified architecture, from low-end platforms to high-end platforms, also allows system administrators to learn and use the same management and monitoring paradigm.

2 Lenovo Networking Basics

2.1 Lenovo ONTAP Overview

Some basic terms used in ONTAP include the following:

 Node. A single Lenovo controller in a high-availability (HA) pair.  Cluster. One or more nodes that are interconnected and managed as a single system.  Cluster interconnect. A dedicated high-speed, low-latency, private network used for communication

and replication between nodes in the same cluster.

 Data network. The network used by clients to access data.  Management network. The network used for administration of the cluster, SVM, and nodes.  HA interconnect. The dedicated interconnect between two nodes in one HA pair.  HA pair. Two nodes configured in a pair for HA.  Physical port. A physical port such as e0e or e0f or a logical port such as a virtual LAN (VLAN) or

an interface group (ifgrp).

• Virtual port:

 Ifgrp. A collection of physical ports combined to create one logical port used for link aggregation.  VLAN. A VLAN subdivides a physical network into distinct broadcast domains. As a result, traffic

is completely isolated between VLANs unless a router (layer 3) is used to connect the networks. In ONTAP, VLANs subdivide a physical port into several separate virtual ports, allowing for one of the key components of our secure multitenant messaging―isolation of data.

 Logical interface (LIF). A LIF is an IP address or a worldwide port name (WWPN) that is associated

with a port. It is associated with attributes such as failover groups, failover rules, and firewall rules. A LIF communicates over the network through the port (physical or virtual) to which it is currently bound.

 Intercluster LIF. Logical network interfaces are used for intercluster communication, backup, and

replication. You must create an intercluster LIF on each node in the cluster before a cluster peering relationship can be established. These LIFs can only fail over to ports in the same node. They cannot be migrated or failed over to another node in the cluster.

 Intercluster network. The network used for communication and replication between different

clusters.

 Intercluster ports. Ports dedicated to intercluster replication.  Cluster peering. The act of connecting two clusters to allow replication to occur between them.  SVM. A logical storage server that provides data access to LUNs and/or a network-attached storage

(NAS) namespace from one or more LIFs.

There are multiple types of networks in ONTAP, as shown in Figure 3 and Figure 4. It is important to understand what each network type is used for. The cluster interconnect network is a dedicated, highspeed, low-latency private network used for communication and replication between nodes in the same cluster. This configuration is a redundant back-end network that cannot be used or shared for client access to data or for managing the cluster, nodes, or SVMs. Client access to data occurs on the data network. Management of the cluster, nodes, and SVMs occurs on the management network. The data and management networks might share the same ports or physical network. However, the data and management networks must be a different physical network than the cluster interconnect network.

Figure 3) Cluster interconnect, data, and management networks.

The intercluster network must be configured, to enable cluster peering for replication of data from one geographical location to another as shown in Figure 4. The Intercluster network uses logical interfaces, or LIFs, that correspond to IP addresses and represent network access points to a node. Intercluster LIFs are assigned to ports as part of the cluster peer configuration process.

Figure 4) InterCluster network.

2.2 Intercluster Networking

The following are requirements for intercluster LIFs:  At least one intercluster LIF must be configured on every node in the local cluster and every node in

the remote cluster. Provisioning intercluster LIFs on only some nodes of the cluster is not supported.

 The IP addresses you assign to intercluster LIFs can reside in the same subnet as data LIFs or in a

different subnet. Intercluster LIFs use routes that belong to the system SVM to which they are assigned. ONTAP automatically creates a system SVM for cluster-level communications within an IPspace.

 The cluster peering topology should use full-mesh connectivity. Full-mesh connectivity means that all

the intercluster LIFs of one peer cluster can communicate with all the intercluster LIFs of the other peer cluster. All ports that are used to communicate with a given remote cluster must be in the same IPspace. You can use multiple IPspaces to peer with multiple clusters. Pairwise, full-mesh connectivity is required only within an IPspace. Also, consider using custom IPspaces to isolate replication traffic.

 Intercluster LIFs are node scoped. Therefore, when the port hosting an intercluster LIF fails, the LIF

can only fail over to another intercluster-capable port on that node, as defined by the LIF's failover policy. At least one intercluster LIF is required per node for replication between clusters. Maintain consistent settings between the intercluster LIFs (the same maximum transmission units [MTUs], flow control, Transmission Control Protocol [TCP] options, and so on).

 SnapMirror replication over an FC network is not available in ONTAP.  If a node fails while an intercluster SnapMirror transfer is in progress, the transfer automatically

continues using an intercluster LIF on the surviving node of the HA pair. The same transfer does not automatically continue after the storage failover (SFO) of the destination. If SFO happens on the source, the transfer continues. However, replication as such continues automatically from the surviving node.

For additional information regarding intercluster networking, see the ONTAP 9 Data Protection Power

Guide.

2.3 Intercluster Multipathing and Network Redundancy

You might want more than one physical path for a SnapMirror relationship. SnapMirror supports up to two paths for a SnapMirror relationship. When using multiple paths, you need to set up the configuration in one of the following ways:

 Set up static routes to ensure different routes are used for different IP connections.  Use different subnets for the two connections.

The two paths can be used in one of these two modes:

 Failover mode. SnapMirror uses the first specified path as the desired path and uses the second

specified path only after the first path fails.

 Multiplexing mode. SnapMirror uses both paths at the same time, essentially load balancing the

transfers. If one path fails, the transfers occur on the remaining path. After the failed path is repaired, the transfers resume using both paths.

Failover Mode

In many ways, an intercluster LIF behaves in the same way as a LIF used for CIFS or NFS in terms of failover, except that an intercluster LIF cannot fail over to a port in a different node. The initial placement of a LIF on a specific port determines which port is used by that LIF. If ports are redundant for failover on the same node, then the active path is the port where the initial LIF was placed. The passive path is any port where the LIF might fail over.

Therefore, it can be said that a properly configured redundant LIF provides failover multipathing, as shown in Figure 5:

Figure 5) Failover multipathing.

Communication on an intercluster LIF only occurs on the port to which the LIF is assigned unless that port fails, which causes the LIF to move to another surviving port in that LIF’s failover group.

Figure 6) Failover multipathing during LIF failover.

Best Practice

Assign an intercluster LIF to an intercluster-capable port and make sure that another interclustercapable port is configured to support that connection. Make sure that the failover policy for the LIF is configured with the failover group containing the necessary ports to enable successful failover.

Multiplexing mode

Multiplexing mode requires the configuration of additional intercluster LIFs on a node. SnapMirror uses all available intercluster LIFs on the source and destination nodes to send and receive data for all transferring SnapMirror relationships between those two nodes. If two intercluster LIFs are configured and two ports are available for intercluster communication, then one LIF can be assigned to each port, and SnapMirror simultaneously uses both ports, as shown in Figure 7:

Figure 7) Multiplexing mode.

SnapMirror multipathing with different types and speeds of networks is supported without adversely affecting replication performance on the faster ports. Communication occurs on both ports because an intercluster LIF is assigned to each port. If a port fails, the LIF that was on the failed port moves to another surviving port in that LIF’s failover group. Depending on the number of ports in the failover group, multiple LIFs can now share a port.

Figure 8) LIF failover in multiplexing mode.

Best Practice

Create two intercluster LIFs and assign one LIF to each port. Make sure that each LIF failover policy is configured to use the LIFs failover group, which contains the necessary ports to allow failover.

Switch-Based Link Aggregation for Multipathing

The intercluster LIF can be assigned to any kind of port in the system, including a logical port such as an ifgrp. An ifgrp supports switch-based link aggregation. Multiple physical ports can be configured into an ifgrp, and then the intercluster LIF can be assigned to that ifgrp port. The switch ports can then be combined using link-aggregation technology as a method of providing multipathing and/or redundancy.

Switch-based link aggregation does not guarantee that multiple physical paths in the ifgrp are used simultaneously. For example, assume that a single intercluster LIF is configured on both the source and destinations nodes. Therefore, each node has one IP address to use for intercluster communication and a two-port ifgrp. If the ifgrp is using an IP hash-based method of load balancing, then there is only one pair of source and destination IP addresses on which to perform the load balancing hash. The link might place all connections between these two nodes on the same path within that port group.

Keep in mind that replication can take place between multiple nodes. For example, one node might replicate different volumes to different nodes in the remote cluster. Each node has different intercluster LIFs, which have different pairs of source and destination IP addresses that enable multiple paths within the link to be used for that source node.

If switch-based link aggregation is used to allow multiple physical paths in the ifgrp to be used when replicating between two nodes, additional intercluster LIFs can be configured on either of the two nodes. ONTAP automatically establishes a connection between every LIF on the source and destination node for SnapMirror. This approach provides additional combinations of source and destination IP addresses for the load-balancing hash, which could be placed on different paths within the link. However, in this example the purpose of configuring multiple LIFs on one node is to enable multiple paths to be used for replication between any two nodes. This precaution is likely not necessary in many WAN replication scenarios because WAN bandwidth might be significantly less than the bandwidth of the combined links in the ifgrp. Enabling multiple paths between two nodes might not be beneficial, because many nodes must share the WAN bandwidth anyway.

Best Practice

When using switch-based link aggregation, create the ifgrp with multimode_lacp mode and set the distribution function of the ifgrp to port. Using the port value for the distribution function configures the ifgrp to distribute connections across paths by hashing the source/destination IP address, as well as the port used. This practice does not guarantee that connections are evenly distributed across all paths in the ifgrp, but it does allow use of multiple physical links in the ifgrp.

2.4 Network Connections for Intercluster SnapMirror

In ONTAP, the number of intercluster LIFs determines the number of TCP connections established between the source and destination nodes for SnapMirror. TCP connections are not created per volume or per relationship.

ONTAP establishes at least 12 intercluster TCP connections for sending data, as shown in Figure 9. This is true even if both the source and destination nodes have only one intercluster LIF and enough connections are created so that all intercluster LIFs on both the source and destination nodes are used.

Figure 9) TCP connections with one intercluster LIF.

If the source node, destination node, or both nodes are configured with two intercluster LIFs, then ONTAP establishes 12 TCP connections for sending data. However, instead of both connections using the same LIFs, one connection uses one LIF pair, and the other connection uses the other LIF pair, as shown in Figure 10. This example shows different combinations of intercluster LIFs that produce 12 intercluster TCP connections.

Note: It is not possible to select a specific LIF pair to use for a certain TCP connection. They are

managed automatically by ONTAP.

Figure 10) TCP connections with two intercluster LIFs.

Best Practice

Although it is not required, the same number of intercluster LIFs can be configured on both the source and destination nodes for operational consistency. Multiple intercluster LIFs can be created to enable active-active multipathing across multiple physical paths.

For example, if a node is configured with four 1 Gigabit Ethernet (GbE) ports for intercluster replication, then four intercluster LIFs are required, one assigned to each port to make sure all paths are used to provide bandwidth beyond just one GbE link.

2.5 Share or Dedicate Ports?

You can use dedicated ports for intercluster communication, or share ports used by the data network. Configuring intercluster LIFs to use dedicated data ports allows greater bandwidth than using shared data ports. Although configuring intercluster LIFs to share data ports enables you to use existing data ports, it does not physically isolate this network from the clients. If configured this way, the administrator should take care that routing rules or data center firewalls (external to the cluster) are set up such that general clients cannot reach the IP addresses used on the intercluster LIFs or view the intercluster traffic.

There are several configurations and requirements to consider when determining whether to share or dedicate ports for replication. They include the following:

 LAN type. If you have a high-speed network, such as 10GbE, 25GbE, 40GbE, and 100GbE, you

might have enough local LAN bandwidth to perform replication using the same 10GbE ports used for data access. You should compare your available WAN bandwidth to your LAN bandwidth. If the available WAN bandwidth is significantly less than 10GbE, you might be limited to the network utilization that the WAN can support.

 Available WAN bandwidth (compared to LAN bandwidth). The WAN can act as a throttle if there

is significantly less available WAN bandwidth than LAN bandwidth. If the available WAN bandwidth is significantly less than 10GbE, you might need to use dedicated ports.

Note: The one exception to this rule might be when all or many nodes in the cluster replicate data,

in which case bandwidth utilization is typically spread across nodes.

 Replication interval. Consider how your available bandwidth will handle the level of client activity

during the replication interval. Replication during nonproduction hours might have an irrelevant effect on the data network. If replication takes place in off-peak hours, you should be able to use data ports for replication, even without a 10GbE LAN connection. However, if replication takes place during normal business hours, you need to consider the amount of data to be replicated and whether it requires so much bandwidth that it could cause contention with data protocols. If network utilization by data protocols (SMB, NFS, or iSCSI) is above 50%, then you should use dedicated ports for intercluster communication to allow for nondegraded performance if node failover occurs.

 Change rate. Consider the amount of data to be replicated in each interval and whether it requires so

much bandwidth that it could cause contention with data protocols for shared data ports. If you use the peer relationship for replication and replication is set to occur only when minimal to no client activity occurs, you might be able to use data ports for intercluster replication successfully, even without a 10GbE LAN connection.

 Number of ports. If you determine that replication traffic is interfering with data traffic, you can

migrate intercluster LIFs to any other intercluster-capable shared port on the same node. You can also dedicate VLAN ports for replication. The bandwidth of the port is shared between all VLANs and the base port. However dedicating ports for replication require additional switch ports and cable runs.

Note: If you decide to dedicate ports for intercluster communication, it is a best practice to configure

at least two intercluster ports per node. An intercluster LIF cannot fail over to a port on a different node; its failover group contains only intercluster-capable ports on the same node. If you use intercluster ports, ONTAP uses only intercluster ports in the failover group for an intercluster LIF. Therefore, if you use intercluster ports, you should configure at least two intercluster ports per node so that there is a port to which the intercluster LIF can fail over.

Note: If you are not using dedicated ports, the maximum transmission unit (MTU) size of the

replication network should typically be the same as the MTU size of the data network.

Best Practice

 If the network utilization generated by the data protocols (CIFS, NFS, or iSCSI) is above 50%, then

you should dedicate ports for intercluster communication to allow for nondegraded performance if a node failover occurs.

2.6 Firewall Requirements

SnapMirror uses the typical socket, bind, listen, and accept sequence on a TCP socket. The firewall and the intercluster firewall policy must allow the following protocols:

 TCP to the IP addresses of all the intercluster LIFs over the ports 10000, 11104, and 11105. Data

ONTAP uses port 11104 to manage intercluster communication sessions and port 11105 to transfer data.

 Bidirectional HTTPS between the intercluster LIFs.  Although HTTPS is not required when you set up cluster peering using the CLI, HTTPS is required

later if you use ThinkSystem Storage Manager for DM Series to configure DP.

2.7 Licensing

You must purchase and enable a SnapMirror license. If the SnapMirror source and destination are on different systems, you must enable a SnapMirror license on each system.

Note: You can use a SnapMirror license to enable SnapVault® technology without the need for a

separate SnapVault license.

A DP_Optimized (DPO) license, which enables SnapMirror protection for increased numbers of volumes and peer relationships, is required on both the source and destination depending on the platform. A DPO license is also available as a tiered license or a standalone license for ONTAP secondary clusters.

Note: A DPO license allows you to scale up to 2,500 FlexVol volumes per node or 5,000 FlexVol

volumes in failover mode.

3 Lenovo replication basics

3.1 SnapMirror Technology

SnapMirror replicates data from a source FlexVol or FlexGroup volume to a destination cluster by using Snapshot copies. SnapMirror performs the following operations:

1. A Snapshot copy of the data on the source is created.

2. The Snapshot copy is copied to the destination during baseline synchronization. This process creates a destination that is online, read-only, and contains the same data as the source at the time of the most recent update.

3. The destination is updated to reflect incremental changes on the source according to the schedule you specify.

 Intercluster LIFs are node scoped (they only fail over to other ports on the same node). Therefore,

use a naming convention for intercluster LIFs that includes the node name followed by ic or icl for the intercluster LIF: for example, node_name_icl# or node-name-ic#, depending on your preference.

 Verify that all relevant ports have access to the necessary networks or VLANs to allow

communication after port failover.

 As intercluster LIFs become available or unavailable, the list of active IP addresses can change.

The discovery of active IP addresses is automatic in certain events, such as when a node reboots. The –peer-addrs option requires the provision of only one remote cluster address. However, if the node hosting that address is down and becomes unavailable, then the cluster peer relationship might not be rediscovered. Therefore use at least one intercluster IP address from each node in the remote cluster, so that the peer relationship remains stable in the event of a node failure.

+ 39 hidden pages