Sommaire
ToggleContexte de l’architecture :
L’entreprise 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 de l’entreprise :
L’entreprise souhaite :
- Organiser les données sous forme d’une arborescence unique.
- Répliquer les données sur plusieurs sites (PRA).
- 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.
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, nous vous invitons à lire cet article : http://msreport.free.fr/?p=281
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 DfsrPrivateConflictandDeleted folder. »
En cas de conflits, un des deux fichiers est déplacé dans le sous dossier DfsrPrivateConflictandDeleted 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.
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.
Nous vous préconisions l’utilisation de 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.
Nous vous invitons à 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 PanelAll Control Panel ItemsAdministrative Tools) et ajouter les compteurs : BanchCacheSMB : Bytes from cache et BanchCacheSMB : Bytes from server.
Conclusion :
Selon nous, 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.