Fonctionnement

Dans cette rubrique se trouve la description du fonctionnement du système. Il vous sera utile de connaître au moins le schéma général, ainsi que les notions de serveur tampon, de mésocentre de client, et des provenances (en réalité des étiquetages de point de transfert utilisés par Omero-Quay), dans les grandes lignes, pour savoir comment vos données seront transférées, et ne pas être perdu lors de l'utilisation. Les détails techniques s'adresseront principalement aux administrateurs.

Schéma global

architecture_drawio

On note la présence de 3 grandes régions:

  • La région "facility-quay" (+ VLAN), qui sera nommée "Tampon + iRODS local"
  • La régions "omero-server", qui sera nommée "Mésocentre (iRODS + OMERO.server)"
  • La région client, regroupant les clients du parc informatique local et une instance OMERO.web

Tampon + iRODS local

Le réseau LAN virtuel (VLAN) regroupe l'ensemble des machines (clients) du bâtiment de recherche, ainsi qu'un serveur tampon regroupant les données à importer. La connexion entre les clients et le tampon se fait via Samba.

On entend par tampon la machine servant d'intermédiaire entre la station de travail et le mésocentre. L'intérêt premier d'une telle configuration est de centraliser les différentes requêtes d'importation reçues dpuis son domaine d'influence. Les données seront ensuite accédées par le mésocentre. Ceci permet d'assurer une certaine continuité de service en évitant la saturation d'une connexion directe vers le mésocentre par le transfert d'une quantité massive de données et par un nombre massif de requêtes de téléchargement ou de consultations.

Mésocentre (iRODS + OMERO.server)

Il s'agit de l'endroit où sont stockées (théoriquement) les données d'imagerie.

Client

On entend par client tout ordinateur utilisé pour importer les images et leurs métadonnées. La station de travail associée à un microscope peut être utilisée pour cela. L'instance OMERO.web sera hébergée sur serveur local.

Quelques notions

Elément de provenance

Pour l'acheminement des données d'un point A à un point B, OMERO-quay a recours à des fichiers associés à chacun de ces points. Ces fichiers sont appelés des éléments de provenance. Ils sont au format JSON et comprennent les éléments suivants:

  • "id": Identifiant de l'élément
  • "name": Nom de l'élément
  • "host": Nom du serveur hôte
  • "stores": Liste des stores associés

Le reste des éléments ne sert à rien et est juste hérité de la classe mère. A régler.

Voici 2 exemples de fichiers:

  • docker.json
{
  "id": "docker",
  "name": "docker",
  "description": null,
  "creation_date": null,
  "quay_annotations": [],
  "ome_id": null,
  "irods_id": null,
  "delete": false,
  "states": [],
  "ror_ids": [],
  "host": "localhost",
  "urls": [],
  "stores": [
    {
      "id": "coop_demoResc",
      "name": null,
      "description": null,
      "creation_date": null,
      "quay_annotations": [],
      "ome_id": null,
      "irods_id": null,
      "delete": false,
      "states": [],
      "scheme": "irods",
      "host": "irods-icat",
      "resc": "demoResc",
      "data_roots": ["irods:///tempZone/home/", "file:///mnt/SHARE/"],
      "is_isa": true,
      "post_url": "http://localhost:8898"
    },
    {
      "id": "user_demoResc",
      "name": null,
      "description": null,
      "creation_date": null,
      "quay_annotations": [],
      "ome_id": null,
      "irods_id": null,
      "delete": false,
      "states": [],
      "scheme": "irods",
      "host": "irods-icat",
      "resc": "demoResc",
      "data_roots": [
        "irods:///tempZone/home/{{ manifest.manager }}",
        "file:///mnt/SHARE/{{ manifest.manager }}"
      ],
      "is_isa": false,
      "post_url": "http://localhost:8898"
    },
    {
      "id": "omero_remote",
      "name": null,
      "description": null,
      "creation_date": null,
      "quay_annotations": [],
      "ome_id": null,
      "irods_id": null,
      "delete": false,
      "states": [],
      "scheme": "omero",
      "host": "omero-server",
      "resc": null,
      "data_roots": ["file:///mnt/SHARE"],
      "is_isa": true,
      "post_url": "http://localhost:8898"
    }
  ]
}
  • facility.json

{
  "id": "facility",
  "name": "facility",
  "description": null,
  "creation_date": null,
  "quay_annotations": [],
  "ome_id": null,
  "irods_id": null,
  "delete": false,
  "states": [],
  "ror_ids": [],
  "host": "localhost",
  "urls": [],
  "stores": [
    {
      "id": "coop_facilityResc",
      "name": null,
      "description": null,
      "creation_date": null,
      "quay_annotations": [],
      "ome_id": null,
      "irods_id": null,
      "delete": false,
      "states": [],
      "scheme": "irods",
      "host": "irods-consumer",
      "resc": "facilityResc",
      "data_roots": [
        "irods:///tempZone/home/",
        "file:///mnt/SHARE/home/investigations"
      ],
      "is_isa": true,
      "post_url": "http://localhost:8898"
    },
    {
      "id": "user_facilityResc",
      "name": null,
      "description": null,
      "creation_date": null,
      "quay_annotations": [],
      "ome_id": null,
      "irods_id": null,
      "delete": false,
      "states": [],
      "scheme": "irods",
      "host": "irods-consumer",
      "resc": "facilityResc",
      "data_roots": [
        "irods:///tempZone/home/{{ manifest.manager }}",
        "file:///mnt/SHARE/home/{{ manifest.manager }}"
      ],
      "is_isa": false,
      "post_url": "http://localhost:8898"
    },
    {
      "id": "omero_facilty",
      "name": null,
      "description": null,
      "creation_date": null,
      "quay_annotations": [],
      "ome_id": null,
      "irods_id": null,
      "delete": false,
      "states": [],
      "scheme": "omero",
      "host": "omero-server",
      "resc": null,
      "data_roots": ["file:///mnt/SHARE/home"],
      "is_isa": true,
      "post_url": null
    }
  ]
}
Les indications sur les fichiers d'élément de provenance utilisés pour le point de départ et le point de destination seront renseignés dans le fichier Excel associé au jeu de données.

Store

Un "store" est un espace virtuel alloué par OMERO-quay, pour stocker des éléments. Il peut y en avoir plusieurs pour un élément de provenance. A un store correspondent plusieurs éléments importants:

  • "id": Identifiant du store
  • "scheme": Correspond au type de stockage (dans "data_roots") qui sera utilisé pour le fonctionnement du store: "irods" sera associé à un fonctionnement basé sur iRODS et nécessitera la présence d'une adresse iRODS dans "data_roots". "omero" sera associé à un fonctionnement standard basé sur Unix et nécessitera la présence d'une adresse "file://" dans "data_roots".
  • "host": Nom du serveur hôte
  • "data_roots": Liste comprenant les chemins locaux (sur l'espace virtuel) associés aux données. Voir "scheme".

Zone utilisateur et zone coopérative

Pour les régions "Tampon + iRODS local" et "Mésocentre (iRODS + OMERO.server)", on peut distinguer 2 zones: la zone personnelle et la zone coopérative.

Les zones personnelles (espaces virtuels) de l'utilisateur sont directement accessibles en écriture. Une fois importées, les données se retrouvent ici.

distinction_user_coop_zones

Les zones personnelles sont des zones où les données ne sont pas formatées au standard ISA, on considère qu'elles sont sous une forme "user-friendly", déposées selon les propres formalismes d'organisation de l'utilisateur.

La région "Tampon + iRODS local" comprend les stores suivants:

  • facilityUserFile: zone utilisateur correspondant au tampon où l'utilisateur dépose ses données via Samba
  • facilityUserResc (n'apparaît pas sur le schéma): zone correspondant aux données utilisateurs déposées sur facilityUserFile, mais formatées au format iRODS. Techniquement en zone utilisateur car les données ne sont pas réarrangées au standard ISA, mais l'utilisateur n'aura pas à toucher à cette zone.
  • facilityCoopFile: zone coopérative correspondant aux données utilisateurs réarrangées par omero-quay au standard ISA. L'utilisateur n'y touchera jamais directement.
  • facilityCoopResc: zone coopérative correspondant aux données utilisateurs réarrangées par omero-quay au standard ISA, mais formatées au format iRODS.
  • facilityOmero: cette zone à part correspond aux liens symboliques vers les données utilisateur créés par le système d'import "in-place" d'OMERO.

La région "Mésocentre (iRODS + OMERO.server)" comprend les stores suivants:

  • mesoUserResc: Cette zone correspond aux données utilisateur directement déposées sur le mésocentre via iRODS. Cette possibilité de dépôt qui contourne le système de tampon est offerte par l'utilisation d'un client iRODS (iBridges-GUI ou MetaNX, par exemple)
  • mesoCoopResc: Cette zone correspond aux données utilisateur directement déposées sur le mésocentre via iRODS, mais reformatées au standard ISA. L'utilisateur n'y touchera pas.
  • mesoOmero: cette zone à part correspond aux liens symboliques vers les données utilisateur créés par le système d'import "in-place" d'OMERO, côté mésocentre.

Les stores "facilityOmero" et "mesoOmero" seront accédés via OMERO.web.

Impact sur l'importation des données

2 routes sont actuellement prévues pour l'importation des données vers le mésocentre:

  • Transfert des données d'image sur tampon, puis importation vers mésocentre par le biais du fichier Excel et de OMERO Import UI
  • Transfert direct vers mésocentre à l'aide d'un client iRODS, puis synchronisation avec OMERO par le biais du fichier Excel et de OMERO Import UI