Disaster recovery and business continuity solutions have been historically expensive and time consuming. Microsoft Azure Site Recovery (ASR) makes Disaster Recovery (DR) planning and implementation simpler and affordable for all types of organizations.
Join our team of cloud experts for a walk through of DR and ASR basics. We'll highlight best practices for ASR deployments and help you get a sense of the costs for implementing a solution.
2. Housekeeping
2
No sound?
Check your speakers, if
you are using
headphones …
You can also join via
phone:
+1 (914) 614-3221
Access Code: 846-566-028
Download
GoToWebinar
You need GoToWebinar
client software
Ask Question
You can ask question
anytime using the
Question box on your
screen
Technical
problem?
Check GoToWebinar
Quick Reference Guide
Check GoToWebinar
Help!
http://support.citrixonli
ne.com/Webinar/
3. 3
MOTIFWORKS
AZURE
PRACTICES
AZURE CONSULTANCY
› Azure 101
› Architecture Discussion
Sessions (ADS Sessions)
› Azure Workshops
CLOUD MIGRATION
› Lift and Shift
› End-of-life Migration
› Cloud Burst/Auto-scaling
APP MODERNIZATION
› Azure PaaS Development
› Mobile Backend as a Service
› Multi-tenant SaaS apps
BI AND AZURE ANALYTICS
› Cortana Analytics: Azure
HDInsight and Machine Learning
› SQL Server BI (SSIS, SSAS, SSRS)
DEVOPS AND
AUTOMATION
› Infrastructure as Code
› PowerShell based
Automation
› ALM / Continuous
Integration / Continuous
Delivery
› Trial as a Service (trial.io)
MANAGED SERVICES
› 365 * 24 * 7 Infrastructure &
Application Support
› Backup & Disaster Recovery
› Security as a Service
ABOUT
MOTIFWORKS
4. Today’s Presenter
4
Cloud Solutions Architect
Motifworks
Murad Kayani
A seasoned architect
strong skills in user training,
technical leadership and
support for customers in
complex environments.
Main focus is helping
customers understand how
Azure can help solve
business and technical
challenges.
7. Why you need DR?
Human Errors Reduce Cost
Cost of
downtime
Compliance
Always On System Failures
Brand
reputation
Natural Disaster
Customer
Retention
“IDC estimates that as many as 50% of organizations have inadequate disaster recovery plans. In
fact, IDC warns, such companies might not survive as a going concern after a significant disaster
because of their inability to recover IT systems."
9. 9
Term Definition
Recovery Point Objective The acceptable amount of data loss measured in time.
Recovery Time Objective The duration of time within which a business process must
be restored after a disaster (or disruption) in order to
avoid unacceptable consequences associated with a break
in business continuity.
Failover Failover is a process to recover the workload on to the
protecting site. It can be a planned activity or needed
after a disaster to bring back the business. A test failover
can also be used to regularly check for DR readiness.
Disaster Recovery Plan A plan which captures the various VM which need to be
recovered during failover, the data center dependencies
that need to be followed and additional tasks that need to
be carried out to ensure successful recovery of a
workload.
Disaster Recovery Terminology
12. Identifying Critical Systems
RPO/RTO Threat Preventation Response Recovery
For each critical System
• System Failure
• Network
connectivity
down
• 15 minutes/2 hours • Backup
• Secondary
data center
• Switch server
to backup
Server
• Resolve Issue
and fail back
to primary
server
Example:
13. Disaster Recovery in cloud
Disks, back-up tapes
etc. can be eliminated
Mission-critical data
can be kept off-site
Cost effective
Scalable Efficiency Reduce Infrastructure
Faster Recovery
16. 16
ASR provides single DR solution which works across
platforms (Hyper-V, VMWare, Physical) across clouds
(public, private and service provider) and across
workloads to provide a range of RTO/RPO using
multiple channels (Replica, Scout, SAN etc.).
Azure Site Recovery
17. 17
One solution for multiple infrastructures
VMM site to VMM site
(on-premises)
VMM Site VMM Site
Replication
VMM to Microsoft Azure
Microsoft
Azure
Replication
VMware or physical to
VMware (on-premises)
VMware VMware
Replication
VMware or physical to
Microsoft Azure
VMware or physical
Microsoft
Azure
Replication
VMM to VMM
(on-premises)
Replication
SAN SAN
VMM Site VMM Site VMM Site
Hyper-V to Microsoft Azure
Microsoft
Azure
Replication
Hyper-V
Site
18. Disaster Recovery Process
Microsoft Azure
Data
Channel
Microsoft Azure
Site Recovery
Process Server – Used for
Caching, Compression &
Encryption
Config Server – Used for
Centralized Management
Master Target – Used as a
repository & for retention
Source: VMware VMs
& Physical Servers
Process
Server
Mobility Service – Captures
all data writes from
memory
Microsoft Azure
Target: Microsoft Azure
24. 24
5. Capacity Planning
Gather information about your replication
environment, including VMs, disks per VMs,
and storage per disk.
Estimate the daily change (churn) rate you’ll
have for replicated data.
Microsoft Provides Planning tools for Both
Hyper-V and vSphere
26. 26
7. Executing Recovery Plan
Test Failover
Useful to verify that your recovery plan and virtual
machine failover strategy are working as expected.
Simulates your failover and recovery mechanism into
an isolated network(s), that you define, or that can be
created automatically.
Unplanned Failover
Run an unplanned failover when a primary site
experiences an unexpected incident, such as a power
outage.
Planned Failover
Perform a complete failover and recovery of virtual
machines in your recovery plans in a proactive,
planned manner.
Non-replicated changes are applied to the replica
virtual machine with no data loss before bringing the
VM online in the secondary site.
27. 27
Price For First 31 days Price After 31 Days
Azure Site Recovery to
customer owned sites
Free
$16/month per instance
protected
Azure Site Recovery to
Azure
Free
$25/month per instance
protected
Azure Site Recovery is billed based on number of instances protected. Every
instance that is protected with Azure Recovery is free for the first 31 days as shown
below.
Pricing
28. 28
Item Cost Total/mo
10 VMs $25 Per instance $250
Storage 300 GB /VM $0.01 Per GB $30
Put (1000000) Operations $0.100 per 1000 Operations $10
Data Retrieval (3000) GB $0.010 per GB $30.00
Data Write (3000) GB $0.003 per GB $7.50
Estimated Cost/ month $327.50
Azure Site Recovery To Azure Cost
29. Cloud and Azure Workshops
29
Business
Continuity &
Disaster Recovery
Proof of Concept
We review your business
objectives, create a business
continuity and disaster
recovery strategy for the
selected workload and
implement the DR.
• Define Business
Objectives
• Assess Application
• BC/DR Strategy
• Implementation
• Review Results
Cloud Readiness
Assessment
• Cloud Readiness
Assessment presentation
along with supporting
data, assessment findings
and recommendations.
• Adoption roadmap,
migration options and
high-level architecture.
• Plan for migration for
candidate applications.
• High-level cloud
consumption plan and
costs.
Application
Modernization
• Azure Cloud PaaS
Services overview
• High-level future
architecture
• Migration plan, with
migration options and
high-level plan
• Recommendations for
improved user experience
• High-level cloud
consumption plan and
costs.
You may be qualified to get one of these complimentary workshop
30. 31
Thank You!
Please do not forget to RATE the webinar
Murad Kayani
murad@motifworks.com
202.460.5700
www.motifworks.com
Hinweis der Redaktion
Disks backup - There is no need to maintain daily back-ups using disks, tapes etc. Though this mode can be used, compared to having a DR in the cloud, it is inefficient. The data back-up can be done, even in real-time in the cloud.
Mission Critical Data – Cloud is reduntely designed. In case of failure you can recover you data from the cloud.
Cost Effective - Since the cloud service provider charges only for the services used, the business can pick and choose what it requires, leading to immense cost reduction. Also, costly hardware need not be duplicated since the cloud is the resource for the DR solution.
Scalable - The cloud option can be easily scaled up or down depending on business requirements
Efficiency - Since the data is stored in the cloud, large servers and associated hardware is eliminated, leading to lower capital costs. The entire IT infrastructure of the business will be ‘lean and mean’, yet fighting fit, to face a disaster head-on.
Reduce Infrastructure –
Faster Recovery – With cloud you can expediate the overall recovery, sometimes in minutes. You also have an ability to even recover in the cloud. You can also infact automate the entire recovery plan.
Flexible -
What are the different infrastructures that Azure Site Recovery can provide a solution for?
http://azure.microsoft.com/en-us/documentation/articles/hyper-v-recovery-manager-overview/
Well first, for customers who have multiple sites, or work with a service provider as a secondary site, and Hyper-V is running on both sites, they can take advantage of Azure Site Recovery to orchestrate the replication and recovery between those sites. In that example, the engine of replication will be Hyper-V Replica, an inbox VM replication technology that’s built into Windows Server 2012 and 2012 R2.
<click>
For customers with an investment in SAN technology, that includes replication in the box, through integration with Hyper-V, System Center and Azure Site Recovery, customers can orchestrate the replication and recovery of their key workloads between those sites, this time, harnessing the power of the SAN, through asynchronous or synchronous replication, to transfer data between sites.
<click>
For customers who don’t have a second site, and are running Hyper-V on their primary site, using Azure Site Recovery, customers can orchestrate the replication and recovery of their on-premises workloads, into the Microsoft Azure datacenters, enabling this as a target for failover in the event of a disaster. The engine of replication in this example is Hyper-V Replica.
<click>
What about customers who don’t have Hyper-V within their datacenters? Well, as we mentioned at the start of the presentation, with the acquisition of InMage, under the umbrella of Azure Site Recovery, customers can orchestrate the replication and recovery of key workloads from physical, or VMware-based sites, over to a secondary site, running VMware also. This time, InMage Scout is providing the replication engine, and is transferring the data between the two on-premises locations.
<click>
Finally, just like we saw earlier, where a customers without a secondary location, could use ASR to replicate and recover Hyper-V-based VMs into Azure, with the new InMage technologies, in the future, you will be able to replicate and recover VMware-based VMs into Microsoft Azure. Again, this will be powered by InMage Scout.
<click>
So let’s dive into each of these in more detail, starting with Hyper-V to Hyper-V replication and recovery with ASR.
<next slide>
on-premises machine that coordinates communication and manages data replication and recovery processes.
Acts as a replication gateway. It receives replication data from protected source machines, optimizes it with caching, compression, and encryption, and sends it to Azure storage. It also handles push installation of the Mobility service to protected machines, and performs automatic discovery of VMware VMs.
Master Target- Handles replication data during failback from Azure.
Mobility - This component is deployed on every machine (VMware VM or physical server) that you want to replicate to Azure. It captures data writes on the machine and forwards them to the process server.
Firstly, you'll need an Azure account, so you’ll need to register with an appropriate Microsoft Account. Once completed….
<click>
You create a Recovery Vault – this is a simple process that involves providing a name, and a location of where you want the vault to reside, choosing the geography which is most relevant to you and your business. From there, to register your on-premises Virtual Machine Manager servers in an Azure Site Recovery vault, you'll need to upload a management certificate (.cer) containing the public key to the vault. This management certificate should reside on each of your VMM servers. The SSL certificate can be self-signed, come from an enterprise CA, or any CA that is trusted by Microsoft.
<click>
Once the certificate is imported into the Vault, you can deploy the provider, which is downloaded from the Azure portal. This should be installed on each of your VMM servers. The latest version of the Provider installation file is stored in the Azure Download Center. When you run the file on a VMM server the Provider is installed, and the VMM server is registered with the vault. Upon completion of this stage, metadata from the VMM server(s) is pushed to Azure Site Recovery, in order to orchestrate failover and recovery. After a server has been successfully registered its friendly name will be displayed on the **Resources** tab of the Servers page in the vault
<next slide>
<click>
You then need to create Clouds on the primary site. In VMM, a cloud is an object that is provisioned and managed on-premises by an organization. The cloud is deployed by using an organization’s own hardware to leverage the advantages of the cloud model. By using VMM, an organization can manage the cloud definition and can manage access to the cloud and the underlying physical resources. Clouds contain the VMs that will be protected by Azure Site Recovery.
<click>
On the secondary site, you simply create clouds that map to those on primary, so for instance, if you had a cloud on primary called Test, you may create a cloud on secondary called Test_DR. These clouds will be mapped to one another at a later point.
<click>
The user can then configure the key items within the Azure portal, from replication frequency, to additional recovery points and VSS integration. These settings ultimately determine the settings applied to Hyper-V Replica, which is on each Hyper-V host.
<click>
From this point forward, Azure Site Recovery will monitor the VMM servers on your on-premises locations, but at this point, we have nothing configured for protection – only our clouds are configured.
<click>
We then map our networks between the sites, which we can look at in a bit more detail.
<next slide>
When it comes to executing Recovery Plans, there are 3 ways they can be executed.
Firstly, the user can run a test failover.
<click>
Running a test failover executes the recovery plan, brings workloads up on the secondary site, but in an isolated environment, whilst the primary site is still online. The ability to test failover ensures that recovery plans execute as expected, in the event of a disaster. You can have the test failover process automatically create new networks for VMs on the secondary site using Hyper-V Network Virtualization, or use existing ones that you’ve defined in advance.
<click>
With an unplanned failover, this would be executed when the primary site has had an unexpected outage. When you execute an unplanned failover, you can attempt to shut down the VMs on the primary first, and replicate any final changes, but it’s most likely that in an unplanned scenario, you’ve lost the primary site already, and the main objective is to bring the secondary site online as quickly and efficiently as possible.
<click>
Finally, we have the planned failover, where you’re executing failover in a proactive, planned manner. In this scenario, the VMs are cleanly shut down, their final delta changes since the last replication are replicated, and the VMs are failed over in a controlled and orchestrated manner.
Now that we’ve heard about the process, let’s take a look at it in action with a demo.
<next slide>