Friday, November 15, 2013
In so many cases it’s the item that gets dropped first when push comes to shove and the budget needs to be cut. But does that really save money? Or could that decision come back to bite you where it hurts? We hear the reasons time and time again for cutting DR – it’s too expensive, it’s too complex, it won’t happen to me and, the classic, we have backups. But how many organizations have looked, really looked, at what downtime could cost them with no DR in place to save them?
Downtime is not a rare occurrence. In fact it’s the opposite. In a survey conducted in 2012 by Ponemon Institute, 86% of the organizations surveyed had experienced one or more occurrences of system downtime during the previous 12 months that had, on average, lasted 2.2 days. For a business, that downtime means lost productivity at a cost of approximately $366,363 per year! But that’s not the final tally. Add to those costs the potential expense of replacing hardware together with soft costs (the ones that so many businesses forget about) such as reputation and the opportunity costs of lost new sales, and suddenly the costs of your downtime have rocketed. Downtime can (and does) happen to any business at any time. Natural disasters may grab the headlines but they aren’t the most common cause of downtime. Neither is cybercrime (which, btw, is on the increase). It’s human error that’s the most frequent cause of a disaster.
In our business we’ve seen and heard numerous examples of human error – both internal to an organization and external. One of our favorites is the server room that suffered 100-degree-plus conditions, even though the thermostat was set to 64 degrees. The problem in this case was that someone changed the setting from Fahrenheit to Celsius. The result? Melted drives. There are many more OMG stories out there.
Let us know what your most memorable outage is and we may well include it in our upcoming webinar 5 Reasons to Keep Disaster Recovery in your 2014 Budget.
Thursday, August 22, 2013
The cloud parade is rolling and there’s no stopping it now. It’s no secret that employees on the business side of organizations have turned to the cloud in increasing numbers because they’re equipped with the knowledge and means to sidestep IT and use a tool that speeds up processes and reacts quicker to shifting market conditions. However, when IT becomes a business partner and proactively gets involved in setting strategy and developing cloud management capabilities, amazing things happen! We know because we’ve seen it first-hand with our own customers.
Organizations move workloads to cloud environments for a host of different reasons. Often the pain points underlying those reasons are similar but the approach to solving them is different for each business. Our job is to work closely with customers to find the best possible cloud solution fit. We’ve seen organizations grow rapidly because they’ve been able to quickly spin up virtual machines in the cloud to take advantage of a shift in their business climate. We’ve seen departments of larger organizations successfully implement a cloud environment and as a result become the poster child for the rest of the organization to follow suit. And we’ve seen IT leaders sleep again at night because they no longer worry about they’re infrastructure going down.
If you’re attending VMworld this year and you’d like to discuss best practices, pragmatic strategies and planning do’s and don’ts from peers that have already begun their cloud journey, drop by our booth #2422 and we can share with you what we’ve learned from our own experience of working alongside customers.
Learn more about iland Enterprise Cloud Services, iland CloudConnect, iland Continuity Cloud Services with Zerto, how iland is leveraging VMware vCloud® Connector™ Advanced Edition to provide a secure hybrid cloud environment for customers and more.
And last but not least, iland and Zerto are co-hosting a Disaster Recovery Innovation Exchange event on Monday that offers a fun, informative evening of wine tasting and networking along with a drawing for a chance to win prizes.
We look forward to seeing you at VMworld 2013!
Thursday, July 11, 2013
Site Recovery Manager (SRM) uses Protection Groups and Recovery Plans for disaster recovery and both need to be applied when you want to either run a test of your disaster recovery plan or when disaster recovery is initiated for real.
Protection Group Configuration
Protection Groups are pointers to the replicated virtual machines that will be failed over from the Protected Site to the iland Recovery Site. Virtual machines must be configured in a Protection Group so that SRM can add them to the vCenter Server inventory at the iland Recovery Site.
The 6 Steps Required for Configuration of a Protection Group
- Log on with vSphere client to your Protected site.
Select the Protection Groups pane and click the Create Protection Group button.
In the Create Protection Group dialog box choose VR.
Select the VM to be included in the Protection Group.
Add a name for the Protection Group Name.
Click “Finish” to complete the creation of the Protection Group.
During the creation of the Protection Groups, your Recovery Site vCenter will begin registering the placeholder VMX files in the current location in the inventory. The creation of these placeholder VMs with the new lightning bold icon, makes them easier to distinguish in the Recovery Site vCenter inventory.
SRM knows which network, folder and resource pool to put the recovery VMs into because of the default inventory mapping settings that were specified earlier.
Deleting Protection Groups at the Protected Site vCenter reverses the registration process. When you delete a protected group, it unregisters and destroys the placeholder files created at the Recovery Site.
Recovery Site Configuration
You are now close to running your first test plan. Up to this point the configuration process has been held at the Protected Site vCenter. However, the critical piece with SRM is the creation of a Recovery Plan. The Recovery Plan contains multiple settings and gives you the ability to configure the following:
- The list of protected VMs in the protection group
- Startup order for the VMs
- Custom steps if applicable
- Network settings during the testing of plans
7 Steps for Creating a Full-Site Recovery Plan
- Log on with the vSphere client to the Recovery Site's vCenter.
Click the Site Recovery icon.
Select the Recovery Plans tab and click the Create Recovery Plan button.
Select the Recovery Site where the plan will be recovered. In this case it will be the Office-vctr3 (Recovery Site).
The appearance of “(Local)” next to a site name is dictated by whichever vCenter you logged into when opening the vCenter server. Remember that Protection Groups reside at the Protected Site and Recovery Plans at the Recovery Site.
Select the Protection Group that will be included in the plan
In the Test Networks dialog box you can control what happens to the networking of VMs specifically when you test a Recovery Plan. You can set up a dedicated VLAN if you don't want the system to automatically create a new isolated network environment.
The Auto option creates an “internal” Standard vSwitch called a “bubble”. This ensures that no IP or NetBIOS conflicts can occur between the Protected Site VMs and the Recovery Site VMs. You can override this behavior and map the port group to a Recovery Site vSwitch but watch for conflicts.
Give your Recovery Plan a name.
- Click Next and then Finish to create the Recovery Plan.
Protection Groups and Recovery Plans form significant components of Site Recovery Manager. By following a few easy steps you can ensure that not only will your disaster recovery testing be successful but when a real disaster strikes you will have the confidence that your data and systems will be successfully recovered.
Site Recovery Manager: Five Steps to Replicate Virtual Machines using Replication Seeds or Physical Courier (Part 5)
Thursday, May 16, 2013
To ensure efficient replication of virtual machines (VM), there are times when, due to lack of bandwidth and large virtual disks, carrying out an initial online synchronization is simply unfeasible. When that situation occurs you can download the virtual disks that make up a VM to media such as a USB drive, and then have the data securely couriered to the target iland Recovery Site.
The process is simple:
- Copy your VM(s) to external media and transport to the iland Recovery Site
- As long as the directory and file naming is the same, Site Recovery Manager will sense that it is the same VM and use that to seed the replication
- Confirm the directory in the targeted datastore and click ‘Yes’ to complete the configuration replication wizard.
The process begins by taking a maintenance window on the VM, and powering it down. You can then use the vSphere datastore browser or a 3rd party tool such as Veeam to download the virtual disk to some type of removable media. For the purposes of this blog post, Veeam will be used in the replication example set out below. Simply follow these steps:
Step 1. To begin, download and install Veeam Backup Free Edition. Then identify both the VM to be replicated and the host that has the VM in the Protected Site. The next step is to identify the datastore location of the VM to be replicated, launch Veeam, and connect to the identified ESXI host.
In this example, the VM to be couriered is SRM-Demo. SRM-Demo files are in datastore “500GBSATA-VOL2”. You will need to take a snapshot of the VM SRM-DEMO before starting the copy process.
Step 2. Access the “500GBSATA-VOL2”datastore and select right click on the SRM-Demo folder to be copied. Drag and drop to the designated drive
Step 3. Once the VM has completed downloading to the removable media, attach the media to a workstation in the Recovery site network and upload the files to the Recovery site hosts and datastore.
Step 4. You can then right click the VM to be replicated at the Protected site to launch the vSphere Replication wizard.
Step 5. Confirm the datastore locations of the VM to be replicated by vSphere Replication.
If a file with the same name exists, vSphere Replication prompts you with a warning and offers you the option to use the target disk as a seed for replication. If you click ‘Yes’, vSphere Replication compares the differences and replicates only the changed blocks after the VM replication is fully configured and enabled. If you do not accept the prompt, then you must change the target location for your replication.
Finally, complete the wizard and replication is enabled.
The benefit of replicating data in this way is that your bandwidth requirements from the protected site to the recovery site are significantly reduced and therefore costs are lowered. Typically organizations use either physical courier or replication seeds when there is a concern for bandwidth consumed during an initial copy of a virtual machine across the WAN. The replication seeding option with vSphere Replication allows iland customers to overcome this limitation with “seeding” a copy of the Virtual Machine VMDK files in the remote datastore and synchronizing the changed blocks at the DR datastore.
Thursday, April 11, 2013
In this fourth part of our series of posts on Site Recovery Manager (SRM) I identify the steps required to enable and monitor vSphere replication (VR). Historically, replicating data from one site to another was typically a costly endeavor. For decades, array-based replication technology was the de facto replication platform but, since the introduction of VR, that is no longer the case.
VR allows you to replicate virtual machines from your primary site to your secondary site in the iland Cloud. It is asynchronous-based and allows you to set your recovery point objective (RPO) as low as just 15 minutes – a very short time between replications. However, although a shorter RPO means less data is lost during a recovery more network bandwidth is consumed in keeping the replica up-to-date. In addition, the primary and secondary sites must be connected for you to be able to configure and enable replication.
VR is built for virtual machines only and replicates on a per virtual machine basis. It cannot replicate templates, physical RDMs or ISO files and it cannot replicate powered-off virtual machines. Replication begins once the virtual machine is powered on. Let’s examine how to replicate a virtual machine with VR:
To enable VR on a virtual machine follow these steps:
1. Ensure that the selected virtual machine is powered on; then right-click it and select 'vSphere Replication'
If you want to protect multiple virtual machines, switch to the VMs and Templates view, select a folder and then select the Virtual Machine tab. Select multiple VMs using either Ctrl-Click or Shift-Click; once your selection is complete, right-click and choose 'vSphere Replication'
2. You can set an RPO to determine the period of time between replications. For example, an RPO of 1 hour seeks to ensure that a virtual machine loses no more than 1 hour of data during the recovery.
Guest OS Quiescing types are determined by the virtual machine’s operating system. Microsoft VSS quiescing is supported for Windows virtual machines running Server 2003, XP or newer. VR does not support quiescing for Linux and older versions of Windows such as 2000. VR supports file system level quiescing for Windows 7 and Windows Server 2008 and application-level quiescing for Windows Server 2008 and Windows Server 8 operating systems.
Target File Location - you specify the target location for your virtual machine. You can either replicate the whole virtual disk initially or use the existing disk as a replication seed.
3. Leave the defaults and click Next.
4. Leave the default for the VR Appliance and click Next.
5. Click Finish to start the Replication.
6. Go back to Home, select SRM and click vSphere Replication. Select the VR appliance on the Target and confirm the replication status of the VM being replicated.
Site Recovery Manager is enabling increasing numbers of organizations to integrate disaster recovery in the cloud as part of their business strategy. Part 5 in my SRM blog series will examine the challenges of migrating large amounts of data to your secondary site in the iland cloud.
Friday, November 9, 2012
Using traditional methods to migrate applications and data to the cloud is typically time-consuming because production servers may have to be brought to a standstill in order for the migration to be executed. You also have to keep in mind your storage footprint - the larger the storage footprint, the longer the migration process will take. In fact, large system migrations can typically take hours or days to complete.
The cloud has become increasingly popular as a platform to host business applications because it offers a very cost-effective and flexible IT platform for many organizations. But how do you get your existing applications and data into the cloud? That’s a question we are frequently asked here at iland.
One way is to migrate your data from a file server using traditional data copying tools but you need to ensure that users cannot change any data while the migration is taking place otherwise changes to files that have already been copied will be lost.
You may also need to create a plan for recreating the file shares, permissions, compression, encryption and other settings on the new storage. This can translate into further hours of downtime even if everything works as planned the first time—and much longer if it doesn't.
At first glance it may seem daunting but don’t worry - there are simple ways you can overcome these challenges and perform data migrations without disrupting production applications and shutting down their servers.
Double-Take Move and Double-Take Availability are migration and data replication tools that allow you to migrate physical and virtual workloads with complete data protection. Leveraging Doubletake replication not only allows you to address the migration process for moving applications and data into the cloud. It also offers a way to automatically avoid or correct any migration errors that may occur.
Doubletake replication offers exceptional application and data protection/migration in virtual and cloud environments. Thanks to a single unified management console it is easier to use than ever before.
Six Reasons Why Double-Take Availability Provides Superior High Availability
- Simplicity - Set It and Forget It data protection includes advanced features that automate the initial setup and ongoing management of your availability environment.
- Plug and Play Protection - Double-Take’s pre-configured Universal Virtual Recovery Appliance for physical and virtual environments gives you a plug and play option for extending the protection of your virtualized environment.
- Real-time Replication – Offers you superior protection compared to snapshots because it ensures the uninterrupted availability of critical application systems and virtually eliminates the potential for data loss.
- Zero Downtime during Migrations - Replication technology allows users to remain active while Double-Take Availability is recreating the production environment on the new system.
- Platform Independence - Double Take Availability allows you to cost-effectively protect more of your environment.
- Simplified Management - A unified console makes it easier to implement, manage and extract value from a powerful High Availability environment.
The following steps detail how to configure the Doubletake replication/migration process:
Doubletake Replication Process
Data Sync Tabs
Always select these settings when setting up a replication set:
- Start, Programs, Double-Take, Double-Take replication Console
- Double-click over SOURCE server and login with local admin accounts
- Right-click over SOURCE server and select, New, Replication Set from the menu
- Name the replication set “sourceservername_newservername-rep”
- Double-Click replication set and select files and folders stated in the Sync/move package
Right-click over replication set and select “Save”
Right-click over Replication Set and select “Connection Manager”
Select the “Mirroring” tabs and make sure the following is selected
- Click the “Servers” tab and select the target
- If a direct sync job do a one-to-one mapping
- If the move package/sync job states to copy to another directory, select and “All to One”
(NOTE: Start Mirror on connect and Start replication on connection are marked off by default)
- Select “Connect” and the replication job will start
- The job can be viewed from the SOURCE server
When job the Mirror status states “Idle”, the Disk Queue states “0” and the Replication Status reads “Ready” the job is complete
Disconnect the replication set to break the connection/ complete the job
Thursday, September 20, 2012
Historically, disaster recovery (DR) solutions have been difficult and costly to implement. DR has been a pain point for many IT administrators who have to maintain consistency across duplicate hardware in various locations, document and maintain detailed run books, react to changes in the environment, and schedule testing that is classically disruptive to the production environment. And replication solutions are often time-consuming. They require you to back up data and manually transport the back-ups to a different location.
iland offers a number of cloud-based DR solutions that dispel many of these traditional DR issues. One of these solutions leverages the Dell EqualLogic PS Series built-in Auto-Replication feature to make disaster recovery a rapid, manageable, reliable, and affordable process. Through EqualLogic’s Snapshot and Auto-Replication capability in the iland cloud, end-to-end data protection is now possible.
At the customer site EqualLogic SAN snapshots offer quick recovery based on:
- Volume changes
- Snapshot schedule
- Need to recover
In the iland cloud:
- Critical volumes or possibly all volumes are replicated
- A secondary site is available for operation if the customer site fails.
The EqualLogic replication service is performed between the primary customer site and the iland cloud.
To set up an EqualLogic replication service in the iland cloud, iland sets up a site-to-site VPN tunnel between your site and the iland cloud. These two PS Series groups are then configured as replication partners and iland provides you with your delegated space for replication. The volumes designated for DR are selected allowing you to push your data to iland’s SAN infrastructure.
As shown in the diagram above, once the volumes’ replication is completed, the volumes become replicas in the remote site. Replicas are similar to snapshots in that they represent the contents of the volume at a specific point in time. And replicas ensure that the iland group always preserves a complete and stable copy of the volume data.
The initial push of data to the iland cloud can be challenging if the replication partnership occurs over a slow data link. EqualLogic provides its Manual Transfer Utility to save the initial replica image to external media, physically ship it to iland and restore the image from the external media.
Now that we have discussed how EqualLogic replication is configured, what happens when a real DR event occurs? iland provides two alternatives for that possibility:
EqualLogic Array-Based Replication only:
This option provides a cost effective offsite data storage with an option to have VMware-based images (4.x or higher) powered on in the event of a disaster.
EqualLogic Array-Based Replication with Standby Managed Cloud Resources:
This option provides cost effective offsite data storage with guaranteed resources for VMware-based images (4.x or higher).
In disaster recovery situations, iland takes over from the primary site. When the primary site is ready to resume its original role, iland uses replica failback to efficiently synchronize the changed data on the secondary site with the primary site. Unlike many cloud providers, iland gives you the ability to test your DR solution once a year for free. You also have the ability to test more than once a year if you require.
An EqualLogic replication service in the iland cloud offers a very effective and low-cost solution for your disaster recovery strategy.
Thursday, August 30, 2012
Disaster recovery has become, well… a disaster, depending on who you talk to. There are numerous details that have to be considered prior to DR implementation: RTO (recovery time objective), RPO (recovery point objective), what to back up, retention policies, and perhaps most importantly, how the DR environment will be accessed by end users. In other words, how will your end users be affected?
Even after all of this has been determined, a company must make yet another important decision - how do we make it happen? Some organizations have the luxury of multiple datacenters at their disposal, large IT departments, and the expertise to implement their strategies in-house. But the majority of companies simply don’t have the staff, facilities, or experience required to attain their DR goals.
By leveraging VMware vCloud Director, iland provides a cloud-based DR solution that makes implementation, deployment, and the management of the DR plan easier—IT staff are able to configure their security layers and deploy virtual servers in minutes. vCloud Director is essentially a Web-based, self-service view of the cloud. It includes 10 Gigabit Ethernet connections to multiple Tier 1 providers, enterprise firewall services, and role-based access control through the integration of your directory services.
Because you have control over your DR environment, you can fine tune it to make sure it meets your business’s standards and test it as frequently as you want. Ultimately, you control your end users’ experience.
The takeaway here? The implementation and management of your DR plan doesn’t have to be a strain, nor do your customers have to take the brunt of unnecessary or unplanned downtime. vCloud Director is an effective tool that’s already preparing businesses (of all sizes) for natural and manmade disasters without having their customers feel the effects. iland and vCloud Director are changing things for the better.
Friday, August 17, 2012
This week I want to cover the three major hurdles companies face when planning, implementing and executing a disaster recovery (DR )plan.
How do I get the initial data and subsequent differentials over to iland?
How do my end-users access the environment at time of failover?
How do I get my data back after failover?
There are many variables to consider for each of these questions but for the sake of this blog we will try to focus on common elements. There are three main factors to consider when determining the feasibility and success of a long term DR plan:
The actual amount of bandwidth (specifically upload) available for the replication of data between sites.
The change rate that occurs on guests you wish to replicate.
The frequency of replication you want to achieve.
Bandwidth – this is of huge importance when considering a disaster recovery site. The amount of available upload speed can show you the maximum amount of data that you can push across the WAN in a single day. (Note: a quick and easy calculation is to take the amount of upload speed available in Mbps and multiply by 9; this will show you your maximum data transfer per day in GB i.e. 10 Mbps would allow for about 90GB of data transferred in a day).
Change rate - the change rate in your environment can typically be captured if you are already performing backups or snapshots in your local environment. This change rate can help you determine the actual amount of data you will need to replicate between sites to keep your systems synchronized.
Replication frequency - the frequency of replication can help you factor in the multiplier you need to use on your change rate. (If you are measuring your change rate per day but plan on replicating every hour, you will need to factor in the increase in replication this will trigger because the same blocks on a server may change between every replication period rather than once daily).
Even with sufficient replication speed to accommodate your change rate, you may have an initial amount of data that seems unfeasible to replicate across the WAN. To overcome this for all iland managed DR products, iland ships you an encrypted drive for the initial seeding of data. Once iland imports this data, most customers can simply begin differential replication which greatly expedites the deployment process.
Access to data at the iland site during a failover test or actual DR event can vary according to customer needs. For some customers the majority of their environment is internal facing, while others may rely on WAN-based connectivity for all their servers. Whatever the customers’ requirements, iland provides solutions that support IPsec Site-to-site VPN, SSL and Client VPN, Terminal services, app streaming, NAT and access-list configuration, and the ability for a customer to tie in an existing MPLS or point-to-point circuit. Many iland managed DR solutions allow customers to keep their existing internal subnet assigned to the machines replicated, allowing for faster failover and seamless integration with secondary sites.
Getting data back after a DR event can vary based on the severity of the customer outage. For customers that have a site failure but all their data is still intact, iland DR solutions support failback options designed to simply replicate back the changes that have occurred between failover and cutback. For customers that lose all local data, iland can support the initial seeding of data back to their site using the method outlined for initial seeding above.
Regardless of a customer’s DR goals, iland has a variety of flexible, cost-effective options available to ensure our customers are protected.
Tuesday, May 29, 2012
If you’re considering implementing a cloud-based disaster recovery plan for your organization, there are a number of items you need to think about with respect to what you currently have in place and what you may need to add. Employing a cloud environment for your DR can’t be done on a whim. It requires careful thought, so here’s a checklist to help get you started and hopefully make your cloud-based discussions with both your internal teams and cloud-based providers a more productive experience:
Identify Your Current Infrastructure Environment
How your current IT infrastructure environment is configured is an important piece of your DR plan and you’ll need to ask yourself these questions:
* What kind of storage do we currently have?
* What systems do we currently have in place?
* What is our mix of physical and virtual machines?
* Have we already tiered our applications? If not, do we need to?
* In the event of a disaster, do we want instantaneous failover or are we comfortable with some downtime? If the latter, how much downtime?
Identifying these areas of your IT environment gives you a solid base from which to start planning your cloud-based DR implementation.
Determine Your Bandwidth
Bandwidth costs have seen considerable reductions over the past few years but the amount of bandwidth you currently have will have a direct effect on the speed, recovery time and amount of data you want stored in a cloud environment. You need to ask yourself:
* What bandwidth do we currently have available for upload?
* What RPO do we want?
And for those that already have a DR plan in place, what sort of change rate are you seeing in your environment? If your company has recently adopted an aggressive growth strategy you may be looking at much larger bandwidth requirements.
Executive Team Buy-In - do you have buy-in from your executive management team? To encourage their support of your DR planning, ask them what your company would do with none of its data and systems available. Would it survive? Customers today are used to instant gratification - would they really stay with you if you’re down for any length of time? Or would they simply switch to your closest competitor?
Budget – be realistic with your DR plan when it comes to budget. In our experience, most organizations start their DR discussions wanting immediate failover and recovery – until they find out the true cost. At that point they’ll determine what they really need and what they can manage without depending on the budget available. iland is adept at providing appropriate cloud-based DR solutions that fit within budgets for our customers.
Testing – how are you going to verify that your DR plan works? The only surefire way is to test it. Cloud-based DR has made testing much easier to execute so we strongly recommend an annual DR test to find out what works and what doesn’t. iland offers a complementary annual DR test.
Unfortunately, a well-conceived, cloud-based DR plan comes too late for the majority of companies that don’t have one when disaster strikes. There are a few lucky businesses that survive downtime during a disaster but they usually conclude that an effective DR plan isn’t just a nice-to-have. It’s a necessity. And that’s when iland gets the call…..