Le blog technique

Contexte

Lors de l’utilisation d’un partage réseau, les utilisateurs on souvent l’habitude de travailler directement sur les fichiers partagés.

Afin d’éviter toute corruption des données, un système de verrouillage est utilisé, il garantie que seul un unique utilisateur n’édite le fichier. Ce système fonctionne avec les fichiers temporaire/propriétaire.

Voici les étapes d’ouverture et d’enregistrement pour un fichier Word :

1. A l’ouverture du fichier, Word crée un fichier temporaire où les modifications seront enregistrés. Si un autre utilisateur tente de modifier le fichier, le message d’erreur suivant lui apparait :

Ce fichier est déjà ouvert par <nom_utilisateur>. Souhaitez-vous en faire une copie ?

2.  Lors de l’enregistrement du fichier, Word supprime la version d’origine, et la remplace par le fichier temporaire qu’il a renommé comme le fichier d’origine.

Ainsi, plusieurs utilisateurs auront accès au même fichier sans que celui-ci ne soit corrompu.

Contraintes en mode répliqué

Dans le cas d’un partage de fichiers répliqué, l’intégrité des fichiers n’est plus assurée.

Prenons le scénario suivant :

Dans ce cas de figure les utilisateurs sont redirigés depuis le namespace vers l’un des deux serveurs de données. En fonction de l’ordre “Refferal Ordering” qui par défaut dirige les clients entre les deux serveurs de manière égale.

Or si un utilisateur modifie le fichier work.docx sur le serveur FILE01, le serveur FILE02 n’en seras pas avisé (la fonction de verrouillage de fichier étant locale) et un autre utilisateur seras en mesure de modifier le même fichier causant une perte d’intégrité où le dernier fichier enregistré sera celui gardé par les deux serveurs.

Afin d’éviter ce type de comportement dangereux, il est possible de modifier le fonctionnement des deux serveurs, tout en gardant un minimum de répartition de charge.

Contournement

Imaginons que les serveurs FILE01 et FILE02 hébergent chacun deux fichiers répliqués indépendamment, Commerce et Administratif.

La première chose à faire est de forcer les clients à n’accéder qu’à un seul des deux serveurs, le serveur secondaire seras utilisé dans le cas où le premier venait à ne plus fonctionner.

Pour ce faire il faut dans la partie “Folder Targets” du namespace Commerce choisir le dossier hébergé par le serveur secondaire (FILE02), ouvrir la fenêtre des propriété puis choisir l’onglet “Advanced” et affecter à ce dossier la priorité “Last among all targets” :

Ainsi les utilisateurs souhaitant accéder au partage Commerce, seront toujours dirigé vers FILE01 en priorité.

On peut également aller plus loin et interdire la modification des fichiers sur l’un des serveurs le rendant membre “Read-Only”. La réplication ne fonctionneras alors que dans un sens et le serveur Read-Only, comme son nom l’indique ne pourras qu’afficher les fichiers hébergé en lecture seule.

Pour appliquer le Read-Only sur le serveur secondaire, choisir dans la partie “Replication” le lien de réplication, et dans l’onglet “Membership” sélectionner le serveur membre secondaire comme ceci :

Conclusion

A l’aide de ce contournement les utilisateurs Administratif utiliserons un serveurs tandis que les utilisateurs Commerciaux en utiliseront un autre.

Les deux serveurs sont malgré tout répliqués donc en cas de défaillance de l’un, l’autre pourras prendre le relais, cependant, il ne faut pas oublier – en cas de défaillance du serveur principal – de retirer l’option “Read-Only” si celle-ci a été mise en place.