Objectifs de mise à l’échelle et de performances d’Azure Storage Mover
Les performances d’un service de migration de stockage constituent un aspect essentiel de toute migration. Dans cet article, nous partageons les résultats des tests de performances, même si Stockage Azure Mover est un nouveau service, votre expérience peut varier.
Objectifs de mise à l’échelle
Azure Storage Mover est testé avec 100 millions d’éléments d’espace de noms (fichiers et dossiers), migrés entre une source prise en charge et une cible prise en charge dans Azure.
Notre méthode de test
Azure Storage Mover est un service cloud hybride. Les services hybrides comportent un composant de service cloud et un composant d’infrastructure que l’administrateur du service exécute dans son environnement d’entreprise. Pour Storage Mover, ce composant hybride est un agent de migration. Les agents sont des machines virtuelles, exécutées sur un hôte près du stockage source.
Seul l’agent est une partie pertinente du service pour les tests de performances. Pour omettre les problèmes de confidentialité et de performances, les données transitent directement de l’agent Storage Mover vers le stockage cible dans Azure. Seuls les messages de contrôle et de télémétrie sont envoyés au service cloud.
Bases de référence des performances
Ces résultats de test sont créés dans des conditions idéales. Ils sont conçus comme une base de référence des composants que le service et l’agent Storage Mover peuvent directement influencer. Les différences entre les appareils sources, les disques et les connexions réseau ne sont pas prises en compte dans ce test. Les performances réelles varient.
La migration à partir de S Mo montage vers des tests de partage de fichiers Azure a été exécutée comme suit :
Le tableau suivant décrit les caractéristiques des environnements de test qui ont produit les résultats des tests de performances à partir d’un montage S Mo sur un partage de fichiers Azure.
Test non. | Nombre des fichiers | Poids total des fichiers | Taille du fichier | Structure du dossier |
---|---|---|---|---|
1 | 12 millions | 12 Go | 1 Ko chacun | 12 dossiers, chacun avec 100 sous-dossiers contenant 10 000 fichiers |
2 | 30 | 20 Go | 1 dossier | |
3 | 1 million | 100 Go | 100 Ko chacun | 1 000 dossiers, chacun avec 1 000 fichiers |
4 | 1 | 4 To | ||
5 | 117 millions | 117 Go | 1 Ko chacun | 117 dossiers, chacun avec 100 sous-dossiers contenant 10 000 fichiers |
6 | 1 | 1 To | ||
7 | 3,3 millions | 45 Go | 13 Ko chacun | 200 000 dossiers, chacun contient 16\17 fichiers |
8 | 50 millions | 1 To | 20 Ko chacun | 2 940 000 dossiers, chacun contient 17 fichiers |
9 | 100 millions | 2 To | 20 Ko chacun | 5 880 000 dossiers, chacun contient 17 fichiers |
Différentes configurations de ressources de l’agent sont testées sur les points de terminaison S Mo :
Minspec : 4 processeurs / 8 Go DE RAM 4 cœurs de processeur virtuel à 2,7 GHz chacun et 8 Gio de mémoire (RAM) est la spécification minimale d’un agent mover Stockage Azure.
Test non. Délai d’exécution Temps d’analyse 6 16 min, 42 secondes 1,2 s 7 55 min, 4 secondes 1 min, 17 secondes 8 9 Spécification de démarrage : 8 cœurs processeur /16 Gio RAM 8 virtuels à 2,7 GHz chacun et 16 Gio de mémoire (RAM) est la spécification minimale d’un agent mover Stockage Azure.
Résultats : compte de stockage standard
Test non. Délai d’exécution Temps d’analyse 1 15 h, 59 min 2 heures, 36 min, 34 secondes 2 1 min, 54 secondes 3,34 s 3 1 h, 19 min, 27 secondes 57,62 secondes 4 1 h, 5 min, 57 secondes 2,89 s Résultats : compte de stockage standard avec fichiers volumineux activés
Test non. Délai d’exécution Temps d’analyse 1 3 heures, 51 min, 31 secondes 41 min et 45 secondes 5 25 h, 47 min 23 h, 35 min 6 11 min, 11 secondes 0,7 s 7 55 min, 10 secondes 1 min, 3 secondes 8 9 Résultats : compte de stockage Premium
Test non. Délai d’exécution Temps d’analyse 1 2 h, 35 min, 14 secondes 24 min, 46 secondes 5 23 h, 34 min 21 h, 34 min
Passez en revue les ressources d’agent recommandées pour votre étendue de migration dans l’article sur le déploiement de l’agent.
Pourquoi les performances de migration varient
Fondamentalement, la qualité du réseau et la capacité de traiter les fichiers, les dossiers et leurs métadonnées ont une incidence sur la vitesse de migration.
Dans les deux domaines principaux que sont le réseau et l’informatique, plusieurs aspects ont un impact :
- Scénario de migration
La copie dans une cible vide est plus rapide que celle d’une cible avec du contenu. Ce comportement est dû au moteur de migration qui évalue non seulement la source, mais également la cible pour prendre des décisions de copie. - Nombre d’éléments d’espace de noms
La migration de 1 Gio de petits fichiers prend plus de temps que la migration de 1 Gio de fichiers plus volumineux. - Forme de l’espace de noms
Une hiérarchie de dossiers étendue se prête à un traitement plus parallèle qu’une structure de répertoires étroite ou profonde. Le rapport entre les fichiers et les dossiers est également important. - Évolution de l’espace de noms
Nombre de fichiers, dossiers et métadonnées modifiés entre deux exécutions de copie de la même source vers la même cible. - Réseau
- Bande passante et latence entre l’agent source et l’agent de migration
- Bande passante et latence entre l’agent de migration et la cible dans Azure
- Ressources de l’agent de migration
La quantité de mémoire (RAM), le nombre de cœurs de calcul et même la capacité du disque local disponible sur l’agent de migration peuvent avoir un impact considérable sur la vitesse de migration. Un plus grand nombre de ressources de calcul permet d’optimiser l’utilisation de la bande passante disponible, en particulier lorsque de grandes quantités de petits fichiers doivent être traitées lors d’une migration.
Par exemple, une migration traditionnelle nécessite une stratégie pour minimiser les temps d’arrêt de la charge de travail qui dépend du stockage à migrer. Azure Storage Mover prend en charge une telle stratégie. Elle est appelée migration convergente avec n-passages.
Dans cette stratégie, vous copiez des données entre la source et la cible plusieurs fois. Pendant ces itérations de copie, la source reste disponible en lecture et en écriture pour la charge de travail. Juste avant l’itération finale de la copie, vous mettez la source hors ligne. On s’attend à ce que la copie finale soit terminée plus rapidement que, disons, la première copie produite et qu’elle prenne à peu près autant de temps que celle qui la précède immédiatement. Après la copie finale, la charge de travail est basculée pour utiliser le nouveau stockage cible dans Azure et elle est à nouveau disponible.
Lors de la première copie de la source vers la cible, la cible est probablement vide et tout le contenu de la source doit être acheminée vers la cible. Par conséquent, la première copie est probablement la plus limitée par les ressources réseau disponibles.
Vers la fin d’une migration, lorsque vous avez déjà copié plusieurs fois la source vers la cible, seuls quelques fichiers, dossiers et métadonnées ont changé depuis la dernière copie. Dans cette dernière itération de copie, la comparaison de chaque fichier dans la source et la cible pour vérifier s’il doit être mis à jour, nécessite plus de ressources de calcul et moins de ressources réseau. À ce stade avancé de la migration, les copies sont souvent soumises à des contraintes de calcul. Une ressource appropriée de l’agent mover Stockage devient de plus en plus importante.
Étapes suivantes
Les articles suivants peuvent vous aider à réussir un déploiement d’Azure Storage Mover.