Tag Archives: Azure Site Recovery

Replicate Azure Pack IaaS Workloads to Azure using ASR

A few months back, we announced Azure Site Recovery (ASR)’s integration with Azure Pack, which enabled our Service Providers to start offering Managed Disaster Recovery for IaaS Workloads using ASR and Azure Pack. The response, since we announced the integration, has been phenomenal – customers are appreciating the simplicity of ASR and are adopting ASR as the standard for offering DR solution in their environments. The integration of ASR and Azure Pack also enabled Service Providers to offer DR as a value added service, opening up new review streams and the ability to offer better Service Level Agreements (SLA) to their end customers. A key ask that our early adopters have expressed – and that we are delivering on today – is the ability to use Microsoft Azure as a Disaster Recovery Site for IaaS workloads when using Azure Pack.

The new features in the ASR – Azure Pack integration will enable Service Providers to offer Azure as a DR site or to an on-premise secondary site using their Azure Pack UR 4.0 deployments. To enable these capabilities you can download the latest ASR runbooks and import them into your WAP environments. To know more about the integration, check out our WAP deployment guide.

Getting started with Azure Site Recovery is easy – simply check out the pricing information, and sign up for a free Microsoft Azure trial.  

Announcing GA of Disaster Recovery to Azure – Purpose-Built for Branch Offices and SMB

Today, we are excited to announce the GA for Branch Office and SMB Disaster Recovery to Azure.  Azure Site Recovery delivers a simpler, reliable & cost effective Disaster Recovery solution to Branch Office and SMB customers.  ASR with new Hyper-V Virtual Machine Protection from Windows Server 2012 R2 to Microsoft Azure can now be used at customer owned sites where SCVMM is not deployed.

 

You can visit the Getting Started with Azure Site Recovery for additional information.

Announcing the GA of Disaster Recovery to Azure using Azure Site Recovery

I am excited to announce the GA of the Disaster Recovery to Azure using Azure Site Recovery. In addition to enabling replication to and recovery in Microsoft Azure, ASR enables automated protection of VMs, remote health monitoring, no-impact recovery plan testing, and single click orchestrated recovery – all backed by an enterprise-grade SLA.

The DR to Azure functionality in ASR builds on top of System Center Virtual Machine Manager, Windows Server Hyper-V Replica, and Microsoft Azure to ensure that our customers can leverage existing IT investments while still helping them optimize precious CAPEX and OPEX spent in building and managing secondary datacenter sites.

The GA release also brings significant additions to the already expansive list of ASR’s DR to Azure features:

  • NEW ASR Recovery Plans and Azure Automation integrate to offer robust and simplified one-click orchestration of your DR plans
  • NEW Track Initial Replication Progress as virtual machine data gets replicated to a customer-owned and managed geo-redundant Azure Storage account. This new feature is also available when configuring DR between on-premises private clouds across enterprise sites
  • NEW Simplified Setup and Registration streamlines the DR setup by removing the complexity of generating certificates and integrity keys needed to register your on-premises System Center Virtual Machine Manager server with your Site Recovery vault

Networking 101 for Disaster Recovery to Microsoft Azure using Site Recovery

Getting the networking requirements right is a critical piece in ensuring Disaster Recovery readiness of your business critical workloads.  When an administrator evaluates the disaster recovery capabilities that she needs for her application(s), she needs to think through and develop a robust networking infrastructure that ensures that the application is accessible to end users once it has been failed over and that the application downtime is minimized – RTO optimization is of key importance.


Head over to the Microsoft Azure blog to read our new blog that shows you how you can accomplish Networking Infrastructure Setup for Microsoft Azure as a Disaster Recovery Site. Using the example of a multi-tier application we show you how to setup the required networking infrastructure, establish network connectivity between on-premises and Azure and then conclude the post with more details on Test Failover and Planned Failover.

Azure Site Recovery: Data Security and Privacy

Microsoft is committed to ensuring the Privacy and Security of our customer’s data whenever it crosses on-premises boundaries and into Microsoft Azure. Azure Site Recovery, a cloud-based Disaster Recovery Service that enables protection and orchestrated recovery of your virtualized workloads across on-premises private clouds or directly into Azure, has been designed ground up to align with Microsoft’s privacy and security commitment.

Specifically our promise is to ensure that:

  • We encrypt customer data while in transit and at rest
  • We use best-in-class industry cryptography to protect all channels, including Perfect Forward Secrecy and 2048-bit key lengths

To read more about how the Azure Site Recovery architecture delivers on these key goals, check out our new blog post, Azure Site Recovery: Our Commitment to Keeping Your Data Secure on the Microsoft Azure blog.

ExpressRoute + ASR = Efficient DR solution

Microsoft recently announced the availability of Azure ExpressRoute which enabled our customers to create a private connection between their on-premises to Microsoft Azure. This ensured that the data to Azure used an alternate path to the internet where a connection to Azure could be established through an Exchange Provider or through a Network Service Provider. With ExpressRoute customers can connect in a private peering setup to both Azure Public Cloud Services as well as Private Virtual Networks.

This opened up a new set of scenarios which otherwise was gated on the network infrastructure (or lack of it) – key among them were continuous, replication scenarios such as Azure Site Recovery. At scale, when replicating 10’s-100’s of VMs to Azure using Azure Site Recovery (ASR), you can quickly send TBs of data over ExpressRoute.

You can find tons of documentation on ExpressRoute and it’s capabilities @ https://azure.microsoft.com/en-us/services/expressroute/ and TechEd talks in Channel9 @ http://channel9.msdn.com/Search?term=expressroute#ch9Search. ExpressRoute truly extends your datacenter to Azure and organizations can view Azure as “yet-another-branch-office”.

ASR was truly excited with this announcement which couldn’t have come at a better time. Microsoft’s internal IT (MSIT) and Network Infrastructure Services (NIS), being the very first adopters of ExpressRoute has rolled out ExpressRoute as a Network Service, which enables true hybrid cloud experience for all internal customers.

My partners in MSIT (Arvind Rao & Vik Chhabra) helped me get ExpressRoute connected setup and I got a chance to play around with ASR from one of the Microsoft buildings at Puget Sound. The setup which was loaned to me by MSIT looks similar to this (except that MSIT owns both the infrastructure and the network):

image

At a high level, ASR replicates VM (initial and subsequent changes to the VM) to your storage account directly. The “replication” traffic is sent over the green line to “Azure public resources” such as Azure blob store. Once the VMs are failed over, we create IaaS VMs in Azure using the replicated data. Any traffic back to the corporate network (CorpNet) or from CorpNet to the IaaS VM goes over the red line in the above picture.

The results were fabulous to say the least! High throughput was observed during initial and delta replication. Once the VMs were failed over, the traffic to our internal CorpNet and high throughput was observed for that as well. The key takeaway: Once ER was setup, ASR just worked. There was no extra configuration which was required from ASR’s perspective.

How high is “high throughput” – in a setup, where I had 3 replicating VMs, the below picture captures the network throughput when initial replication was in progress:  

A whooping 1.5Gbps network upload speed to Azure – go ExpressRoute, go!

To get the above network throughput, a registry key needs to be set in *each* of the Hyper-V servers

clip_image001

The “UploadThreadsPerVM” controls the number of threads which is used when replicating each VM. In an “overprovisioned” network, this registry key needs to be changed from it’s default values. We support a maximum of 32 threads per replicating VM.

In summary, ASR combined with ExpressRoute provides a powerful, compelling, efficient disaster recovery scenario to Microsoft Azure. ExpressRoute removes traditional blockers in networking when sending massive amounts of data to Azure – disaster recovery being one such scenario. And ASR removes traditional blockers of providing an easy, cost effective DR solution to a public cloud infrastructure such as Microsoft Azure.

You can find more details on ASR @ http://azure.microsoft.com/en-us/services/site-recovery/. The documentation explaining the end to end workflows is available @ http://azure.microsoft.com/en-us/documentation/articles/hyper-v-recovery-manager-azure/. And if you have questions when using the product, post them @ http://social.msdn.microsoft.com/Forums/windowsazure/en-US/home?forum=hypervrecovmgr or in this blog.

You can also share your feedback on your favorite features/gaps @ http://feedback.azure.com/forums/256299-site-recovery. As always, we love to hear from you!

Azure Site Recovery adds InMage Scout to Its Portfolio for Any Virtual and Physical Workload Disaster Recovery

Azure Site Recovery with Hyper-V Replica already supports the ability to set up disaster recovery between your two Windows Server 2012+ Hyper-V data centers, or between your Windows Server 2012 R2 Hyper-V data center and Microsoft Azure. Recently we acquired InMage Systems Inc., an innovator in the emerging area of cloud-based business continuity. InMage offers migration and disaster recovery capabilities for heterogeneous IT environments with workloads running on any hypervisor (e.g. VMware) or even on physical servers. InMage’s flagship product Scout is now available as a limited period free trial from the Azure Site Recovery management portal.

To learn more, download and try out Azure Site Recovery with InMage Scout, please read my colleague Gaurav Daga’s blog Azure Site Recovery Now Offers Disaster Recovery for Any Physical or Virtualized IT Environment with InMage Scout.

You can find more details about Azure Site Recovery @ http://azure.microsoft.com/en-us/services/site-recovery/. If you have questions when using the product, post them @ http://social.msdn.microsoft.com/Forums/windowsazure/en-US/home?forum=hypervrecovmgr or in this blog. You can also share your feedback on your favorite features/gaps @ http://feedback.azure.com/forums/256299-site-recovery

Azure Site Recovery – case of the “network connection failure”

Luís Caldeira is one of our early adopters who had pinged us with an interesting error. Thanks for reaching out to us Luís and sharing the details of your setup. I am sure this article will come handy to folks who hit this error at some point.

Some days back, Luís sent us a mail informing that his enable-protection workflow was consistently failing with a “network connection failure” error message. He indicated that he had followed the steps listed in the tutorial (http://azure.microsoft.com/en-us/documentation/articles/hyper-v-recovery-manager-azure/). He had:

  • Setup SCVMM 2012 R2
  • Created the Site Recovery vault, uploaded the required certificate
  • Installed & configured the Microsoft Azure Site Recovery Provider in the VMM server
  • Registered the VMM server
  • And finally installed the Microsoft Azure Recovery Services agent in each of his Hyper-V servers.

He was able to view his on-prem cloud in the Azure portal and could configure protection policies on it as well. However, when he tried to enable protection on a VM, the workflow failed and he saw the following set of tasks in the portal:

image

Clicking on ‘Error Details’ showed the following information:

image 

Hmm, not too helpful? Luís thought as much as he reached out to us with the information through our internal DL. We did some basic debugging by looking at the Hyper-V VMMS event viewer logs and the Microsoft Azure Recovery Services event viewer log. Both of them pointed to a failure in the network with the following error message”

image

A snip of the error message (after removing the various Id’s): “The error message read “Could not replicate changes for virtual machine VMName due to a network communication failure. (Virtual Machine ID VMid, Data Source ID sourceid, Task ID taskid)”

The message was less cryptic but still did not provide a solution. The network connection from the Hyper-V server seemed okay as Luis was able to access different websites from the box. He was able to TS into other servers, firewall looked ok and inbound connection looked good as well. The Azure portal was able to enumerate the VMs running on the Hyper-V server – but the enable replication call was failing.

You are bound to see more granular error messages @ C:Program FilesMicrosoft Azure Recovery Services AgentTempCBEngineCurr.errlog  and we proceeded to inspect that file. The trace indicated that the name resolution to the Azure service happened as expected but “the remote server was timing out (or) connection did not happen”

Ok, so DNS was ruled out as well. We asked Luis to help us understand the network elements in his setup and he indicated that he had a TMG proxy server. We logged into the proxy server and enabled real time logs in the TMG proxy server. We retried the workflow and the workflow promptly failed – but interestingly, the proxy server did not register any traffic blip. That was definitely odd. So browsing from the server worked but connection to the service was failed. Hmm.

But the lack of activity in the TMG server indicated a local failure atleast. We were not dealing with an Azure service side issue and that ruled out 50% of potential problems. At a high level, the agent (Microsoft Azure Recovery Services) which is installed in the Hyper-V server acts as a “data mover” to Azure. It is also responsible for all the authentication and connection management when sending replica data to Azure. This component was built on top of a previously released component of the Windows Azure Online Backup solution and enhanced to support this scenario.

The good news is that the agent is quite network savvy and has a bunch of configurations to tinker around. One such configuration is the proxy server which is got by opening the “Microsoft Azure Backup” mmc. Click on the “Change properties” in the Actions menu.

image

We clicked on the “Proxy configuration” tab to set the proxy details in Luís’s setup.

image

After setting the proxy server, we retried the workflow… and it failed yet again. Luis then indicated that he was using an authenticated proxy server. Now things got interesting – as the Microsoft Azure Recovery Services agent runs in System context (unlike, say IE which runs in the user context), we needed to set the proxy authentication parameters. In the same proxy configuration page as above, we now provided the user id and password.

image

Now, when we retried the replication – voila! the workflow went through and initial replication was on it’s way. The same can be done using the Set-OBMachineSetting cmdlet (http://technet.microsoft.com/en-us/library/hh770409.aspx)

Needless to say, once the issue was fixed, Luís took the product out on a full tour and he totally loved it (ok, I just made up the last part).

I encourage you to try out ASR and share your feedback. It’s extremely easy to set it up and provides a great cloud based DR solution.

You can find more details about the service @ http://azure.microsoft.com/en-us/services/site-recovery/. The documentation explaining the end to end workflows is available @ http://azure.microsoft.com/en-us/documentation/articles/hyper-v-recovery-manager-azure/. And if you have questions when using the product, post them @ http://social.msdn.microsoft.com/Forums/windowsazure/en-US/home?forum=hypervrecovmgr or in this blog. You can also share your feedback on your favorite features/gaps @ http://feedback.azure.com/forums/256299-site-recovery

Azure Site Recovery – FAQ

Quick post to clarify some frequently asked questions on the newly announced Azure Site Recovery service which enables you to protect your Hyper-V VMs to Microsoft Azure. The FAQ will not address every feature capability – it should help you get started.

Q1: Did you just change the name from Hyper-V Recovery Manager to Azure Site Recovery?

A: Nope – we did more than that. Yes, we rebranded Hyper-V Recovery Manager to Azure Site Recovery (ASR) but we also brought in a bunch of new features. This includes the much awaited capability to replicate virtual machines (VMs) to Microsoft Azure. With this feature, ASR now orchestrates replication and recovery between private cloud to private cloud as well as private cloud to Azure.

Q2: What did you GA in Jan 2014?…

A: In Jan 2014, we announced the general availability of Hyper-V Recovery Manager (HRM) which enabled you to manage, orchestrate protection & recovery workflows of *your* private clouds. You (as a customer) owned both the primary and secondary datacenter which was managed by SCVMM. Built on top of Windows Server 2012/R2 Hyper-V Replica, we offered a cloud integrated Disaster Recovery Solution.

Q3: HRM was an Azure service but data was replicated between my datacenters? And this continues to work?

A: Yes on both counts. The service was being used to provide the “at-scale” protection & recovery of VMs.

Q4: What is in preview as of June 2014 (now)?

A: The rebranded service now has an added capability to protect VMs to Azure (=> Azure is your secondary datacenter). If your primary machine/server/VM is down due to a planned/unplanned event, you can recover the replicated VM in Azure. You can also bring back (or failback) your VM to your private cloud once it’s recovered from a disaster.

Q5: Wow, so I don’t need a secondary datacenter?

A: Exactly. You don’t need to invest and maintain a secondary DC. You can reap the benefits of Azure’s SLAs by protecting your VMs on Azure. The replica VM does *NOT* run in Azure till you initiate a failover.

Q6: Where is my data stored?

A: Your data is stored in *your* storage account on top of world class geo-redundant storage provided by Azure.

Q7: Do you encrypt my replica data?

A: Yes. You can also optionally encrypt the data. You own & manage the encryption key. Microsoft never requires them till you opt to failover the VM in Azure.

Q8: And my VM needs to be part of a SCVMM cloud?

A: Yes. For the current preview release, we need your VMs to be part of a SCVMM managed cloud. Check out the benefits of SCVMM @ http://technet.microsoft.com/en-us/library/dn246490.aspx

Q9: Can I protect any guest OS?

A: Your protection and recovery strategy is tied to Microsoft Azure’s supported operating systems. You can find more details in http://msdn.microsoft.com/en-us/library/azure/dn469078.aspx under the “Virtual Machines support – on premises to Azure” section.

Q10: Ok, but what about the host OS on-premises?

A: For the current preview release, the host OS should be Windows Server 2012 R2.

In summary, you can replicate any supported Windows and Linux SKU mentioned in Q9 running on top of a Windows Server 2012 R2 Hyper-V server.

Q11: Can I replicate Gen-2 VMs on Windows Server 2012 R2?

A: For the preview release, you can protect only Generation 1 VMs. Trying to protect a Gen-2 VM will fail with an appropriate error message.

Q12: Is the product guest-agnostic or should I upload any agent?

A: The on-premises technology is built on top of Windows Server 2012 Hyper-V Replica which is guest, workload and storage agnostic.

Q13: What about disks and disk geometries?

A: We support all combinations of VHD/x with fixed, dynamic, differencing.

Q14: Any restrictions on the size of the disks?

A: There are certain restrictions on the size of the disks of IaaS VMs on Azure – primary being:

Azure is a rapidly evolving platform and these restrictions are applicable as of June 2014.

Q15: Any gotchas with network configuration or memory assigned to the VM?

A: Just like the previous question, when you failover your VM, you will be bound by Azure’s offerings/features of IaaS VMs. As of today, Azure supports one network adapter and upto 112GB (in the A9 VM). The product does not put a hard-block in case you have a different network and/or memory configuration on-premises. You can change the parameters with which a VM can be created in the Azure portal under the Recovery Services option.

Q16: Where can I find information about the product, pricing etc?

A: To know more about the Azure Site Recovery, pricing, documentation; visit http://azure.microsoft.com/en-us/services/site-recovery/

Q17: Is there any document explaining the workflows?

A: You can refer to the getting-started-guide @ http://azure.microsoft.com/en-us/documentation/articles/hyper-v-recovery-manager-azure/ or post a question in our forums (see below)

Q18: I faced some errors when using the product, is there any MSDN forum where I can post my query.

A: Yes, please post your questions, queries @ http://social.msdn.microsoft.com/Forums/windowsazure/en-US/home?forum=hypervrecovmgr

Q19: But I really feel strongly about some of the features and I would like to share my feedback with the PG. Can I comment on the blog?

A: We love to hear your feedback and feel free to leave your comments in any of our blog articles. But a more structured approach would be to post your suggestions @ http://feedback.azure.com/forums/256299-site-recovery

Q20: Will you build everything which I suggest?

A: Of course…not 🙂 But on a serious note – we absolutely love to hear from you. So don’t be shy with your feedback.

Disaster Recovery to Microsoft Azure – Part 2

 

Continuing from the previous blog – check out the recent TechEd NA 2014 talk @ https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B322 which includes a cool demo of this product.

Love it??? Talk about it, try it and share your comments.

Let’s retrace the journey – in Jan 2014, we announced the General Availability of Hyper-V Recovery Manager (HRM). HRM  enabled customers to co-ordinate protection and recovery of virtualized workloads between SCVMM managed clouds. Using this Azure service, customers could setup, monitor and orchestrate protection and recovery of their Virtual Machines on top of Windows Server 2012, WS2012 R2 Hyper-V Replica.

Like Hyper-V Replica, the solution works great when our customers had a secondary location. But what if it isn’t the case. After all, the CAPEX and OPEX cost of building and maintaining multiple datacenters is high. One of the common questions/suggestions/feedback to our team was around using Azure as a secondary data center. Azure provides a world class, reliable, resilient platform – at a fraction of a cost compared to running your workloads or in this case, maintaining a secondary datacenter.

The rebranded HRM service – Azure Site Recovery (ASR) – delivers this capability. On 6/19, we announced the availability of the preview version of ASR which orchestrates, manages and replicates VMs to Azure.

When a disaster strikes the customer’s on-premises, ASR can “failover” the replicated VMs in Azure.

And once the customer recovers the on-premises site, ASR can “failback” the Azure IaaS VMs to the customer’s private cloud. We want you to decide which VM runs where and when!

There is some exciting technology built on top of Azure which enables the scenario and in the coming weeks we will dive deep into the workflows and the technology.

Top of my head, the key features in the product are:

  • Replication from a System Center 2012 R2 Virtual Machine Manager cloud to Azure – From a SCVMM 2012 R2 managed private cloud, any VM (we will cover some caveats in subsequent blogs) running on Windows Server 2012 R2 hypervisor can be replicated to Azure.

  • Replication frequency of 30seconds, 5mins or 15mins – just like the on-premises product, you can replicate to Azure at 30seconds.

  • Additional 24 additional recovery points to choose during failover – You can configure upto 24 additional recovery points at an hourly granularity.

 

  • Encryption @ Rest: You got to love this – we encrypt the data *before* it leaves your on-premises server. We never decrypt the payload till you initiate a failover. You own the encryption key and it’s safe with you.

  • Self-service DR with Planned, Unplanned and Test Failover – Need I say more – everything is in your hands and at your convenience.

  • One click app-level failover using Recovery Plans
  • Audit and compliance reporting
  • .…and many more!

The documentation explaining the end to end workflows is available @ http://azure.microsoft.com/en-us/documentation/articles/hyper-v-recovery-manager-azure/ to help you get started.

The landing page for this service is @ http://azure.microsoft.com/en-us/services/site-recovery/

If you have questions when using the product, post them @ http://social.msdn.microsoft.com/Forums/windowsazure/en-US/home?forum=hypervrecovmgr or in this blog.

Keep watching this blog space for more information on this capability.