[ome-users] OMERO and NFS (was: NullPointerException in FileMaker)
callan at lifesci.dundee.ac.uk
Wed Sep 19 20:31:08 BST 2012
On 17 Sep 2012, at 14:15, Niko Ehrenfeuchter wrote:
> Hi all,
> On 07.08.2012 09:59, Chris Allan wrote:
>> Hi Harri,
>> On 6 Aug 2012, at 15:42, Harri Jäälinoja wrote:
>>> Hi all,
>>> I think I've solved this. Some googling points to NFS locking issues:
>>> This makes sense, because in our new environment, the big data drive is a NFS share.
>>> I did this:
>>> service nfslock start
>>> and after that, I haven't seen the errors anymore.
>> We'll certainly try and add that to the startup script tests in the future so that it's obvious when there is a complete lack of locking.
>>> Do you have any comments in general about having OMERO store data on NFS (speed for example)? We have also the PostgreSQL data directory there. In our case we got this 4T storage area for free from a national computing center, and I don't think we have much say about how we receive it, but it would be good to know if there are any possible issues.
>> Really that heavily depends on the performance of your NFS data store. One of the classical problems with NFS is locking semantics, and really this applies to any distributed or network filesystem. OMERO makes fairly heavy use of POSIX locking, especially on the Files and Index portions of the binary repository. You may wish to store your Index on local disk, it will be faster, less prone to corruption and should be small anyway. Storing your PostgreSQL data directory on NFS is probably a very bad idea unless you have a really good understanding of the semantics of the NFS data store you're using.
> I'd like to pick up this older thread again...
> We're currently planning a somewhat bigger OMERO installation for our imaging facility and the groups we're servicing. During the discussions with our IT department (they're going to provide the server space plus the storage), they mentioned that storage will be delivered as an NFS share - so I'm a bit worried now what decisions to take on which hardware to buy for the server running OMERO.
> My current idea is as follows:
> - rather more Gigahertz than cores, so kind of a quad-core CPU with 2.8 GHz preferred over a six-core 2.4
That's fine. The more flexibility you have though the better. You're not going to know what your OMERO work load is until people start using your installation.
> - keep I/O paths as separate as possible, e.g. one RAID1 for the OS and one for the database (the latter maybe even on SSD if that makes sense)
Almost every action OMERO takes is I/O limited. The more I/O, and the more spread out it is across more volumes the better your experience is going to be.
> - my personal preference for storage (speaking of the binary repository) would definitely be a dedicated storage network like iSCSI or FibreChannel (first of all for performance reasons and congestion fears on the regular network), but this currently seems to be unavailable
> ...hence my question about any concerns regarding NFS as the storage provider for the binary repository? Is locking a real issue on NFS or can this be thoroughly solved using the "nfslock" service as stated above?
Locking and latency are really the only things that can trip you up.
As long as you're prepared to monitor locking and take action if something goes wrong you should be fine on that front. Keeping the Lucene index (/OMERO/FullText), your OMERO install itself and potentially /OMERO/.omero off of NFS via symlinks is really the only other thing I can suggest to avoid locking issues.
Latency and throughput, well that's going to be down to the quality of the NFS volume being provided to you and the quality of the network between your server and the server providing the NFS volume.
> Don't worry, putting the Postgres on NFS has never been an option (and it never will ;)).
> Any help and thoughts are greatly appreciated!
More information about the ome-users