Salut à tous
Architecture actuelle du client :
Le client dispose d’un site principal (200 utilisateurs / stations de travail) et d’une agence (30 utilisateurs / stations de travail).
La bande passante entre les deux sites est faible et doit être économisée au maximum.
Les besoins du client :
Le client souhaite :
1. Organiser les données sous forme d’une arborescence unique.
2. Répliquer les données sur plusieurs sites (PRA).
3. Limiter l’impact sur la liaison WAN entre les deux sites quand les utilisateurs de l’agence ouvre / modifie un fichier sur les serveurs de fichiers.
La problématique des accès concurrents en modification (un utilisateur du siège et un utilisateur de l’agence modifient en même temps le même fichier) doit être prise en compte.
1. Solution préconisée pour la mise en place d’une arborescence unique :La meilleure solution est de mettre en place un espace de noms DFS. Si vous souhaitez en savoir plus, je vous invite à lire cet article : http://msreport.free.fr/?p=281
2. Solutions préconisées pour répliquer les données sur plusieurs sites (PRA) :
Plusieurs solutions sont possibles :
Solution 2A : utilisation du système de réplication DFS-R :
Cette solution nécessite de disposer de serveur de fichiers Windows 2003 R2 au minimum (espace de noms DFS en mode Windows 2000). Le moteur de réplication DFS permet de définir des plages horaires pour la réplication et limiter les débits. Quand deux réplicas existent pour le même partage, les utilisateurs sont redirigés vers un réplica en fonction de leur site Active Directory de rattachement. Si la topologie de site / sous réseaux IP Active Directory est bien configurée, l’utilisateur va se connecter sur un réplica accessible à travers un réseau rapide (le plus rapide possible en tout cas).
La principale contrainte de cette solution est qu’elle ne gère pas la problématique des accès concurrents en modification (un utilisateur du siège et un utilisateur de l’agence modifient en même temps le même fichier). Le Technet Microsoft est très claire sur le sujet :
« Do not use DFS Replication in an environment where multiple users update or modify the same files simultaneously on different servers. Doing so can cause DFS Replication to move conflicting copies of the files to the hidden DfsrPrivate\ConflictandDeleted folder. »
En cas de conflits, un des deux fichiers est déplacé dans le sous dossier DfsrPrivate\ConflictandDeleted folder à la racine de chaque cible DFS. Ce répertoire n’est visible que par les administrateurs et a une taille limite (à modifier !!!). Il y a donc un risque de perte de données.
Si vous souhaitez uniquement répliquer les fichiers dans le cadre d’un PRA, configurer l’espace de noms DFS pour forcer tous les utilisateurs à se connecter sur le même réplica !
Windows 2012 inclue de nombreuses nouveautés au niveau du DFS mais rien par rapport à la problématique des accès concurrents en modification au même fichier depuis 2 réplicas DFS.
Pour plus d’informations :
http://blogs.technet.com/b/filecab/archive/2012/11/12/dfs-replication-improvements-in-windows-server-2012.aspx
http://blogs.technet.com/b/askds/archive/2010/01/05/understanding-dfsr-conflict-algorithms-and-doing-something-about-conflicts.aspx
http://blogs.technet.com/b/askds/archive/2009/02/20/understanding-the-lack-of-distributed-file-locking-in-dfsr.aspx
Solution 2B : utilisation du système de réplication DFS-R et du plugin PeerLock :
Même principe que la solution précédente mais la gestion des conflits en modification est gérée par le module PeerLock (1500 € par serveur de fichiers). Cette solution est fonctionnelle (validation sur maquette) mais présente les problématiques suivantes :
– Quand on ouvre le fichier sur le site A, le fichier n’est accessible qu’en lecture sur le site B. Cependant cela bloque la réplication DFS. Quand on ferme l’application, le fichier doit encore répliqué. Si un utilisateur ouvre le fichier avant que ce dernier réplique, il peut y avoir un conflit !
– Pour que cela fonctionne, les applications doivent disposer d’un système de lock ce qui n’est pas le cas de toutes les applications. NOTEPAD permet par exemple d’ouvrir un fichier TXT plusieurs fois en modifications.
– Cette solution gère un maximum de 3 serveurs de fichiers en mode réplication multi-maître (faible montée en charge).
Procédure de mise en place de PEARLOCK :
http://www.peersoftware.com/support/knowledgebase/item/what-are-the-recommended-peerlock-options-to-work-with-dfs-replication.html
http://www.peersoftware.com/support/knowledgebase
Solution 2C : Utilisation de la solution PeerLink :
Cette solution est plus complète / fonctionnelle que la solution DFS-R / PeerLock et corrige les principaux défault de la solution DFS-R / PeerLock.
http://www.peersoftware.com/products/file-collaboration/peerlink.html
La principale problématique semble l’absence d’un support en Français.
3. Solutions pour limiter l’impact sur la liaison WAN entre les deux sites quand les utilisateurs de l’agence ouvre / modifie un fichier sur les serveurs de fichiers :
Si votre besoin est d’économiser la bande passante et non pas de répliquer les données, les solutions suivantes sont possible :
– Utilisation de DFS / DFS-R / PeerLock
– Utilisation de PeerLink
– Utilisation de BranchCache.
Je vous préconise clairement la solution BranchCache.
Présentation de la solution BranchCache :
Cette solution nécessite des serveurs Windows 2008 R2 et des stations de travail sous Windows 7 Enterprise / Ultimate (cela ne marche pas avec Windows 7 Professionnel).
Que retenir de cette solution :
Le mécanisme de cache n’est utilisé que pour les accès en lecture aux données. En cas de modification, l’utilisateur se connecte au serveur.
BranchCache supporte le protocole BITS, SMB et HTTP.
Je vous invite à lire les documents suivants pour la mise en place de la solution :
http://technet.microsoft.com/fr-fr/library/dd996641(v=ws.10).aspx
http://technet.microsoft.com/fr-fr/library/dd996634(v=ws.10).aspx
http://www.labo-microsoft.org/articles/SCCM_BranchCache/0/?action=print
http://www.microsoft.com/en-us/download/details.aspx?id=19558
http://windowsitpro.com/windows/q-how-can-i-test-if-branchcache-working
http://social.technet.microsoft.com/Forums/windowsserver/en-US/9f6de382-f317-45fe-8932-dac8ed904872/branchcache-cache-is-not-used-by-clients
Penser à configurer la latence sur 0 si vous êtes en environnement de tests.
Pour voir les paramètres BranchCache sur une machine : netsh branchcache show status all
Pour purger le cache BranchCache : netsh branchcache flush
Pour vérifier que la solution BranchCache fonctionne (pour les accès SMB) en mode Distribué :
– Il faut au moins 2 machines Windows 7 Enterprise. Une qui accède au fichier la première fois et la seconde qui accède au fichier via le cache.
– Démarrer le Performance Monitor (Control Panel\All Control Panel Items\Administrative Tools) et ajouter les compteurs : BanchCache\SMB : Bytes from cache et BanchCache\SMB : Bytes from server.
Conclusion :
Pour moi, la meilleure solution est :
– De configurer un ou plusieurs espaces de noms DFS.
– Utiliser le moteur DFS-R pour répliquer les données entre le siège et l’agence mais en configurant l’espace de noms pour que tous les clients se connectent au même serveur DFS. Les utilisateurs de l’agence se connecteront donc au serveur sur le site centrale.
– Utiliser BranchCache pour permettre de réduire le besoin en bande passante au niveau de l’agence.
A+
Guillaume MATHIEU
Consultant PROSERVIA
La connaissance s’accroît quand on la partage.
Très bon article sur les différentes possibilités. J’ai personnellement mis en oeuvre DFS+DFS-R à de nombreuses reprises pour ateindre les objectifs suivants :
– Très bon niveau de service du à l’usage des données locale (lien DFS actif seulement local). Nota : la liaison WAN est réservée pour les applications métier qui fonctionnent en central ainsi que, pour une faible partie, pour les réplications DFSR
– Sauvegarde centralisé au Datacenter des réplica DFSR. Pas d’infra de backup dispersé ou via des liaisons WAN (c’était avant l’émergence de la déduplication à la source). De nos jours, ça pourrait se discuter en fonction des infra de backup existantes, des bandes passantes disponibles, …
– Possibilité de reprise d’activité en cas de désastre du serveur local par switch des DFS Target Folder links vers les liens en central. Ce ne peut être que de la repsie d’activité, en aucun cas de la continuité de service, car rappelons qu’un seul lien est actif à un instant donné (DFS et sa foutue limitation concernant le locks des fichiers dans les réplicas, grr…).
Peerlock a été utilisé en production durant un certain temps chez un gros client avant de revenir à la solution décrite ci-avant pour cause de coût.
Peerlink, j’ai découvert dans cet article.
Branchcache : Je reste peu convaincu de l’utilité réelle dans cette situation. Toute modification d’un fichier requiert de travailler sur la source d’origine (en central donc) et non sur le BranchCache. Très certainement plus gourmand en bande passante WAN que la solution server de fichier local, publication DFS + réplication DRF-R.
Un bon tour d’horizon … et les liens en référence sont très appréciés.