Many posts cover the installation and performance benefits that come from using the Dell Multipathing Extension Module (MEM) on EqualLogic arrays (check the spoonapedia.com one), but the big difference for me was a bit of a pleasant side-effect in terms of handling backups! I’ve covered off this strategy from a high level in my previous blog post, Backup Strategies with Virtual Machines in VMware using Veeam, but I wanted to explain in a little bit of detail how I actually got there: it was down to the MEM!
Before – accessing data from within the OS

Because the file servers I’ve been working on access a lot of data (8TB worth), the original setup involved using the EqualLogic Host Integration Tools (HIT kit) from within the file server OS to access LUNs on the EQL array – this provided valuable multipath access and proved to be a very successful way of handling access to the data. The problem was that is complicated backups quite significantly, I could use veeam to backup the OSs (and I did), but I had no way of backing up the actual file data.
With various bad experiences from using market-leading backup software such as BackupExec in the past I wasn’t in a rush to go out and spend money on a software solution to handle all this file data, so I resorted to a very low-tech solution: I bought a nas box and did a nightly robocopy.
This was simple, but it was awful: the backups didn’t finish in time (they’re being taken over a 100mbit LES), they never caught up with themselves. It was a waste of time and it basically meant no backups were worth having.
After – install the MEM and let ESXi deal with it

But then the MEM came out, and essentially claimed to offer the same (if not better) performance via ESXi – no messing around with the HIT kit any more, and more importantly, a chance to re-evaluate my first decision about not using .vmdks… I changed my mind.
The first time round I did thick LUN straight into Windows, formatted as NTFS, simple. This time I re-evaluated and did a thick LUN on the EQL and then allocated thin disks in ESXi and mounted them to the file servers… This gives me greater flexibility if a disk gets close to its limits but it also now means that the extra .vmdks are picked up by veeam allowing me to replicate my previously successful backup strategy.
In summary…
Veeam now handles the file data as incremental .vmdks which means it only transfers the changes in the .vmdk files – the entire series of backups finishes over the 100mb LES in about 12 hours (which, bearing in mind I run it once a week at the weekend is ideal); the previous robocopy never finished in that amount of time: the size of the data transferred is obviously the same, but because robocopy iterated through every single file and folder for a comparison it took much longer whereas now veeam just… does it, and it was a product that I already had so didn’t require any extra spend (not to mention the money that could now be saved on not upgrading the LES to 1GB purely for the purposes of backup).
Next?
Now being quite satisfied with this setup I’m going to investigate the series of advice from ErikZandboer on optimising his ix2-200 backup speeds, specifically the post that looks at jumbo frames to target storage.