Administrators can also initiate a planned failover from the Windows Admin Center to migrate workloads from an active site to a secondary site. A planned failover can be beneficial when a scheduled maintenance window or approaching natural disaster has the potential to negatively affect running workloads on the active site. The Switch Direction feature of Windows Admin Center allows administrators to move workloads from one site to another in a stretched cluster configuration. This feature must be initiated on a per-volume basis.

We performed a Switch Direction operation on the OM volume, which hosted the OME-1 VM virtual disk. The two main goals of this test were as follows:

• Determine whether any loss of connectivity occurs between a client and the OpenManage Enterprise web application during the Switch Direction operation.
• Determine whether the Switch Direction operation causes any interruption to a running device discovery job in OpenManage Enterprise.

The following figures depict the healthy VMs, healthy volumes, and the Storage Replica partnerships, respectively, in Windows Admin Center before the Switch Direction operation was initiated.

Figure 24.    View of healthy VMs in Site 1

Figure 25.    View of healthy volumes in Site 1

Figure 26.    Storage Replica partnerships configured for ax740sc101

A device discovery job was created in the OpenManage Enterprise portal. The following figure depicts the running job in progress before the Switch Direction operation was initiated.

Figure 27.    OpenManage Enterprise device discovery job begun before Switch Direction operation

The Switch Direction operation was initiated from the Storage Replica tool in Windows Admin Center. We selected only the partnership involving OpenManage Enterprise, which consisted of OM-group and OM-replica-group, for planned failover. After selecting the partnership, we selected Switch direction from the list options, as shown in the following figure:

Figure 28.    Initiating Switch Direction operation

Figure 29.    Confirming the Switch Direction operation

Within seconds, Owner Node for the OM and OM-Log volumes changed to Node 2 in Site 2, and Owner Node for the OM-Replica and OM-Replica-Log volumes changed to Node 2 in Site 1, as shown in the following figure. During this operation, we observed no interruption while accessing the OpenManage Enterprise web application from a client device.

Figure 30.    Volume owner nodes displayed after Switch Direction operation

The following figure shows that the OpenManage Enterprise discovery job was still progressing throughout the Switch Direction operation.

Figure 31.    OpenManage Enterprise device discovery job progress

At this time, the OME-1 VM was running in Site 1, but its virtual disk that resided on the OM volume was running in Site 2. Performance problems can result because I/O is traversing the replication links across sites. After approximately 10 minutes, a Live Migration of the OME-1 VM would occur automatically so that the VM would be on the same node as its virtual disk. To speed up the process and avoid a potential degradation in performance, we manually initiated a Live Migration in Failover Cluster Manager.

Figure 32.    Live migration of OME-1 to Chennai site

As with the unplanned failover test scenario, an IP address change was required after the Live Migration because the VM networks in both sites are on separate L3 subnets. However, the Live Migration presented an additional challenge because the VM was never restarted. Thus, the VM would not request an IP address from the DHCP server in the new subnet. To avoid this issue in the lab, we took the following steps:

• Configured the DHCP scopes servicing the VM networks to use short lease durations. This configuration ensured that OME-1 had to request a new IP address from DHCP after the Live Migration.
• Configured a low TTL value on the lab DNS servers.

These actions produced the following behavior from OpenManage Enterprise:

• The OME-1 application was reachable by its hostname from the client device within 3 minutes after the Live Migration to Site 2.
• The device discovery job running within OME-1 was never affected, as shown in the following figure:

Figure 33.    OpenManage Enterprise device discovery progress during live migration