[one-users] NFS datastore performance during VM instantiation

[Ruben S. Montero]

Hi Matt,

NFS is not a valid solution for medium size deployments, specially when
there is contention on the network (deploying multiple VMs at the same
time, multiple VMs with heavy I/O concurrently). The solution could be
based on two basic alternatives (or a combination of both):

1.- Use a better NFS server (SAN) or a better distributed/shared FS
(gluster,  lustre...)

2.- Balance the NFS load by using different servers. Simple configure
several datastores mounting volumes from different NFS servers. You may
also want to tune the NFS mounting parameters caches, syncs,....

Hope it helps

Ruben

On Fri, Jun 15, 2012 at 12:43 PM, Matt Willsher <matt.willsher at boxuk.com>wrote:

>  Hi,****
>
> ** **
>
> I’m currently working on Open Nebula using NFS as a shared data store.
> I’ve found that during the large copy done during instantiation all other
> VMs on the same node suffer storage performance issues and are unable to
> write to disk. In some circumstances this produces warnings in the VM’s
> kernel due to time outs. I’ve been over the system configuration, tried
> different NFS options, sync, async, and others. Nfsiostat is showing avg
> exe times to be 40+ seconds during these large sequential writes.  There
> are no errors in either NFS or network stats and the NFS server is
> responsive when accessed from other clients. ****
>
> ** **
>
> My question is, has anyone else come across these sorts of performance
> issues  during VM instantiation when using NFS a shared datastore? ****
>
> ** **
>
> Thanks,****
>
> Matt ****
>
> ** **
>
> ****
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
>


-- 
Ruben S. Montero, PhD
Project co-Lead and Chief Architect
OpenNebula - The Open Source Solution for Data Center Virtualization
www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20120622/5c2dc3c1/attachment-0003.htm>