Comment Miria distribue les Jobs aux Datamovers

Une configuration Miria typique utilise 1 serveur maître et 1 ou plusieurs datamovers (ou agents). 

Des Pools de 1 ou plusieurs datamovers peuvent être créés. 

Exclure le serveur maître des pools évite de le surcharger puisque un serveur est aussi un agent (datamover). 

Le serveur maître enregistre toutes les informations nécessaires pour garder la trace des fichiers migrés dans sa database mais est aussi l’orchestrateur des tâches de migration et de leur(s) job(s) respectif(s) .

Une tâche de migration copie des fichiers depuis le stockage source vers le stockage cible (de nombreux types de stockages sont supportés par Miria) 

Par défaut, 1 tâche de migration utilise 1 job qui, lui, utilise 1 processus (thread). 

Mais vous pouvez configurer la tâche pour utiliser plusieurs jobs. 

Et/ou vous pouvez configurer les jobs pour utiliser plusieurs processus (threads). 

Répartition des jobs 

Lancer la tâche de migration va démarrer un scannage des fichiers du stockage source et, peu après, démarrer le premier job de transfert des fichiers. 

Si configuré, un nouveau job sera démarré chaque fois qu’un des critères ci-dessous est atteint: 

• Taille totale des fichiers scannés 
• Durée du job de scannage 
• Nombre de fichiers scannés 

 Dès qu’un de ces critères est atteint, le serveur maître démarre un nouveau job qui est assigné au datamover qui a le moins de jobs en cours.  

La répartion des jobs dans Miria est donc basée sur le nombre de jobs en cours sur chaque datamover.

 Single thread or Multithread 

Par défaut, 1 job utilise un seul processus (thread) qui utilise 1 cœur (core) du processeur (CPU) et un peu de mémoire (RAM). 

Mais 1 job peut aussi utiliser plusieurs processus (multithread) auquel cas chaque processus utilise un cœur du CPU et de la mémoire. 

Le nombre de processus (thread) qu’un job peut utiliser est configuré par un paramètre de la tâche de migration. 

En se basant sur cette explications, vous pouvez maintenant comprendre en partie comment est construite une configuration Miria. 

Prenons un exemple:  

1. Imaginez une configuration avec 1 serveur Miria et 1 datamover (agent) Miria où seul l’agent, grâce à l’utilisation d’un pool, sera utilisé pour transférer les fichiers. 
2. Le datamover (agent) possède 1 CPU avec 8 cœurs et disons que nous avons suffisamment de mémoire pour cet exercice. 
3. Vous pouvez donc exécuter 8 jobs ayant chacun 1 processus (thread) ou 4 jobs ayant chacun 2 processus (threads) ou 2 jobs de 4 processus ou enfin 1 job de 8 processus.

Essayer de lancer plus de jobs ou plus de processus causera des problèmes de performance ! 

Si vous avez besoin de plus de jobs et/ou processus pour compléter la migration dans les temps impartis, vous pouvez ajouter plus de datamovers (agents) qui pourront les faire tourner

La performance de la migration sera aussi influencée par de nombreux autres paramètres comme les capacités de charge des stockages source et cible ainsi que par les capacités du réseau par exemple.

La première passe de la tâche de migration sera la plus longue car : 

1. le 1er job de scannage doit scanner l’entièreté du stockage source
2. cette tâche doit transférer tous les fichiers vers la destination

Si le stockage source reste en production pendant la migration, plusieurs passes seront nécessaires afin de transférer les fichiers modifiés depuis la passe précédente.

Les passes suivantes de la tâche de migration seront plus rapides puisqu’elles ne traiteront que les fichiers modifiés depuis la passe précédente. 

Miria supporte le FastScan sur plusieurs modèles de stockages source rendant les passes suivantes du scannage également plus rapides.
FastScan est basé sur les techniques de Snapdiff.