Administrator Guide

Live Volume support for Microsoft Windows/Hyper-V
81 Dell EMC SC Series: Synchronous Replication and Live Volume | CML1064
9.10.4 DR failure scenarios
Refer to section 8 for a list of DR events and how LV-AFO will function to protect the environment. The DR
events that will cause a Live Volume to automatically fail over are platform agnostic; LV-AFO itself works the
same given VMware or Windows Server/Hyper-V hosts or clusters. However, the steps necessary to recover
VMs and workloads given a DR situation will be different based on the following:
• The nature, scope, and duration of the disaster
• The platform (VMware or Microsoft)
• The type of server mappings (uniform or non-uniform)
• Configuration of the workload.
In general, VMware (when configured) may offer more HA resiliency with its ability to automatically move and
recover VMs and workloads at another location given a disaster.
9.10.5 Best practices for DSM tiebreaker placement with LV-AFO
One commonly asked question is about the placement of the Dell Storage Manager tiebreaker role, and if it
needs to be installed at third site. The simple answer is, yes. From a best-practices standpoint, particularly for
production workloads, it is critical to place the DSM tiebreaker at a third location to prevent site bias, which is
explained in this section.
While nothing will prevent a customer from co-locating the DSM tiebreaker role at the same site as the
primary or secondary Live Volume, cutting corners with this design puts the customer at an elevated risk of an
unintended outage due to loss of LV-AFO quorum. To avoid confusion, the reference to LV-AFO quorum is
separate, in addition to the Windows Server/Hyper-V quorum, as discussed in section 9.10.2.
For example, if the DSM tiebreaker is co-located at the same site as the secondary Live Volume, and this site
suffers an outage so that the primary Live Volume loses connectivity to both the secondary Live Volume and
DSM tiebreaker, the primary Live Volume will also go offline due to loss of quorum. The result is that there will
be a complete outage for any workloads that use this Live Volume. This is by design. When the primary Live
Volume loses connectivity to both the DSM tiebreaker and the secondary Live Volume concurrently
(assuming the Live Volume pair is in sync at the time), the primary Live Volume has to assume that by
becoming completely isolated (loss of quorum), that the DSM tiebreaker and secondary Live Volume are still
online, and that the DSM tiebreaker is now promoting the secondary Live Volume to primary status.
Placing the DSM tiebreaker at the primary site with the primary Live Volume will help prevent an unintended
loss of quorum, but only as long as the primary Live Volume stays at that site. If the primary Live Volume ever
fails over (for any reason, manually or automatically) to the other site, then the customer is again vulnerable
to an unintended loss of quorum and an outage due to site bias. To work around this, the customer could
install another instance of DSM at the secondary site to manually seize the local tiebreaker role for that
particular Live Volume if it ever fails over to that site, but this is not a very practical situation from an
administration standpoint.
If the customer does not have a third site of their own for the DSM tiebreaker role, then a cloud service can be
used. DSM can be installed on a physical host or a VM, as long as the OS is supported.
Each customer will need to make an informed choice about DSM tiebreaker placement. The risk of an outage
due to unintended loss of quorum might be permissible in some cases, such as for test or development
environments.