Hello. In this video demonstration, we will be presenting a disaster recovery solution for guest connect storage with cloud volumes ontap as VMware solution and jetream. We will show configuration tasks, validation of virtual machine failover to guest OS failback. So with that, let's jump right in and begin by explaining the architecture. Here'sa highle view of the solution architecture. The application VM workloads include Microsoft SQL Server, SnapCenter 4.6, Windows 2016, and a Linux VM. The OS discs of the workload VMs are protected using Jetstream and can be recovered in the Azure VMware solution environment. The ingest data volumes for the SQL server are snap mirrored to cloud volumes on which is hosted in the Microsoft Enzero environment as well. The SnapCenter VM protects the SQL server application data and is used to recover the same in the standby site. Here's a view of the workload virtual machines as well as the source and target volumes. Our first step is going to be configuration of Jetream. We click on the Jetream appliance VM and then click on the configure tab and Jetream DR to access the configuration options. The configuration wizard pops up to begin the required configuration for protecting VM. We'll select no cluster configured here to continue. As seen here, the MSA appliance is registered with VSCenter and with the appropriate subscription ID, tenant ID and application secret. Click configure cluster and select the relevant storage cluster of the VMs to be protected. The next step is to deploy and configure the DRVA appliances. Click configure and provide all the required input parameters for the DRVA deployment. Click deploy to submit the task. The progress of the task can be monitored under the task log tab. A supporting replication log volume needs to be created for each DRVA appliance which serves the purpose of storing metadata. The final step is to create a protected domain. Once again specify all required parameters, validate the inputs and click create to submit the task. The VM protection can be initiated under the protected domain with start protection. Select the VM workloads and change the protection mode to write back VMDK to achieve the protection with a higher performance. The protection mode can be applied to all VMs or can be individually selected. Further, the protected VMs can be configured with failover runbook to group them, control their boot sequence, configure a static IP address, and retain the VM's MAC addresses. Next, we will log into the vsenter of the Azure VMware solution. The Jetream appliance is already set up here. The storage site setup will have reference to Azure blob storage that has been preconfigured on the on premises vsenter. Click scan domains to identify the protected domain that has been created on premises and import this protected domain to the AVS vCenter. All of the VMs that are protected from the on- premises vsenter are in a recoverable state. Jetream provides the option to configure continuous failover to constantly hydrate data that is being written to the workload VMs on premises. This option can be selected under the more button. Certain values are prepopulated including protected domain name and the estimated size of data protected. Select options for the failover settings including data center name, cluster name, and data store of the AVS vsenter server. The wizard provides the option to select the appropriate VM network on the recovery site which can be selected from the drop-down. Optionally, a relevant storage policy for the VM discs can be selected here. In addition, the recovery virtual appliance network settings can be configured by selecting the port groups to which the VAS can be connected from the drop-down. Next, the DR settings are configured by selecting a DRVA, a replication log disk for the metadata, and specifying a log size. Click continuous failover to begin the continuous data rehydration. It can be observed that the JSSRVM appliances are created for each of the protected VMs to achieve the task. The status of this task can be seen in mode under protected domains which reports continuous rehydration in progress. It goes through a series of steps to perform the activity and the same can be seen under current step. The amount of data being processed during the rehydration is also indicated as the task progresses. With the above setup in place, let's test the guest VM failover to the DR site running on Azure VMware solution. On the Jetream DR screen, hit failover. Under the protected domains tab, select force failover to initiate the VM workload failover. The wizard also provides an option to select a recovery VM network. Click confirm to approve the force failover. If the failover runbook configuration is set up, it is required to provide the administrator credentials to set up the network configuration during the failover. Select the VMs to apply the credentials for the administrator account. Click complete failover to complete the task. The list of steps can be reviewed to see the list of tasks that it goes through during the failover process.Let's log into cloud central to review the replication status of the ice scuzzi lens which are connected to the SQL servers on premises. The next step would be to break the snap near me replication relationship for the LUNs between the on premises and cloud volumes ontap ice scuzzy luns so that these loans can be connected to the VMs that are restored in the recovery site. The protected VMs can now be seen recovered on the vsenter server of the recovery site. The results of recovery can also be verified from the configure jetream DR option. Warnings reported here are about the failure of VM power on which can be done manually. Connect to the console of the SQL VM and set up the iscuzils that are replicated on the cloud volumes ontap instance on the recovery site. Copy the initiator IQN name and configure the sand initiator groups on system manager to allow access to the LUNs. Log into the iscuzzi target from the issues initiator properties of the Windows SQL VM and ensure that the login to the target is successful. Launch disk management and bring up all connected discs online. Restart the SQL Server and launch the Microsoft SQL Server Management Studio 18. Log into the SQL Server with appropriate credentials. Then we'll drill down into the CARD DB database and rightclick on the dbo.card card DB table to run a query of the top 10,00 rows and verify the table's contents have been replicated. As seen, the VM is online with the database contents replicated on the recovery site. Now, we'll log into our SnapCenter server. Click resources to verify and manage the backup copies of the database that have been hosted on the Windows SQL server. Go to settings and then global settings and ensure the check box for VMs have ice direct or NFS is selected. Expand disaster recovery and check the enable disaster recovery option and then apply to confirm. This is to indicate that the resources are accessed from secondary storage. With this checked, the backup jobs and replication activity will be suspended. Note that the option is available on SnapCenter 4.6 six for Microsoft SQL Server or later. It can also be observed from the Jetstream DR option on the AVS center that the environment is running in failover mode. The VMs can be configured to retain the same network address as indicated in the failover runbook configuration task. Let's take a look at the guest OS failback process which can be achieved using NetApp Snapmir and Jetstream. In the AVS V center under Jetream DR, select the failback option from under the more dropdown to initiate the recovery task. On the pop-up wizard, provide all the required inputs. Network port groups used for replication to object store, host to DVR, data network, and management network should be selected from the wizard drop-down as well. Select the Jetstream DRVA appliance and the replication log storage for the metadata that will be used for the failback process. Indicate the replication log size that will be consumed from the log storage. Review the inputs from the summary screen and click failback to initiate the task. The progress of the failback task can be viewed on the Jetream DR screen under protected domains. As the tasks come close to completion, it can be observed that the VMs are available back on the VSCenter and powered on. The results of the task are displayed after the completion of the task with the status. The task has completed successfully. Here we will verify that our operating systems are up and running with our original network IP addresses. Next, let's log in to NetApp Cloud Central. On the replication tab, initiate reverse reync so that the changes on the recovery site are synced back to the volumes in the primary site. Repeat the reync task on all three volumes. Ensure that the volumes are healthy and in the snap mirrored state. Log in back to the Microsoft SQL Server to disconnect any stale connections and restart the Microsoft SQL Server services.The database and the tables can be verified from the SQL Server Management Studio.Finally, log into the SnapCenter server. Select settings and under global settings, expand disaster recovery and uncheck the enable disaster recovery setting to restore backup workflow and restore activity. This concludes our video demonstration of a disaster recovery solution for guest connect storage with cloud volumes ontap as snap center and jetream. Thanks for watching.