Multitple repositories within one OMERO server?

[rpoehlmann]

Hi all,

our OMERO server (5.0.5-ice35-b47 on CentOS 6.5) is using a remote volume on a NAS storage system mounted via NFS as image repository.

Is there a way to attach an additional 2nd repository to the same server? If yes, would there be an option to also define certain rules which repository is used when (e.g. for specific user/groups only)?

Background of this question is the fact that our current OMERO repository resides on a multi-purpose NAS storage system.
Now, we we've been approached by user that would like to deposit there images in OMERO as well but depend on subsequent image analysis on an HPC environment having a high-performance file-system underneath. If we could manage to directly target their files on this high-performance FS configured as 2nd repository an managed by OMERO, we could avoid copying of data between those different type of file-systems.
Of course, we would allow them only read-only access to the OMERO repo sitting on the HPFS area. But they could then directly read their image data from the OMERO repo even from cluster nodes by obtaining the corresponding path via Python API.

I've seen the "FS configuration options" at http://www.openmicroscopy.org/site/support/omero5/sysadmins/fs-upload-configuration.html.
The "omero.repo.dir (experimental) - value" points slightly in this direction, but I could not find additional details, examples, etc.

Would this be an option? Or am I completely wrong?

Any hint would be greatly appreciated.

Thanks a lot and best regards,
-Rainer

[mtbc]

omero.data.dir and omero.managed.dir apply to all groups and users. Rainer, your best chance at getting user- or group-specific behavior is to use the omero.fs.repo.path configuration option mentioned under "Template path". This determines the directory within the managed repository that is created for new imports.

The %user%, %userId%, %group%, %groupId% expansion terms allow that user's or group's imports to map to specific directories in your binary repository. You can then play tricks with operating system mounts underneath OMERO to map these to different filesystems or physical disks. After reading http://www.openmicroscopy.org/site/supp ... -repo-path also see the examples within our presentation from the latest OME users' meeting: from http://downloads.openmicroscopy.org/pre ... kshop/#/13 navigate using down arrow then right arrow and continue at least as far as the caveats slide! With luck, this should allow you to construct a setting for omero.fs.repo.path that you can associate with a specific mount within the OMERO binary repository. (Already, with default settings, images imported by a specific user will all be under their directory inside ManagedRepository/ so perhaps that can be made to suffice.)

An alternative solution that may be better for you could be to mount the high-performance filesystem elsewhere, but still visible by the OMERO server process, and to use the ln_s "soft-linking" option described on http://www.openmicroscopy.org/site/supp ... mport.html in importing the images into OMERO such that it does not duplicate the files' content in its binary repository. Before trying this out in production, read that page's warnings in the red boxes!

All this probably doesn't go all the way to conveniently solving your issue, but does it seem sufficient? If we need to improve the documentation, or if we ought to consider adding some extra features beyond this, please do mention; certainly we've not thought of all the ways an institution's systems may be reasonably set up.

Cheers,
Mark

[rpoehlmann]

Hi Mark,

thanks a lot for your detailed answer.

When looking at the documentation you described, I could imagine a setup as shown in the "template-group.png" example (see attachment). Since need for a high-performance filesystem is clearly associated with a group, a

Code: Select all

ManagedRepository/%groupid%/%user%_%userid%//&year%_%month%/%day%/%time%

type of setup could work where the high-performance filesystem will then be mounted at the corresponding "%group% entry points within the ManagedRepository.

However, since we already have 12TB of data and historically this type of granularity using a "%groupid%" component within the path was not needed, adding it now would shift the whole repository one level further down. If I understood the setup correctly, this would require to correct the paths stored in the database accordingly. And I assume, that's not an easy deal.

Would the "omero.repo.dir (experimental)" be an option? Is there any additional documentation how to configure a second node, or maybe use cases? Could this eventually run on the same machine?

Cheers,
-Rainer

[jmoore]

Hi Rainer,

However, since we already have 12TB of data and historically this type of granularity using a "%groupid%" component within the path was not needed, adding it now would shift the whole repository one level further down. If I understood the setup correctly, this would require to correct the paths stored in the database accordingly. And I assume, that's not an easy deal.

You wouldn't need to immediately migrate the existing data further down, assuming you had other disks you could mount at '%groupid%'. The previously imported data would continue to work since the template is an import-time property. That being said, you will of course eventually want to migrate that data to the other disks. At the moment, we only have a tool for migrating one dataset at a time. Scripting the entire move should be possible, but we haven't tested it sufficiently to suggest it for general use.

Would the "omero.repo.dir (experimental)" be an option? Is there any additional documentation how to configure a second node, or maybe use cases? Could this eventually run on the same machine?

The original design called for having multiple repositories. For that to be most useful, though, the entire software stack will be required to allow choosing which repository to import, too. At the moment, the choice of which repository would be random which is almost certainly not what you are looking for. Until that functionality comes out of the experimental stage, I'd suggest we find a template and migration path that works for you.

Cheers,
~Josh.

[rpoehlmann]

Thanks a lot for clarifying those topics!

Cheers,
-Rainer