5 votes

Sommes-nous en train d'utiliser DFS de manière erronée ?

Nous sommes une entreprise qui possède des succursales dans tout le pays. Nous avons un minimum de 1 T1 pour chaque succursale et un maximum de 2 T1. Nous avons un serveur DFS dans chaque succursale et dans notre bureau principal. Au cours de la semaine écoulée, un partage particulièrement problématique contenant certains de nos fichiers utilisateur n'a jamais eu d'arriéré de 0 fichier. J'ai ajusté le calendrier de réplication pour essayer de le faire disparaître et le minimum que j'ai atteint est de 1500 fichiers pour ce partage particulier.

Mes questions sont donc les suivantes :

  • Est-il anormal que nous ayons installé DFS sur un réseau étendu ?
  • Avons-nous tout simplement trop peu de bande passante pour le nombre de fichiers et le nombre de modifications que nous effectuons ?
  • Existe-t-il une configuration magique qui n'a pas été réalisée ?

7voto

Jay Teal Points 183

Vous semblez avoir répondu à votre propre question. Étant donné le grand nombre de modifications que vos utilisateurs apportent à ce partage, aucune configuration DFS ne pourra résoudre le problème. Votre arriéré dépend de la bande passante et ne sera jamais ramené à 0 si vos utilisateurs effectuent des modifications plus rapidement que la routine de synchronisation ne peut le faire. Vous devriez peut-être reconsidérer l'architecture de l'utilisation de DFS dans cette configuration. Un système de gestion de documents/collaborative groupware semble mieux convenir ici que d'essayer de tout faire fonctionner au niveau du système de fichiers.

5voto

Peter Bagnall Points 738

J'ai pris en charge votre configuration exacte avec 70 sites WAN sur Windows Server 2003 R2, principalement avec des T-1. Cela a très bien fonctionné. DFSR était notre méthode de sauvegarde du serveur de fichiers WAN. Pouvez-vous utiliser MRTG pour surveiller la bande passante de votre routeur T-1 afin de vérifier les éventuels problèmes de bande passante ?

Nous avons utilisé MRTG pour voir les graphiques d'utilisation de la bande passante, et des GPO basées sur le site pour contrôler la bande passante utilisée pour les BITS sur DFSR. Nous avons paramétré les GPO pour qu'ils utilisent ~700kb pendant la journée et qu'ils exploitent au maximum le T-1 pendant la nuit. Parfois, les arriérés augmentaient et s'ils ne se vidaient jamais, nous savions, grâce à la surveillance des serveurs et de MRTG, que la seule option était de leur fournir plus de bande passante. DFSR est déjà compressé et au niveau des blocs, je ne sais pas si d'autres solutions tierces pour la réplication des données hors site l'amélioreront (si vous pouvez effectivement démontrer que la bande passante est limitée).

DFSR en 2008 ou 2008 R2 peut bénéficier d'optimisations supplémentaires, c'est pourquoi il convient de rechercher cette option de mise à niveau également.

1voto

Ian Murphy Points 1329

Avec 2008, vous pourriez passer à l'utilisation de branchcache, qui ne se contente pas de répliquer aveuglément tout ce qui a été modifié, mais conserve les fichiers qui ont été ouverts dans un cache qui se met à jour si la copie centrale est mise à jour. Si je me souviens bien, sous 2003, DFS fonctionne comme un réplicateur de fichiers modifiés. Vous changez 1 octet dans un fichier de 100mb et il recopie 100mb. Sous 2008, il ne copie qu'un octet.

Je suis surpris que vous ne rencontriez pas plus de problèmes. J'ai utilisé DFS de cette manière il y a quelques années mais j'ai commencé à rencontrer des problèmes pour répliquer environ 70gb de fichiers. Après avoir enquêté, j'ai trouvé un document de MS qui indiquait qu'il n'était pas pris en charge au-delà de la barre magique des 50 gigaoctets. Les problèmes comprenaient la suppression des fichiers non répliqués... et cela sur un réseau local plutôt que sur un réseau étendu.

Linux dispose de quelques systèmes de fichiers distribués et d'outils de réplication de fichiers, mais ils connaissent tous les mêmes problèmes en cas de manque de bande passante.

Une autre solution consisterait à utiliser les accélérateurs de cifs. Nous utilisons packeteer (qui fait maintenant partie de bluecoat) et il est possible d'ouvrir et d'éditer des diagrammes CAO de 20 mégaoctets par le biais d'une simple ligne d'abonné numérique. Les temps d'ouverture et de sauvegarde sont raisonnables.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X