Optimizing Azure Site Recovery (ASR) with Riverbed® SteelHead™

Authors

Brett Hill (Riverbed Technology Inc.), Kevin Sullivan (Microsoft), Prateek Sharma (Microsoft)

Publication Date

1st April 2016

Summary:

This paper details results of a study conducted by Microsoft on the effectiveness of using Riverbed SteelHead optimization with Azure Site Recovery. It also describes in details the steps to be used to configure Riverbed SteelHead such that it can be used with Azure Site Recovery.

Copyright

This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. Riverbed and any Riverbed product or service name or logo used herein are trademarks of Riverbed Technology. All other trademarks used herein belong to their respective owners. The trademarks and logos displayed herein may not be used without the prior written consent of Riverbed Technology or their respective owners. Some examples depicted herein are provided for illustration only and are fictitious.  No real association or connection is intended or should be inferred.This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. © 2016 Microsoft. All rights reserved. © 2016 Riverbed. All rights reserved.Microsoft, Hyper-V, SharePoint, SQL Server, Windows, and Windows Server are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.

ContentsScope...................................................................................................................................................4

Introduction.........................................................................................................................................4

Solution Overview................................................................................................................................5

Encryption...............................................................................................................................................6

Network Encryption.............................................................................................................................6

Encryption at Rest (Available for Protection of System Center VMM-Managed Hyper-V VMs)..........6

ASR Setup............................................................................................................................................7

SteelHead Setup...................................................................................................................................9

Configuring the Azure Hosted Riverbed SteelHead CX............................................................................9

General Configuration.........................................................................................................................9

SSL Overview.....................................................................................................................................10

Enabling SSL Optimization of Encrypted Azure Site Recovery Traffic.................................................10

Riverbed SteelHead – Configuring On-premises Device........................................................................12

System Center VMM (Hyper-V VM Protection) to Azure Scenario Testing...........................................13

Scenario #1: Replicating Sparse Disks....................................................................................................14

Scenario #2: Dense Disk.........................................................................................................................15

Scenario #3: Multi-VM Scenario............................................................................................................18

Summary for VMM Azure Site Recovery Optimization Tests.................................................................20

VMware to Azure Scenario Testing.....................................................................................................20

Single VM – Thin Provisioned................................................................................................................21

Single VM – Thick Provisioned...............................................................................................................22

Multiple VMs.........................................................................................................................................23

Overall Conclusions............................................................................................................................24

Resources..........................................................................................................................................25

Revision History.................................................................................................................................26

ScopeAzure Site Recovery (ASR) is a Microsoft Azure service that orchestrates the protection and recovery of your virtualized applications for business continuity disaster recovery (BCDR) purposes. This document details network optimization delivered by Riverbed® SteelHead™ devices when replicating virtual machines (VMs) to Microsoft Azure using ASR. This document is intended for IT administrators, network administrators, ASR users, ASR evaluators, and IT decision makers.

IntroductionThe two general scenarios for using ASR for server protection are:

Protection between two on-premises sites: In this deployment, the customer owns both the primary and secondary datacenters. ASR is used to protect and orchestrate workloads running in the primary datacenter. These workloads can be servers running as VMware VMs, Hyper-V VMs, or physical servers.

Protection between an on-premises site and Azure: In this deployment, the customer owns the primary datacenter and relies on Microsoft Azure as the secondary datacenter. Customers can save on the CAPEX and OPEX costs involved in setting up the secondary data center and rely on ASR to address their BCDR needs.

This paper focuses on replication of on-premises VMs to Azure.

The benefits of optimizing bandwidth and decreasing replication time include:

1. Increasing effective network throughput. With optimization, bandwidth reduction allows you to carry more data on your existing infrastructure. This can eliminate or reduce costs associated with adding additional capacity and allows you to replicate more virtual machines. simultaneously. In addition, you reduce costs where bandwidth utilization is metered.

2. Reducing the time, it takes to implement BCDR. As VMs replicate faster, time to coverage is reduced. Project duration is decreased while you realize the benefits of BCDR earlier. In addition, new VMs can be added in less time when optimized.

3. Due to increased bandwidth from optimization, potentially decrease the delay between delta updates thereby improving the recovery point objective (RPO).

The two key metrics when recovering from a disaster are recovery point objective (RPO) and recovery time objective (RTO). RPO refers to the data loss (measured in seconds or minutes) when recovering from a disaster and RTO refers to the time taken to recover from a disaster (measured in minutes or hours). When a disaster strikes the customer’s datacenter, using ASR, customers can quickly bring online their replicated virtual machines (low RTO) located in either the secondary datacenter or Microsoft Azure with minimum data loss (low RPO).

Failover is made possible by the Azure Site Recovery Service, which initially replicates designated virtual machines from the primary datacenter to either a secondary data center or Azure (initial replication) and then continuously sends the changes (delta replication). Replication is a network intensive operation (based on workload patterns) and WAN (or Internet) bandwidth is precious. During infrastructure planning, network saturation should be considered as a potential bottleneck that can prevent you from meeting company RPO objectives. SteelHeads are designed to optimize network traffic of this kind.

Passing the ASR traffic through an on-premises SteelHead paired with a SteelHead CX virtual machine hosted in Azure can help you meet these RPO objectives by optimizing the network.

To test this scenario, a series of experiments were conducted in the Microsoft Enterprise Engineering Center (EEC) lab in Redmond, WA and updated with later testing by Riverbed in January 2016. The updated testing incorporates the scenario when the source machines are deployed on VMware as described here .

In the Hyper-V scenario, depending on the workload pattern in the VM, the SteelHeads eliminated more than 90 percent of the WAN bandwidth for initial replication and up to 80 percent for subsequent delta replication. In the VMware scenario, when using a mixed type of VMware VMs, more than 72 percent of the traffic was eliminated during initial replication. In addition, time to completion was reduced by more than half (65 percent). In a bandwidth-restrictive environment, these benefits translate into major savings and allow customers to meet their RPO and potentially RTO objectives without clogging the organization’s Internet traffic.

Microsoft and Riverbed have collaborated previously to publish two whitepapers (which can be found here and here) that studied the network optimization delivered by Riverbed’s SteelHead on Hyper-V replication traffic sent between the primary and secondary datacenters.

Solution OverviewWhen protecting applications deployed on a VMware-based site, physical servers, a Hyper-V site, or a System Center-managed private cloud to Microsoft Azure, ASR tracks the changes to the on-premises virtual machine and writes them directly to Azure storage blobs in the customer’s storage account. There are two major phases to replication: initial replication (IR) and delta replication (or DR).

Initial replication (IR) happens when a replication relationship is created for a VM. The entire VM (which can vary in size from a few gigabytes to a few terabytes) is transferred over the network from the primary site to the secondary site. The replication traffic goes over HTTPS.

After IR starts, any changes (specifically the writes) to the virtual machine are tracked in log files that are transferred periodically. Based on workload characteristics and read/write patterns, the size of the log file in each replication interval can range from a few megabytes to a few 100 megabytes.

Network congestion has typically proven to be a bottleneck, which prevents the customer from meeting RPO objectives. If the network is not provisioned to handle the load, time taken to transmit the log file to the storage account increases. In this scenario, Riverbed SteelHead devices can play a critical role in ensuring that the RPO objectives are met.

WAN optimization requires two devices, a SteelHead appliance running in the on-premises datacenter and another SteelHead appliance running in Azure When a SteelHead in the company datacenter is paired with an Azure-hosted SteelHead CX virtual machine, traffic between the devices is highly optimized resulting in dramatically reduced bandwidth and faster replication. To achieve this, SteelHeads provide three levels of optimization:

TCP optimization: Protocol optimization reduces round trips and improved throughput. Deduplication: Files that travel between SteelHeads are recorded as bit patterns on both

SteelHead devices. When a SteelHead detects a pattern it has seen before, the paired SteelHead

is instructed to deliver the matched content directly to the requester. In this way, the identified data does not need to traverse the network between the SteelHeads. This results in significant bandwidth reduction when replicated virtual disks have duplicate content such as the same installation of an operating system or fixed sized virtual disks that have empty space.

Compression: Many virtual disks benefit significantly from compression. The SteelHead pair compresses the bit stream on one end and decompresses on the other resulting in reduced traffic over the Internet. In particular, fixed sized VHDx files with empty space benefit from this optimization.

The solution is illustrated in Figure 1:

Figure 1: Solution Architecture

EncryptionEncryption is available at the network layer. Encryption at rest is optionally available for the protection of System Center Virtual Machine Manager (VMM) managed Hyper-V VMs.

Network EncryptionEncryption on the network layer is achieved by sending the replica traffic over HTTPS. By adding the proper certificates to the SteelHead, SSL traffic is decoded, optimized, and re-encrypted such that SSL is maintained end-to-end and highly optimized.

Encryption at Rest (Available for Protection of System Center VMM-Managed Hyper-V VMs)Encryption at rest is achieved by encrypting the data on-premises using certificate keys provided by the customer. Even before the replica copy (initial or delta replication) hits the network, the ASR agent running in the Hyper-V server encrypts the payload. The encrypted data remains encrypted-at-rest in Azure and can be decrypted only by the customer when bringing up the VM in Azure (or “failover”). The encryption key is owned by the customer and never leaves customer premises.

Note that when the encrypted contents are transmitted through the SteelHeads, network optimization is rendered impractical. Consequently, do not encrypt the contents at rest when you intend to optimize the network traffic.

ASR Setup Step-by-step ASR deployment guidance is provided online. On the documentation page, in the Deploy category (see Figure 2), you will find links for each ASR scenario including those used in this paper: Replicate Hyper-V VMs (with VMM) to Azure and Replicate VMware VMs to Azure . This solution is also known to work: Replicate Hyper-V VMs to Azure (no VMM). Other scenarios may work, but were not tested.

Figure 2: Site Recovery Documentation

In general, you first create and configure a Site Recovery Vault, as shown in Figure 3.

Figure 3: Azure Site Recovery Vault Creation

Once the vault is created, you then proceed with configuring your on-premises environment, as detailed in the documentation, by downloading the Azure Site Recovery Provider and Azure Recovery Service agent for your scenario. The Hyper-V and VMware scenarios each have their own specific deployment procedures that must be followed.

During configuration, make a note of the storage account name (URI), as shown in Figure 4, you plan to use with ASR. This is needed when configuring the SteelHeads.

As a best practice, you should first configure ASR end-to-end before configuring optimization on SteelHead.

SteelHead Setup As with on-premises solutions, optimization occurs between two Riverbed SteelHead devices. A SteelHead is required on the on-premises side and is paired with a Riverbed SteelHead CX, which runs as an Azure infrastructure-as-a-service (IaaS) VM. Traffic between these devices from the datacenter into Azure is optimized.

Configuring the Azure Hosted Riverbed SteelHead CXThe SteelHead CX hosted in Azure can easily be deployed from the Azure virtual machine gallery, as shown in Figure 5.

Figure 4: Storage Account Blob URI

Figure 5: SteelHead VM in Azure Gallery

Complete instructions are contained in the document Optimizing Azure Workloads with the SteelHead CX - Solution Guide.pdf .

General ConfigurationThe following steps detail the general configuration of the SteelHead CX for Azure Site Recovery.

1. Obtain a SteelHead CX trial license from Riverbed. Contact Riverbed for details. Riverbed has offices worldwide.

NOTE: The SteelHead CX optimization service cannot be started until a license has been installed.

2. Deploy the SteelHead CX as described in Optimizing Azure Workloads with the SteelHead CX - Solution Guide.pdf.

3. Configure the Azure SteelHead for SSL and install the certificates need for optimization for ASR as detailed below under Enabling SSL Optimization of Encrypted Azure Site Recovery Traffic.

Ensure that your Azure SteelHead is deployed on an Azure virtual network where you intended to failover your virtual machines. Complete SteelHead configuration guidance can be found in the SteelHead deployment guide at https://support.riverbed.com/download.htm?did=uffde61aideokpffksfk6g9vcs .

SSL OverviewAt a high level, in order to optimize HTTPS traffic, the SteelHead decrypts the packet from the client (in this case, each participating Hyper-V Host for Hyper-V VM protection or the Process Server for VMware VM and physical server protection), optimizes the content and then re-encrypts the content so that the traffic between the SteelHeads over the Internet/VPN/WAN is secured. The server-side SteelHead (in Azure) decrypts the incoming traffic, applies optimization and then re-encrypts the traffic using the

appropriate certificates for the server side (the public Microsoft certificates). The network flow, shown in Figure 6, is captured in the diagram taken from the deployment guide mentioned above.

Figure 6: Data Transfer on SSL

The keys used in Figure 6 are:

kc is the session key between the client initiating the transmission and the server-side SteelHead.

ks is the session key between the server-side SteelHead and the server. kt is the session key between the client-side SteelHead and the server-side SteelHead appliance

for the inner secure SSL channel.

Enabling SSL Optimization of Encrypted Azure Site Recovery TrafficYou must create and install a self-signed trusted “proxy” certificate to the Azure SteelHead CX. This certificate will be presented to the client (Hyper-V hosts for Hyper-V VMs or the Process Server for VMware VMs). The certificate must be issued by a trusted private CA (usually the Enterprise CA), and have the correct common name. See the document Creating Proxy Certificates for a Riverbed Steelhead Appliance with a Microsoft Certificate Authority for step-by-step details.

1. Obtain and install an SSL license for each SteelHead from https://support.riverbed.com/content/support/my_riverbed/ssl.html.

2. Remove port 443 from the secure ports list. In the SteelHead web administration portal, browse to Networking->Port Labels->Secure. If port 443 is listed in the Ports, remove the entry click Apply, and then click Save.

3. Select the Enable SSL Optimization check box in Optimization->SSL Main Settings.

4. Create and install the appropriate certificate. ASR uses a certificate with the common name *.blob.core.windows.net.

Use this information to create and export the certificate from a private CA that contains the private key and matches the Common Name and Subject Alternative Names.

Figure 7: Install CA Root Certificate (left) and Proxy Certificate (right) on Azure SteelHead CX

Install the root CA certificate on:

1. The Azure SteelHead under Optimization->Certificate Authority.2. The CA Root Certificate store for the Hyper-V Hosts or the Process Servers used with VMware.

This step might not be required if your servers already trust the CA (such as your Enterprise CA) used to create the certificate.

Install the proxy certificate with the private key on the Azure SteelHead under Optimization->SSL Main Settings, as shown in Figure 8.

Figure 8: Proxy Certificate installed in Azure SteelHead

Refer to Chapter 10, “SSL Deployments,” in the Steelhead Appliance Deployment Guide available on Riverbed.com/support. Additional details can be found at https://splash.riverbed.com/docs/DOC-4068.

Riverbed SteelHead – Configuring On-premises DeviceAfter deploying the Azure SteelHead CX, you must pair the on-premises SteelHead with the Azure SteelHead CX. Step-by-step instructions for this simple operation are included in Chapter 4 of the referenced deployment guide. Pairing the devices allows them to securely exchange traffic.

Finally, you must add one or more in-path rules to intercept and direct ASR traffic to the SteelHead in Azure. Ping the URL of the blob storage containers you plan to use and record the IP addresses. Create a rule for each storage account that you plan to use. To create an in-path rule, click Optimization->In-Path Rule and then click Add a New In-Path Rule. Complete the form, as shown in Figure 9.

Figure 9: Fixed Target Rule on On-premises SteelHead

Provide the following information, as shown in the figure.

1. Type: Select Fixed-Target rule.2. Destination Subnet: Type the blob storage IP Address followed by /32. 3. The public VIP of the Azure SteelHead4. Set the PreOptimization policy to SSL.

You can also enter the Source Subnet if you want to further specify what traffic this rule should optimize.

When you click Add (or Apply as shown in Figure 9) the rule will be in activated.

NOTE: You might need to move the rule to the top of the in-path rules. Rules are enforced in order.

NOTE: In practice, the IP addresses for the storage account tend to be stable, but can change. If this occurs, synchronization will not be interrupted; however, optimization will not occur until the IP the in-path rule is updated.

System Center VMM (Hyper-V VM Protection) to Azure Scenario TestingThe setup used for this validation effort involved a 3-node Windows Server 2012 R2 Hyper-V cluster that is managed by System Center 2012 R2 Virtual Machine Manager (VMM) and represents the customer’s primary site. Three VMM clouds (Gold, Silver, Bronze) were created for the purpose of this effort. The Azure Recovery Services agent is installed on each of the Hyper-V servers while the Azure Site Recovery Provider is installed on the VMM server. An end-to-end guide to deploy Azure Site Recovery is available at https://azure.microsoft.com/en-us/documentation/articles/site-recovery-vmm-to-azure/.

After the agents are installed, the clouds (Gold, Silver, Bronze as seen in the left pane of Figure 10) show up on the portal under the configured vault. The cloud’s protection policy is configured and any VM that is part of this cloud can then be enabled for replication. The cloud is configured to receive the replication traffic to a storage account (blob store) in your subscription. Make a note of the storage account name because it will be required when configuring the on-premises SteelHead.

Figure 10: Selecting the Storage Account

In the example in Figure 10, the storage account that receives the replication traffic is rbedvalidate155 and the blob store URL is rbedvalidate155.blob.core.windows.net, as shown in Figure 4.

The on-premises and Azure SteelHeads were running RiOS 8.6. The network for these tests used a Wan Simulator that throttled the network to 50 Mbs.

Scenario #1: Replicating Sparse DisksThe first experiment involved studying the optimization delivered by the SteelHead when replicating a sparsely populated Windows Server 2012 R2 VM.

The VM was attached to a VHD created using the default configuration of a 127 GB dynamic VHDx. Once the OS is installed, the explorer view of the VM was 11.42 GB in size as shown in Figure 11.

Figure 11: Sparse Disk Explorer View from Guest VM

After replication starts, optimization takes a few minutes begin. In this test, due to the sparseness of the data in the disk, bandwidth reduction is very high, as shown in Figure 12.

Figure 12: Sparse Disk Optimization

Given the data distribution, both the data reduction and the average throughput is consistently high as shown in Figure 13. The top graph shows data reduction while the bottom graph shows average throughput.

Key Takeaway from Scenario #1:

Replication of a sparsely populated data set delivered greater than 95 percent reduction of network traffic.

Scenario #2: Dense DiskAfter the SteelHead cache was cleared, a second VM was created and populated with random data. When the VM booted up, the File Explorer in the guest displayed the details shown in Figure 14.

Figure 14: Dense Disk - Explorer View

This time around, given the nature of the disk, the optimization delivered was slightly lower at 60 percent, as shown in Figure 15.

Figure 13: Bandwidth Optimization for a Sparse Disk

Figure 15: Dense VHD - Optimization

Referring to Figure 16, the average LAN bandwidth was 39 Mbps and the average WAN bandwidth was 15.3 Mbps, meaning that the SteelHead solution reduced network traffic by greater than 50 percent. The P95 values for the LAN bandwidth and WAN bandwidth were 134.5 Mbps and 73.8 Mbps respectively. This translates into important savings on the networks.

Figure 16: WAN, LAN Bandwidth - Dense disk

Referring to Figure 17, the bandwidth optimization that started slowly, got higher over a period of time as the data reduction cache “warmed up”.

Figure 17: Bandwidth Optimization - Dense disk

Key Takeaway from Scenario #2: Replication of a densely populated data set delivers approximately 60 percent reduction of network traffic.

Scenario #3: Multi-VM ScenarioScenario 3 tested optimization of ASR in a “scaled-out” scenario over a 7-day period using 50 virtual machines. The VM deployment consisted of:

Physical sizes between 8 GB to 40 GB Logical size between 4 GB to 30 GB When enabling replication using ASR:

o Spread of replication frequencies of 30 seconds, 5 minutes, 15 minutes.o Synthetic workloads were run inside the VM, which represent SQL, Exchange, and file

server data read/write characteristics.o The workload simulated peak times and off-business hours, weekday traffic and

weekend traffic. o VMs “churned” (increasing the size of the log files that tracked the changes) between 2

MB per minute to 100 MB per minute.

Once an optimized connection is set up, the following can be seen in the Riverbed console. The key components are called out in the Figure 18.

Figure 18: Optimized Connection Details from the SteelHead Administration Console

Snapshots of the optimization were taken at different points and high data reduction was achieved over a period of time.

Figure 19: Data Reduction

Data reduction is influenced by a number of factors such as read/write patterns, block size, repetition of the write patterns, workload peaks and valleys, and churn. While it is very difficult to model the application characteristics, the above experiment used a variety of tools during the entire exercise. Each time, the SteelHead solution delivered superior optimization.

A snip of the active transfers during replication can be seen in the Figure 20, which illustrates the optimization delivered during delta replications.

Key Takeaway from Scenario #3: The SteelHead solution reduced network traffic more than 80 percent in a scaled out environment.

Figure 20: Current Connections Page in SteelHead Administration Console

Summary for VMM Azure Site Recovery Optimization TestsWe found that the SteelHead solution exceeded expectations in reducing network traffic in a variety of scenarios as shown in Figure 21.

VMware to Azure Scenario TestingThe setup used for this validation effort involved a VMware ESXi 6.0 server with six virtual machines. representing the customer’s primary site. One VM was assigned the role of the Process Server (also referred to as the Management Server in the documentation) used to coordinate transactions between Azure and the on-premises VMware virtual machines. As per the documentation, the Mobility Servicer agent was installed on the remaining virtual machines. Complete documentation can be found at https://azure.microsoft.com/en-us/documentation/articles/site-recovery-vmware-to-azure-classic/ .

Optimization occurred on a 100 Mbs network through a 6050L SteelHead paired with an Azure 3070 CX.

To provide representative results, virtual disks were created from a variety of operating systems. In addition, virtual disk types were varied. A thin virtual disk consumes less disk space and dynamically grows until it reaches its’ provisioned capacity. For example, if you provision a thin disk for 500 GB and install an operating system, the file size for the virtual hard drive will be only the space needed for the installation of the OS. A thick virtual disk file size is equal to the provisioned capacity. If you provision a 500 GB drive and only install the OS to the drive, the disk file size is 500 GB.

# OS Role Disk Type Size on Disk Notes1 2008 R2 File Server Thin 16 GB 4000 random text files

added2 2008 R2 IIS Thick/Lazy Zero 42GB Visual Web Developer

Figure 21: Summary of VMM/Hyper-V VM Optimization Results

added3 2012 R2 AD Thick/Eager Zero 133GB Standard4 2012 R2 IIS Thick/Lazy Zero 84GB .NET Database Added5 2012 R2 SQL Thin 31GB Fresh install

Table 1: VMware Virtual Machines

Time and bandwidth for initial replication were measured for optimized and un-optimized trials. Time was monitoring Resource Monitor in combination with the bandwidth report from the WAN Simulator on the network. Note that time recorded is actual time taken to transfer data to Azure. End-to-end processing time is longer than transfer time due to pre- and post-processing tasks. For example, when you enable replication, the first stage is “Enabling Protection”. This phase can take several minutes during which no traffic is directed to blob storage. Actual replication begins when the process “cbengine.exe” (shown in Figure 22) starts sending traffic to Azure blob storage.

Figure 22: Resource Monitor Showing Transfer to ASR

Single VM – Thin ProvisionedInitial testing was conducted using VM #1. This 16 GB file took 39 minutes to replicate un-optimized and 16.8 GB of network traffic, as shown in Figure 23. SteelHead optimization reduced traffic by 57 percent and improved time by 1/3.

Figure 23: VMware Initial Replication 16 GB – Thin Provisioned

Single VM – Thick ProvisionedInitial testing was conducted using VM #2, which is 40 GB on disk as shown in Figure 24. IIS and Visual Web Developer were installed on the server. Un-optimized, 8.1 GB of data was transferred in 21 minutes. Optimized, 2.5 GB of data was transferred in 15 minutes.

Figure 24: VMware Initial Replication 40 GB – Thick Provisioned

Shown in Figure 25: is the Bandwidth optimization report shows a 68.5 percent data reduction on this test, resulting in 3.2x effective increase in network carrying capacity.

Figure 25: VMware Initial Replication 16 GB – Thin Provisioned

Multiple VMsA test was conducted for initial replication of all virtual machines. Overall, as shown in Figure 26, replication time was decrease by more than half, and 72 percent of the data was removed from the transfer.

Figure 26: VMware Initial – Multiple VMs

The Bandwidth Optimization report from the Azure SteelHead for this test is shown in Figure 27.

Figure 27: VMware Initial – Multiple VMs

Overall ConclusionsAzure Site Recovery brings down the CAPEX and OPEX costs of a disaster recovery solution by enabling customers to protect their workloads to Microsoft Azure. A key component of this solution is around provisioning the network appropriately to ensure that the RPO goals are met. It is also important to

ensure that the impact to the organization’s Internet bandwidth is kept to a minimum. Riverbed SteelHead’s WAN optimization technology plays a crucial role in meeting this twin objective. With an industry-first Azure optimization appliance, the Riverbed SteelHead appliance provides significant savings on the Internet bandwidth.

This paper illustrated the savings in a controlled environment running synthetic workloads which represent real-world applications – and the savings are very evident.

The two key takeaways are:

Ease of configuration: Azure Site Recovery and the SteelHead appliances were easy to configure and setup. This experiment was made successful with minimal interaction between the two companies – no special hooks were required from either side.

Delivering high optimizations: The Riverbed SteelHead provides a scalable, secure and efficient solution to optimize the replication traffic that was sent over HTTPS from the on-premises environment to Microsoft Azure. This significantly reduced bandwidth utilization, lowering WAN throughput required for ASR, helping to ensure that ASR is able to deliver the RPO promise in scaled-out deployments. Network bandwidth is a precious commodity and the Riverbed SteelHead solution delivered greater than 90% reduction of replica traffic for Hyper-V scenarios and 72% in VMware scenarios.

ResourcesThis section contains a list of web pages referenced in the paper.

http://www.riverbed.com/contact/#overview

http://www.riverbed.com/products/steelhead/steelhead-cx.html

https://azure.microsoft.com/en-us/documentation/articles/site-recovery-hyper-v-site-to-azure/

https://azure.microsoft.com/en-us/documentation/articles/site-recovery-vmm-to-azure/

https://azure.microsoft.com/en-us/documentation/articles/site-recovery-vmware-to-azure-classic/

https://splash.riverbed.com/docs/DOC-3473

https://splash.riverbed.com/docs/DOC-4068

https://splash.riverbed.com/docs/DOC-4627

https://support.riverbed.com/bin/support/download?did=agrtjjih4pipacd6gu02b3c5uf

https://support.riverbed.com/content/support/my_riverbed/ssl.html

https://support.riverbed.com/download.htm?did=uffde61aideokpffksfk6g9vcs

https://www.microsoft.com/en-us/download/details.aspx?id=42627

https://www.microsoft.com/en-us/download/details.aspx?id=44571

Revision HistoryPublication Date Version Comments23rd October 2014 1.0 Initial publication1st April 2016 2.0 Revision to include optimization in a VMware setup