EMC Celerra Version 5.6 Technical Primer: SLA-Driven Replication with Celerra Replicator (V2) Technology Concepts and Business Considerations

Transcription

1 EMC Celerra Version 5.6 Technical Primer: SLA-Driven Replication with Technology Concepts and Business Considerations Abstract This white paper is an overview of the new SLA-driven Celerra Replicator (V2) feature available in EMC Celerra version 5.6. The intent of this paper is to familiarize the audience with the features, capabilities, and limitations of this powerful new functionality, which helps businesses meet real-world requirements for disaster recovery, content distribution, migration, and numerous other services. July 2008

2 Copyright 2008 EMC Corporation. All rights reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com All other trademarks used herein are the property of their respective owners. Part Number H5604 Technology Concepts and Business Considerations 2

3 Table of Contents Executive summary...4 Business problem... 4 Technical problem... 4 Feature introduction... 5 What s new... 6 Introduction...6 Audience... 6 Terminology... 6 Detailed overview...8 Architecture... 8 Celerra SnapSure... 9 Adaptive scheduler Data Mover interconnect Bandwidth throttling Alternative destination object initialization Advanced topologies: One-to-many and cascaded replication Alerting Application consistency for iscsi replicas Best practices...16 Best practices for sizing with file system and VDM replicas Best practices for sizing with iscsi LUN replicas Upgrades Limitations Compatibility with older releases...19 Conclusion...19 References...20 Technology Concepts and Business Considerations 3

4 Executive summary Celerra Replicator version 2 (V2) is the completely redesigned replication technology in Celerra version 5.6 that delivers powerful new capabilities that are both easy to use and groundbreaking in performance and scale. With its new adaptive scheduling technology, responds to changing environmental conditions by dynamically allocating resources to ensure that objects are replicated in compliance with their customer-configurable recovery point objectives (RPOs). This direct alignment to business recovery point and recovery time objectives eases the administrative burden of replication by leveraging system intelligence and accuracy to ensure that business-critical data automatically remains available and synced within the RPO at the recovery site. Business problem Information systems are the strategic backbone of corporate IT infrastructure and critical in the ongoing operation of most businesses. There is no tolerance for downtime or system unavailability in these systems because downtime usually equates to loss of revenue and/or lost productivity. This sets a high bar for IT organizations tasked with delivering business-critical information systems recovery services. While system availability may be highly desired, there are constraints that make it difficult to realize. For instance, financial constraints may limit expenditures for dedicated data center infrastructure or personnel. System bandwidth for backup or replication may be limited during peak business hours, impeding the ability to move all data to remote sites for processing or protection. System maintenance and upgrades may inadvertently bring the system down, causing an indeterminate outage. In short, the real world introduces real constraints, and success must be obtained within those constraints. Technical problem Disaster recovery is the ultimate test of any information protection plan it requires bringing users back online after a disaster with minimal service disruption and in accordance with promised service levels. Preparing to meet this challenge can be particularly difficult given the often unpredictable rate at which new data is generated and the limited capability of most replication tools available today. Most of today s replication tools offer the storage administrator limited options when trying to align disaster recovery plans to the recovery needs of the business. In most cases these options include timebased or size-based rules that, when met, trigger a replication transfer. Unfortunately, these rules do not align directly to the RPO, which is a measure of data as described by time. In other words, the RPO is not a simple measure of data bytes, so size-based replication scheduling ( transfer after every 50 MB change ) does not ensure that the RPO will be met. Likewise, the RPO is not just a measure of time, so time-based rules like transfer every 10 minutes also do not ensure that the RPO will be met. Even policies that combine both time and size, like transfer after every 50 MB change OR every 10 minutes, do not ensure that the RPO will be met. Unless size is taken into account within the context of time, then there is no guarantee that the transfer will fully complete on time, resulting in a missed RPO. Because an RPO is a measure of data as described by time, data size and elapsed time need to be considered together and analyzed within the context of network conditions in order to most effectively manage transfer execution. This innovative approach delivers intelligent, adaptive scheduling decisions automatically, ensuring that any data changes (delta set) will not only begin, but also finish transferring before the RPO is violated. Technology Concepts and Business Considerations 4

5 Feature introduction represents a new generation of replication technology, utilizing adaptive replication technology to optimize replication performance and quality of service in accordance with set RPO levels, which can be set for each replication session. This adaptive replication approach empowers the business to focus on deciding how many minutes of data loss is acceptable in a disaster recovery event (the RPO), while automatically attempts to achieve that RPO by intelligently taking into account changes in network transfer rates. Further highlights include: Scalability Up to 1,024 replication sessions, up to 256 active (transferring) replication sessions, and up to 16 initialization replication sessions per Data Mover. Replication from a single storage object to up to four different destinations, and the ability to cascade the replication from each of the four destination objects to as many as three additional destinations yielding a net 16 replicas per source object while enabling each replica to be governed by its own RPO. Performance Adaptive, RPO-based replication scheduling: Set your desired RPO and optimizes your replication sessions continually. Administrative operations (create session, delete session, failover session, and others) are extremely fast. One-click switchover and reverse: This new operation provides a simple method to turn the destination object into production with no data loss, with optional reversal of the replication direction. Failover commands may be issued in parallel. Loopback replication is extremely fast and bypasses the network for a purely disk-to-disk copy. Ease of use Single interface configuration: One simple and intuitive management model to configure all replica types (file system, iscsi LUN, VDM) through your choice of either the Celerra Manager or the CLI. A new graphical wizard to further streamline the replication creation process. Continued integration with EMC Replication Manager for application-consistent iscsi LUN replicas. Automatic creation of destination file systems and VDMs. New alerting mechanisms to help notify the administrator when network or other problems are interfering with replication. Functionality Multiple replication modes: Remote, Local (intra-cabinet), and Loopback (intra-data Mover) replicas. One-time copy tool. New Data Mover interconnects carry data as well as control information. Flexible bandwidth throttling: Reduces network usage during times of peak demand by slowing replication according to configurable policies. Disaster Recovery Auditing (Testing): Disaster recovery auditing/testing with Celerra Replicator (V2) can be easily performed using a variety of methods that cater to different test objectives including switchover, failover, and copy operations and the ability to create a read-write checkpoint on the destination file system. Technology Concepts and Business Considerations 5

6 In summary, represents a leap forward in the area of information protection. It delivers more value to storage administrators and helps them attain their ultimate goal of service level delivery by easing administration and working to meet their RPOs automatically. At the same time, it delivers groundbreaking scalability and flexibility to help the storage administrator do more with less. What s new is entirely new in Celerra version 5.6. Architected around the data store s RPO, brings all replicated objects Celerra file systems, iscsi LUNs, and Virtual Data Movers (VDMs) within the same replication architecture and lets them all be managed under the same management interface with common semantics. Introduction This white paper introduces the new SLA-driven, adaptive functionality in Celerra Network Server version 5.6. It covers the following: Business and technical drivers behind replication Overview of Basic technical description of the architecture, including: RPO-based adaptive scheduler Network bandwidth (QOS) controls Alternate initialization methods Replicating a single object to up to four destinations with one-to-many replication Cascaded replication topologies Best practices Limitations of Audience This white paper is intended for customers, including IT planners, storage architects and administrators, and any others involved in evaluating, acquiring, managing, operating, or designing an EMC networked storage environment. Terminology Automatic Volume Management (AVM): A feature of the Celerra Network Server that creates and manages volumes automatically without manual volume management by an administrator. AVM organizes volumes into storage pools that can be allocated to file systems. Checkpoint: A read-only, logical, point-in-time image of a file system (PFS). A checkpoint is sometimes referred to as a checkpoint file system, a snap, or a SnapSure file system. Data Access in Real Time (DART): On a Celerra system, the operating system software that runs on the Data Mover. It is a real-time, multithreaded operating system optimized for file access, while providing service for standard protocols. Data Mover: A Celerra Network Server cabinet component running its own operating system that retrieves files from a storage device and makes them available to a network client. This is also referred to as a blade. A Data Mover is sometimes internally referred to as DART because DART is the software running on the platform. Technology Concepts and Business Considerations 6

7 Destination File System (DFS): A destination object that is of the file system type. Destination Object (DO): The target (possibly remote) Celerra Network Server object in a Celerra Replicator (V2) session. It may be a file system, VDM, or iscsi LUN depending upon the type of the source object. The destination object is typically the standby side of a disaster recovery configuration. Initialization: The process of performing a full copy from a point-in-time view of the production object to the destination object. This full copy, sometimes referred to as silvering, enables Celerra Replicator to keep the destination object within the RPO by performing subsequent differential copies as needed. Production File System, or Primary File System (PFS): A production object that is of the file system type. Production Logical Unit, or Production LUN (PLU): An iscsi LUN that serves as a primary (production) storage device. A PLU can be configured as a disk device through an iscsi initiator. Production Object, or Primary Object (PO): A Celerra object where production data is stored and the source object in a replication session. It may be a file system, VDM, or iscsi LUN. Refresh: A checkpoint operation that discards the checkpoint s previous point-in-time view and replaces it with the current point-in-time view of the PFS. In the context of, it also includes a subsequent transmission of the data that changed since the last refresh operation. Replica: An exact point-in-time copy of a production object. Recovery Point Objective (RPO): The amount of data, measured in units of time, which may be lost in a failure. This value represents a target, and it may be influenced by the RTO, SLA, and business impact analysis. Recovery Time Objective (RTO): The length of time a business process can be unavailable before the consequences are unacceptable. This value represents a target and is typically the result of a business impact analysis. Service Level Agreement (SLA): A contract or agreement that formally defines the level of service expected or required along various lines of attributes. It may include the maximum acceptable downtime and the maximum acceptable disaster recovery parameters (RTO and RPO). Secondary File System (SFS): See Destination File System. This term was used in Celerra Replicator V1, and is now deprecated. Snap: See Snapshot. Snapshot: A generic term for a point-in-time copy of data. In Celerra, a point in time of an iscsi LUN is called a snap or snapshot, and a point-in-time copy of a file system is typically called a checkpoint although the generic term of snap or snapshot can also be used. SnapSure: A feature that provides read-only point-in-time views, known as checkpoints, of a PFS. SnapSure for iscsi: A feature that provides read-only point-in-time views, known as snapshots, of an iscsi PLU. SnapSure SavVol: As used in SnapSure Checkpoints and, a Celerra volume to which SnapSure copies original point-in-time data blocks from the PFS before the blocks are altered by a transaction. SnapSure uses the contents of the SavVol and the unchanged PFS blocks to maintain a checkpoint of the PFS. As used in Celerra Replicator (V1), it is a Celerra volume, required by replication, Technology Concepts and Business Considerations 7

8 used to store modified data blocks from the source file system. A dedicated replication SavVol is no longer used with which uses the SnapSure checkpoint SavVol. Source Object: See Production Object. Virtual Data Mover (VDM): A Celerra software feature enabling users to administratively separate CIFS servers, replicate their CIFS environments, and move servers from Data Mover to Data Mover. Detailed overview is architected around the concept of the recovery point objective (RPO). The RPO, in a nutshell, is how much data (measured in units of time) a business can lose before the consequences of the loss are unacceptable. Not all data is equivalent, so each data store, be it a file system, VDM, or iscsi LUN, may have its own RPO. This section will look at s architecture, including the way is designed to make meeting the RPO effortless. Architecture has several internal architectural components that enable it to provide its industryleading intelligent and efficient replication functionality. While knowledge of its internal architecture isn t required to realize its value, it may be helpful or interesting to have a conceptual understanding of the mechanics. This section outlines the primary purpose and architecture of each major architectural component, including: Celerra SnapSure: The operational foundation of Adaptive scheduler: The RPO-based decision maker behind Data Mover interconnect: The new Data Mover-to-Data Mover communication pipe that carries both data and control information Bandwidth throttler: The mechanism to limit s bandwidth usage on the Data Mover interconnect during selected time periods In addition, this section will cover the important concepts of: Alternate destination object initialization The alternative mechanisms for initializing large destination objects Advanced topologies One-to-many and cascaded replication Alerting Mechanisms that allow you to ensure that RPOs are not being violated Technology Concepts and Business Considerations 8

9 Celerra SnapSure is built upon EMC SnapSure technology. uses SnapSure to capture and track changes between incremental transfers. Figure 1 shows the position of Celerra Replicator (V2) relative to SnapSure in the DART I/O stack. CIFS, NFS, FTP requests CIFS Network File Protocols FTP File System Celerra Replicator Celerra SnapSure Volume Manager NFS Figure 1. and Celerra SnapSure in relative positions in the I/O stack of the Data Mover When a replication session is first created as shown in Figure 2, the following events occur: Source (Production) File System or VDM Destination File System or VDM 1 2 7:30 7:30 3 7:30 Checkpoint 1 Checkpoint 2 Checkpoint 1 Checkpoint 2 Source (Production) iscsi LUN Destination (Production) iscsi LUN 1 2 8:25 8:25 Snap 1 Snap 2 3 8:25 Snap 1 Snap 2 Figure 2. Initialization of a newly created replication session 1. The system creates two internal checkpoints (for file systems and VDMs), or two snaps (for iscsi LUNs), for each source and destination object. 2. A full copy of the source object is made to the destination object. Data is read from a checkpoint of the source object and transferred directly into the destination object. This process is called initialization. 3. When initialization completes, the system refreshes a checkpoint at the destination site. The destination checkpoint and the source checkpoint form what is known as the common base. The common base is simply a common point-in-time view a time for which both the source and the destination have exactly the same data object view. Technology Concepts and Business Considerations 9

10 4. Once the common base has been created, ongoing replication begins. The Scheduler periodically determines when a new transfer of outstanding changes is needed based upon the specified RPO, transferring all unique changes that have come into the production object since the last transfer was initiated. An efficiency achieves by leveraging SnapSure is that if user-created checkpoints/snaps (manual or scheduled) exist, then the storage required by to store these changes is likely to be very small if any. Utilizing SnapSure, is able to determine which blocks have changed since the last transfer, and ensure a consistency point on the destination that can be leveraged if for any reason the incremental copy is prevented from completing. The consistency point can be used to restart incremental transfers or to provide a consistent destination object when disaster recovery failover is required. When a replication refresh is executed, either manually or by the Adaptive Scheduler as shown in Figure 3, the following events occur: Source (Production) File System or VDM Destination File System or VDM 1 Δ 7:30 (cb) 8:15 Checkpoint 1 Checkpoint :15 7:30 (cb) 8:15 Checkpoint 1 Checkpoint 2 Source (Production) iscsi LUN Destination (Production) iscsi LUN 1 2 8:31 Δ 8:25 (cb) 8:31 3 8:25 (cb) 8:31 Snap 1 Snap 2 Snap 1 Snap 2 Figure 3. Transfer refresh operation 1. If there is an ongoing transfer from the production object, the system waits (queues the refresh operation) until it completes. (Note: "(cb)" means "common base". The Greek delta symbol Δ represents the difference or delta set between the two checkpoints or snaps.) 2. Celerra refreshes the internal replication checkpoint that is not the common base. 3. Celerra transfers the difference between the common base and this second (newly refreshed) checkpoint. In other words, transfer any changes that were made to the production object since the point in time at which the last transfer was initiated. This is a block-based transfer, and only one copy of each block is transferred. (If a single block had been written multiple times, only the last write is transferred.) 4. After the transfer is complete, the destination object looks just like the point in time that is reflected in the newer checkpoint (not the common base) on the source. The system refreshes the second checkpoint on the destination, and now the old common base will be voided and the newer checkpoints on the source and destination become the common base. Technology Concepts and Business Considerations 10

11 5. Repeat when the next refresh is requested, or when the scheduler determines a refresh is necessary. Some architectural details within this process are worth noting. First, because is based on SnapSure technology, the change sets are stored in either the checkpoint SavVol (for file system or VDM replication) or in the Celerra file system (for iscsi LUN replication). While V1 for file system and VDM replication had relied upon a second SavVol (devoted to replication), that is no longer the case for V2, which shares the checkpoint SavVol to achieve improved storage efficiency. Second, during file system or VDM replication when changes are transferred from the source to the destination, Celerra Replicator V1 transferred those changes into a destination replication SavVol and then replayed them into the destination object. V2 is simpler and more efficient it is a one-step process with a transfer directly into the destination object. No playback takes place, and only one SavVol is needed on the destination object and this SavVol is used for both replication and checkpoints. For more on SnapSure checkpoints see the Using SnapSure on Celerra technical module. Also, the Configuring iscsi Targets on Celerra technical module provides more information on SnapSure for iscsi snapshots. Adaptive scheduler Unlike competing replication technologies, is configured only with an RPO that specifies a time within which the source and destination must be kept in sync. This RPO may be as small as 1 minute and as large as 1,440 minutes (24 hours) 1. automatically and transparently attempts to keep the destination object within the limits of its specified RPO amid changing environmental conditions. To accomplish this, the adaptive scheduler uses two key pieces of information to determine the appropriate time to begin a new transfer (also referred to as a refresh or sync). They are: The amount of change (delta set) that has built up in the production object since the last transfer The average transfer rate that was observed the last time a transfer for this production object. This average transfer rate is recalculated at the completion of every transfer for the production object. Using this information the scheduler (which runs at least every 10 seconds) predicts when a transfer completes, and based on that prediction decides whether or not to begin the transfer. A key goal of is to not transfer too often since transfers consume system resources that could be used for other purposes. s scheduler attempts to optimize the transfer scheduling so that transfers take place only when necessary. Note that the adaptive scheduler also builds in a small buffer to help account for the possibility that data transfer rates may decrease slightly on the next transfer. It does this effectively by using an RPO in its calculations that is slightly shorter than the RPO that has been specified. This helps the scheduler to ensure accuracy even in an imperfect environment. 1 The default RPO in Celerra Manager is 10 minutes for file system and iscsi LUN replicas, and 5 minutes for VDM replicas. While the use of smaller RPOs is possible it should be done with care to apply the smaller RPOs only to the most critical replication objects because a smaller RPO will result in more frequent refreshes and each refresh consumes system resources. Likewise, extremely large RPOs should only be used with the least critical data since it requires to predict network conditions and could increase the chance of an RPO violation. Technology Concepts and Business Considerations 11

12 Data Mover interconnect does not require an ongoing connection between source and destination Control Stations for its normal operation as shown in Figure 4. All data and control commands are sent over a new connection between the source Data Mover and the destination Data Mover called the Data Mover interconnect. This is a secured (password protected) channel that may contain multiple network interfaces. It is a directional interconnect so each pair of Data Movers will have two interconnects configured one for each direction. A connection between source Control Station and destination Control Station is needed only at the time the Data Mover interconnect and replication sessions are configured; all other operations are sent over the Data Mover interconnect. Celerra Celerra Internal network Control Station Data Mover Data Mover Interconnect 5.6 Control & Data Path Control Station Data Mover Internal network Data Mover Data Mover Figure 4. 's Data Mover interconnect that carries both data and control information between Data Movers Bandwidth throttling allows the bandwidth it uses to be controlled during specified time periods throughout the week. This is most useful in environments where must share networks and bandwidth with other applications. For example, if shares networks with users and the Celerra provides home directories over these same networks then spikes in network utilization may occur during the day when users log in to their systems or store files to their home directories. To avoid taking the maximum possible bandwidth during peak times, an administrator can configure to temporarily limit the bandwidth it uses. Bandwidth usage schedules are completely custom; the Celerra administrator specifies which days, which hours, and what bandwidth during those hours to allocate as shown in Figure 5. A default maximum bandwidth can also be specified for periods that are not specifically covered by a schedule. There is, by default, no maximum bandwidth. Technology Concepts and Business Considerations 12

13 Figure 5. Creating a custom bandwidth schedule in. This screenshot has been taken from the Replication wizard within the Celerra Manager graphical user interface Bandwidth control policies are applied to the Data Mover interconnect with each interconnect having one set of policies. sessions that use the same Data Mover interconnect are all subject to the bandwidth policies for that interconnect. Alternative destination object initialization Initializing the destination object can take a long time when the source object has a large amount of data on it and the network throughput to the destination is constrained. It is for this reason that Celerra Replicator (V2) supports the initialization of destination file systems using alternative mechanisms. Specifically, destination file systems may be initialized from tape or from a third Celerra (a swing box ) that is transported to the destination. If the destination Celerra is not used for production, then it is possible to eliminate the swing box by transporting the destination Celerra to the source site where it can be directly initialized and then transported back to the remote site. Advanced topologies: One-to-many and cascaded replication enables you to create as many as 16 replicas of a single source object using two advanced topologies: one-to-many and cascaded. These configurations allow you to build out your replication infrastructure in powerful new topologies. In a one-to-many replication, a single source object may be replicated to multiple destinations as shown in Figure 6. Each replication destination object uses a separate and independent replication session with its own RPO, so it is possible to assign priorities to sites by using larger RPOs for the less critical sites than for the most critical sites. In Celerra version 5.6, up to four replicas can be created from a single source object in this topology. Technology Concepts and Business Considerations 13

14 Shanghai Bangkok Chicago WAN London Moscow Figure 6. One-to-many replication. Up to four destinations supported Another possible topology is the cascaded topology the replication of one (intermediate) destination to another destination as shown in Figure 7. In this topology you have an object that is both a destination and a source for replication. As with the one-to-many topology, each hop uses a separate and independent replication session with its own RPO that allows prioritization of sites. In a cascaded topology the incoming replication session (from the production object) counts toward the perobject limit of four replication sessions, which leaves three sessions available for replicating to secondary destinations. It is not uncommon to see a higher RPO used for the second hop. In Celerra 5.6, two hops (A B C) are supported and those hops may be loopback, local to another Data Mover, or remote. Chicago WAN London WAN Moscow Figure 7. Cascaded replication topology. Up to two hops supported allows the use of a one-to-many topology along with a cascade topology as shown in Figure 8. This allows you to create up to 16 replicas of a single source object. Again, each destination uses its own replication session and has its own RPO, which may be the same as or different than the RPO of the other sessions. Technology Concepts and Business Considerations 14

15 Sydney Shanghai Bangkok Mumbai Chicago WAN London WAN Moscow Cairo Phoenix Brasília Seattle Mexico City Figure 8. Combining a one-to-many topology with a cascaded topology to produce a cascade-to-many topology. As many as 16 replicas of one source object may be created with this topology When architecting with these topologies the general rule of thumb is that only four replication sessions are allowed per object, including all incoming and outgoing sessions. At most one incoming session is allowed, so in a cascade-to-many topology three sessions per intermediate destination are available for replicating on a second hop. Alerting includes the ability to register for or SNMP alerts sent in the event that a replication session s RPO is violated. Several factors could cause such a violation, including loss of network connectivity, significant loss of bandwidth, and the simultaneous triggering of more than 256 replication transfers, in which case only 256 per Data Mover will be allowed concurrently and the remainder will be queued. An RPO violation will be noted by, which will automatically work to bring the replication session back within the limits of the RPO. Application consistency for iscsi replicas EMC supports application consistency for iscsi LUN replicas through the use of EMC Replication Manager (RM) software (preferably version or later). When using RM to manage iscsi replicas the adaptive scheduler will not control replication refresh. Instead, RM will manually refresh the replica from the host at the specified interval. Technology Concepts and Business Considerations 15

16 Best practices This section describes a few best practices for. This section is not intended to be a comprehensive, detailed list of all best practices: Ensure sufficient throughput As with all IP replication technologies, you should ensure adequate throughput is available between the source and destination objects to handle the expected rate of change on your source object. Leverage VDMs for CIFS disaster recovery When replicating CIFS file systems (particularly for disaster recovery purposes) mount those CIFS file systems within VDMs and replicate the VDMs as well as the file systems. Test your disaster recovery plans using a risk-based approach When choosing disaster recovery test/auditing plans, evaluate the options based on the risk/impact to production data as well as on the ability to best simulate a disaster scenario. Typically, the best DR tests involve data loss (because a disaster can cause data loss), but that is usually undesirable for production data. Consider performing DR tests at least one to two times per year using a copy of your production data so that you can avoid production data loss and interruption to your production environment. The failover command should only be tested on copies of production data since it can result in data loss. To test disaster recovery using the actual production data, consider using the switchover or reverse commands (which prevent data loss) or a writeable checkpoint (or promoted iscsi snap) created on the destination object. Ensure that RPOs align to actual business needs Use replication RPOs that reflect your actual business needs for the data being replicated. In most cases, not all data has the same importance, so RPOs should vary among your replicated objects. Incremental transfers require system resources, so you want the frequency of transfers to be no higher than what is actually required by your business needs. Accept the default RPO for VDM replicas EMC recommends that you accept the default RPO of 5 minutes for VDM replicas. These replicas carry important information about the CIFS configuration (such as the secmap and other internal databases), so it is important to keep them within a fairly short sync window. Use of a smaller RPO may be warranted in some cases, but use of a larger RPO is not recommended for VDM replicas. Leverage the alerting facility EMC recommends that you use the alerting functionality to ensure the operation of your replications. If you find that RPOs are being violated frequently, you can then attempt to determine and fix the cause of the violations. If RPO violations cannot be fixed by implementing controls in the environment (such as network QOS measures), then address the situation by giving a smaller RPO than originally specified so that it samples network conditions more frequently and does not have to predict the network conditions as far out in time. That said, always start with the RPO required by your business needs and then reduce it only if necessitated by dynamic network conditions. Best practices for sizing with file system and VDM replicas, unlike the previous version, no longer requires a separate SavVol to store file system and VDM replication data. Because is built on Celerra SnapSure technology, it uses the SnapSure SavVol to store incremental changes and maintain a consistency point (common base). Under most circumstances, the SnapSure SavVol can be automatically extended to accommodate any additional space needed by. In the typical file system replication scenario where SnapSure is already in use to maintain user-created checkpoints of the file system (whether manual or scheduled), the amount of additional SavVol space consumed by will be little or none if the user-created checkpoints are maintained Technology Concepts and Business Considerations 16

17 for a period longer than two to three times the replication RPO. If SnapSure is not already in use on the PFS or the oldest user-created checkpoint is newer than two times the RPO, then the amount of storage needed by will be dependent upon the change rate in the source object and the length of the RPO. On the destination object the amount of storage needed by will be dependent upon the change rate in the source object and the length of the RPO. You may choose to let the system automatically manage the SnapSure SavVol for you, or you may manage it yourself. Whichever you choose, these are some best practices to follow: Understand your change rates In all IP replication scenarios, whether using or another IP replication technology, it is critical to understand your change rates. The amount of unique data change between transfers will determine not only how much storage you need to enable the replication but also how much throughput you need to enable the replication to transmit changes. Understand how long you will store your oldest checkpoint It is the oldest checkpoint that determines the maximum storage needs of SnapSure. The oldest checkpoint could be a internal checkpoint, but is more likely to be a usercreated (manual or scheduled) checkpoint. Once you know how long you will be storing your oldest checkpoint and your rate of unique data change in the PFS you can estimate the amount of SavVol storage needed by SnapSure. Use AVM to create the PFS AVM is optimized and well suited to most customer workloads. Unless you specifically need to manage file systems and volumes manually, it is recommended that you let AVM create the file system storage for you. Allow the system to manage VDM SavVols EMC recommends that the system always be allowed to manage the VDM SavVols. Enable SavVol auto-extension File system and VDM replication leverages file system SnapSure technology on the production object. SavVol auto-extension can help to ensure that the SavVol grows as your change rate or checkpoint retention time grows. Thus, EMC recommends that you allow the SavVol to grow automatically when necessary. If you manage the SavVol yourself, use due diligence If you choose to limit the growth of the SavVol or you completely disable SavVol auto-extension, then you will need to carefully analyze your change rates to ensure that enough space is available in the SavVol to store data for Celerra Replicator-created and user-created (manual or scheduled) SnapSure checkpoints. Make sure you include space for any writeable checkpoints that you wish to create. EMC recommends that you also include some extra capacity when planning your maximum SavVol size to allow for unanticipated spikes in the change rate on your PFS or network unavailability 2. Create the SavVol with the same type of storage as the PFS, and preferably on different spindles Although not required, try to use the same type of storage for the SavVol as you did for the PFS. Using slower storage for the SavVol may impact not only Celerra Replicator performance but also PFS performance. Putting the SavVol on different spindles than the PFS may benefit Celerra Replicator (V2) performance. Create the SavVol on the same backend system as the PFS EMC recommends that you use the same backend storage system for the SavVol as you did for the PFS. Because the SnapSure checkpoints and the PFS may share data, separating them onto different 2 When the network is unavailable the system cannot transmit changes. This may cause additional changes to accumulate in the SavVol until the network becomes available again and Celerra Replicator is able to transmit them to the destination. Technology Concepts and Business Considerations 17

18 storage systems means that if one of the storage systems becomes unavailable but the other does not, both the PFS and the SnapSure checkpoints will be affected even though they are on different backend systems. Keeping them together on the same backend system is best. The Using SnapSure on Celerra technical module provides more information on SnapSure concepts and space planning. Best practices for sizing with iscsi LUN replicas iscsi LUNs, including their snaps and replicas, do not store data in a SnapSure SavVol but instead store it in files within a Celerra file system. uses snaps of the iscsi PLU in the same way that it uses checkpoints of the PFS in file system replication. In the typical iscsi LUN replication scenario where SnapSure for iscsi is already in use to maintain snaps of the PLU (whether manual or scheduled), the amount of additional Celerra file system space consumed by will be little or none if the manually created or scheduled snaps are maintained for a period longer than two to three times the replication RPO. These are some best practices to follow for sizing file systems for iscsi LUN replicas: Understand your change rates In all IP replication scenarios, whether using or another IP replication technology, it is critical to understand your change rates. The amount of unique data change between transfers will determine not only how much storage you need to enable the replication but also how much throughput you need to enable the replication to keep up with your changes. With iscsi replication your changes will be in blocks of a size that is typically determined by the host operating system running the iscsi initiator. Consider the impact of mounted snaps in your calculations Mounted (promoted) snaps require a Temporary Writeable Snap (TWS) to capture writes to the snap. This TWS may be virtually provisioned (sparse) or dense. Whether the TWS is virtually provisioned or dense will affect storage requirements. Understand how long you will store your oldest snap It is the oldest snapshot that determines the storage maximum needs of unmounted (unpromoted) iscsi snaps, including internal snaps. Once you know how long you will be storing your oldest snap, the impact of mounted snaps, and your rate of unique data change in the PLU you can approximate the amount of file system storage needed by SnapSure for iscsi. Enable file system auto-extension when using virtually provisioned LUNs Because a virtually provisioned LUN may not have its storage fully allocated, enable auto-extension on the containing Celerra file system to ensure that space is available to allocate to the virtually provisioned PLU and its snaps. The Configuring iscsi Targets on Celerra technical module provides more information on SnapSure for iscsi concepts and space planning. Upgrades V1 and V2 of Celerra Replicator cannot coexist at the same time on a Celerra. Only one of them may be licensed at a time. An upgrade path is available for upgrading a V1 environment to V2. It will convert existing V1 sessions to V2 sessions without requiring re-initialization of the destination, and it will remove the V1 SavVols. This upgrade procedure is a complimentary support offering for Celerra Replicator (V1) licensees who are covered under maintenance agreements. Contact your support provider for more information on this upgrade path. Technology Concepts and Business Considerations 18

19 Limitations Note the following limitations in the Celerra version 5.6 release. currently supports one-to-many and cascaded topologies for file system and iscsi LUN objects. However, a maximum of four destination objects are allowed in the one-to-many topology. A VDM may be replicated to only one destination VDM at the time this paper was written, but EMC expects to offer VDM replication for one-to-many and cascaded topologies in the near future. Of the 1,024 configured sessions allowed per Data Mover, 256 can simultaneously be active (transmitting data). Sessions above 256 will be queued and wait until one of the 256 active sessions has completed. Each file system, iscsi LUN, and VDM session counts towards the supported number of sessions. If you have file systems or iscsi LUNs being initialized, only 16 of these initialization sessions can be running simultaneously per Data Mover. Any initialization sessions above 16 will be queued. Checkpoints and snaps cannot serve as the replication source. Only production objects can be replicated. There is no iscsi LUN tape silvering procedure in Celerra version 5.6. Because of a VDM s small size (128 MB), VDM tape silvering is not being considered. Compatibility with older releases Celerra Replicator (V1) and are mutually exclusive. You can only run one version or the other on a single Celerra, not both. Replication is only allowed between two systems whose major release numbers (U.V in U.V.X.Y) are the same. The build numbers (X.Y) may be different. Release Compatibility Comments 5.6.x Yes with restrictions may replicate to or from other 5.6.x Data Movers running. However, may not replicate to or from other 5.6.x Data Movers running V No cannot replicate to or from this version. 5.4 No cannot replicate to or from this version. 5.3 No cannot replicate to or from this version. Conclusion Storage system administrators can now meet their business s disaster recovery requirements with confidence using the new functionality. Just specify an RPO and the system will automatically meet the RPO by intelligently adapting to the ever-changing network conditions that are seen in the real world. Need more than one copy? No problem! Use the one-to-many and cascaded topologies to replicate a single object to up to 16 different destinations. Worried about the replication sessions causing congestion on the network during peak times? No problem! Use the bandwidth throttling capabilities of to control the total bandwidth available to on each Data Mover interconnect. Have a file system that is too large to perform a full copy over the network? No problem! Celerra Replicator (V2) provides the flexibility to choose the initialization method that is right for the conditions at hand. Technology Concepts and Business Considerations 19

20 In addition to making replication incredibly powerful yet very easy, provides a fast, convenient, one-time copy mechanism whether the copy is to the same Data Mover, a different Data Mover within the same Celerra, or a remote Celerra. Whatever your information protection and disaster recovery needs, Celerra can help you meet them more easily, more efficiently, and more accurately with the new world-class. References Name: Using Type: Technical Publication URL: See the 5.6 Celerra documentation CD (available at Audience: Customer Technical Depth: Medium Name: Using SnapSure on Celerra Type: Technical Publication URL: See the 5.6 Celerra documentation CD (available at Audience: Customer Technical Depth: Medium Name: Configuring iscsi Targets on Celerra Type: Technical Publication URL: See the 5.6 Celerra documentation CD (available at Audience: Customer Technical Depth: Medium Technology Concepts and Business Considerations 20