Optimiser le chargement réseau
Les cadres Jumbo sont des cadres Ethernet supérieurs aux 1 500 octets par défaut. Les tailles de cadres Jumbo classiques sont de 9 000 octets. L’augmentation de la taille de frame sur le serveur de base de donnée source, tous les périphériques réseau intermédiaires (comme les commutateurs), et les serveurs Intel R3load réduisent la consommation du processeur et augmentent le débit du réseau. La taille de frame doit être identique sur tous les appareils, sinon la conversion demande un grand nombre de ressources.
Des fonctionnalités réseau supplémentaires, comme le partage du trafic entrant (RSS), peuvent être activées ou configurées pour distribuer le traitement réseau entre plusieurs processeurs. L’exécution de serveurs R3load sur VMware a prouvé que le réglage du réseau pour les frames Jumbo et RSS est plus complexe et n’est pas recommandé, sauf si vous avez un haut niveau d’expertise.
R3load exporte des données à partir de tables SGBD et compresse ces données brutes indépendantes du format dans des fichiers de copie de sauvegarde. Ces fichiers de copie de sauvegarde doivent être chargés dans Azure et importés dans la base de données SQL Server cible.
Le niveau de performance de la copie et du chargement vers Azure de ces fichiers de copie de sauvegarde est un composant essentiel du processus de migration global.
Il existe deux approches de base pour le chargement de fichiers de copie de sauvegarde R3load :
Copier des serveurs d’exportation R3load locaux vers le stockage Blob Azure via Internet public avec AzCopy
Sur chacun des serveurs R3load, exécutez une copie de AzCopy à l’aide de la ligne de commande suivante :
Azcopy copy "C:\ExportServer_1\Dumpfiles" "https://[storage_account].blob.core.windows.net/ExportServer_1/Dumpfiles?[SAS_Token]" --recursive
Vous pouvez augmenter le débit en définissant la variable d'environnement VALUE_AZCOPY_CONCURRENCY. Cette variable spécifie le nombre de demandes pouvant être effectuées simultanément.
Si votre ordinateur a moins de 5 UC, la [valeur] de cette variable est définie sur 32. Sinon, la valeur par défaut est égale à 16 multiplié par le nombre d’unités centrales. La valeur par défaut maximale de cette variable est 300, mais vous pouvez la définir manuellement à une valeur supérieure ou inférieure :
| Système d’exploitation | Commande |
|---|---|
| Windows | set AZCOPY_CONCURRENCY_VALUE=[value] |
| Linux | export AZCOPY_CONCURRENCY_VALUE=[value] |
| macOS | export AZCOPY_CONCURRENCY_VALUE=[value] |
Utilisez azcopy env pour vérifier la valeur actuelle de la variable d’environnement AZCOPY_CONCURRENCY_VALUE. Si la valeur est vide, vous pouvez lire la valeur utilisée en examinant le début de tout fichier journal AzCopy. La valeur sélectionnée et la raison pour laquelle elle a été sélectionnée sont signalées ici.
Avant de définir la valeur de concurrence, exécutez un test d’évaluation. Le processus de test d’évaluation signale la valeur de concurrence recommandée. Sinon, si vos conditions réseau et charges utiles varient, vous pouvez également définir cette variable sur le mot AUTO plutôt que sur un nombre particulier. La valeur AUTO indique qu’AzCopy exécute toujours le même processus de réglage automatique que pendant les tests d’évaluation.
Si un client a un serveur puissant et un Internet rapide, la valeur de concurrence peut être augmentée. Si la valeur de concurrence est trop augmentée, la connexion au serveur d’exportation R3load est perdue en raison de la saturation du réseau. Analysez le débit du réseau dans le gestionnaire de tâches Windows. Le débit de copie de plus de 1 Gigabit par seconde par serveur d’exportation R3load peut être facilement effectué. Le débit de copie peut être augmenté en utilisant plus de serveurs R3load (4 sont représentés dans le diagramme précédent).
Un script similaire doit être exécuté sur les serveurs d’importation R3load dans Azure pour copier les fichiers du blob dans un système de fichiers auquel R3load peut accéder.
Copier des serveurs d’exportation R3load locaux vers une machine virtuelle ou un stockage blob Azure via une connexion ExpressRoute dédiée en utilisant AzCopy, Robocopy ou un outil similaire
Robocopy C:\Export1\Dump1 \\az_imp1\Dump1 /MIR /XF *.SGN /R:20 /V /S /Z /J /MT:8 /MON:1 /TEE /UNILOG+:C:\Export1\Robo1.Log
Le diagramme de blocs suivant illustre 4 serveurs Intel R3load exécutant R3load. En arrière-plan, Robocopy démarre le chargement des fichiers de copie de sauvegarde. Lorsque des tables et des packages fractionnés sont terminés, le fichier SGN est copié manuellement ou à l’aide d’un script. Quand le fichier SGN d’un package arrive sur le serveur d’importation R3load, cela déclenche automatiquement l’importation de ce package.
Remarque
La copie de fichiers via les protocoles NFS ou SMB Windows n’est pas aussi rapide et robuste que des mécanismes comme AzCopy. Il est recommandé de tester les performances des deux techniques de chargement de fichiers. Il est recommandé de notifier le Support Microsoft des projets de migration VLDB, car des opérations réseau haut débit peuvent être incorrectement identifiées comme attaques par déni de service.