>> Hey friends, you know
whether you're working for a large Fortune 500 corporation
or a small business, you probably want to protect
your applications from downtime. Siddharth is here to show
me how Azure Site Recovery can help you recover your
applications in the event of natural or man-made
disasters by leveraging availability zones within an Azure
region today on Azure Friday. [MUSIC] Hey friends, I'm Scott Hanselman and it's Azure Friday we're talking with Siddharth here
who's going to talk to me about Azure Site Recovery. How are you? >> I'm good, how are you Scott? >> I'm living the dream
and learning about Azure. I'm excited to keep my sights up. You know I'm always concerned
with disasters can happen. It could be a natural
disaster like something bad, or I could just trip over a
wire and mess something up. Literally, I had a
disaster today where the power went out in my city, in the middle of a workshop
that I was giving. But fortunately, I had a UPS and my computer and my
internet kept running. The client was so impressed
that I had disaster recovery, even though it's just a
little battery under my desk. >> That is very cool.
Yeah, business continuity and disaster recovery is super important guideline
especially when it comes to mission
critical applications, you want to make sure that you have a sound business continuity and
disaster recovery strategy. Azure Site Recovery really helps you strengthen that VCDR strategy by helping you recover your applications in the event of a planned
or unplanned outage. So if, you're doing a disaster
recovery drill of thoughts, then Azure Site Recovery
can help you fill over your VMs and then fill them back
once your Azure is complete. But God forbid, there's an
outage and that could be a natural disaster or
a man-made outage. There might be a rogue
admin who might, like you said, trip a wire somewhere. For those kinds of
situations as well, Azure Site Recovery can help you fill over your applications
from one site to another and then fill back to your original site once
the outage has passed. >> Now, I'm used to thinking about websites where you do
a ping or you have a health check where you make an http call and then you have to make a decision about
what unhealthy is. But with virtual machines and with more sophisticated sites
that aren't just my blog, how do you decide that it's a
disaster as opposed to a hiccup? >> Yeah, great question. What most customers tend to notice is their applications
malfunctioning. If they are unable to use their applications and
they notice errors, then that's a clear signal
that something is wrong. Now, if these virtual
machines that are hosting the application
happen to be in Azure, then Azure communications
actually sends out an e-mail to you as a user, which clearly communicates
that Azure is facing an outage and then encourages you to look
at your disaster recovery plan. Then if you as a user
believe that it is in your best interests to actually
perform a disaster recovery, then Azure Site Recovery helps
you to go ahead and do that. >> Interesting, and
this isn't necessarily a Cloud only situation, right? I might have a physical
machine in my office and I have a backup in the Cloud
or I could fill up to the Cloud? >> Yeah. Let me actually
share my screen and display. Azure Site Recovery is a complete
disaster recovery solution. It applies whether you are on-prem
environment or in Azure, right? If you're on-prem, you could
have physical servers on-prem and you could replicate
those into Azure. You may be a VMware or Hyper-V shop. And if you have those VMs, you can replicate those
into Azure as well. Then recently we've started
supporting Azure Stack. So if you're on Azure Stack VMs, those can be replicated as well. The cool thing is, you can
fill these over into Azure, and then once the outage passes or once you are comfortable
with your DR drill and you want to feel
that you can feel back to your VMware or
Hyper-V environment. Now, a couple of years ago, we launched region to region DR. What that means is if you are running
your VMs on Azure already, so you're located in North Europe and you're running your VMs
from the north Europe region, you can actually replicate
to West Europe or UK South or any one of
the regions in Europe. You can fill over to that
region and then fill back to North Europe
anytime you want. That's a really cool offering
and it's quickly become one of our most highly adopted scenarios. We do this for on-prem machines, whether they be physical
servers or virtual machines. We do these for Azure
Virtual Machines as well. We support all operating systems, so this is not just
a Windows offering. We have first-last the next support regardless of the distribution you are using where that be wouldn't do our Debian or Red
Hat, what have you? We support them all. But what I really want to talk
about today is an US toll-free. We did a preview of dicentric
night last year and then we went to GA a few months ago. That is is zone to zone DR. >> So availability zones. I remember that if I have a
virtual machine and I say, hey, Azure make two virtual machines, they could randomly show
up next to each other. They could be in the same rack, they could be near each other in the same aisle inside of
this giant warehouse. But by giving them different
availability zones, I'm telling Azure keep
these away from each other, put them on other
sides of the building; Is that a way to think
about availability zones? >> Yes, exactly. Within any region, we have three availability zones, and these are three
separate datacenters, which may be a few miles or a
couple of dozen miles apart. You can host your VMs in
each availability zones. So if you have two VMs, you put the first VM in zone one, the second VM in zone
three, for example. Then that way you ensure
that they are not in the same datacenter and
certainly not in the same rack. >> Fantastic. That's really nice
where I can be in North Europe, but I'm not following
falling over from north to west or to a totally
different country. I'm just failing a
couple of miles away. >> Exactly. >> Very cool. Is it hard to set up? Is it something that I would need to spend a lot of time preparing? >> No, it's actually
super easy to set. Let me actually show you how. If I go to my browser here. I have a virtual machine
that I have set up in Southeast Asia and it's pinned to
Zone one as as you can see here. Now, if I wanted to replicate
this virtual machine to a different zone
within Southeast Asia, then all I need to do is under operations on the
left hand side blade here I go to disaster recovery. But I'm saying good and displayed. It asks me whether I want to
fill over to a different region. I have different options here. I can choose to fill over within the same region, using Zone-to-Zone. So I say yes to disaster recovery
between availability zones. Now what that does is it pins
me to Southeast Asia and then I can go to Advanced Settings and I can actually choose the zone
that I want to fill over to. If you see availability
as a field here, then my source is an
Availability Zone one, which I showed you in
the overview blade. But my target can be in Availability Zone three
or Availability Zone two. I can choose those, I can also choose other fields. For example, I can fill over it
to a different subscription. I can fill over or to a
different resource group. I may choose to use the same virtual network or
a different virtual network. I can perform a number of different
configuration changes here, but I can just choose
to accept the defaults, pick a different availability zone, and then review and
start the application. Once I do that, it takes
a few minutes for your application to be enabled and
for your VM to be protected. >> Now every virtual
machine is different, every application is different, how do I know that my users, or whether they be actual
users or whether they be clients that are calling services on those that
they are addressing this, do the address it by IP
address, by DNS name? How do I know when I fill
over from one to the other it is still addressable? >> Great question. Once you actually
protect your virtual machine, while protecting it you can choose the network you
want to feed over to. The nice thing about
Zone-to-Zone Replication or Zone-to-Zone Disaster
Recovery is that you can reuse some of the
networking components. You can reuse the same IP address for your secondary virtual machine. You do not need to reconfigure
your private IP addresses. You can just pick and use the same ones that you
were using earlier, and this is a big
benefit of Zone-to-Zone Disaster Recovery versus
Region-to-Region Disaster Recovery, where you really have to
set up on the networking. In a lot of cases our customers
have complicated networking setups and many at times they
don't want to replicate the same complicated networking
across different regions. For those types of customers Zone-to-Zone Disaster Recovery
is actually a great choice, because you literally
don't have to change anything with the
networking, it just works. >> That's fantastic. The
last question I have is, where are we thinking about storage? Some virtual machines
store on the local VHD, some talk to CosmosDB, some talk to SQL Server. If you failover and then fail back, how do you make sure you
have data integrity? >> Great question. So
we actually create a replica disk in the
target availability zone. We actually create a disk
which is of the same, or if you want to choose a different type of disk you can
choose a different type of disk. But we try to maintain the same
disk configuration and we'd replicate to a different
disk in that target zone. So once you failover, we actually spin up a
virtual machine for you in the target availability zone and attach that disk that
you were replicating to. >> That's fantastic.
That's brilliant. >> If I can just go
ahead and show you what it looks like to
have a protected VM. If I can go ahead and click on
review and start replication here. Here I can see a quick summary of my automation account and I can
choose to change any of these. Now for the purposes of
this demo I'm just going to choose and accept the default and I'm going
to start replication. Once I start replication
in a few minutes, my VM gets protected and here I have a second VM that I have already protected and let me show you
what a protected VM looks like. So when I go to the
disaster recovery blade, I can see that the VM
happens to be protected. The replication health is healthy, which means that we are actually
replicating in real-time. So any churn, any IOs that are happening on your source
virtual machine in your primary availability zone are faithfully replicated into your target availability
zone in real time. You also see the
recovery point objective here which is really, really cool. So you have a recovery point
objective here of a few seconds. That's really powerful for customers who can't
stand any data loss. Recovery point objective
is really a measure of the data loss that you might
see in the event of an outage. In this case, you can see that you'll probably lose about 34 seconds worth of data in the event of an outage as soon
as you click failover. >> Okay. >> Now, in the event of a disaster, failing over is really easy. I can just click on
failover here and then I can choose a recovery
points to failover to. That recovery point could go back
as far as 24 hours by default. But we can go back as far as 72 hours and choose
any recovery points. So we can failover to a point as
far as 72 hours back in history. Now for most customers, they actually prefer failing
over to the latest point, and that's what we choose as default. If I go ahead and accept
the defaults here. The latest process recovery point
was just a few moments ago. I can choose that and click
"Okay" and my failover has begun. Now, failover takes anywhere
between 20 to 30 minutes. RPO, SLA is about two hours
but really for most customers, for well over 95
percent of VMs we see that the RTO is a few minutes. Now, let me show you a failover VM. So this is a separate VM which I actually got a failover
for some time ago, and let me show you
what that looks like. So here I have a VM3, which has actually failed over. I actually failed over and
re-protected this back to primary. So you can see that
I have re-protected it back to my original zone. The status is protected, the application health is healthy, and again, I am ready to go and
fill back to my on-premise. Just to show you where I am
now with this virtual machine, you can see that I'm
actually in zone three. So I have failed over this virtual machine from
zone one to zone three, and all of this takes
just a few minutes. >> Could you again
tell us the acronyms? RPO and RTO? >> Sure. So RPO refers to
recovery point objective. A way to think about it is, it is a measure of the data loss that you might see in
the event of an outage. Typically, the RPO that you
might see is of a few minutes. So if you see an RPO of say
five-minutes for example, that means that you are
going to lose data worth about five minutes in
the event of an outage. Now RTO which is the
recovery time objective, is actually a measure
of the time it takes to spin up your application again
in the secondary datacenter. So if the RTO is five minutes, that means that it's going
to take five minutes after you click on failover
for your application to become accessible in
the target region or the target zone
as the case may be. >> I see. So there's the
returning back to live, returning to live and being
ready to service users. Then there's that
moment of data loss. Even though you said it might
take 10 minutes or 20 minutes, there's a lot of work
happening underneath in the background to make sure
that you're shuttling data, replication, and
disks back and forth. >> Exactly. We actually spin up a VM. So your VM in the target zone is actually not up until
you click on failover. That's a really cool functionality
because it drastically reduces the total cost of operations of your
disaster recovery setup. You don't need to keep your compute resources up
and running at all times. Only when you actually failover
do we actually bring up the compute resources in the target zone or the target
region as the case maybe. >> Well, this feels like something
that everyone should have. Now does this part of just
running virtual machines, does everyone have this? Does it cost to do recovery or does it just part of
the cost of a virtual machine? >> No. There is an additional
cost on this Scott, so it's $25 per VM per month. Customers tend to use it for their
business critical applications. Really, before they get to Azure Site Recovery as
the tool of choice, they actually perform an
audit of their environment and try to figure it out which of their applications are mission
critical versus which are not. For their mission critical
applications which cannot tolerate any
outage whatsoever, they choose Azure Site Recovery as the default disaster
recovery solution. >> That's great. You said that availability zone is a new feature
that is just recently out, so that's new separate from
region to region failover. >> That's right. We launched
region to region failover in 2018 and it is one of our
most popular scenarios. So customers can choose
to actually failover between the regions using the
Region-to-Region DR scenario. But Zone-to-Zone disaster recovery is something that we launched in June earlier this year and that's available in Southeast
Asia and UK South. The reason we actually launched
it is quite interesting Scott. So in most of our geographies
we have region pairs. If you look at any
large Azure regions so for example if you look at UK, you have two regions in UK, UK South and UK West. Or if you look at France we
have a couple of regions there. We have many regions in the US. So most of our GOs are covered
from a region pair perspective. But when it comes to Southeast Asia
which happens to be Singapore, Singapore is actually a city-state
of which is not very large. So it's difficult to house
two regions which are a few 100 miles away from each
other inside of Southeast Asia. For those type of customers
who have just one region in their geo and who are concerned
about data residency, they often don't want to or are not comfortable failing over
into a different region. So for example, for Southeast Asia, which is Singapore you may
choose to failover to Hong Kong. But a lot of our financial
services customers in Singapore are not comfortable
failing over to Hong Kong because they have strict data
residency requirements and legal compliance issues
and therefore they cannot move their data and their
applications outside of Singapore. So for those type of customers, Zone-to-Zone disaster
recovery is ideal. Because that way you're
actually ensuring that your data and your application
never leaves the regional boundary. It's constrained to
a particular region, but you're also failing
over between zones and so you are covered from a disaster
recovery standpoint as well. >> Very cool. So where can folks go to learn more about Zone-to-Zone Disaster Recovery and see
if it applies to what their technology needs are? >> Sure. We actually have
extensive documentation. So if you go to Azure docs, you can read up on how to enable Azure VM disaster recovery
between availability zones. I just showed you the
portal experience. But we also support PowerShell and
we have a rich set of Rest API, so customers can choose to use
those as well if they so choose. All of that is documented
in Azure docs. >> Fantastic. Well, thank you so
much for chatting with me today. >> Thanks Scott. It was
great to be on your show. >> I am learning all
about how to protect my applications across zones within the same region using Azure Site
Recovery today on Azure Friday. Hey, thanks for watching this
episode of Azure Friday. Now I need you to like
it, comment on it, tell your friends, retweet it, watch more. Azure Friday. [MUSIC]
