Réplication DFS et panne de disque dur - besoin d'aide

Windows Server & IT Pro Windows Server 2022 & antérieur
1

Nous envisageons actuellement de mettre en place la réplication DFS pour un PC Windows Server 2019 Standard dans notre environnement. Nos postes clients utilisent ce serveur pour se connecter à toutes nos applications. (Veuillez consulter les ‘Notes’ plus loin dans ce message pour savoir pourquoi nous n’optons pas pour Storage Replica et restons avec DFS-R)

Nous avons besoin d’aide pour savoir si la réplication DFS pourrait satisfaire les critères suivants :

A) En cas de panne du disque dur de données de notre serveur principal (appelons-le PC-1) due au disque dur (HDD), comme un disque non détecté, une corruption de disque, etc., nous aimerions mettre en pause/arrêter la réplication DFS, et retirer physiquement le HDD du serveur secondaire (disons PC-2) afin de remplacer le HDD existant dans le premier serveur (PC-1) pour se connecter aux applications en conservant les permissions de fichiers NTFS. Est-ce faisable avec une configuration DFS-R ?

B) En cas de panne du serveur principal (PC-1) pour des raisons autres que le HDD, comme un OS qui ne démarre plus, etc., nous aimerions retirer le HDD de données de ce serveur principal et le connecter au serveur secondaire (PC-2), renommer ce secondaire en PC-1 et commencer à l’utiliser pour se connecter aux applications en conservant les permissions de fichiers NTFS.

Veuillez nous indiquer si la réplication DFS conviendrait pour les exigences ci-dessus. Nous acceptons environ 10-15 minutes d’indisponibilité pour toutes les tâches associées telles que le changement de nom du PC, les entrées DNS, etc., tant que (A) ou (B) ou les deux fonctionnent. S’il existe une meilleure méthode, n’hésitez pas à nous en informer.

Notes :

Storage Replica ne convient pas à notre cas d’utilisation sous Windows Server 2019 Standard, en raison de la limitation d’un seul partenariat de réplication (c’est-à-dire un volume) avec une taille maximale de 2 To. Nous avons plusieurs volumes sur le serveur, et la mise à niveau vers Datacenter est coûteuse pour nous.

Nous comprenons que la réplication DFS prendrait en charge la partie ‘basculement’ car le cluster DFS basculerait la réplication vers PC-1 ou PC-2 en cas de panne, mais nous devrions donner au cluster virtuel un nom totalement différent, comme PC-3 (corrigez-moi si je me trompe ?). Cela ne serait pas possible pour nous, donc nous aimerions conserver la connectivité des applications vers “PC-1” comme serveur et non via un autre nom. La raison d’opter pour la réplication plutôt qu’une ‘sauvegarde et restauration manuelle’ est de réduire le temps d’indisponibilité opérationnel.

Pour nous, les données fichier sont plus importantes que le lecteur OS ou les données OS. Le serveur secondaire dans notre cas aurait le même OS, processeur, mémoire que le primaire et nous envisageons DFS-R pour la récupération du système de fichiers.

Le serveur et nos postes clients sont tous hébergés sur site. Nous n’avons pas de VM Azure ni de PC cloud impliqués. (P.S : Nous sommes conscients des limitations de la réplication DFS, telles que les limitations de réplication des fichiers verrouillés, l’impossibilité de répliquer les copies VSS, les permissions de fichiers ‘partagées’ car cela fonctionne au niveau fichier et non au niveau volume, etc.)

Nous faisons des recherches depuis un moment maintenant et avons fait une comparaison élaborée avec Storage Replica, et par DFS, il semble que la logique de base pour la réplication de fichiers repose sur les ‘Espaces de noms DFS’, qui permettent de router les requêtes de fichiers vers l’un ou plusieurs serveurs du cluster de réplication, quand le serveur principal est en panne. Nous avons consulté plusieurs vidéos YouTube, blogs techniques et documents Microsoft mais n’avons pas trouvé de réponses à nos exigences.

Merci.

2

D’après ce que vous décrivez, ce n’est pas vraiment un problème de réplication, c’est un problème de haute disponibilité (HA). DFS-R n’est tout simplement pas conçu pour le niveau de cohérence dont vous avez besoin. Si votre plan est de retirer un disque du serveur de destination et de le brancher dans la source comme remplacement, vous avez besoin d’une synchronisation bloc à bloc 1:1 réelle. DFS-R ne peut pas faire cela car il opère deux niveaux au-dessus, au niveau du système de fichiers. Et c’est avant de rencontrer tous les problèmes habituels de DFS-R, qui sont :

Pas de basculement véritablement transparent. Votre application pourrait ou non le détecter.

Pas de réplication des fichiers ouverts. Microsoft avait une version interne qui le pouvait, mais elle n’a jamais été commercialisée ; les outils tiers comme PeerLock sont depuis longtemps abandonnés.

Une surcharge d’E/S importante car DFS-R doit relire les données avant de les envoyer, réduisant essentiellement vos IOPS de moitié.

La cerise sur le gâteau : une utilisation extrêmement inefficace du réseau.

Si vous voulez quelque chose de fiable, je vous recommanderais de repenser l’approche :

Windows Storage Replica si vous pouvez allouer un budget. Storage Spaces Direct si votre latence réseau est suffisamment bonne (Notez qu’il n’y a toujours pas de support officiel pour les clusters étendus avec une latence élevée, même en 2025, près de 10 ans après la disponibilité générale de S2D, ce qui est dommage !). Ou un outil de réplication bloc tiers comme StarWind Virtual SAN, qui fait exactement ce que vous voulez. Il existe une version gratuite, en PowerShell uniquement, sans limitation de capacité. StarWind vient d’être acquis par DataCore, donc on ne sait pas combien de temps cette édition durera, mais cela vaut le coup d’oeil. Et si vous parvenez à avoir un gros budget, DataCore SANsymphony est une autre option viable. Comme StarWind, il peut se placer au-dessus de votre RAID matériel existant, donc en théorie vous pourriez toujours échanger les disques entre serveurs et rester cohérent.