XenDesktops and Deduplication

[MarcMoennikes]

Hello,

is with version 5.8 deduplication official released and not experimental?
We are planning to implement XENDESKTOP, so deduplication maybe very interesting for our VHD files (we will use hyper-v as hypervisor).

About performance: Are there performance disadvantages with deduplication (so you advisable to use deduplication) or is the san performance not affected?

Thank you

Regards

[anton (staff)]

Yes. In V5.8 it works in non-HA configs only and with V5.9 and up HA is expected to be supported as well.

The answer is "it depends". It does chew out some RAM for hash tables (so the same RAM is not used for write-back caching obviously) but cache is deduplicated now and with proper environments amount of I/O requests is decreased. So you'll have different performance pattern. Not exactly worser or better then you have now w/o dedupe.

Hello,

is with version 5.8 deduplication official released and not experimental?
We are planning to implement XENDESKTOP, so deduplication maybe very interesting for our VHD files (we will use hyper-v as hypervisor).

About performance: Are there performance disadvantages with deduplication (so you advisable to use deduplication) or is the san performance not affected?

Thank you

Regards

[Aitor_Ibarra]

During the 5.8 beta I did an experiment with good performance results, and that was before 5.8 had been fully performance optimised.

I was using one pair of 5.8 installs as a "traditional" starwind HA target. These were storing their .IMG's on iSCSI targets which were other instances of 5.8 running dedupe targets on SSD. This set up enabled me to have HA & dedupe.

From memory, I could simultaneously boot four VMs in about 15 seconds. This was with Hyper-V, with the VHD on a CSV on the HA target. I didn't have enough RAM on my hyper-v nodes to try with more.

The main problem with this setup was orchestrating shutdowns/reboots of the four starwind nodes. It has to be HA node first, then corresponding dedupe node. You are also effectively doubling the amount of data passing around your SAN, so NIC & PCIe performance, CPU, ram speed etc are all things which might limit scalability. And latency will go up a bit too. Starwind upcoming HA dedupe will eliminate much of this extra overhead.

I think with SSD as your backend storage (or SSD + HD with LSI CacheCade or similar) you should be able to build something capable of coping with the IOP storms you get with VDI hundreds of VMs starting at the same time. With Starwind dedupe, most of the work is pushed onto the CPU at write time rather than read. Given that VDI is going to be 80%+ read, this will work really well. Once dedupe is HA, the setup should be simpler than what I tried, and given Starwind's laser sharp focus on performance & reliability, I think this will be a killer solution for VDI - or any situation where you have a large number of similar VMs.

hope this helps!

cheers,

Aitor

[MarcMoennikes]

Hello,

thanks for your reply. I will try with some vhd for VDI.
At the moment our VDI is not in production use, so i have time to test

Regards

[Anatoly (staff)]

Well, I will ask you to keep us updated if possible.

Thank you

[MarcMoennikes]

Hello,

next week we will start to test xendesktop and data deduplication.
Somebody has tested in the meantime? Maybe some best practices?
First plan was to use Hyper-V for the virutal desktops. But, i have seen something about intellicache with XENSERVER, maybe the best way is to use for the SAN deduplication and enbale intellicache on the xenserver.
At the moment we have also only 1 Gigbit Ethernet conncetions the the san.

Regards

[Anatoly (staff)]

All I can suggest you is those two links (I think it hsould be good start):
http://support.citrix.com/servlet/KbSer ... ctices.pdf
http://blogs.citrix.com/2012/03/21/best ... available/

[MarcMoennikes]

Hello,

some updates:
XENSERVER and intellicache only works with NFS storage. So not possible with starwind and deduplication.
OK, we have used hyper-v again. The performance with deduplication was slower compared with no deduplication device.
I have read, new version of starwind will improve the performance.

We have also tested windows 2012 hyper-v with starwind. There is a cache feature with clustered shared volumes (the memory from the 2012 server is used for read cache). A performace boost for read speed
So, we are waiting for 2012 server RTM and next starwind version. I think, this could be the best vdi environment. Save space with dedup and get the speed with cluster shared volume cache.

Regards

[anton (staff)]

1) Yes, there should be a lot of performance incrase points with upcoming version of dedupe. Starting with it will be based on out LSFS thing so 90-95% raw disk bandwidth for write would be available.

2) Microsoft CSV cache is cappy. It's write-thru so no writes are buffered. We use write-back now (distributed among different nodes so safe) and it's much more effective. Also we're replacing LRU with ARC-style cache (pretty much like the one used with ZFS but a bit better as we have extra dimension in it - blocks relation original ARC from ZFS is missing).

Hello,

some updates:
XENSERVER and intellicache only works with NFS storage. So not possible with starwind and deduplication.
OK, we have used hyper-v again. The performance with deduplication was slower compared with no deduplication device.
I have read, new version of starwind will improve the performance.

We have also tested windows 2012 hyper-v with starwind. There is a cache feature with clustered shared volumes (the memory from the 2012 server is used for read cache). A performace boost for read speed
So, we are waiting for 2012 server RTM and next starwind version. I think, this could be the best vdi environment. Save space with dedup and get the speed with cluster shared volume cache.

Regards

[MarcMoennikes]

Hello,

of course, csv cache is only read cache. But for VDI, boot stomrs at the morning, loading the os. Is read cache not a good solution?
And the cache is on the hypervisor. no bottleneck on the storagepaths.
For any other scenario, yes, i agree, csv cahe is not a solution...

regards

[anton (staff)]

Golden image and linked clones are a way to go. However there are too many ways to skin a cat.

Stick with Native SAN for Hyper-V and you'll have cache @ hypervisor side. Both read and write. Add here in-line dedupe.

Hello,

of course, csv cache is only read cache. But for VDI, boot stomrs at the morning, loading the os. Is read cache not a good solution?
And the cache is on the hypervisor. no bottleneck on the storagepaths.
For any other scenario, yes, i agree, csv cahe is not a solution...

regards