Should I use vRDM?

[rfn]

Hi,

I'm new to Veeam Backup & Replication and have a question about whether I should configure our file server and SQL server with vRDM or VMDK. We got our EqualLogic SAN's about a month ago and previously we were running on local storage on ESXi. Now everything is on the EqualLogic and we're running ESX 4.1.

Our file server (running Windows Server 2008) currently has only a C drive with a huge data folder where we store all our shared files. It was a stupid design mistake but it wasn't really my decision, and it has worked fine as long as we were using local storage. Now I wish to move the files to a new D drive, but I'm not sure if I should use a vRDM or a VMDK.

Our SQL Server (running Windows Server 2003 with SQL Server 2005) is currently a physical installation, but will we virtualized soon. I plan on creaiting a couple of LUN's for log and database and connect to them using the MS iSCSI initiator and move the database files. Then I will virtualize the server. EqualLogic recommmends that I use the iSCSI initiator inside the VM, but that will make it impossible for Veeam to back it up and that's not so smart.

I have done some testing, and when using vSphere thin provisioning then VMDK's are much slower when writing than vRDM. If I perform a full format of the VMDK (or create it as eagerzerothick) then performance is equal to vRDM, but then I loose the option of using thin provisioning on the EqualLogic. Volumes connected with the iSCSI connector inside the VM perform equally as the vRDM but uses a lot more CPU inside the VM. I have no idea if it's using more host resources to create the iSCSI connection inside the VM when compared to have ESX create the connection, but the VM is definately more busy.

vRDM seems to be the best option for us, since it's not resource intensive and I can use thin provisioning on the EqualLogic without any real performance penalty. The question is if this is going to be a problem when using Veeam? I have read that it can backup up vRDM but is there ANY downside at all? What about restores, are they still restored as a full VMDK as I have read on this forum or has that changed in the latest version 4.1?

What will happen when I use the automated testing in Veeam version 5 when using vRDM? Will the backup be able to see the backed up files? Will the volume be converted to a VMDK during the backup? As you can tell, then I'm very new to Veeam and I'm currently reading the manual to configure our installation correctly.

BTW, we're running vSphere Essentials ESX 4.1 on 3 hosts. We only plan on using Veeam for backup since we're using the built-in replication in EqualLogic to replicate between our two EqualLogic's. If this is stupid, then please let me know

[Vitaliy S.]

Hello Rene,

vRDMs will be converted to full VMDK files during you backup jobs, thus meaning that those disks will be treated as full VMDK files for both SureBackup jobs and restore jobs.

As regards to differences in using built-in SAN replication capablities and Veeam Backup and Replication, you may consider searching the fourms for more information on those approaches, here is one of the topics that might be relevant:
http://www.veeam.com/forums/viewtopic.p ... ion#p15055

Thank you!

[Gostev]

Hi Rene, Vitaly is correct - inside our backup, you will have VMDK files (converted from vRDM during backup). The only downside is full VM restore will restore them as VMDK. All other restore types and functionality will not be affected.

[tsightler]

Any plans to fix this to support restores of vRDM disks?

[rfn]

Thank you for your replies. Of course I don't plan on ever having to restore a full VM, especially since we're also using replication to a secondary site (a building next door), but it's good to know what will happen if I perform such a restore.

Should I understand your replies as there's now real downside to use vRDM for our data disks on SQL Server and file server?

[Gostev]

Any plans to fix this to support restores of vRDM disks?

This is not impossible, we just had very few requests for this so far.

Should I understand your replies as there's now real downside to use vRDM for our data disks on SQL Server and file server?

Correct, no real downside, except full VM restore. All other existing and new v5 functionality will work with backed up vRDM disks.

[rfn]

Will Veeam v5 still be able to perform SureBackup checks of VM's with vRDM disks? Does Veeam reconfigure the backed up VM to point to the VMDK's that it converts the vRDM to or does it still point to a vRDM, effectively making it impossible to boot and check?

[Vitaliy S.]

Rene, yes, Veeam converts vRDM disks to full VMDK files during backup jobs and edits VM configuration, so SureBackup job will also be able to perform health checks for your applications.

[rfn]

Great... I have configured our VM's with vRDM disks for now, but since all three hosts needs access to these LUN's then I'm creating a lot iSCSI connections to our EqualLogic SAN and i'm nearing the maximum of 128 connections for one pool. This leaves me little room for growth in case I need to create more VM's which should also have their own vRDM.

I'm considering going back to VMDK files located next to the VM itself but my own testing showed that if I didn't zero out the VMDK's then write performance was pretty bad the first time a block is written to. And when zeroing VMDK's then I loose thin provisioning which is a shame.

[bperez]

Did you ever come up with an effective solution? I am running into the same issues.

Brent

[rfn]

We're still using vRDM for our SQL Server but doesn't have a lot of datastores beside that and with the newer EqualLogic firmware then we can have double the amount of iSCSI connections to our SAN so we don't have any issues with to many iSCSI connections anymore.

Further testing has showed that there's no real performance benefit by using vRDM versus VMDK, but it's working as it is and I still have to separate the VMDK's on separate LUN's so I won't really simplify anything by using VMDK.

[bperez]

Right now the consultants that set up my SAN used iSCSI within the VM... but I am think thinking of the ability to use Veeams solution.. it wont see the Data and SQL volumes. So its either use the VMDK or vRDM....
Seems like VMDK would be simpler since I have to change anyway. I was hoping to find a way do make backups easy and VM's easy to move but also use the EQ built in snapshots to add another level is recovery....

Looks like I am having a few issues with the MPIO / IScsi connections too... they arlready "broke" once and we had to rebuild the Volume once already.

[rfn]

First, I'm by no means an expert on this subject but here's my 5 cents:

It's of course a viable solution to use iSCSI from within the VM and that will let you use ASM/ME to create snapshots and replicate to another SAN. The problem is as you have discovered that VBR is not able to see the volumes and that's one of the reasons that I haven't done that. That and the fact that the MS iSCSI initiator used quite a bit of CPU inside the VM, but I don't know if it's more if the iSCSI connection is handled by vSphere.

If you need to get maximum performance from your SQL Server then I guess it's still best practice to separate the system, database and log files on separate LUN's. If you create two datastores for the database and logs and fill them up with one VMDK on each then I guess that it would create an alarm in vCenter unless it's possible to create an exception for some datastores?

With a vRDM you don't have that problem and you can also use thin provisioning on the SAN level which doesn't really hurt performance. If you use thin provisioning in a VMDK then it hurts write performance a lot, at least when it's writing to blocks that were previously unused. I have had to zero out VMDK's to get the same performance as vRDM's and then you can't use thin provisioning.

Regarding your MPIO/iSCSI problems then we had problems in the beginning as well. What network adapters are you using for iSCSI?