in this video you'll learn the important
concepts you need to stretch an azure
stack hci cluster between two sites for
disaster recovery
no selling just an explanation of how it
works it's time to get hands-on
with azure stack hci it's easy to
stretch one azure stack hci cluster
between two sites for a simple robust
business continuity and disaster
recovery solution more commonly known as
bcdr the sites can be close together
in different fire zones of the same
building or far apart geographically
as in different cities for example when
deploying your cluster using windows
admin center
choose azure stack hci and then choose
stretch cluster
based on your network configuration
azure stack hci can usually detect which
server nodes are in which
sites if not the cluster creation
workflow will prompt you to specify that
to orchestrate quorum in any stretch
cluster you need a tiebreaker vote
often called witness azure stack hci
natively uses the azure cloud
as its witness this makes for a very
lightweight solution that requires
minimal bandwidth and just a few
kilobytes of storage
you don't need a clunky virtual machine
appliance nor a third site
in fact the minimum you need is just two
nodes per site and an internet
connection
once the stretched cluster is created it
is a simple step to provision storage
including setting up replication between
sites choose to replicate
choose the replication direction then
choose asynchronous
or synchronous and additional options
for example to achieve near-synchronous
replication
you can specify a very tight recovery
point objective
or rpo this site-to-site replication is
in addition to local resiliency
which is always provided by the azure
stack hci software defined storage stack
and works exactly as it would in a
non-stretch cluster
behind the scenes azure stack hci will
provision two identical volumes
the primary and the replica plus log
volumes for each
joined in a storage replica partnership
then when you're ready to create virtual
machines
simply place their virtual hard disk
files into the replicated volume
if you choose synchronous replication
all rights to persistent storage will be
replicated to both sites before they're
acknowledged
if you choose asynchronous writes will
acknowledge as soon as they're persisted
to one site
and then replicated to the other site
moments later based on your chosen rpo
because it's one cluster failover is
automatic
disasters happen at unexpected times
like the middle of the night
if the power goes or pipe bursts over
the server room with azure stack
hci stretched cluster it's no problem
the virtual machines automatically fail
over to the other site and resume
running
providing business continuity with no
need for an administrator to take any
action whatsoever
in windows admin center you can watch as
the servers in one site go down
and the virtual machines automatically
move over until they're all
on the other site with azure stack hci
it's also possible to run virtual
machines on both sites
simultaneously sometimes called an
active active configuration
in this configuration for certain
virtual machines one site is the replica
for the other
and for the other virtual machines it's
vice versa some virtual machines can
even have no replication at all
depending on your business requirements
to precisely control virtual machine
placement between sites
azure stack hci offers powerful new
affinity and anti-affinity controls
an affinity rule ensures that two
virtual machines are kept on the same
site
for example to ensure locality between
the web tier of an application
and its database an anti-affinity rule
ensures that two virtual machines stay
on separate sites
for example if you have two domain
controllers
these rules are easy to set up directly
from the virtual machines tool
in windows admin center under vm
settings or if you prefer
you can also see all the rules and
configure them centrally in cluster
settings
with an active active azure stack hci
you can
increase utilization while also
benefiting from each site effectively
providing disaster recovery for the
other
with azure stack hci robust bcdr
is built in its lightweight architecture
means you don't need a vm appliance or
third site
both sites in the cluster can be active
and host virtual machines at the same
time
when disaster strikes failover happens
automatically
there's nothing you need to do you have
the flexibility to choose synchronous
near sync or async storage replication
depending on your needs and your network
and it's all natively integrated in
azure stack hci with no third-party
software required
to learn more and for step-by-step
instructions visit aka dot
ms forward slash hci
thanks for watching