Monday, 2 May 2016

VDP Hot-Add vs NBD

When a backup job is initiated for a virtual machine, there are two methods or protocols by which VDP performs the backup. 
The first one we have is the Hot-Add protocol, wherein the virtual disks of the virtual machine being backed up is going to be mounted on to the VDP appliance and then the backup will be performed. 
The second one is using Network Block Device (NBD) protocol, where in the virtual disk backup is done via the management network.

In the below screenshot, you can see the VM, New Virtual Machine, resides on Recovery_LUN datastore. 

From the next screenshot you can see that the VDP appliance virtual machine is residing on VDP-Datastore.

For the ESXi host where the VDP appliance resides, the storage configuration page shows that it does not have access to the Recovery_LUN datastore. This means the ESXi host hosting the VDP appliance does not see the virtual machine's datastore. 

In this scenario, where the ESXi host where the VDP appliance does not see the VMs datastore, Hot-Add protocol is not going to work and it falls back to the NBD protocol. 

Here are a few test results while using the NBD protocol:

I have a backup job called "ble" (Please ignore the name) and this contains the virtual machine named, New Virtual Machine. 

The next thing I did was, I started a manual backup job for this virtual machine. The backup job as usual initiates two tasks, create a virtual machine snapshot and a VDP: Backup Job.

When you go to Snapshot Manager for the virtual machine being backed up, you can see the snapshot created by the VDP, goes by VDP-EPOCH of backup.

And if I check the Edit Settings of the VDP appliance, I do not see the disk of the New Virtual Machine Hot-Added to the VDP appliance.

So now, the backup traffic will be flowing via the management network. So I performed a little esxtop test to check for this information. 

From the SSH session for the host which is hosting the virtual machine being backed up, I saw the following:

The virtual machine and the management network resides on the vSwitch0 with a vmnic2 uplink and we can see that the PKTTX/s is high and rising and dropping accordingly throughout the backup process. 

Next, if I SSH to the destination ESXi host where the VDP appliance is running, I see the following:

The VDP appliance is on vSwitch0 and is connected to an uplink vmnic0 and we can see the PKTRX/s is similarly high and is almost at the same rate of PKTTX/s of the virtual machine being backed up. 

Next, the observations of Hot-Add:
I am going to migrate this VM to a datastore which is seen by the ESXi host hosting the VDP appliance. 

So I migrated the VM to be backed up to the same host as my VDP appliance (As this host does not have any shared datastore) and put it on a different datastore, Suhas-Local-2. From my above screenshots you can see the Suhas-Local-2 is a datastore on my VDP hosting ESXi host. 

I then ran the backup job again, and this time, if I come to the Edit Settings of the VDP appliance I see that there is a disk added to the VDP appliance and this corresponds to the virtual disk of the VM being backed up. 

Additional information:
If you have virtual flash read cache disks (VFRC) in your environment, then those virtual machines have to be on virtual hardware 10 and above. When your VDP is on a lower version than the VMs with VFRC disks, then the backup protocol is always going to be NBD regardless if the ESXi host can see the datastore or not. 

Well, that's pretty much it!


Post a Comment