What is Business Continuity? ü Business Continuity is the preparation for, response to, and recovery from an application

outage that adversely affects business operations ü Business Continuity Solutions address systems unavailability, degraded application

performance, or unacceptable recovery strategies There are many factors that need to be considered when calculating the cost of downtime. A formula to calculate the costs of the outage should capture both the cost of lost productivity of employees and the cost of lost income from missed sales.

ü The Estimated average cost of 1 hour of downtime = (Employee costs per hour) *( Number of employees affected by outage) + (Average Income per hour).

ü Employee costs per hour is simply the total salaries and benefits of all employees per week, divided by the average number of working hours per week.

ü Average income per hour is just the total income of an institution per week, divided by average number of hours per week that an institution is open for business.

Recovery Point Objective (RPO) is the point in time to which systems and data must be recovered after an outage. This defines the amount of data loss a business can endure. Different business units within an organization may have varying RPOs. Recovery Time Objective (RTO) is the period of time within which systems, applications, or functions must be recovered after an outage. This defines the amount of downtime that a business can endure, and survive. Disaster Recovery versus Disaster Restart ü Most business critical applications have some level of data interdependencies ü Disaster recovery

– Restoring previous copy of data and applying logs to that copy to bring it to a known point of consistency

– Generally implies the use of backup technology – Data copied to tape and then shipped off-site – Requires manual intervention during the restore and recovery processes

ü Disaster restart – Process of restarting mirrored consistent copies of data and applications – Allows restart of all participating DBMS to a common point of consistency utilizing

automated application of recovery logs during DBMS initialization – The restart time is comparable to the length of time required for the application

to restart after a power failure. Elevated demand for increased application availability confirms the need to ensure business continuity practices are consistent with business needs. Interruptions are classified as either planned or unplanned. Failure to address these specific outage categories seriously compromises a company’s ability to meet business goals. Planned downtime is expected and scheduled, but it is still downtime causing data to be unavailable. Causes of planned downtime include:

ü New hardware installation/integration/maintenance ü Software upgrades/patches ü Backups ü Application and data restore ü Data center disruptions from facility operations (renovations, construction, other)

ü Refreshing a testing or development environment with production data ü Porting testing/development environment over to production environment

Today, the most critical component of an organization is information. Any disaster occurrence will affect information availability critical to run normal business operations. In our definition of disaster, the organization’s primary systems, data, applications are damaged or destroyed. Not all unplanned disruptions constitute a disaster. Business Continuity is a holistic approach to planning, preparing, and recovering from an adverse event. The focus is on prevention, identifying risks, and developing procedures to ensure the continuity of business function. Disaster recovery planning should be included as part of business continuity. BC Objectives include:

ü Facilitate uninterrupted business support despite the occurrence of problems. ü Create plans that identify risks and mitigate them wherever possible. ü Provide a road map to recover from any event.

Disaster Recovery is more about specific cures, to restore service and damaged assets after an adverse event. In our context, Disaster Recovery is the coordinated process of restoring systems, data, and infrastructure required to support key ongoing business operations. Business Continuity Planning (BCP) is a risk management discipline. It involves the entire business--not just IT. BCP proactively identifies vulnerabilities and risks, planning in advance how to prepare for and respond to a business disruption. A business with strong BC practices in place is better able to continue running the business through the disruption and to return to “business as usual.” BCP actually reduces the risk and costs of an adverse event because the process often uncovers and mitigates potential problems. The Business Continuity Planning process includes the following stages:

1. Objectives ü Determine business continuity requirements and objectives including scope and

budget ü Team selection (include all areas of the business and subject matter expertise

(internal/external) ü Create the project plan

2. Perform analysis ü Collect information on data, business processes, infrastructure supports,

dependencies, frequency of use ü Identify critical needs and assign recovery priorities. ü Create a risk analysis (areas of exposure) and mitigation strategies wherever

possible. ü Create a Business Impact Analysis (BIA) ü Create a Cost/benefit analysis – identify the cost (per hour/day, etc.) to the

business when data is unavailable. ü Evaluate Options

3. Design and Develop the BCP/Strategies ü Evaluate options ü Define roles/responsibilities ü Develop contingency scenarios ü Develop emergency response procedures ü Detail recovery, resumption, and restore procedures ü Design data protection strategies and develop infrastructure ü Implement risk management/mitigation procedures

4. Train, test, and document

5. Implement, maintain, and assess This is an example of Business Impact Analysis (BIA). The dollar values are arbitrary and are used just for illustration. BIA quantifies the impact that an outage will have to the business and potential costs associated with the interruption. It helps businesses channel their resources based on probability of failure and associated costs. Identifying Single Points of Failure

Configure multiple HBAs, and use multi-pathing software

Ø Protects against HBA failure

Ø Can provide improved performance (vendor dependent)

Planning and configuring clusters is a complex task. At a high level: ü A cluster is two or more hosts with access to the same set of storage (array) devices ü Simplest configuration is a two node (host) cluster ü One of the nodes would be the production server while the other would be configured as a standby. This configuration is described as Active/Passive. ü Participating nodes exchange “heart-beats” or “keep-alives” to inform each other about their health. ü In the event of the primary node failure, cluster management software will shift the production workload to the standby server. ü Implementation of the cluster failover process is vendor specific. ü A more complex configuration would be to have both the nodes run production workload on the same set of devices. Either cluster software or application/database should then provide a locking mechanism so that the nodes do not try to update the same areas on disk simultaneously. This would be an Active/Active configuration.

Local Replication: ü Data from the production devices is copied over to a set of target (replica) devices. ü After some time, the replica devices will contain identical data as those on the production

devices. ü Subsequently copying of data can be halted. At this point-in-time, the replica devices can

be used independently of the production devices. ü The replicas can then be used for restore operations in the event of data corruption or

other events. ü Alternatively the data from the replica devices can be copied to tape. This off-loads the

burden of backup from the production devices. Remote Replication: ü The goals of remote replication are the same as local replication except that data is

replicated to different storage arrays ü Storage arrays can be side by side or thousands of miles apart. ü If replicated to remote location, business can continue with little or no interruption and

little or no loss of data if primary site is lost. Backup Restore: ü Backup to tape has been the predominant method for ensuring data availability and

business continuity. ü Low cost, high capacity disk drives are now being used for backup to disk. This

considerably speeds up the backup and the restore process. ü Frequency of backup will be dictated by defined RPO/RTO requirements as well as the

rate of change of data. Powerpath: PowerPath is host-based software that resides between the application and the disk device layers. Every I/O from the host to the array must pass through the PowerPath driver software. This allows PowerPath to work in conjunction with the array and connectivity environment to provide intelligent I/O path management. This includes path failover and dynamic load balancing, while remaining transparent to any application I/O requests as it automatically detects and recovers from host-to-array path failures.

PowerPath is supported on various hosts and Operating Systems such as Sun- Solaris, IBM-AIX, HP-UX, Microsoft Windows, Linux, and Novell. Storage arrays from EMC, Hitachi, HP, and IBM are supported. The level of OS and array models supported will vary between PowerPath software versions.

PowerPath maximizes application availability, optimizes performance, and automates online storage management while reducing complexity and cost, all from one powerful data path management solution. PowerPath supports the following features: ü Multiple path support - PowerPath supports multiple paths between a logical device and a

host. Multiple paths enables the host to access a logical device, even if a specific path is unavailable. Also, multiple paths enable sharing of the I/O workload to a given logical device. ü Dynamic load balancing - PowerPath is designed to use all paths at all times. PowerPath

distributes I/O requests to a logical device across all available paths, rather than requiring a single path to bear the entire I/O burden. ü Proactive path testing and automatic path recovery - PowerPath uses a path test to ascertain

the viability of a path. After a path fails, PowerPath continues testing it periodically to determine if it is fixed. If the path passes the test, PowerPath restores it to service and resumes sending I/O to it. ü Automatic path failover - If a path fails, PowerPath redistributes I/O traffic from that path to

functioning paths. ü Online configuration and management - PowerPath management interfaces include a

command line interface and a GUI interface on Windows. ü High availability cluster support - PowerPath is particularly beneficial in cluster environments,

as it can prevent operational interruptions and costly downtime. Without PowerPath, if a host needed access to 40 devices, and there were four host bus adapters, you would most likely configure it to present 10 unique devices each host bus adapter. With PowerPath, you would configure it in a way to allow all 40 devices could be “seen” by all

four host bus adapters. PowerPath supports up to 32 paths to a logical volume. The host can be connected to the array using a number of interconnect topologies such as SAN, SCSI, or iSCSI. The PowerPath filter driver is a platform independent driver that resides between the application and HBA driver. The driver identifies all paths that read and write to the same device and builds a routing table called a volume path set for the device. A volume path set is created for each shared device in the array . PowerPath can use any path in the set to service an I/O request. If a path fails, PowerPath can redirect an I/O request from that path to any other available path in the set. This redirection is transparent to the application, which does not receive an error.

This example depicts how PowerPath failover works. When a failure occurs, PowerPath transparently redirects the I/O down the most suitable alternate path. The PowerPath filter driver looks at the volume path set for the device, considers current workload, load balancing, and

device priority settings, and chooses the best path to send the I/O down. In the example, PowerPath has three remaining paths to redirect the failed I/O and to load balance. A Backup is a copy of the online data that resides on primary storage. The backup copy is created and retained for the sole purpose of recovering deleted, broken, or corrupted data on the primary disk. The backup copy is usually retained over a period of time, depending on the type of the data, and on the type of backup. There are three derivatives for backup: disaster recovery, Archival, and operational backup. We will review them in more detail, on the next slide. The data that is backed up may be on such media as disk or tape, depending on the backup derivative the customer is targeting. For example, backing up to disk may be more efficient than tape in operational backup environments. Several choices are available to get the data written to the backup media. 1. You can simply copy the data from the primary storage to the secondary storage (disk or

tape), onsite. This is a simple strategy, easily implemented, but impacts the production server where the data is located, since it will use the server’s resources. This may be tolerated on some applications, but not high demand ones.

2. To avoid an impact on the production application, and to perform serverless backups, you can mirror (or snap) a production volume. For example, you can mount it on a separate server and then copy it to the backup media (disk or tape). This option will completely free up the production server, with the added infrastructure cost associated with additional resources.

3. Remote Backup, can be used to comply with offsite requirements. A copy from the primary storage is done directly to the backup media that is sitting on another site. The backup media can be a real library, a virtual library or even a remote filesystem.

4. You can do a copy to a first set of backup media, which will be kept onsite for operational restore requirements, and then duplicate it to another set of media for offsite purposes. To simplify thr procedure, you can replicate it to an offsite location to remove any manual procedures associated with moving the backup media to another site.

Disaster Recovery addresses the requirement to be able to restore all, or a large part of, an IT infrastructure in the event of a major disaster. Archival is a common requirement used to preserve transaction records, email, and other business work products for regulatory compliance. The regulations could be internal, governmental, or perhaps derived from specific industry requirements. Operational is typically the collection of data for the eventual purpose of restoring, at some point in the future, data that has become lost or corrupted. Reasons for a backup plan include: ü Physical damage to a storage element (such as a disk) that can result in data loss. ü People make mistakes and unhappy employees or external hackers may breach security and

maliciously destroy data. ü Software failures can destroy or lose data and viruses can destroy data, impact data

integrity, and halt key operations. ü Physical security breaches can destroy equipment that contains data and applications. ü Natural disasters and other events such as earthquakes, lightning strikes, floods, tornados,

hurricanes, accidents, chemical spills, and power grid failures can cause not only the loss of data but also the loss of an entire computer facility. Offsite data storage is often justified to protect a business from these types of events.

ü Government regulations may require certain data to be kept for extended timeframes. Corporations may establish their own extended retention policies for intellectual property to protect them against litigation. The regulations and business requirements that drive data as an archive generally require data to be retained at an offsite location.

Backup products vary, but they do have some common characteristics. The basic architecture of a backup system is client-server, with a backup server and some number of backup clients or agents. The backup server directs the operations and owns the backup catalog (the information about the backup). The catalog contains the table-of-contents for the data set. It also contains information about the backup session itself. The backup server depends on the backup client to gather the data to be backed up. The backup client can be local or it can reside on another system, presumably to backup the data visible to that system. A backup server receives backup metadata from backup clients to perform its activities. There is another component called a storage node. The storage node is the entity responsible for writing the data set to the backup device. Typically there is a storage node packaged with the backup server and the backup device is attached directly to the backup server’s host platform. Storage nodes play an important role in backup planning as it can be used to consolidate backup servers. The following represents a typical Backup process: ü The Backup Server initiates the

backup process (starts the backup application).

ü The Backup Server sends a request to a server to “send me your data”.

ü The server sends the data to the Backup Server and/or Storage Node.

ü The Storage Node sends the data to the tape storage device and the Backup Server begins building the catalog (metadata) of the backup session.

ü When all of the data has been transferred from the server to the Backup Server, the Backup Server writes the catalog to a disk file and closes the connection to the tape device.

Some important decisions that need consideration before implementing a Backup/Restore solution are shown above. Some examples include: ü The Recovery Point Objective (RPO) ü The Recovery Time Objective (RTO) ü The media type to be used (disk or tape) ü Where and when the restore operations will occur – especially if an alternative host will be

used to receive the restore data. ü When to perform backups. ü The granularity of backups – Full, Incremental or cumulative.

ü How long to keep the backup – for example, some backups need to be retained for 4 years, others just for 1 month

ü Is it necessary to take copies of the backup or not. Data Considerations: File Characteristics ü Location: Many organizations have dozens of heterogeneous platforms that support a

complex application. Consider a data warehouse where data from many sources is fed into the warehouse. When this scenario is viewed as “The Data Warehouse Application”, it easily fits this model. Some of the issues are:

− How the backups for subsets of the data are synchronized − How these applications are restored ü Size: Backing up a large amount of data that consists of a few big files may have less system

overhead than backing up a large number of small files. If a file system contains millions of small files, the very nature of searching the file system structures for changed files can take hours, since the entire file structure is searched.

ü Number: a file system containing one million files with a ten-percent daily change rate will potentially have to create 100,000 entries in the backup catalog. This brings up other issues such as:

− How a massive file system search impacts the system − Search time/Media impact − Is there an impact on tape start/stop processing? Data Considerations: Data Compression Many backup devices such as tape drives, have built-in hardware compression technologies. To effectively use these technologies, it is important to understand the characteristics of the data. Some data, such as application binaries, do not compress well. Text data can compress very well, while other data, such as JPEG and ZIP files, are already compressed. Data Considerations: Retention Periods As mentioned before, there are three types of backup models (Operational, Disaster Recovery, and Archive). Each can be defined by its retention period. Retention Periods are the length of time that a particular version of a dataset is available to be restored. Retention periods are driven by the type of recovery the business is trying to achieve: ü For operational restore, data sets could be maintained on a disk primary backup storage

target for a period of time, where most restore requests are likely to be achieved, and then moved to a secondary backup storage target, such as tape, for long term offsite storage.

ü For disaster recovery, backups must be done and moved to an offsite location. ü For archiving, requirements usually will be driven by the organization’s policy and regulatory

conformance requirements. Tapes can be used for some applications, but for others a more robust and reliable solution, such as disks, may be more appropriate.

Backup Methods: Backing up databases can occur useing two different methods:

ü A Hot backup, which means that the application is still up and running, with users accessing it, while backup is taking place.

ü A Cold backup, which means that the application will be shut down for the backup to take place.

Most backup applications offer various Backup Agents to do these kinds of operations. There will be different agents for different types of data and applications.

The granularity and levels for backups depend on business needs, and, to some extent, technological limitations. Some backup strategies define as many as ten levels of backup. IT organizations use a combination of these to fulfill their requirements. Most use some combination of Full, Cumulative, and Incremental backups. A Full backup is a backup of all data on the target volumes, regardless of any changes made to the data itself. An Incremental backup contains the changes since the last backup, of any type, whichever was most recent. A Cumulative backup, also known as a Differential backup, is a type of incremental that contains changes made to a file since the last full backup.

Following is an example of an incremental backup and restore:

1. A full backup of the business data is taken on Monday evening. Each day after that, an incremental backup is taken. These incremental backups only backup files that are new or that have changed since the last full or incremental backup.

2. On Tuesday, a new file is added, File 4. No other files have changed. Since File 4 is a new file added after the previous backup on Monday evening, it will be backed up Tuesday evening.

3. On Wednesday, there are no new files added since Tuesday, but File 3 has changed. Since File 3 was changed after the previous evening backup (Tuesday), it will be backed up Wednesday evening.

4. On Thursday, no files have changed but a new file has been added, File 5. Since File 5 was added after the previous evening backup, it will be backed up Thursday evening.

5. On Friday morning, there is a data corruption, so the data must be restored from tape. a. The first step is to restore the full backup from Monday evening. Then, every

incremental backup that was done since the last full backup must be applied, which, in this example, means the:

b. Tuesday, c. Wednesday, and d. Thursday incremental backups.

The following is an example of cumulative backup and restore:

1. A full backup of the data is taken on Monday evening. Each day after that, a cumulative backup is taken. These cumulative backups backup ALL FILES that have changed since the LAST FULL BACKUP.

2. On Tuesday, File 4 is added. Since File 4 is a new file that has been added since the last full backup, it will be backed up Tuesday evening.

3. On Wednesday, File 5 is added. Now, since both File 4 and File 5 are files that have been added or changed since the last full backup, both files will be backed up Wednesday evening.

4. On Thursday, File 6 is added. Again, File 4, File 5, and File 6 are files that have been added or changed since the last full backup; all three files will be backed up Thursday evening.

5. On Friday morning, there is a corruption of the data, so the data must be restored from tape.

a. The first step is to restore the full backup from Monday evening. b. Then, only the backup from Thursday evening is restored because it contains all

the new/changed files from Tuesday, Wednesday, and Thursday.

Backup Architecture Topologies ü There are 3 basic backup topologies:

– Direct Attached Based Backup – LAN Based Backup – SAN Based Backup

ü These topologies can be integrated, forming a “mixed” topology Direct Attached Based Backups Lan Based Backups:

SAN Based backups (LAN Free): SAN/LAN Mixed Based Backups:

Backup Media: ü Tape

– Traditional destination for backups

– Sequential access – No protection

ü Disk – Random access – Protected by the storage

array (RAID, hot spare, etc)

ü Multiple streams interleaved to achieve higher throughput on tape

– Keeps the tape streaming, for maximum write performance – Helps prevent tape mechanical failure – Greatly increases time to restore

Tape drive streaming is recommended from all vendors, in order to keep the drive busy. If you do not keep the drive busy during the backup process (writing), performance will suffer. Multiple streaming helps to improve performance drastically, but it generates one issue as well: the backup data becomes interleaved, and thus the recovery times are increased

Backup to disk replaces tape and its associated devices, as the primary target for backup, with disk. Backup to disk systems offer major advantages over equivalent scale tape systems, in terms of capital costs, operating costs, support costs, and quality of service. It can be implemented fully on day 1 or over a phased approach. In a traditional approach for backup and archive, businesses take a backup of production. Typically backup jobs use weekly full backups and nightly incremental backups. Based on business requirements, they will then copy the backup jobs and eject the tapes to have them sent offsite, where they will be stored for a specified amount of time. The problem with this approach is simple - as the production environment grows, so does the backup environment. ü Production environment grows

– Requires constant tuning and data placement to maintain performance – Need to add more tier-1 storage

ü Backup environment grows – Backup windows get longer and jobs do not complete – Restores take longer – Requires more tape drives and silos to keep up with service levels

ü Archive environment grows – Impact flexibility to retrieve content when requested – Requires more media, adding management cost – No investment protection for long term retention requirements

Differences Between Backup / Recovery & Archive:

The recovery process is much more important than the backup process. It is based on the appropriate recovery-point objectives (RPOs) and recovery-time objectives (RTOs). The process usually drives a decision to have a combination of technologies in place, from online local replicas, to backup to disk, to backup to tape for long-term, passive RPOs.

Archive processes are determined not only by the required retention times, but also by retrieval-time service levels and the availability requirements of the information in the archive. For both processes, a combination of hardware and software is needed to deliver the appropriate service level. The best way to discover the appropriate service level is to classify the data and align the business applications with it.

Replication: What is replication? Local replication is a technique for ensuring Business Continuity by making exact copies of data. With replication, data on the replica will be identical to the data on the original at the point-in-time that the replica was created. Examples: ü Copy a specific file ü Copy all the data used by a database application ü Copy all the data in a UNIX Volume Group (including underlying logical volumes, file systems,

etc.) ü Copy data on a storage array to a remote storage array Replicas can be used to address a number of Business Continuity functions: ü Provide an alternate source for backup to alleviate the impact on production. ü Provide a source for fast recovery to facilitate faster RPO and RTO. ü Decision Support activities such as reporting. − For example, a company may have a requirement to generate periodic

reports. Running the reports off of the replicas greatly reduces the burden placed on the production volumes. Typically reports would need to be generated once a day or once a week, etc.

ü Developing and testing proposed changes to an application or an operating environment. − For example, the application can be run on an alternate server using the

replica volumes and any proposed design changes can be tested. ü Data migration. − Migration can be as simple as moving applications from one server to the

next, or as complicated as migrating entire data centers from one location to another. Key factors to consider with replicas: ü What makes a replica good: − Recoverability from a failure on the production volumes. The replication

technology must allow for the restoration of data from the replicas to the production and then allow production to resume with a minimal RPO an RTO.

− Consistency/re-startability is very important if data on the replicas will be accessed directly or if the replicas will be used for restore operations.

ü Replicas can either be Point-in-Time (PIT) or continuous: − Point-in-Time (PIT) - the data on the replica is an identical image of the

production at some specific timestamp Ø For example, a replica of a file system is created at 4:00 PM on

Monday. This replica would then be referred to as the Monday 4:00 PM Point-in-Time copy.

Ø Note: The RPO will be a finite value with any PIT. The RPO will map to the time when the PIT was created to the time when any kind of failure on the production occurred. If there is a failure on the production at 8:00 PM and there is a 4:00 PM PIT available, the RPO would be 4 hours (8 – 4 = 4). To minimize RPO with PITs, take periodic PITs.

− Continuous replica - the data on the replica is synchronized with the production data at all times.

Ø The objective with any continuous replication is to reduce the RPO to zero.

Database replication can be offline or online:

• Offline – replication takes place when the database and the application are shutdown.

• Online – replication takes place when the database and the application are running.

ü Databases/Applications maintain integrity by following the “Dependent Write I/O

Principle” – Dependent Write: A write I/O that will not be issued by an application until a

prior related write I/O has completed Ø A logical dependency, not a time dependency

– Inherent in all Database Management Systems (DBMS) Ø e.g. Page (data) write is dependent write I/O based on a successful log

write – Applications can also use this technology – Necessary for protection against local outages

Ø Power failures create a dependent write consistent image Ø A Restart transforms the dependent write consistent to transactionally

consistent v i.e. Committed transactions will be recovered, in-flight

transactions will be discarded

Database applications require that for a transaction to be deemed complete a series of writes have to occur in a particular order (Dependent Write I/O), these writes would be recorded on the various devices/file systems.

ü In this example, steps 1-4 must complete for the transaction to be deemed complete.

− Step 4 is dependent on Step 3 and will occur only if Step 3 is complete − Step 3 is dependent on Step 2 will occur only if Step 2 is complete − Step 2 is dependent on Step 1 will occur only if Step 1 is complete

ü Steps 1-4 are written to the database’s buffer and then to the physical disks.

At the point in time when the replica is created, all the writes to the source devices must be captured on the replica devices to ensure data consistency on the replica. ü In this example, steps 1-4 on the source devices must be captured on the replica devices for

the data on the replicas to be consistent. Creating a PIT for multiple devices happens quickly, but not instantaneously.

ü Steps 1-4 which are dependent write I/Os have occurred and have been recorded successfully on the source devices

ü It is possible that steps 3 and 4 were copied to the replica devices, while steps 1 and 2 were not copied.

ü In this case, the data on the replica is inconsistent with the data on the source. If a restart were to be performed on the replica devices, Step 4 which is available on the replica might indicate that a particular transaction is complete, but all the data associated with the transaction will be unavailable on the replica making the replica inconsistent.

Database replication can be performed with the application offline (i.e., application is shutdown, no I/O activity) or online (i.e., while the application is up and running). If the application is offline, the replica will be consistent because there is no activity. However, consistency is an issue if the database application is replicated while it is up and running.

Online Replication – Some database applications allow replication while the application is up and running – The production database would have to be put in a state which would allow it to be

replicated while it is active – Some level of recovery must be performed on the replica to make the replica consistent

An alternative way to ensure that an online replica is consistent is to:

1. Hold I/O to all the devices at the same instant. 2. Create the replica. 3. Release the I/O.

Holding I/O is similar to a power failure and most databases have the ability to restart from a power failure. Note: While holding I/O simultaneously one ensures that the data on the replica is identical to that on the source devices, the database application will timeout if I/O is held for too long.

Changes will occur on the production volume after the creation of a PIT, changes could also occur on the target. Typically the target device will be re-synchronized with the source device at some future time in order to obtain a more recent PIT. Note: The replication technology employed should have a mechanism to keep track of changes. This makes the re-synchronization process will be much faster. If the replication technology does

not track changes between the source and target, every resynchronization operation will have to be a full operation. Replication technologies can classified by:

ü Distance over which replication is performed - local or remote ü Where the replication is performed - host or array based

− Host based - all the replication is performed by using the CPU resources of the host using software that is running on the host.

− Array based - all replication is performed on the storage array using CPU resources on the array via the array’s operating environment.

Note: In the context of this discussion, local replication refers to replication that is performed within a data center if it is host based and within a storage array if it is array based. ü Host based

– Logical Volume Manager (LVM) based mirroring – File System Snapshots

ü Storage Array based – Full volume mirroring – Full volume: Copy on First Access – Pointer based: Copy on First Write

ü Host resident software responsible for creating and controlling host level logical storage

– Physical view of storage is converted to a logical view by mapping. Logical data blocks are mapped to physical data blocks.

– Logical layer resides between the physical layer (physical devices and device drivers) and the application layer (OS and applications see logical view of storage).

ü Usually offered as part of the operating system or as third party host software ü LVM Components:

– Physical Volumes – Volume Groups – Logical Volumes

A Volume Group is created by grouping together one or more Physical Volumes. Physical Volumes:

ü Can be added or removed from a Volume Group dynamically. ü Cannot be shared between Volume Groups, the entire Physical Volume becomes

part of a Volume Group. Each Physical Volume is partitioned into equal-sized data blocks. The size of a Logical Volume is based on a multiple of the equal-sized data block. The Volume Group is handled as a single unit by the LVM.

ü A Volume Group as a whole can be activated or deactivated. ü A Volume Group would typically contain related information. For example, each

host would have a Volume Group which holds all the OS data, while applications would be on separate Volume Groups.

Logical Volumes are created within a given Volume Group. A Logical Volume can be thought of as a virtual disk partition, while the Volume Group itself can be though of as a disk. A Volume Group can have a number of Logical Volumes.

Logical Volumes (LV) form the basis of logical storage. They contain logically contiguous data blocks (or logical partitions) within the volume group. Each logical partition is mapped to at least one physical partition on a physical volume within the Volume Group. The OS treats an LV like a physical device and accesses it via device special files (character or block). A Logical Volume:

ü Can only belong to one Volume Group. However, a Volume Group can have multiple LVs.

ü Can span multiple physical volumes. ü Can be made up of physical disk blocks that are not physically contiguous. ü Appears as a series of contiguous data blocks to the OS. ü Can contain a file system or be used directly. Note: There is a one-to-one

relationship between LV and a File System. Note: Under normal circumstances there is a one-to-one mapping between a logical and physical Partition. A one-to-many mapping between a logical and physical partition leads to mirroring of Logical Volumes.

ü LVM based replicas add overhead on host CPUs ü If host devices are already Storage Array devices then the added redundancy provided

by LVM mirroring is unnecessary – The devices will have some RAID protection already

ü Host based replicas can be usually presented back to the same server ü Keeping track of changes after the replica has been created

With storage array based local replication:

ü Replication performed by the Array Operating Environment − Array CPU resources are used for the replication operations − Host CPU resources can be devoted to production operations instead of

replication operations ü Replicas are on the same array

− Can be accessed by an alternate host for any BC operations ü Typically array based replication is performed at a array device level.

− Need to map storage components used by an application back to the specific array devices used – then replicate those devices on the array.

− A database could be laid out on over multiple physical volumes which belong. One would have to replicate all the devices for a PIT copy of the database.

ü For future re-synchronization to be incremental, most vendors have the ability to track

changes at some level of granularity (e.g., 512 byte block, 32 KB, etc.)

– Tracking is typically done with some kind of bitmap ü Target device must be at least as large as the Source device

– For full volume copies the minimum amount of storage required is the same as the size of the source

Copy on First Access (COFA) provides an alternate method to create full volume copies. Unlike Full Volume mirrors, the replica is immediately available when the session is started (no waiting for full synchronization).

ü The PIT is determined by the time of activation of the session. Just like the full volume mirror technology this method requires the Target devices to be at least as large as the source devices.

ü A protection map is created for all the data on the Source device at some level of granularity (e.g., 512 byte block, 32 KB, etc.). Then the data is copied from the source to the target in the background based on the mode with which the replication session was invoked.

In the Copy on First Access mode (or the deferred mode), data is copied from the source to the target only when: ü A write is issued for the first time after the PIT to a specific address on the source ü A read or write is issued for the first time after the PIT to a specific address on the

target. Since data is only copied when required, if the replication session is terminated the target device will only have data that was copied (not the entire contents of the source at the PIT). In this scenario, the data on the Target cannot be used as it is incomplete. ü Targets do not hold actual data, but hold pointers to where the data is located

– Actual storage requirement for the replicas is usually a small fraction of the size of the source volumes

ü A replication session is setup between the Source and Target devices and started

– When the session is setup based on the specific vendors implementation a protection map is created for all the data on the Source device at some level of granularity (e.g 512 byte block, 32 KB etc.)

– Target devices are accessible immediately when the session is started – At the start of the session the Target device holds pointers to the data on the

Source device

The original data block from the Source is copied to the save location, when a data block is first written to after the PIT.

ü Prior to a new write to the source or target device: − Data is copied from the source to a “save” location − The pointer for that specific address on the Target then points to the

“save” location − Writes to the Target result in writes to the “save” location and the

updating of the pointer to the “save” location ü If a write is issued to the source for the first time after the PIT the original data

block is copied to the save location and the pointer is updated from the Source to the save location.

ü If a write is issued to the Target for the first time after the PIT the original data is copied from the Source to the Save location, the pointer is updated and then the new data is written to the save location.

ü Reads from the Target are serviced by the Source device or from the save location based on the where the pointer directs the read.

− Source – When data has not changed since PIT − Save Location – When data has changed since PIT

Data on the replica is a combined view of unchanged data on the Source and the save location. Hence if the Source device becomes unavailable the replica will no longer have valid data.

Most array based replication technologies will allow the creation of Consistent replicas by holding IO to all devices simultaneously when the PIT is created.

ü Typically applications are spread out over multiple devices − Could be on the same array or multiple arrays

ü Replication technology must ensure that the PIT for the whole application is consistent

− Need mechanism to ensure that updates do not occur while PIT is created

ü Hold IO to all devices simultaneously for an instant, create PIT and release IO − Cannot hold IO for too long, application will timeout

Mechanisms to hold IO

ü Host based − Some host based application could be used to hold IO to all the array

devices that are to be replicated when the PIT is created − Typically achieved at the device driver level or above before the IO

reaches the HBAs Ø Some vendors implement this at the multi-pathing software layer

ü Array based − IOs can be held for all the array devices that are to be replicated by the

Array Operating Environment in the array itself when the PIT is created What if the application straddles multiple hosts and multiple arrays?

ü Federated Databases ü Some array vendors are able to ensure consistency in this situation

Array Replicas: Restore/Restart Considerations ü Production has a failure

– Logical Corruption – Physical failure of production devices – Failure of Production server

ü Solution

– Restore data from replica to production Ø The restore would typically be done in an incremental manner and the

Applications would be restarted even before the synchronization is complete leading to very small RTO

-----OR------ – Start production on replica

Ø Resolve issues with production while continuing operations on replicas Ø After issue resolution restore latest data on replica to production

– Before a Restore – Stop all access to the Production devices and the Replica devices – Identify Replica to be used for restore

Ø Based on RPO and Data Consistency – Perform Restore

– Before starting production on Replica – Stop all access to the Production devices and the Replica devices – Identify Replica to be used for restart

Ø Based on RPO and Data Consistency – Create a “Gold” copy of Replica

Ø As a precaution against further failures – Start production on Replica

– RTO drives choice of replication technology ü Full Volume Replicas

– Restores can be performed to either the original source device or to any other device of like size Ø Restores to the original source could be incremental in nature Ø Restore to a new device would involve a full synchronization

ü Pointer Based Replicas – Restores can be performed to the original source or to any other device of like

size as long as the original source device is healthy Ø Target only has pointers

v Pointers to source for data that has not been written to after PIT v Pointers to the “save” location for data was written after PIT

Ø Thus to perform a restore to an alternate volume the source must be healthy to access data that has not yet been copied over to the target

ü Full Volume Replica

– Replica is a full physical copy of the source device – Storage requirement is identical to the source device – Restore does not require a healthy source device – Activity on replica will have no performance impact on the source device – Good for full backup, decision support, development, testing and restore to last

PIT – RPO depends on when the last PIT was created – RTO is extremely small

ü Pointer based - COFW

– Replica contains pointers to data Ø Storage requirement is a fraction of the source device (lower cost)

– Restore requires a healthy source device – Activity on replica will have some performance impact on source

Ø Any first write to the source or target will require data to be copied to the save location and move pointer to save location

Ø Any read IO to data not in the save location will have to be serviced by the source device

– Typically recommended if the changes to the source are less than 30% – RPO depends on when the last PIT was created – RTO is extremely small

ü Full Volume – COFA Replicas

– Replica only has data that was accessed – Restore requires a healthy source device – Activity on replica will have some performance impact

Ø Any first access on target will require data to be copied to target before the I/O to/from target can be satisfied

– Typically replicas created with COFA only are not as useful as replicas created with the full copy mode – Recommendation would be to use the full copy mode it the technology allows such an option

EMC – Local Replication Solutions All the local replication solutions that were discussed in this module are available on EMC Symmetrix and CLARiiON arrays.

ü EMC TimeFinder/Mirror and EMC TimeFinder/Clone are full volume replication solutions on the Symmetrix arrays, while EMC TimeFinder/Snap is a pointer based replication solution on the Symmetrix. EMC SnapView on the CLARiiON arrays allows full volume replication via SnapView Clone and pointer based replication via SnapView Snapshot.

ü EMC TimeFinder/Mirror: Highly available, ultra-performance mirror images of Symmetrix volumes that can be non-disruptively split off and used as point-in-time copies for backups, restores, decision support, or contingency uses.

ü EMC TimeFinder/Clone: Highly functional, high-performance, full volume copies of Symmetrix volumes that can be used as point-in-time copies for data warehouse refreshes, backups, online restores, and volume migrations.

ü EMC SnapView Clone: Highly functional, high-performance, full volume copies of CLARiiON volumes that can be used as point-in-time copies for data warehouse refreshes, backups, online restores, and volume migrations.

ü EMC TimeFinder/Snap: High function, space-saving, pointer-based copies (logical images) of Symmetrix volumes that can be used for fast and efficient disk-based restores.

ü EMC SnapView Snapshot: High function, space-saving, pointer-based copies (logical images) of CLARiiON volumes that can be used for fast and efficient disk-based restores.

We will discuss EMC TimeFinder/Mirror and EMC SnapView Snapshot in more detail in the next few slides. ü Array based local replication technology for Full Volume Mirroring on EMC Symmetrix

Storage Arrays – Create Full Volume Mirrors of an EMC Symmetrix device within an Array

ü TimeFinder/Mirror uses special Symmetrix devices called Business Continuance Volumes (BCV). BCVs:

– Are devices dedicated for Local Replication – Can be dynamically, non-disruptively established with a Standard device. They

can be subsequently split instantly to create a PIT copy of data. ü The PIT copy of data can be used in a number of ways:

– Instant restore – Use BCVs as standby data for recovery – Decision Support operations – Backup – Reduce application downtime to a minimum (offline backup) – Testing

ü TimeFinder/Mirror is available in both Open Systems and Mainframe environments ü Establish

– Synchronize the Standard volume to the BCV volume – BCV is set to a Not Ready state when established

Ø BCV cannot be independently addressed – Re-synchronization is incremental – BCVs cannot be established to other BCVs – Establish operation is non-disruptive to the Standard device – Operations to the Standard can proceed as normal during the establish

ü Split

– Time of Split is the Point-in-Time – BCV is made accessible for BC Operations – Consistency

Ø Consistent Split – Changes tracked

The TimeFinder/Mirror Consistent Split option ensures that the data on the BCVs is consistent with the data on the Standard devices. Consistent Split holds I/O across a group of devices using a single Consistent Split command, thus all the BCVs in the group are consistent point-in-time copies. Used to create a consistent point-in-time copy of an entire system, an entire database, or any associated set of volumes. The holding of I/Os can be either done by the EMC PowerPath multi-pathing software or by the Symmetrix Microcode (Enginuity Consistency Assist). PowerPath-based consistent split executed by the host doing the I/O, I/O is held at the host before the split. Enginuity Consistency Assist (ECA) based consistent split can be executed, by the host doing the I/O or by a control host in an environment where there are distributed and/or related databases. I/O held at the Symmetrix until the split operation is completed. Since I/O is held at the Symmetrix, ECA can be used to perform consistent splits on BCV pairs across multiple, heterogeneous hosts.

ü Restore

– Synchronize contents of BCV volume to the Standard volume – Restore can be full or incremental – BCV is set to a Not Ready state – I/Os to the Standard and BCVs should be stopped before the restore is initiated

ü Query – Provide current status of BCV/Standard volume pairs

TimeFinder/Mirror allows a given Standard device to maintain incremental relationships with multiple BCVs. This means that different BCVs can be established and then split incrementally from a standard volume at different times of the day. For example a BCV that was split at 4:00 a.m. can be re-established incrementally even though another BCV was established and split at 5:00 a.m. In this way, a user can split and incrementally re-establish volumes throughout the day or night and still keep re-establish times to a minimum. Incremental information can be retained between a STD device and multiple BCV devices, provided the BCV devices have not been paired with different STD devices. The incremental relationship is maintained between each STD/BCV pairing by the Symmetrix Microcode. ü Two BCVs can be established concurrently with the same Standard device ü Establish BCVs simultaneously or one after the other ü BCVs can be split individually or simultaneously. ü Simultaneous. “Concurrent Restores”, are not allowed

SnapView is software that runs on the CLARiiON Storage Processors, and is part of the CLARiiON Replication Software suite of products, which includes SnapView, MirrorView and SAN Copy. SnapView can be used to make point in time (PIT) copies in 2 different ways – Clones, also called BCVs or Business Continuity Volumes, are full copies, whereas Snapshots use a pointer-based mechanism. Full copies are covered later, when we look at Symmetrix TimeFinder; SnapView Snapshots will be covered here. The generic pointer-based mechanism has been discussed in a previous section, so we’ll concentrate on SnapView here. Snapshots require a save area, called the Reserved LUN Pool. The ‘Reserved’ part of the name implies that the LUNs are reserved for use by CLARiiON software, and can therefore not be assigned to a host. LUNs which cannot be assigned to a host are known as private LUNs in the CLARiiON environment. To keep the number of pointers, and therefore the pointer map, at a reasonable size, SnapView divides the LUN to be snapped, called a Source LUN, into areas of 64 kB in size. Each of these areas is known as a chunk. Any change to data inside a chunk will cause that chunk to be written to the Reserved LUN Pool, if it is being modified for the first time. The 64 kB copied from the Source LUN must fit into a 64 kB area in the Reserved LUN, so Reserved LUNs are also divided into chunks for tracking purposes. The next 2 slides show more detail on the Reserved LUN Pool, and allocation of Reserved LUNs to a Source LUN.

The CLARiiON storage system must be configured with a Reserved LUN Pool in order to use SnapView Snapshot features. The Reserved LUN Pool consists of 2 parts: LUNs for use by SPA and LUNs for use by SPB. Each of those parts is made up of one or more Reserved LUNs. The LUNs used are bound in the normal manner. However, they are not placed in storage groups and allocated to hosts, they are used internally by the storage system software. These are known as private LUNs because they cannot be used, or seen, by attached hosts. Like any LUN, a Reserved LUN will be owned by only one SP at any time and they may be trespassed if the need should arise (i.e., if an SP should fail). Just as each storage system model has a maximum number of LUNs it will support, each also has a maximum number of LUNs which may be added to the Reserved LUN Pool. The first step in SnapView configuration will usually be the assignment of LUNs to the Reserved LUN Pool. Only then will SnapView Sessions be allowed to start. Remember that as snapable

Remote Replication Concepts LUNs are added to the storage system, the LUN Pool size will have to be reviewed. Changes may be made online. LUNs used in the Reserved LUN Pool are not host-visible, though they do count towards the maximum number of LUNs allowed on a storage system. ü Replica is available at a remote facility

– Could be a few miles away or half way around the world – Backup and Vaulting are not considered remote replication

ü Synchronous Replication – Replica is identical to source at all times – Zero RPO

ü Asynchronous Replication – Replica is behind the source by a finite margin – Small RPO

ü Connectivity – Network infrastructure over which data is transported from source site to remote

site Synchronous Replication ü A write has to be secured on the remote replica and the source before it is acknowledged

to the host ü Ensures that the source and remote replica have identical data at all times

– Write ordering is maintained at all times Ø Replica receives writes in exactly the same order as the source

ü Synchronous replication provides the lowest RPO and RTO – Goal is zero RPO – RTO is as small as the time it takes to start application on the remote site

ü Response Time Extension

– Application response time will be extended due to synchronous replication Ø Data must be transmitted to remote site before write can be

acknowledged Ø Time to transmit will depend on distance and bandwidth

ü Bandwidth – To minimize impact on response time, sufficient bandwidth must be provided for

at all times ü Rarely deployed beyond 200 km

Asynchronous Replication ü Write is acknowledged to host as soon as it is received by the source ü Data is buffered and sent to remote

– Some vendors maintain write ordering – Other vendors do not maintain write ordering, but ensure that the replica will

always be a consistent re-startable image ü Finite RPO

– Replica will be behind the Source by a finite amount – Typically configurable

ü Response Time unaffected ü Bandwidth

– Need sufficient bandwidth on average ü Buffers

– Need sufficient buffers ü Can be deployed over long distances

Remote Replication Technologies ü Host based

– Logical Volume Manager (LVM) Ø Synchronous/Asynchronous

– Log Shipping ü Storage Array based

– Synchronous – Asynchronous – Disk Buffered - Consistent PITs

Ø Combination of Local and Remote Replication ü Duplicate Volume Groups at local and remote sites ü All writes to the source Volume Group are replicated to the remote Volume Group by the

LVM – Synchronous or Asynchronous

LVM Based Remote Replication ü In the event of a network failure

– Writes are queued in the log file – When the issue is resolved the queued writes are sent over to the remote – The maximum size of the log file determines the length of outage that can be

withstood ü In the event of a failure at the source site, production operations can be transferred to

the remote site ü Advantages

– Different storage arrays and RAID protection can be used at the source and remote sites

– Standard IP network can be used for replication – Response time issue can be eliminated with asynchronous mode, with extended

RPO ü Disadvantages

– Extended network outages require large log files – CPU overhead on host

ü For maintaining and shipping log files

Host Based Log Shipping Log Shipping is a host based replication technology for databases offered by most DB Vendors

ü Initial State - All the relevant storage components that make up the database are replicated to a standby server (done over IP or other means) while the database is shutdown

ü Database is started on the production server – As and when log switches occur the log file that was closed is sent over IP to the standby server

ü Database is started in standby mode on the standby server, as and when log files arrive they are applied to the standby database

ü Standby database is consistent up to the last log file that was applied Advantages

ü Minimal CPU overhead on production server ü Low bandwidth (IP) requirement ü Standby Database consistent to last applied log

− RPO can be reduced by controlling log switching Disadvantages

ü Need host based mechanism on production server to periodically ship logs ü Need host based mechanism on standby server to periodically apply logs and

check for consistency ü IP network outage could lead to standby database falling further behind

Array Based – Remote Replication Replication Process

ü A Write is initiated by an application/server ü Received by the source array ü Source array transmits the write to the remote array via dedicated channels

(ESCON, Fibre Channel or Gigabit Ethernet) over a dedicated or shared network infrastructure

ü Write received by the remote array Only Writes are forwarded to the remote array

ü Reads are from the source devices Array Based – Synchronous Replication

Array Based – Asynchronous Replication ü No impact on response time ü Extended distances between arrays ü Lower bandwidth as compared to Synchronous

ü Ensuring Consistency

– Maintain write ordering Ø Some vendors attach a time stamp and sequence number with each of

the writes, then ship the writes to the remote array and apply the writes to the remote devices in the exact order based on the time stamp and sequence numbers

Ø Remote array applies the writes in the exact order they were received, just like synchronous

– Dependent write consistency Ø Some vendors buffer the writes in the cache of the source array for a

period of time (between 5 and 30 seconds) Ø At the end of this time the current buffer is closed in a consistent

manner and the buffer is switched, new writes are received in the new buffer

Ø The closed buffer is then transmitted to the remote array Ø Remote replica will contain a consistent, re-startable image on the

application Disk buffered consistent PITs is a combination of Local and Remote replications technologies. The idea is to make a Local PIT replica and then create a Remote replica of the Local PIT. The advantage of disk buffered PITs is lower bandwidth requirements and the ability to replicate over extended distances. Disk buffered replication is typically used when the RPO requirements are of the order of hours or so, thus a lower bandwidth network can be used to transfer data from the Local PIT copy to the remote site. The data transfer may take a while, but the solution would be designed to meet the RPO. We will take a look at a two disk buffered PIT solutions. Disk buffered replication allows for the incremental resynchronization between a Local Replica which acts as a source for a Remote Replica.

Benefits include: ü Reduction in communication link cost and improved resynchronization time for

long-distance replication implementations ü The ability to use the various replicas to provide disaster recovery testing, point-

in-time backups, decision support operations, third-party software testing, and application upgrade testing or the testing of new applications.

Synchronous + Extended Distance Consistent PIT

Synchronous + Extended Distance Buffered Replication benefits include:

ü Bunker site provides a zero RPO DR Replica ü The ability to resynchronize only changed data between the intermediate Bunker

site and the final target site, reducing required network bandwidth ü Reduction in communication link cost and improved resynchronization time for

long-distance replication implementations ü The ability to use the replicas to provide disaster recovery testing, point-in-time

backups, decision support operations, third-party software testing, and application upgrade testing or the testing of new applications.

Remote Replicas – Tracking Changes ü Remote replicas can be used for BC Operations

– Typically remote replication operations will be suspended when the remote replicas are used for BC Operations

ü During BC Operations changes will/could happen to both the source and remote replicas – Most remote replication technologies have the ability to track changes made to

the source and remote replicas to allow for incremental re-synchronization – Resuming remote replication operations will require re-synchronization between

the source and replica

Primary Site Failure – Operations at Remote Site ü Remote replicas are typically not available for use while the replication session is in

progress ü In the event of a primary site failure the replicas have to be made accessible for use ü Create a local replica of the remote devices at the remote site ü Start operations at the Remote site

– No remote protection while primary site issues are resolved ü After issue resolution at Primary Site

– Stop activities at remote site – Restore latest data from remote devices to source – Resume operations at Primary (Source) Site

Array Based – Which Technology? ü Synchronous

– Is a must if zero RPO is required – Need sufficient bandwidth at all times – Application response time elongation will prevent extended distance solutions

(rarely above 125 miles) ü Asynchronous

– Extended distance solutions with minimal RPO (order of minutes) – No Response time elongation – Generally requires lower Bandwidth than synchronous – Must design with adequate cache/buffer or sidefile/logfile capacity

ü Disk Buffered Consistent PITs – Extended distance solution with RPO in the order of hours – Generally lower bandwidth than synchronous or asynchronous

Storage Array Based – Remote Replication ü Network Options

– Most vendors support ESCON or Fibre Channel adapters for remote replication Ø Can connect to any optical or IP networks with appropriate protocol

converters for extended distances v DWDM v SONET v IP Networks

– Some Vendors have native Gigabit Ethernet adapters which allows the array to be connected directly to IP Networks without the need for protocol converters

Dense Wavelength Division Multiplexing (DWDM) ü DWDM is a technology that puts data from different sources together on an optical fiber

with each signal carried on its own separate light wavelength (commonly referred to as a lambda or λ).

ü Up to 32 protected and 64 unprotected separate wavelengths of data can be multiplexed into a light stream transmitted on a single optical fiber.

Synchronous Optical Network (SONET) Synchronous Optical Networks (SONET) is a standard for optical telecommunications transport formulated by the Exchange Carriers Standards Association (ECSA) for the American National Standards Institute (ANSI). The equivalent international standard is referred to as Synchronous Digital Hierarchy and is defined by the European Telecommunications Standards Institute (ETSI). Within Metropolitan Area Networks (MANs) today, SONET/SDH rings are used to carry both voice and data traffic over fiber. ü SONET is Time Division Multiplexing (TDM) technology where traffic from multiple

subscribers is multiplexed together and sent out onto the SONET ring as an optical signal ü Synchronous Digital Hierarchy (SDH) similar to SONET but is the European standard ü SONET/SDH, offers the ability to service multiple locations, its reliability/availability,

automatic protection switching, and restoration EMC – Remote Replication Solutions ü EMC Symmetrix Arrays

– EMC SRDF/Synchronous – EMC SRDF/Asynchronous – EMC SRDF/Automated Replication

ü EMC CLARiiON Arrays – EMC MirrorView/Synchronous – EMC MirrorView/Asynchronous

All remote replication solutions that were discussed in this module are available on EMC Symmetrix and CLARiiON Arrays. The SRDF (Symmetrix Remote Data Facility) family of products provides Synchronous, Asynchronous and Disk Buffered remote replication solutions on the EMC Symmetrix Arrays. The MirrorView family of products provides Synchronous and Asynchronous remote replication solutions on the EMC CLARiiON Arrays. SRDF/Synchronous (SRDF/S): High-performance, host-independent, real-time synchronous remote replication from one Symmetrix to one or more Symmetrix systems. MirrorView/Synchronous (MirrorView/S): Host-independent, real-time synchronous remote replication from one CLARiiON to one or more CLARiiON systems. SRDF/Asynchronous (SRDF/A): High-performance extended distance asynchronous replication for Symmetrix arrays using a Delta Set architecture for reduced bandwidth requirements and no host performance impact. Ideal for Recovery Point Objectives of the order of minutes. MirrorView/Asynchronous (MirrorView/A): Asynchronous remote replication on CLARiiON arrays. Designed with low-bandwidth requirements, delivers a cost-effective remote replication solution ideal for Recovery Point Objectives (RPOs) of 30 minutes or greater. SRDF/Automated Replication: Rapid business restart over any distance with no data exposure through advanced single-hop and multi-hop configurations using combinations of TimeFinder/Mirror and SRDF on Symmetrix Arrays. EMC SRDF/Synchronous - Introduction ü Array based Synchronous Remote Replication technology for EMC Symmetrix Storage

Arrays – Facility for maintaining real-time physically separate mirrors of selected volumes

ü SRDF/Synchronous uses special Symmetrix devices – Source arrays have SRDF R1 devices

– Target arrays have SRDF R2 devices – Data written to R1 devices are replicated to R2 devices

ü SRDF uses dedicated channels to send data from source to target array – ESCON, Fibre Channel or Gigabit Ethernet are supported

ü SRDF is available in both Open Systems and Mainframe environments SRDF Source and Target Volumes ü SRDF R1 and R2 Volumes can have any local RAID Protection

– E.g. Volumes could have RAID-1 or RAID-5 protection ü SRDF R2 volumes are in a Read Only state when remote replication is in effect

– Changes cannot be made to the R2 volumes ü SRDF R2 volumes are accessed under certain circumstances

– Failover – Invoked when the primary volumes become unavailable – Split – Invoked when the R2 volumes need to be concurrently accessed for BC

operations SRDF/Synchronous

SRDF Operations - Failover Failover operations are performed if the SRDF R1 Volumes become unavailable and the decision is made to start operations on the R2 Devices. Failover could also be performed when DR processes are being tested or for any maintenance tasks that have to be performed at the source site. If failing over for a Maintenance operation: For a clean, consistent, coherent point in time copy which can be used with minimal recovery on the target side some or all of the following steps may have to be taken on the source side:

ü Stop All Applications (DB or what ever) ü Unmount file system. ü Deactivate the Volume Group ü A failover leads to a RO state on the source side. If a device suddenly becomes

RO from a RW state the reaction of the host can be unpredictable if the device is in use. Hence the suggestion to stop applications, un-mount and deactivation of Volume Groups.

SRDF Operations – Establish/Restore ü Establish - Resume SRDF operation retaining data from source and overwriting any

changed data on target ü Restore - SRDF operation retaining data on target and overwriting any changed data on

source

SR

DF O

pe

ratio

ns - F

ailb

ack

SRDF Operations - Split ü Enables read and write operations on both source and target volumes ü Suspends replication

EMC CLARiiON MirrorView/A Overview ü Optional storage system software for remote replication on EMC CLARiiON arrays

– No host cycles used for data replication ü Provides a remote image for disaster recovery

– Remote image updated periodically - asynchronously – Remote image cannot be accessed by hosts while replication is active – Snapshot of mirrored data can be host-accessible at remote site

ü Mirror topology (connecting primary array to secondary arrays) – Direct connect and switched FC topology supported – WAN connectivity supported using specialized hardware

Mirrorview Terms: ü Primary storage system

– Holds the local image for a given mirror ü Secondary storage system

– Holds the local image for a given mirror ü Bidirectional mirroring

– A storage system can hold local and remote images ü Mirror Synchronization

– Process that copies data from local image to remote image ü MirrorView Fractured state

– Condition when a Secondary storage system is unreachable by the Primary storage system

Mirrorview Configuration: ü MirrorView/A Setup

– MirrorView/A software must be loaded on both Primary and Secondary storage system

– Remote LUN must be exactly the same size as local LUN – Secondary LUN does not need to be the same RAID type as Primary – Reserved LUN Pool space must be configured

ü Management via Navisphere Manager and CLI

Consistency Groups allow all LUNs belonging to a given application, usually a database, to be treated as a single entity, and managed as a whole. This helps to ensure that the remote images are consistent, i.e. all made at the same point in time. As a result, the remote images are always restartable copies of the local images, though they may contain data which is not as new as that on the primary images. It is a requirement that all the local images of a Consistency Group be on the same CLARiiON, and that all the remote images for a Consistency Group be on the same remote CLARiiON. All information related to the Consistency Group will be sent to the remote CLARiiON from the local CLARiiON. The operations which can be performed on a Consistency Group match those which may be performed on a single mirror, and will affect all mirrors in the Consistency Group. If, for some reason, an operation cannot be performed on one or more mirrors in the Consistency Group, then that operation will fail, and the images will be unchanged.