Présentation du service de migration de stockage
Le Service de migration du stockage facilite la migration du stockage vers Windows Server ou vers Azure. Il fournit un outil graphique qui inventorie les données sur les serveurs CIFS Windows, Linux et NetApp, puis transfère les données vers des serveurs plus récents ou vers des machines virtuelles Azure. Le service de migration de stockage offre également la possibilité de transférer l’identité d’un serveur vers le serveur de destination afin que les applications et les utilisateurs puissent accéder à leurs données sans modifier les liens ou les chemins d’accès.
Cet article décrit les aspects suivants du service de migration de stockage :
- Raisons d’utiliser le service de migration de stockage.
- Fonctionnement du processus de migration.
- Exigences pour les serveurs source et de destination.
- Nouveautés du service de migration de stockage.
Pourquoi utiliser le service de migration de stockage ?
Utilisez le service de migration de stockage parce que vous disposez d’un ou plusieurs serveurs que vous voulez migrer vers du matériel plus récent ou vers des machines virtuelles. Le service de migration de stockage est conçu pour vous aider à effectuer les tâches suivantes :
- Inventorier plusieurs serveurs et leurs données
- Transférer rapidement des fichiers, des partages de fichiers et la configuration de sécurité à partir des serveurs sources
- Éventuellement, prendre l’identité des serveurs sources (on parle aussi de basculement) afin que les utilisateurs et les applications n’aient rien à changer pour accéder aux données existantes.
- Gérer une ou plusieurs migrations depuis l’interface utilisateur de Windows Admin Center
Fonctionnement du processus de migration
La migration est un processus en trois étapes :
Inventorier les serveurs pour collecter des informations sur leurs fichiers et leur configuration, montrés dans la figure suivante.
Transférer (copier) les données depuis les serveurs sources vers les serveurs de destination.
Basculer vers les nouveaux serveurs (facultatif).
Les serveurs de destination prennent les anciennes identités des serveurs sources, de sorte que les applications et les utilisateurs n’aient pas à modifier quoi que ce soit.
Les serveurs sources entrent dans un état de maintenance où ils contiennent les mêmes fichiers qu’auparavant (nous ne supprimons jamais des fichiers des serveurs sources), mais où ces fichiers ne sont pas disponibles pour les utilisateurs et les applications. Vous pouvez par la suite désactiver les serveurs à votre convenance.
La vidéo suivante montre comment utiliser le service de migration de stockage pour prendre un serveur, comme un serveur Windows Server 2008 R2 qui ne fait l’objet d’un support, et déplacer le stockage vers un serveur plus récent.
Configuration requise
Pour utiliser le service de migration de stockage, vous avez besoin des éléments suivants :
- Un serveur source ou un cluster de basculement à partir duquel migrer les fichiers et les données.
- Un serveur de destination exécutant Windows Server 2019 ou version ultérieure (en cluster ou autonome) vers lequel effectuer la migration. Bien que Windows Server 2016 soit également pris en charge, il peut être plus difficile de migrer vers et son support prendra fin en janvier 2027.
- Serveur d’orchestrateur exécutant Windows Server 2019 ou version ultérieure pour gérer la migration. Si vous migrez un seul serveur, vous pouvez utiliser la destination comme orchestrateur. Si vous migrez plusieurs serveurs, utilisez un serveur d’orchestrateur distinct.
- Un PC ou un serveur exécutant Windows Admin Center dans sa version la plus récente pour exécuter l’interface utilisateur du service de migration de stockage ainsi que l’outil (extension) Service de migration de stockage le plus récent disponible à partir du flux.
Nous recommandons fortement d’avoir des ordinateurs orchestrateur et de destination avec au moins deux cœurs ou deux processeurs virtuels, et au moins 2 Go de mémoire. Les opérations d’inventaire et de transfert sont beaucoup plus rapides avec plus de processeurs et de mémoire.
Exigences de sécurité, service proxy du service de migration de stockage et ports de pare-feu
Un compte de migration qui est administrateur sur les ordinateurs sources et sur l’ordinateur orchestrateur. Ce compte peut être un compte de domaine ou local, sauf dans le cas d’un ordinateur qui n’est pas joint au domaine, auquel cas il doit s’agir d’un utilisateur local.
Un compte de migration qui est administrateur sur les ordinateurs de destination et sur l’ordinateur orchestrateur. Ce compte peut être un compte de domaine ou local, sauf dans le cas d’un ordinateur qui n’est pas joint au domaine, auquel cas il doit s’agir d’un utilisateur local.
La règle de pare-feu Partage de fichiers et d’imprimantes (SMB-In) doit être activée en entrée sur l’ordinateur orchestrateur.
Les règles de pare-feu suivantes doivent être activées en entrée sur les ordinateurs sources et de destination (vous les avez peut-être déjà activées) :
- Partage de fichiers et d’imprimantes (SMB-Entrée)
- Service Netlogon (NP-In)
- Windows Management Instrumentation (DCOM-In)
- Windows Management Instrumentation (WMI-In)
Conseil
L’installation du service proxy du service de migration de stockage sur un ordinateur de destination ouvre automatiquement les ports de pare-feu nécessaires sur cet ordinateur. Pour ce faire, connectez-vous au serveur de destination dans Windows Admin Center, puis accédez à Gestionnaire de serveur (dans Windows Admin Center) >Rôles et fonctionnalités, sélectionnez Proxy du service de migration de stockage, puis choisissez Installer.
Si les ordinateurs appartiennent à un domaine Active Directory Domain Services, ils doivent tous appartenir à la même forêt. Le serveur de destination doit également se trouver dans le même domaine que le serveur source si vous voulez transférer le nom de domaine de la source vers la destination lors du basculement. Bien que le basculement fonctionne sur plusieurs domaines, le nom de domaine complet de la destination est différent de la source et l’utilisation de deux domaines différents entraîne probablement des problèmes DNS.
Exigences pour les serveurs sources
Le serveur source doit exécuter un des systèmes d’exploitation suivants :
- Windows Server, canal semi-annuel
- Windows Server 2025
- Windows Server 2022
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
- Windows Server 2008
- Windows Server 2003 R2
- Windows Server 2003
- Windows Small Business Server 2003 R2
- Windows Small Business Server 2008
- Windows Small Business Server 2011
- Windows Server 2012 Essentials
- Windows Server 2012 R2 Essentials
- Windows Server 2016 Essentials
- Windows Server 2019 Essentials
- Windows Storage Server 2008
- Windows Storage Server 2008 R2
- Windows Storage Server 2012
- Windows Storage Server 2012 R2
- Windows Storage Server 2016
Notes
Windows Small Business Server et Windows Server Essentials sont des contrôleurs de domaine. Storage Migration Service ne peut pas basculer des contrôleurs de domaine, mais il peut inventorier et transférer des fichiers à partir d’eux.
Vous pouvez migrer les autres types de sources suivants si l’orchestrateur exécute Windows Server 2019 avec KB5001384 installé ou Windows Server 2022 :
- Clusters de basculement exécutant Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 ou Windows Server 2008 R2. Windows Server 2008 R2 prend en charge seulement l’inventaire et le transfert, mais pas le basculement.
- Serveurs Linux qui utilisent Samba. Nous avons testé les distributions suivantes :
- CentOS 7
- Debian GNU/Linux 8
- RedHat Enterprise Linux 7.6
- SUSE Linux Enterprise Server (SLES) 11 SP4
- Ubuntu 16.04 LTS et 12.04.5 LTS
- Samba 4.8, 4.7, 4.3, 4.2 et 3.6
- Groupes NetApp FAS hébergeant un serveur CIFS NetApp, exécutant NetApp ONTAP 9.
Exigences pour les serveurs de destination
Le serveur de destination doit exécuter l’un des systèmes d’exploitation suivants :
- Windows Server, canal semi-annuel
- Windows Server 2025
- Windows Server 2022
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
Les serveurs de destination peuvent être des serveurs autonomes ou un cluster de basculement Windows. N’oubliez pas que les clusters eux-mêmes ne sont pas migrés, uniquement les ressources de cluster du serveur de fichiers. Ils ne peuvent pas exécuter Azure Stack HCI ou utiliser un module complémentaire de clustering non-Microsoft. Bien que le service de migration de stockage ne prenne pas en charge Azure Files comme destination, il prend entièrement en charge les serveurs exécutant l’agent Azure File Sync avec la hiérarchisation cloud.
Conseil
Les serveurs de destination exécutant Windows Server 2019 ou version ultérieure ont deux fois les performances de transfert des versions antérieures de Windows Server. Cette amélioration des performances est due à l’inclusion d’un service proxy de service de migration de stockage intégré.
Migration de machines virtuelles Azure
Windows Admin Center intègre le déploiement Azure IaaS dans le service de migration de stockage. Il vous permet de ne pas devoir créer manuellement des serveurs et des machines virtuelles dans le portail Azure avant de déployer votre charge de travail. Il vous permet aussi de ne oublier des étapes et des configurations requises. Windows Admin Center peut déployer la machine virtuelle Azure IaaS, configurer son stockage, la joindre à votre domaine, installer des rôles, puis configurer votre système distribué.
La vidéo suivante montre comment utiliser le service de migration de stockage pour migrer vers des machines virtuelles Azure.
Si vous voulez effectuer une opération lift-and-shift de machines virtuelles vers Azure sans migrer vers un système d’exploitation ultérieur, envisagez d’utiliser Azure Migrate. Pour plus d’informations, consultez Azure Migrate.