Using PVS for XenApp? You Should be Caching to RAM!

I’ve been going through a lot of design options for PVS and storage lately in my day job.  There’s so many great options now from Nutanix, Simplivity, and the like that administrators have available that it makes me wonder if the traditional NAS or SAN will ever regain their foothold in the world of a streamed server OS.  But with all the options that come down the pipe none of them can match the sheer cost effectiveness for caching in a XenApp environment than using RAM.  It has it drawbacks, but pound for pound it’s just plain awesome.

Using a RAM cache isn’t a new idea.  Lots of technologies employ a RAM cache.  Heck, years ago I had a SCSI device that created a RAM drive out of a bunch of DIMs.  You had to connect a battery to it to avoid data loss when you powered down but man was it fast when I played Quake.  Ah, the good old days!  These days RAM is vastly more available and dirt cheap in comparison.  And when you look at XenApp sizing in a PVS environment it is the first and last word in write caching.  And if you are in a silo’d management environment you never have to talk to your storage guys again.

The architecture of a RAM-cached system is fairly simple.  The 16GB DIMMs are the sweet spot from a price/density perspective.  On an HP BL460 you can get 256GB and on Cisco UCS 384 in an equivalent.  Combine that with 10 or 12 core processors in the newer Intel lines and turn on Hyperthreading.  We get 13 guests per blade on a 10 core UCS using a 3 vCPU/29GB RAM for each box.  In PVS under the write-cache settings we set the RAM cache size to 15GB which is more than enough for a week’s worth of cache and we reboot every weekend.  If you are going to go longer you need to adjust your cache size accordingly but it usually will work out just fine.  If you use AppV and deploy large apps, that might eat into your RAM too much.  Instead look at running 10 guests with 4vCPU/38GB RAM per box with 22GB devoted to write-cache.  If 22GB doesn’t do it for you then you might need to reassess your design :).  Using that much RAM does require you to be running Enterprise or Datacenter for your Windows server license however.

So what’s the downside of RAM caching?  Well for starters your DRS (or whatever) is done for.  You can’t have any migration from host to host because you have no common storage.  And because you have no storage you also can’t use the PVS wizard to create the VMs.  The best way to solve it is to create your template and then script the VM creation.  In ESX we have a script that essentially spins up new VMs from the template to fully populate blade by blade.  The template is generally on spinning disk local to each blade.  If you BDM boot with an ISO you will also need to make that available individually on every local storage volume and modify the ISO settings on each machine to point at their local ISO.  And of course with no DRS when you need to do blade maintenance you have to have the overall provisioned environment large enough.  So we use a 16 node cluster and leave 1 blade always unpopulated but provisioned with the shell VMs.  That way we can spin them up as a replacement when we need to do blade maintenance.

Is it worth all the headache?  Heck yes.  We cut 35-40% off our per seat cost using the RAM cache model as opposed to our older NFS design with NetApp.  It takes careful planning to make the RAM cache solution work but it’s just so darn cheap.  And from a performance standpoint, it is incredibly fast.  In the end those two things make for a great PVS environment all around.

, ,

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">