Utilisons-nous DFS «faux»?

Nous sommes une entreprise qui a des succursales dans tout le pays. Nous avons un minimum de 1 T1 par branche et un maximum de 2 T1. Nous avons un serveur DFS dans chaque succursale et à notre bureau principal. La semaine dernière, un partage particulièrement gênant qui contient 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 supprimer et le plus bas que j'ai géré est de 1 500 fichiers pour ce partage particulier.

Donc mes questions sont:

• Est-ce une erreur que nous ayons installé DFS sur un réseau étendu?
• Avons-nous simplement trop peu de bande passante pour le nombre de fichiers et le nombre de modifications que nous avons?
• Y a-t-il une configuration magique qui n'a pas été faite?

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 problèmes de bande passante?

Nous avons utilisé MRTG pour visualiser les graphiques d'utilisation de la bande passante, et des objets de stratégie de groupe basés sur le site pour contrôler la bande passante utilisée pour BITS sur DFSR. Nous avons paramétré les objets de stratégie de groupe pour qu’ils utilisent environ 700 Ko pendant la journée et maximisent le T-1 la nuit. Nous avons parfois eu des cas où les arriérés augmentaient et s'ils ne se vidaient jamais, nous savions que, grâce au serveur et à MRTG, la seule option était de leur fournir davantage de bande passante. DFSR est déjà compressé et au niveau des blocs, donc je ne sais pas si d'autres solutions tierces pour la réplication de données hors site le rendront meilleur (si vous pouvez en effet montrer que sa bande passante est limitée).

DFSR en 2008 ou 2008 R2 peut avoir d'autres optimisations. Par conséquent, recherchez cette option de mise à niveau également.

Vous semblez avoir répondu à votre propre question ici. Étant donné le grand nombre de modifications que vos utilisateurs apportent à ce partage, aucune modification de la configuration DFS ne résoudra ce problème. Votre backlog dépend de la bande passante et ne sera jamais effacé à 0 si vos utilisateurs apportent des modifications plus rapidement, la routine de synchronisation peut les synchroniser. Vous voudrez peut-être reconsidérer l'architecture d'utilisation de DFS dans cette configuration. Un système de groupe de travail collaboratif / gestion de documents semble pouvoir être mieux adapté ici que d'essayer de tout exécuter au niveau du système de fichiers.

Avec 2008, vous pouvez passer à l’utilisation de branchcache - elle ne réplique pas aveuglément tout ce qui a changé, mais conserve les fichiers qui ont été ouverts dans un cache qui se met à jour si la copie centrale se met à jour. Autant que je me souvienne, sous 2003, DFS fonctionnait comme un réplicateur de fichiers modifié. Vous modifiez 1 octet dans un fichier de 100 Mo et il recopie 100 Mo. En 2008, il ne copie que le 1 octet.

Je suis surpris que vous ne voyiez pas plus de problèmes. J'ai utilisé DFS comme ces années en arrière, mais j'ai commencé à avoir des problèmes pour reproduire environ 70 Go de fichiers. Après avoir enquêté, j'ai trouvé un document MS qui indiquait qu'il n'était pas pris en charge par la marque magique de 50 Go. Les problèmes incluaient la suppression de fichiers non répétés ... et cela sur un réseau local plutôt que sur un réseau local.

Linux a des systèmes de fichiers distribués et des outils de réplication de fichiers, mais ils subiront tous les mêmes problèmes si vous manquez de bande passante.

Une autre alternative consisterait à utiliser des accélérateurs cifs. Nous utilisons packeteer (qui fait maintenant partie de bluecoat) et il est possible pour les gens d’ouvrir et d’éditer des diagrammes CAO de 20 Mo sur un DSL ordinaire. Les temps d'ouverture et de sauvegarde sont raisonnables.