Club des Utilisateurs Atempo > Miria > Miria : Comment Faire ? > Comment Miria distribue les Jobs aux Datamovers
Comment Miria distribue les Jobs aux Datamovers
Articles / Posts
- Tina 4.8 GA est disponible
- Lina 6.1 GA est disponible
- PowerShell pour Lina 6.0
- Advisory ID : LINA/ADE-2023-0002
- Advisory ID : LINA/ADE-2023-0001
- Time Navigator 4.6.9 Hyper-V Software Alert
- Tina 4.7.1 GA est disponible
- L’installation de Miria tombe en erreur sur un serveur Linux sans X11
- La réplication HSS nécessite une attention particulière lors de la mise à niveau vers 5.x
- Agents LINA 5.3.4
Archives
- juillet 2023
- avril 2023
- mars 2023
- février 2023
- janvier 2023
- décembre 2022
- octobre 2022
- septembre 2022
- juillet 2022
- décembre 2021
- novembre 2021
- octobre 2021
- septembre 2021
- juillet 2021
- mai 2021
- avril 2021
- mars 2021
- février 2021
- janvier 2021
- novembre 2020
- octobre 2020
- septembre 2020
- août 2020
- juillet 2020
- juin 2020
- mai 2020
- mars 2020
- février 2020
- janvier 2020
- décembre 2019
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:
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:
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 :
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.