Atlantis USX – deduplication

In my previous post I tested disk performance base on Windows 2008 R2 servers. All the servers was installed using the same build (image for Terminal Services/XenApp service). In the past I’ve done some tests with deduplication on NetApp filers. I’ve placed 10 W2K8 servers on one LUN. When I enabled deduplication I was able to reduce used space to 30%. So deduplication ratio was at 60-70%.

I wanted to test how many physical data can be reduced in Atlantis USX.

Atlantis USX™ includes integrated HyperDup™ Content-Aware Data Services that leverage Atlantis real-time deduplication technology to provide data reduction, IO acceleration, provisioning, data mobility, security and business continuity for any storage.


Here is the Atlantis USX technology diagram.


Let’s focus on the block called “Data reduction”.


Atlantis USX provides patented, real-time, in-line deduplication and compression to reduce the capacity required to store data by up to 90%.
Atlantis USX deduplicates at the 4KB block level and operates by detecting redundant data and replacing it with a single logical copy, maintaining an index and using reference pointers to make that data available whenever it is required. The higher the amount of redundant data, the larger the storage capacity and cost savings associated with the Atlantis USX HyperDup technology.



Compression is another proven data reduction technology that Atlantis USX uses in conjunction with deduplication to reduce storage capacity requirements even furtherAtlantis USX In-Memory Storage Optimization Technology offers policy-driven lossless compression, based on proven Lempel-Ziv algorithms, which can be applied to the deduplicated I/O stream before it is written to storage.


I’ve created 8 VMs, placed them on storage LUN and installed Windows 2008 R2 (one image). After that, I moved 3 VMs from storage LUN to Atlantis Hyper-converged (HC) volume. Deduplication ratio (reported by USX console) was 68%. Capacity used (from XenServer perspective) was 40.5GB (inside Windows server spaced used was 20GB).


XenServer XenCenter console – volume space utilization:


In this configuration I’ve done some tests, and started moving next VMs to this volume:

  • 3 VM’s – 40,5GB
  • 5 VM’s – 45,8GB
  • 6 VM’s – 47,6GB
  • 7 VM’s – 49GB
  • 8 VM’s – 50,7GB

When I moved all 8 VMs deduplication ratio was 79%. In thick provisioned LUN used space will be 20GB * 8 VMs = 160GB. And on Atlantis volume used space was almost 51GB.

Here are some graphs from USX Manager console.

As you can see, deduplication ratio increased, and simultaneously metadata size also increased (those data have to be put somewhere).




Here is very interesing graph – IOPS offload. I guess that means (documentation doesn’t explain this very well), that all those I/O operation was handled by RAM, and it doesn’t have to go to disk (increase speed and reduce latency).




And the last very interesting thing. Here is the screenshot from Volume VM statistics. In those rectangles we have 4 columns – starting from the left: disk read, disk write, network receive, network send. I made this screenshot, when I started VM move operation (from storage LUN to Atlantis volume). We have about 60MBps input network traffic. At the beginning some part of those data goes to disks (10MBps) – I guess, it was some unique data (red box), but after a while some data was the same as those already stored on a disks, so deduplication process started saving only metadata, and only small portion of those data goes directly to disks.


Note: All test was done on Atlantis USX version 2.2.2.

Post author

There are 2 Comments

  1. Posted by Andrew Wood Reply

    Good testing there. Just out of interest, which USX volume type did you test here? Simple Hybrid?

    Did you have a look at the fastclone technology?

    If you point to the documentation piece where you’d like extra clarification I can get that sorted 🙂

  2. Posted by Andrew Wood Reply

    I’d also say that while 70% is “better than netapp” 😉 … we do see much higher dedupe rates for non-persistent/cloned VMs – but 70% is a decent enough start – and thats *inline* dedupe; that is, its happening during the write process – so the load and capacity being put onto the backend storage is reduced by utilising some resources from the XenServer hosts.

Leave a Reply