I recently had the opportunity to test briefly, for only one day, this Dell deduplication appliance. I’ve not been able to do extensive testing or performance ones, only a quick assessment of the management interface and derive some impressions on its use.
DR4000 is a first for Dell, and its deduplication technology comes from the Ocarina Networks acquisition Dell made some time ago. From the hardware point of view, the DR4000 uses a R720XD server carrying 12 SAS 10k rpm disks, 300 GB each. The confirmation is done by connecting a monitor to the video jack, where we can see the Dell bios and CentOS Linux operating system booting. Different appliances use Linux operating systems as a starting point, upon which they build their real value thanks to proprietary software.
Once booted, the entire administration is done through an intuitive web interface. There are not so many options, it all boils down to the creation of one or more network shares in different formats
(NFS, CIFS, or OST for Symantec), and a couple further configurations, such as the ability to optimize the level of deduplication and compression to favor disk space or performance.
The system also provides the ability to clone the contents of one share to another appliance, but having only one system available I could not test this feature. I could see that in any case, you can configure different schedules to better manage network usage by replication activity.
The client where I was able to test the DR4000 has an EMC Clariion CX4-120 storage connected via FC to a VMware cluster, and a physical backup server also connected to FC, and Veeam Backup & Replication 6.5 on board. We ran some tests to better understand the behavior of the appliance, but the numbers you will see below absolutely do not want to be a benchmark. To get the comparable numbers not affected by VMware CBT, all backups were full ones. We selected two virtual machine for a total of 740 Gb of vmdk disks, of which 428 actually used. The fabric is a 4gbit FC, while the Ethernet network whre the appliance was connected to was 1 Gbit. First, we performed a backup to the internal storage of the backup server, consisting of 10 SAS 15k rpm disks aggregated into a RAID10.
In these results, bottleneck values were 80% Source and 53% target, so we have reasonably inferred that 148 MBs was the maximum speed of the storage. Before saving backups to the appliance, we set as best practices compression to “dedupe-friendly”. The new Veeam backup gave these results:
Beeing the DR4000 an “inline” deduplication appliance, the loss of performance compared to a non-deduplicated storage was expected. The decline is visible in both speed values(from 148 to 77 MBs, as also seen in the console DR400)
and also in different bottleneck values inside Veeam: we moved from Source bottleneck to Target. Again, nothing unexpected, but definitely a parameter to be taken into consideration when sizing a backup infrastructure. Another important aspect when you go to use a deduplication appliance is its behavior during restore operations. Data must be read and “rehydrated” in real time to provide them to the application that is requesting them. So we did a restore test of an entire vmdk from the same virtual machine we saved before.
Restore had an average speed of 60 MBs, and this number was comparable with the one of the backup operation.
To conclude, I should say that the DR4000 is all in all a good appliance and it does what you would expect from such a system. I would expect a greater number of options available, but it could also have been a deliberate choice of Dell to make the appliance very easy to set up and use. About performances, the tests were unfortunately too short to draw any clear guidance.