![Disaster Recovery challenges ,[object Object],[object Object],[object Object],[object Object],* Reported by Eagle Rock Alliance Ltd., “ONLINE SURVEY RESULTS 2001 COST OF DOWNTIME”](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
Viewers also liked
Viewers also liked (18)
VMware’s SRM & FalconStor NSS Data Recovery
- 1. Disaster Recovery Solutions for VMware Peter Eicher Product Marketing Director
- 4. What to look for in a DR solution for VMware
- 5. What to look for in a DR solution for VMware
- 7. The VMware and FalconStor Solution Industry Standard Disk Array VirtualCenter Virtual Machines Production Site Disaster Recovery Site Standby virtual machines Application Snapshot Agents VMware Infrastructure Application Snapshot Director Site Recovery Manager with Storage Replication Adapter FalconStor Application Snapshot Agents FalconStor Application Snapshot Director FalconStor Network Storage Server Site Recovery Manager Storage Replication Adapter ESX Servers FC or iSCSI Industry Standard Disk Array VMware Infrastructure Virtual Machines VirtualCenter ESX Servers Site Recovery Manager Storage Replication Adapter Application Snapshot Director Application Snapshot Agents FC or iSCSI FalconStor NSS and Thin Replication
- 19. Thank You. Any Questions? Contact us Corporate Headquarters 2 Huntington Quadrangle Melville, NY 11747 USA Tel: +1 631.777.5188 Support: +1 631.777.3332 [email_address] Asia Pacific Headquarters 6F-1, No.521, Sec. 1, Wunsin Rd. Taichung 40848 Taiwan Tel: +886-4-2259-1868 [email_address] European Headquarters 58 rue Pottier 78150 Le Chesnay France Tel: +33.1.3923.9550 [email_address]
Editor's Notes
- Recovery from site failures remains one of the most difficult and complex aspects of IT. Traditionally, DR plans involve many complex manual steps, are difficult to test, often take longer than expected to validate application data integrity, and require expensive duplication of the production data center infrastructure. Because of cost factors, many companies are unable to provide sufficient disaster recovery protection within their desired timeframe and budget for more than a select few of their important production systems.
- While virtualized server environments provide many benefits, they bring their own challenges in terms of disaster recovery. A standard means of backing up virtual machines is to use backup agents inside the virtual machines, at the application level. This fits easily into well understood backup models, but there are problems with this approach. Physical server resources tend to be highly utilized. This is by design. The reason you moved to a virtual server in the first place was because your physical servers were underutilized and you wanted to consolidate virtual resources onto fewer physical resources. However, this means your physical servers are running at much higher rates of CPU and memory usage, as well as much high I/O rates (both for IP network and storage network). This squeezes out most of the free capacity needed for running backups. VMware uses the VMDK file format, which is a large “blob” file that contains the virtual machine. If you just backup the VMDK file while the ESX server is running, you end up with a data image that is crash-consistent, at best. This means recovering from that image can take a long time as applications run through consistency checks and so on. In the worst case, data will be corrupted and the system may be unusable. You may start a virtual machine only to see it bluescreen on you. In order to get transactionally consistent backups, you need to shut down the VM before backing up. Because this means a lot of downtime, you can instead use storage-level snapshots of a shutdown VM. However, coordinating the shutdown, snapshot and backup process will either require daily manual effort, or it will require very sophisticated scripting abilities, which have to be done for every virtual machine. From a DR perspective, you also need to concern yourself with the coordination of virutal machines and physical storage. You no longer have a clean one-to-one server-to-storage relationship. Instead, you may have many virtual machines all using the same storage LUN, giving you a many-to-one relationship. And when you replicate this data to another site, the many-to-one relationships may be different, because you have different combinations of ESX servers and virtualized applications.
- So what are the things to look for in a proper DR solution for VMware? Time to Recovery The most basic point of any DR solution is to capture the data successfully at a separate location. However, once that is done, the next most important factor is time to recover. How long will it take me to restart my systems? Because until your systems restart, you’re out of business. Remember, we’re not talking about restarting a bunch of computers. We’re talking about restarting your business. If every server takes hours and hours to start because databases have to be rebuilt, logs have to be played, etc., then you are suffering from severely extended downtime. Systems should be ready to go immediately after a boot cycle. Application/Transactional consistency Data consistency is the factor that’s is going to make your time to recovery fast. You can’t resolve the first issue unless you resolve this one. When you capture data images, they must be transactionally complete. System Manageability When a disaster strikes, the last thing you want to be doing is trying to figure out what belongs where, or if you’ve got all your virtual machines properly aligned with your storage (given the complexities we spoke of earlier). Your DR solution should have a way to automate and verify that all the pieces are in place.
- WAN Bandwidth Utilization When you consider DR costs, the largest cost isn’t servers and storage. It’s bandwidth. Bandwidth is an ongoing, never-ending DR cost. Many DR solutions, especially array-based solutions, are highly inefficient when it comes to using bandwidth. For instance, they will replicate far more data than actually changes at the disk level because they are using very large granularities when they examine disk changes. Your DR solution should minimize the amount of data sent over the wire. Ideally, it will work at a sub-block, disk-sector level. The smallest possible such level is 512bytes. If your DR solution has a granularity larger than 512 bytes you are introducing inefficiencies into the system. Freedom of Choice You don’t want a DR solution that locks you into any specific storage device or storage protocol. DR is expensive, and one way to reduce costs is to be able to use whatever storage and protocols fit your performance and costs needs. For example, you may have key production applications running on very high-end, fast performing disk arrays. But the price level of these devices is outside your DR budget. Unfortunately, the DR tools built-in to the array only work within the same array family. You have no choice in the matter. Your DR solution should let you replicate from any array to any other array. This means you can deploy Tier 2 storage at your recovery site if that’s what fits your budget. Similarly with protocols. You may have a FC SAN at your production site, but you don’t have the budget for an FC SAN at your DR site. Your DR solution should let you use FC at one side and iSCSI at the other. DR Plan Testing One of the most painful jobs for any IT manager is disaster recovery testing, yet it’s also one of the most important jobs. Still, it’s so painful that many IT operations never test their DR plans, and others test only once or twice a year. (And “testing” doesn’t mean “passing”!). Your DR environment should be easily testable, preferably in an automated manner. Failback DR is not a one-way street. At some point you will need to rebuild the primary data center, either physically or from a data standpoint. For instance, you may have a power failure that doesn’t physically harm the primary infrastructure. However, because you switched to your DR site, you’ve now accumulated data at the DR site. How are you going to merge that new data back into your primary operations? Before signing off on a DR solution, you need to ask the question: can I easily restore newly accumulated data back to my primary site?
- [Text from VMware] VMware has been working to leverage the disaster recovery features and capabilities of the VMware Infrastructure platform with a new product developed specifically for disaster recovery. This new product will simplify and automate the key elements of disaster recovery: setting up disaster recovery plans, testing those plans, executing failover when a datacenter disaster occurs, and failing back to the primary datacenter. This new product, VMware Site Recovery Manager, will make it possible for customers to provide faster, more reliable, and more affordable disaster recovery protection than previously possible. Although not a part of VMware Infrastructure, Site Recovery Manager works closely with VMware Infrastructure to manage and automate disaster recovery for virtual environments. [FalconStor addition] Site Recovery Manager is a great product for reducing the management complexities of DR, as well as for automating testing. However, it doesn’t address the issues of data integrity, disk flexibility or efficient bandwidth utilization. FalconStor provides the answer for these issues, combining with SRM to offer a fully DR solution for VMware.
- This slide depicts all the pieces and parts of a VMware/FalconStor DR solution. FalconStor controlled pieces are in blue. We have already discussed what Site Recovery Manager does. The next several slides will drill down into all the specific FalconStor areas.
- The FalconStor Network Storage Server (NSS) is the base platform for providing VMware DR services. NSS is a storage virtualization platform that uses any open-storage disk array, and supports all storage networking protocols: FC, iSCSI and even InfiniBand. Volumes of up to 16TB are supported. Because the storage is virtualized, the size of the underlying volume can easily be expanded.
- The FalconStor Storage Replication Adapter (SRA) provides the connectivity between SRM and the underlying physical disk resources as controlled by the FalconStor NSS server. SRA informs SRM about which virtual disks belong to which virtual servers. SRM then uses this information at the DR site to correlate virtual machines with the proper storage resources.
- FalconStor Application Snapshot Agents are used to properly protect application data. The Agents run within the virtual machine (on top of the application). When a snapshot is requested, the Agent ensures that the application is put into a proper backup mode. This allows the snapshot image to be transactionally complete. However, putting the application into a backup/snapshot mode is not enough in a virtual environment. You also have to deal with the VMware layer, the VMware data image itself.
- The FalconStor Application Snapshot Director for VMware takes care of the VMware side of the snapshot. It coordinates the snapshot process between the application layer (the virtualized application) and the ESX server itself. ASD runs at the ESX level. When a snapshot request is received from the NSS server, the ASD coordinates putting the application into backup mode while at the same time putting the VMware session into a proper backup mode. This process ensures transactionally complete data from top to bottom.
- SRM relies on a disk-level replication model. It does not have its own replication features. FalconStor NSS performs the replication process. A key part of NSS replication is that it uses the smallest possible level of data granularity, 512 bytes, when determining what data to send over the wire. This method is anywhere from 8 to 64 times more efficient than major disk vendor replication models. This means you need less bandwidth, which means less money.
- This slide show the process of recovering from a disaster using SRM. After a site failure, the SRM console drives the recovery process. From within SRM, you select the servers you want to start (Step 1). SRM communicates to NSS, through the SRA (Step 2), to ensure the proper disk resources are assigned (Step 3). Then the virtual machines are started up. Because the data images were created using ASD and application agents, systems start immediately.
- Another key feature of SRM is the ability to test recovery scenarios. The process is very similar to an actual recovery process, with one significant difference. The first step is the same, as SRM communicates via the SRA (Step 1). The SRA then communicates with NSS. But rather than asking it to actually mount the replica volume itself, for a test a snapshot image is mounted (Step 2). This snapshot image is then used to boot the virtual machines being tested (Step 3). Once the machines are successfully started and verified as such, SRM will shut them down and NSS will delete the snapshot that was used for the test process. The entire process is automated and requires no manual intervention other than to initiate the testing.
- The final aspect of your DR solution is the ability to failback. FalconStor replication includes built-in failback capability, also called “reverse replication.” This allows data to move from the recovery site to the product facility once it is back online. In the case of physical loss, the full data set can be transferred. If the physical resources were only temporarily offline (e.g. a power outage) the system can send only the data changes that have accumulated while the recovery site was in operation.
- The FalconStor SRA for use with SRM will be distributed at no cost to FalconStor users.
- To summarize, the combination of SRM and FalconStor hits all the key areas of VMware Disaster Recovery. Application support ensures that systems can boot immediately. Low-granularity replication uses the least amount of bandwidth possible, saving costs. An open approach to storage and storage protocols keeps your DR plans flexible and allows you to save costs. SRM’s testing ability ensures you can have confidence that your recovery will work when it’s needed. Data failback lets you rebuild your primary site after a failure. The management tools included in SRM keep track of systems and storage and let you build DR plans in advance.