Log in

No account? Create an account

Previous Entry | Next Entry

Virtualization HyperDrive

Finally got my new virtualization design working.  I love how Winblows doesn't know it's infamous C: drive is actually an NFS share mounted for it by a Linux brain (ESX) and serviced by an array of disks managed by a Solaris box.  It could go in the opposite direction but I don't trust Microsoft disk management.  Let Winblows be a slave to the system ;) 

This was actually the best solution with the parts available.  The design allows each guest a dedicated LUN, where the array itself handles caching; the Solaris box merely interprets the file handles via NFS and offers a management interface for creating and sharing new LUNs.  ESX still creates a virtual disk for the guest (with its crappy filesystem, VMDK) and presents this disk to the guest OS; I expect that will be the only bottleneck.  It's always the weakest link, and in this case NetApp's Triantos has admitted that bandwidth is less of an issue than IO latency, i.e. ESX generates lots of little read/writes versus big ones.

So far, it seems just as responsive as the previous setup: direct connect SATA.  That is saying volumes.  The parts available for the new setup range from circa 2000 - 2004. The SATA stuff was all new, and had far fewer hoops: virtual SCSI drive -> guest OS VMDK -->> VMDK formatted volume -> SATA controller -> SATA drive.  The diagram below doesn't do justice for increasing to .5TiB, because the new sequence is: virtual SCSI drive -> NFS client kernel (ESX) -> NFS server module (Solaris) -> guest OS VMDK -->> UFS formatted LUN -> array controllers -> SCSI drive.  

and SUPER geek!


( 2 comments — Leave a comment )
Aug. 6th, 2009 06:42 am (UTC)
What are you talking about? This doesn't even make sense and I don't think its in English. :p
Aug. 6th, 2009 06:56 am (UTC)
Re: Uhm
Shush! It's techno-babble ... not very different from hippy-speak.
( 2 comments — Leave a comment )