Facteurs de performances et meilleures pratiques pour les migrations hybrides
Il existe de nombreux chemins pour migrer des données d’une organisation de messagerie locale vers Microsoft 365 ou Office 365. Lors de la planification de la migration, une question courante concerne la façon d’améliorer les performances de la migration des données et d’optimiser la vitesse de migration. Cet article traite des performances de migration pour les déploiements hybrides Exchange. Pour plus d’informations sur les performances des autres méthodes de migration, consultez Performances et bonnes pratiques de migration microsoft 365 et Office 365.
La migration de déploiement hybride prend en charge la migration fluide entre les serveurs Exchange locaux et les Exchange Online dans Microsoft 365 ou Office 365.
La migration de déploiement hybride est de loin la méthode de migration la plus rapide pour migrer des données de boîte aux lettres vers Microsoft 365 ou Office 365. Nous avons observé jusqu’à 100 Go/heure de débit pendant les déploiements de clients réels. Le tableau suivant fournit une liste de facteurs qui s’appliquent aux scénarios de migration hybride microsoft 365 et Office 365 natifs.
Si votre environnement local contient plusieurs sites se trouvant dans différents emplacements géographiques, vous pouvez améliorer les performances de migration en créant des points de terminaison de migration physiquement proches. En effet, dans un tel scénario, le processus de migration utilise le réseau Microsoft plutôt qu’un point de terminaison de migration centralisé qui a recours à votre réseau local.
Facteur 1 : Source de données (Exchange Server)
| Liste de vérification | Description | Meilleures pratiques |
|---|---|---|
| Performances du système | L'extraction des données est une tâche intensive. Le système source doit disposer de ressources suffisantes (temps processeur et mémoire) afin de fournir de meilleures performances de migration. Au moment de la migration, le système source est généralement proche de sa pleine capacité pour servir la charge de travail normale de l’utilisateur final. Une charge de travail de migration supplémentaire peut même réduire l’accès des utilisateurs finaux en raison d’un manque de ressources système. | Surveillez les performances système lors du test de migration pilote. Si le système est occupé, nous déconseillons l'utilisation d'une planification de migration agressive pour le système en question, car elle pourrait entraîner des problèmes de disponibilité du service et de lenteur de migration. Dans la mesure du possible, améliorez les performances du système source en ajoutant des ressources matérielles et en réduisant la charge sur le système en déplaçant des tâches et des utilisateurs vers d'autres serveurs qui ne sont pas concernés par la migration. Pour plus d'informations, consultez les rubriques suivantes : Demandez à l'expert de performances : Redimensionnement des déploiements Exchange 2016 Exchange Server intégrité et performances Présentation des performances d'Exchange 2010. Lors de la migration à partir d'une organisation Exchange sur site comportant plusieurs serveurs de boîtes aux lettres et plusieurs bases de données, nous vous conseillons de créer une liste d'utilisateurs de migration distribuée de manière égale parmi les différents serveurs de boîtes aux lettres et bases de données. En fonction des performances de chaque serveur, cette liste peut être affinée en vue d'optimiser le débit. Par exemple, si le serveur A présente une disponibilité des ressources supérieure de 50 pour cent à celle du serveur B, il est raisonnable de compter 50 pour cent d'utilisateurs du serveur A en plus dans le même lot de migration. Des pratiques similaires peuvent être appliquées à d'autres systèmes sources. Effectuez les migrations lorsque les serveurs disposent d'une disponibilité des ressources maximale, par exemple en dehors des heures de travail ou lors des week-ends ou jours fériés. |
| Tâches principales | D'autres tâches principales s'exécutent au moment de la migration. Étant donné qu'il est préférable d'effectuer la migration en dehors des heures de travail, les migrations peuvent entrer en conflit avec d'autres tâches de maintenance exécutées sur vos serveurs locaux, telles que les sauvegardes de données. | Examinez les autres tâches système susceptibles de s'exécuter durant la migration. Nous vous recommandons d'effectuer la migration des données lorsqu'aucune autre tâche nécessitant de nombreuses ressources ne s'exécute. Remarque : Pour les clients qui utilisent Microsoft Exchange local, les tâches principales courantes sont les solutions de sauvegarde et la maintenance du magasin Exchange . |
Facteur 2 : le serveur de migration
La migration du déploiement hybride est une migration par extraction et envoi de données initiée par le cloud, et un serveur hybride Exchange agit comme serveur de migration. Cet aspect ne reçoit généralement pas l'attention qu'il mérite, et les clients utilisent un ordinateur virtuel peu puissant comme serveur hybride. Cela entraîne des performances de migration médiocres.
Meilleures pratiques relatives au serveur de migration
En plus de l'application des meilleures pratiques décrites précédemment, nous avons testé les meilleures pratiques suivantes, lesquelles ont permis d'améliorer les performances de migration lors de migrations réelles chez des clients :
- Utilisez de puissants ordinateurs physiques de classe serveur au lieu d'ordinateurs virtuels pour les serveurs hybrides Exchange.
- Utilisez plusieurs serveurs hybrides placés derrière le mécanisme d'équilibrage de la charge réseau du client.
Par exemple, lors de migrations réelles chez des clients, nous avons obtenu un débit régulier de 30 Go/heure avec la configuration suivante :
- Réseau : canal sortant de 500 Mo vers Internet ; réseau interne sur 1 Go avec une dorsale fibre de 10 Go.
- Matériel : les spécifications des deux serveurs d’accès client/HUB (physique) sont les suivantes :
- UC: Processeur Intel® Xeon® E5520 @ 2,27 GHz 2,26 GHz (deux processeurs).
- RAM: 24 Go.
- Disques : huit, 146 Go par disque. Configuration RAID 5 = 960 Go d'espace total brut.
- MRSProxy : configuré avec une concurrence de 100.
Facteur 3 : le moteur de migration
La migration de déploiement hybride utilise microsoft 365 et des outils Office 365 natifs. Il est soumis à la limitation du service de migration Microsoft 365 et Office 365.
Exchange 2003 et versions ultérieures d’Exchange
Il existe une différence clé dans l’expérience de l’utilisateur final lors de la migration à partir d’Exchange 2003. À la différence des dernières versions d'Exchange, les utilisateurs finals d'Exchange 2003 ne sont pas en mesure d'accéder à leurs boîtes aux lettres lors de la migration de leurs données. Par conséquent, les clients d'Exchange 2003 se soucient généralement davantage du moment où les migrations sont planifiées et de la durée nécessaire aux migrations, en particulier quand les performances de migration sont faibles en raison de la lenteur du réseau ou de la taille importante des boîtes aux lettres.
La migration d'Exchange 2003 est également très sensible aux interruptions. Par exemple, dans une migration de client réel, pendant la migration d’une boîte aux lettres de 10 Go, un incident de service s’est produit lorsque la migration de la boîte aux lettres était terminée à 50 %. Le serveur d'accès au client Office 365, qui traitait la migration des données, a dû être redémarré pour résoudre le problème. Dans ce cas, la migration de cette boîte aux lettres a dû être redémarrée, ce qui a obligé le client à migrer à nouveau les 10 Go de données. La migration n'a pas pu être reprise à partir du point où elle avait été interrompue. Exchange 2010 et les versions ultérieures d'Exchange, toutefois, peuvent reprendre les migrations après des interruptions.
Bonnes pratiques relatives au moteur de migration
Certains clients choisissent d'effectuer des migrations à deux sauts pour les boîtes aux lettres Exchange 2003 sensibles et de taille importante :
- Premier tronçon : Migrez les boîtes aux lettres d’Exchange 2003 vers un serveur Exchange 2010 ou version ultérieure, qui est généralement le serveur hybride. Le premier saut est un déplacement hors connexion, mais il s'agit en général d'une migration très rapide sur un réseau local.
- Deuxième tronçon : Migrer des boîtes aux lettres d’Exchange 2010 ou version ultérieure vers Microsoft 365 ou Office 365.
Le second saut est un déplacement en ligne, ce qui procure une meilleure expérience utilisateur et davantage de tolérance de panne. Cette approche en deux sauts requiert une licence Exchange pour la boîte aux lettres utilisateur sur site temporaire.
Proxy du service de réplication de boîtes aux lettres (MRSProxy)
Le proxy MRS est la fonctionnalité de migration locale qui fonctionne avec le service de réplication de boîtes aux lettres s’exécutant côté Microsoft 365 et Office 365. Pour plus d'informations, consultez la rubrique Présentation des demandes de déplacement.
Meilleures pratiques MRSProxy
Il est possible de configurer la quantité maximale de connexions MRSProxy pour le serveur hybride Exchange local. Exécutez la commande Windows PowerShell suivante.
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSMaxConnections <number between 0 and unlimited; default is 100>
Remarque
Pour la plupart des migrations de clients, il est inutile de modifier la valeur de MRSMaxConnections par défaut. Si vous devez protéger le serveur source contre la surcharge de migration, vous pouvez réduire le nombre de connexions. Ce paramètre s'applique pour chaque serveur MRSProxy. Si un client a deux serveurs MRSProxy, chacun défini pour 10 connexions, il obtiendra 20 (2x10) comme quantité totale de connexions de MRSProxy. Pour plus d'informations sur la configuration du service MRSProxy dans votre organisation Exchange 2010 sur site, consultez la rubrique Démarrer le service MRSProxy sur un serveur d'accès client distant.
Facteur 4 : le réseau
Tests de vérification
Pour les clients exécutant Exchange 2010 ou une version ultérieure, les tests de performances réseau pour les migrations hybrides peuvent être réalisés en effectuant plusieurs migrations de boîtes aux lettres tests. En guise d'alternative, vous pouvez migrer des boîtes aux lettres utilisateur réelles avec l'option -SuspendWhenReadyToComplete pour obtenir une indication des performances de migration. Une fois les tests terminés, supprimez la demande de déplacement afin d'éviter toute incidence sur les utilisateurs finals.
Pour plus d'informations sur les demandes de déplacement, consultez la rubrique New-MoveRequest.
Facteur 5 : le service Office 365
Microsoft 365 et Office 365 limitation basée sur l’intégrité des ressources affecte les migrations à l’aide des migrations de déploiement hybride microsoft 365 ou Office 365. Pour plus d’informations, consultez la section Facteur 3 : Moteur de migration ci-dessus.