AWS Elastic Disaster Recovery with VMware Raw Device Mappings

4 minute read
Content level: Advanced
1

Demonstrate AWS DRS ability to replicate filesystems backed by a physical mode RDM

Introduction

A VMware virtual machine disk is typically backed by a VMDK file sitting on a VMFS filesystem. A VMware Raw Device Mapping (RDM) in physical mode gives a guest VM the ability to directly access a SCSI device. This is most frequently used to create a guest VM cluster using SCSI persistent reservations. It was also commonly used in the past to give guests access to filesystems larger than the maximum VMDK size.

Physical mode RDMs present a recoverability problem because most tools cannot access them. Commercial backup solutions including AWS Backup do not support physical RDMs. However, AWS Elastic Disaster Recovery (AWS DRS) is agent-based and can see guest filesystems backed by a physical mode RDM.

This post is:

  • A demonstration of failing over vSphere VMs with a physical mode RDM into a native EC2 instance
  • A demonstration of failing a native EC2 instance back into a vSphere VM with a physical mode RDM
  • NOT a support statement guaranteeing that AWS DRS will work for all physical mode RDM use cases
  • NOT a recommendation that you use physical mode RDMs in AWS - RDMs are not a supported construct in native AWS or in VMware Cloud on AWS
  • NOT a full demonstration recovering a VMware physical mode RDM clustered application

Testing environment

I used Ubuntu Linux VMs in my lab with a standard boot volume and a 10GB iSCSI LUN attached as a physical mode RDM.

/dev/sda is an ext4 filesystem backed by a standard VMDK. /dev/sdb is an ext4 filesystem backed by a physical mode RDM, mounted to /rdm

VM RDM

Configuration

I used this document to configure the default replication settings.

I used this document to configure replication of my source VMs

During installation, I was prompted to confirm which devices I wanted to replicate - the agent successfully detected the RDM-backed /dev/sdb

Device selection

The installer continued and finished once it established a replication connection.

Initial Replication

Replication

I placed a few text files on the RDM-backed volume

RDM files

After the initial sync completed, I had to wait for a snapshot to be taken before I could use the backup for a recovery procedure

Waiting for snapshot

Recovery Drill

A recovery drill lets you recover a replicated backup without doing a full failover. I executed a recovery drill on my replicated EC2 instance

Recovery Drill - Screen 1

Recovery Drill - Screen 2

The files that were on the physical mode RDM are visible in the drill EC2 instance

Enter image description here

The Ubuntu instance retains the mountpoint in /etc/fstab:

fstab

The device names have changed from sda and sdb to nvme0 and nvme1

EC2 device names

Failover

To test a full failover, I created a second Ubuntu VM (ubuntu02) on-prem and connected it to the same physical mode RDM as the original VM (ubuntu01).

I ran a failover of ubuntu02.

Failover1

Failover2

Once failed over into EC2, I added a few extra files to /rdm

Enter image description here

Failback

I used the failback documentation to fail my EC2 instance back to my on-prem VMware environment. I had to build out a shell of a VM with a VMDK attached as the first device and the RDM attached as the second device. Then I booted the VM shell into the recovery client. The files that I added to the EC2 instance were successfully recovered to the RDM.

RDM files

Conclusion

In a VMware environment, AWS DRS makes it is possible to protect the files on a filesystem backed by a physical mode RDM. AWS DRS cannot replicate the RDM itself. Your clustered application that is dependent on the physical mode RDM will not be available in AWS. If your clustered application can function with the necessary files available at the expected mountpoint, you might be able to use AWS DRS to protect your on-prem workload. A pilot is strongly recommended to prove out your use case.

profile pictureAWS
EXPERT
published a year ago1053 views