1-888-674-9495 www.doubletake.com

SAN Array-based Replication Many storage area networks (SANs) today can replicate data across distances between similar models of storage hardware and this can be an important part of any business continuity or disaster recovery strategy. Double-Take Availability is a software-based solution that also replicates data but at the host level, providing higher availability when systems are at the same location and disaster protection and recovery when they are not. Host-level file system replication occurs at the byte-level which is almost always more efficient than block-level SAN replication technologies and the application-aware monitoring and failover capabilities of Double-Take Availability make it an excellent choice for critical applications such as Exchange and SQL Server. But what about organizations that have already made significant investments in SANs and SAN-based replication? Are these solutions redundant and therefore provide no additional value or can they serve a complementary function? To answer that, consider these questions:

A disaster can take many forms. Natural disasters like hurricanes, tornadoes, floods, fires and earthquakes first come to mind. Sometimes these are referred to as “big D” disasters. But the destruction of computer hardware is the least likely cause of data loss. The less apparent “little d” disasters are statistically far more prevalent. The number one culprit in data loss is the failure of computer hardware components – power supplies, motherboards, disk drives, disk controllers, network interfaces, etc. If you can’t do accounting because a SQL server box has failed, or email because of the loss of an Exchange server, that is a disaster in perfectly good weather. Hardware failure and the second most common cause of failure, human error, cause over two-thirds of data loss. Even software corruption, theft and computer viruses are each two to four times as likely to cause data loss as the destruction of computer hardware. Only three percent of the time is hardware destruction the culprit.

• Against what kind of data loss “disaster” do you need to protect your business? • What can be done to ensure that the services on which users depend can be restored quickly in the event of a disaster when that data is protected with SAN-based technologies? • What happens if the replacement system is from a different hardware vendor or has a different type of processor video card, storage controller or network adapter? • What implication does virtualization have on disaster recovery and business continuity and how does it affect the underlying storage? • Are there business requirements which dictate the use of some of the unique capabilities provided by Double-Take Software’s other products? • Against what kind of data loss “disaster” do you need to protect your business?

Whatever the cause, a disaster is anything that keeps an organization from meeting its objectives. An objective might be as simple getting the day’s work done, or it might be as tactical as providing a report to managers or as strategic as providing an analysis to the board of directors or the chief legal officer regarding a lawsuit. Sooner or later, smaller objectives lead to global objectives of generating revenue and making a profit. If you don’t have the information to accomplish these objectives - that’s a disaster.

SAN Array-based Replication What can be done to ensure that the services on which users depend on can be restored quickly in the event of a disaster when data is protected with SAN-based technologies? If data is lost at one site, it is good to have it replicated to other one. More important is the failover process - ensuring the data is usable again after a disaster. Because it is software running on a host, Double-Take Availability can perform all the steps necessary at the operating system and network levels to make the recovery time as short as possible. At the same time, SAN array-based replication can keep information synchronized on the separate data volumes. For instance, the Double-Take Availability target can monitor the health of the source to detect when a failure occurs. It can then send an email or generate a Simple Network Management Protocol (SNMP) alert to notify administrators that a failure has occurred. While automatic failover is easily configured, especially over a WAN, a one-click human intervention is recommended to confirm that failover should occur. Double-Take Availability can then failover the functions of the failed source server to the equivalent target server. IP addresses and hostname changes may be moved to the target. Even operating system patches and applications not previously present on the target may be installed and the target rebooted so that the original source environment is recreated. Software processes are started in the proper order on the target. Further, changes may be made on the appropriate Active Directory and DNS servers so that surrounding servers can begin accessing the appropriate targets as if the failed sources were still available. Double-Take Availability can do all these steps in a matter of minutes and allow users and other servers to quickly begin receiving the desired information as if there had been no failure. Double-Take Availability can coordinate the failback process as well. Using array-based replication of data on the SAN and having Double-Take Availability monitor the source’s health and control the multi-step failover processes are not mutually exclusive. DoubleTake Availability allows you to select which storage it will and will not protect. With Double-Take Availability it is easy to deselect the SAN volumes, leaving that replication under the control of the storage subsystem. In many cases, a server’s operating system and even some data may not reside on the SAN but instead on internal or Direct Attached Storage (DAS). Double-Take Availability can be used to replicate that data and control the failover processes. During a failover, the target can mount the SAN volumes even though Double-Take Availability has not been protecting that storage. But the end result is the desired one – within a matter of minutes, the target becomes available with all the necessary changes - users and other servers depending on the original source continue as if nothing had happened. Becoming ever more common is the situation where everything – operating system, application and data – reside on the SAN. For reliability purposes, the servers themselves may truly be diskless and have access via multiple fibre channel or iSCSI network paths to the RAID-protected SAN storage. In this case, it is important to realize that SAN array-based replication does not need to be done on all the SAN storage. Typically the choice is made on a per-volume basis: an individual choice is made for each volume whether it is or is not replicated to its counterpart volume on the target storage. Excluding the operating system from SAN array-based replication makes it possible for Double-Take Availability to protect it

SAN Array-based Replication and control the failover processes – while only requiring that the OS be installed on a separate volume for user or application data, something that is typically the case anyway. The process of SAN array-based replication inherently doesn’t address these issues when disaster strikes. Storage arrays can’t monitor the health of physical servers or notify administrators should they fail. They cannot coordinate the failover or failback between the source and target. They cannot communicate the necessary Active Directory and DNS changes to the relevant servers. Instead, SAN array-based replication can only replicate the selected data. What happens if the replacement system is from a different hardware vendor or has a different type of processor video card, storage controller or network adapter? A disaster could be caused by the loss of an entire site or just the failure of a server or component. While SAN array-based replication works well for the data, it can’t differentiate software components that are 32 or 64 bit or Intel or AMD specific. It can’t “know” if a driver is for a Broadcom or VMware NIC, or that a particular byte pattern is even a device driver at all. The operating system and the applications on the original server may need to be significantly different on the replacement equipment. But SAN array-based replication only replicates bytes of storage. Double-Take Availability, on the other hand, has two ways to address this situation. One approach is to protect at the application level while the other protects the entire system state. The system state consists of operating system updates, the applications themselves and even application patches. Both approaches are available in any Double-Take Software product – it just depends on how you configure it. There is no different license or penalty if you change from one approach to another and even back again at any time. Application-level protection keeps the application data consistent. During failover, Double-Take Availability can automatically change the network IP addresses and even hostname on the local system, request Active Directory and DNS changes, and start or (maybe if vendor specific) not start the appropriate services, all based on the configuration choices made beforehand. The ability to have Active Directory changes made is especially important during Exchange failover. This method does require that the operating system, updates, applications and application patches be pre-installed on the target server. Updates to the source should also be done on the target. A significant advantage of this approach is that failover can be from an Intel-based server to an AMD-based one or from a 32-bit OS server to a 64-bit one (or vice versa). Each may have different device drivers that correspond to their specific hardware components. Even application versions can be different between the source and target, though this is more commonly the case for a migration project than for high availability or disaster recovery purposes. Application-level failover is typically faster since no server reboot is involved and may only take a couple minutes. Application-level failback is also very easy. While users continue to work productively on the new or restored target, the first step is mirror the existing application data back and replicate ongoing changes in real time. If there is no application data present on a replacement server, then a full mirror will be done. If, however, some of the data is present then an intelligent difference mirror can be done. For file servers this is done on a file-by-file basis. For email and database servers, a very efficient block checksum difference mirror is done that doesn’t depend on the file timestamps being correct. Email and database applications working within large files often don’t perfectly update the timestamps. SAN array-based replication can be used from the original target during this time. Once the mirroring process has completed, at any convenient time – because ongoing changes are still being replicated in real time – the necessary IP address, hostname, Active Directory and DNS changes are made in reverse and the appropriate services are started. Once the original target again begins monitoring the source, application-level protection continues like before. Users may not even know that anything had happened. The second approach, protecting the entire system state, has many similarities to the application-level one. All of the network, hostname, Active Directory and DNS changes can automatically be made also. But the target only needs to have the base operating system initially installed. During the initial mirroring and ongoing replication processes, the operating system updates, the applications and their patches are all stored in a staging directory on the target. When a failover occurs, these are all installed on the

SAN Array-based Replication target server, which then reboots and becomes operational with all the other changes made. The result is that its services are again available to the users. How long this takes depends on the typical reboot time and how many applications needed to be installed but generally is in the ten to twenty minute range. The major advantage here is that, especially with a legacy server where no one may know how to install and configure the applications, the initial system preparation time is just loading the base operating system. That fact makes this ideal for migrations, as well as the high availability and disaster recovery protection of a legacy server. It is also ideal when significant registry changes are made, such as with domain controllers dedicated or combined with other applications like Small Business Server does. To reverse the process is going from the original target back to the original or replacement source server.

What implication does virtualization have on disaster recovery and business continuity and how does it affect the underlying storage? The examples given so far have focused on physical servers but certainly virtualization is extremely popular. If one’s environment is all virtualized workloads of the same technology, then choices can be made using products within the same family. But frequently there is a mix of physical servers and virtual workloads, as well as more than one virtualization technology. A December 2009 survey reports that almost two-thirds of customers running VMware products have already evaluated alternatives and may run a mixture of virtualization technologies In all these situations, Double- Take Availability has significant advantages. Many have found that using a single Disaster Recovery / Business Continuation solution avoids adding complexity in the midst of a disaster. Virtualization encapsulates the workload as a set of files which is independent of the hardware where it runs. While a volume in the physical world still appears to be a volume in the virtual workload, it is actually just a file on the physical host of the virtual workloads. That file typically has a .vmdk file extension in the VMware ESX/vSphere environment and a .vhd file extension in the Microsoft Hyper-V environment. As one can see from the diagram below, SAN array-based replication won’t work from a physical volume to a virtual volume. But because Double-Take Availability runs on the host, be it on the physical server or inside the virtual workload, Double-Take Availability can replicate data between these different environments. Double-Take Availability works with any mixture of physical servers and virtual workloads – P2P, P2V, V2P and V2V – so this is referred to as X2X protection.

Are there business requirements which dictate the use of some of the unique advantages of host-level replication as provided by Double-Take Availability? Double-Take Availability has two companion products, Double-Take Move and Double-Take Backup. Even in SAN environments both have distinct benefits. All use the same proven replication and mirroring technologies as Double-Take Availability. Double-Take Move migrates servers, workloads and storage little to no downtime. Double-Take Move includes the replication, mirroring and automated failover components that make the necessary network, Active Directory and DNS changes. Run in the background while the source still does its usual production work, it does full system state protection – operating system, OS patches, applications, application updates and data – to a different hardware configuration. It works with any combination of physical servers and virtual workloads – P2P, P2V, V2 and even V2P. When convenient, the actual full system state failover is accomplished with only minutes of minor interruption that users often don’t even notice. Though it doesn’t include the failover components, Double-Take Backup can protect the system state and/or data from scores of servers and workloads to a single target. Unlike tape or even de-duped backups whose data is usually hours or days old, DoubleTake Backup keeps data current in real time. It also works with any combination of physical server and virtual workload. Leveraging Microsoft’s Virtual Shadow Copy Services (VSS) on Windows, an individual file or the entire system can be recovered to the most recent version or any snapshot version. Many companies are finding this a different and far less expensive solution with far superior Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs) than traditional backup solutions.

SAN Array-based Replication Summary The critical issue after a disaster is how quickly users can again work productively. Replicating data to other sites is one issue. More important is having programs and processes start, as well as Active Directory and DNS changes made, so that users can reach the targets just like before the disaster when the sources failed. For many, an automated failover process with minimal to no human intervention is needed to get users working again in a matter of minutes. For others, a more time-intensive manual process may be acceptable. SAN array-based replication methods may be perfectly acceptable for synchronizing data to other locations. Double-Take Availability can automate the failover process of the operating system, network, and applications. These can be on non-SAN array (internal or directly attached) storage or even on separate SAN volumes not configured for SAN array-based replication. Double-Take Availability can accommodate the differences in brand, processor, operating system and adapters that may occur with a replacement server or component. Both application and full system state protection and failover are available to achieve the diverse situations one may encounter. Double-Take Availability works equally well protecting physical and virtual workloads to any type of target. Even the virtualization technology can be different (e.g., a vSphere virtual machine to a Hyper-V virtual machine). Double-Take Move can be used to initially move the data and even the operating system and application configurations from dissimilar storage to a new production environment. Double-Take Backup can protect numerous workloads to a single target for individual file or complete system recovery later.

QUESTIONS?

1-888-674-9495 [email protected] www.doubletake.com © Double-Take Software, Inc. All rights reserved. Double-Take, Balance Double-Take Cargo, Double-Take Flex, Double-Take for Hyper-V, Double-Take for Linux, Double-Take Move, Double-Take ShadowCaster, Double-Take for Virtual Systems, GeoCluster, Livewire, netBoot/i, NSI, sanFly, TimeData, TimeSpring, winBoot/i and associated logos are registered trademarks or trademarks of Double-Take Software, Inc. and/or its affiliates and subsidiaries in the United States and/or other countries. Microsoft, Hyper-V, Windows, and the Windows logo are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. Linux is a registered trademark of Linus Torvalds. Red Hat is a registered trademark of Red Hat, Inc. Novell, the Novell logo, the N logo, SUSE are registered trademarks of Novell, Inc. in the United States and other countries. All other trademarks are the property of their respective companies.