VMware and iSCSI best-practice

[brattex]

Hi guys

I have to decide how best to set up a VMware and iSCSI SAN. Here's the basic information:

I am splitting a 36TB SAN (running DDP) into various Virtual Disks. For one VM, it will be a File Server so it will have a 5TB drive available on its D: (Windows Server 2012).

I am not sure which of the following is a best-practice route:

Option 1: VM runs iSCSI connection to SAN, VMware Host does not
The Server 2012 VM initiates the iSCSI connection to the SAN directly, so on the operating system level, it is using iSCSI to connect to the 5TB D:

Option 2: VMware Host runs iSCSI connection to SAN as one big datastore, and I set up a 5TB VMDK for the VM
The VMware Host initiates the iSCSI connection to the SAN and has one big 22TB datastore (after DDP). I then configure the local VM as having a 5TB VMDK on that datastore.

My questions aren't easily answered because I can't tell which would be best-practice. We are not running vMotion or HA or anything right now besides an independent ESXi host, so if the host were to die, I can run a new host that talks to the SAN and gets the VMs back up.

Is it better to have the iSCSI running on the Host layer (so when the host boots up, it establishes the iSCSI connection before the VMs boot up) or to have the VMs run the connection? I don't really know ...

 

[drs]

For the sake of completeness:

Option 3: present a 5TB LUN from the storage system to VMware via iSCSI, and present it to the VM as a Raw Device Mapping hard disk.

I'd go with option 2, though. VMFS scales much better than it used to in the days of ESX 3. Consider carefully whether you want the VMDK thin provisioned or not, though.

I wouldn't be keen on option 1. I'd bet it'd be less CPU efficient than option 3, and probably option 2. Also, when you need to this for a second server VM, you'll have to go through setting up the iSCSI initiator again on that server.

 

[Clarotech]

You should be presenting the iSCSI (or any storage) to the VMware host and creating a VMFS ontop of that. It will give you the most flexibility in your virtual environment. IIRC whitepapers from VMware a while back there is an insignificant overhead in having the VMFS layer between your guest OS and the storage target.

Internal benchmarking we've done has also shown an insignificant performance difference between thick and thin provisioning. Obviously if you have a specific app and need every ounce of disk I/O you have you'd have a use case for thick provisioning, but "general" workload servers are fine with thin provisioning.

 

[brattex]

One thought I hadn't formulated yet was how VEEAM would function on snapshots / backups of the VM's.

If the VM's are running in-guest iSCSI initiators then I don't think VEEAM would see them; it would back up the OS which has the connection but it would not back up the entire 5TB disk.

If the VM's are running on VMDK's then VEEAM would back up the entire VM including the 5TB disk.

At least, that's how it would make sense to me...

 

[Clarotech]

Correct. If you want use Veeam your guests need be be sitting ontop of VMFS so Veeam can perform the snapshots.

You can drill into the backup settings in Veeam to exclude volumes. So if there is something you want to exclude then separate your data by creating additional disks and excluding them in Veeam.