Bonsoir,

Je fais face à une difficulté avec deux serveurs sous Windows Server 2008 R2 Standard qui font pointer un volume disque sur la même ressource SAN et pour cela j'aurais bien besoin de vos lumières...

Voici toute l'histoire depuis le début :

Chacun des serveurs héberge une instance de la même application (basée sur JBoss 4.02/J2EE 1.4) sur son volume RAID 1 local.
L'application est de ce fait redondée avec en amont un répartiteur de charge/failover réseau, mais elle n'est pas consciente de cette architecture.

Avec l'évolution de l'application un problème est apparu concernant le choix de cette architecture.
Désormais, l'application doit présenter des fichiers. Et ces fichiers doivent donc être joignables depuis le serveur n°1 ou le serveur n° 2 (le « ou » n'est pas exclusif, mais le contrat de service autorise une tolérance à l'écrasement du même fichier par plusieurs utilisateurs simultanés).

Voici les solutions que j'ai déjà tenté pour que les 2 serveurs profitent d'un espace unifié de stockage :

1) Monter un lecteur réseau vers un partage de fichiers (SMB v1) d'un serveur physique (Windows Server 2003) : Fonctionnel mais ce modèle ne garanti aucune tolérance de panne au niveau serveur, donc rejeté.

2) Monter un lecteur réseau vers un partage de fichiers (SMB v1) d'un cluster MSCS (Windows Server 2003) : L'application n'arrive pas à joindre le système de fichiers sous le mappage du lecteur réseau (et pourtant c'est le même serveur que dans le test ci-dessus mais via le nom d'instance du cluster).

3) Configurer un partage de fichiers (SMB v1) directement (sans monter de lecteur réseau) dans l'application : L'application n'arrive pas à joindre le système de fichiers.

4) Configurer un volume local dans l'application : Fonctionnel, mais n'offre pas le fonctionnement désiré. En attendant de trouver mieux ça reste la solution de dépannage avec un script (redondé sur chaque serveur) de Robocopy de la différence de fichiers entre les deux instances de l'application.

5) Configurer l'application pour utiliser un espace de fichiers sur DFS ou NFS : L'accès aux partages de fichiers via NFS ou DFS pose des problèmes politico-administratifs au sein de l'entreprise. Dommage car cela aurait été une solution élégante au problème.

6) Configurer l'application pour utiliser un volume hébergé sur une LUN SAN partagée entre les 2 serveurs (sur chacun des serveurs il y a une carte SAN et on y a présenté la même LUN de SAN) : C'est fonctionnel, les fichiers y sont visibles, on peut créer et modifier des deux côtés. Le problème c'est qu'à chaque changement sur les fichiers (ajout, suppression, modification) sur un serveur, l'autre bécane ne voit pas le changement tant qu'elle ne redémarre pas ou ne démonte-remonte pas la LUN et c'est normal car les journaux USN ne sont pas synchronisés (comme c'est le cas en cluster MSCS par exemple). J'ai cherché du côté de la commande FSUTIL, sur les forums et Technet mais je n'ai rien trouvé qui répond à mon problème. Voici un schéma (désolé si c'est moche car pas d'éditeur de schéma @ home) :

Pour 2 serveurs non membres d'un cluster, y-a-t 'il un moyen de synchroniser les journaux USN sur les propriétés physiques des fichiers ?
Si, oui comment ?

Merci d'avance.

Euh sur Windows, jamais tu dois avoir un volume d'un SAN monté sur 2 serveurs hors MSCS (et encore en MSCS le système n'est monté que sur un serveur sauf CSV).
 
C'est quoi le but de vouloir faire ce genre de redondance ? Parce que autant faire un serveur virtuel qui bouge d'host en host (tu palies pas le reboot de la vm etc. mais déjà tu as de la haute dispo)

J'ai bien conscience que c'est clairement pas une solution supportée par Microsoft, mais ont fait avec les contraintes que nous imposent le client et les admin/« experts » de leur domaine respectif (DFS, SAN, ESX, LAN...)
Si toutefois on a une possibilité de synchroniser (même si c'est via un script) les journaux USN ça serait top ?!

En fait, le but recherché par le client c'est bien la haute disponibilité et aussi les performances.
Et malheureusement, l'infrastructure virtuelle dans l'entreprise pose les mêmes problèmes à 2 balles que pour le DFS...
On est également obligé de passer à des bécanes surpuissantes (une seule ne suffit pas) pour 3 fois rien car les développeurs ne maîtrisent pas le produit et ne nous laissent pas l'optimiser.

Non, c'est pas supporté et à mon avis c'est source de corruption du volume NTFS J'éviterai perso.
 
Tu peux regarder les scaleout file server de windows server 2012 qui pourrait répondre à ton besoin (mais SMB v3 obligé donc les serveurs applicatifs aussi).
 
C'est quoi le problème du DFS ? Quelle partie en particulier du DFS pose problème ?

Pour le DFS la partie qui pose problème c'est l'administrateur du domaine : si j'ai pas xx k€/an à lui lâcher il ne m'autorise pas l'accès...
Et il n'aime pas trop mon application car j'ai plus d'un million de fichiers à déposer sur le DFS et selon lui ça pourrait engendrer de sévères pertes de performances pour moi ainsi que les autres membres de l'espace noms.

Idem pour l'achat de licences Microsoft qui ne sont pas au standard du SI de l'entreprise. Je peux oublier. Et même si je payais cette licence avec mon salaire on ne m'autoriserait pas à l'installer dans le domaine.

On a un client qui a de gros problèmes organisationnels et structurels, mais il faut faire avec le temps qu'il fasse le ménage dans ses équipes.

[EDIT]
N'empêche j'ai hésité à faire installer ces deux serveurs en cluster, mais il aurait fallut que je prenne des licences Enterprise comme surcoût à encaisser pour le client.
Car avec un peu de chance JBOSS digère mieux SMB (version 2.1 pour Windows Server 2008 R2) sur instance cluster d'un nœud sur lequel il installé, plutôt que sur un cluster Windows Server 2003 distant où SMB y est encapsulé en version originelle.

Pour faire du DFS tu es pas obligé de le pointer sur le domaine.
 
Mais vu tes problèmes j'irai bien voir du côté de linux qui pourra surement t'aider

Il te manque un élément dans ton système : te faut un failover de l'autre côté (un petit serveur qui envoie un partage NFS vers 1 serveur et garde l'autre en failover) qui lui ira stocker le tout sur ton SAN
 
 
                 ----serveur 1----
Cluster NLB |                       |storage process --- SAN
                 ----serveur 2----
 
Ton "SP" jouera le rôle de failover

Pour les règles de mon SI, si malheureusement. On ne nous autorise pas à faire du DFS décentralisé. Idem pour les NFS, FTP et SFTP qui nous sont prohibés pour les applications sur serveurs Windows.

C'est comme pour les licences hors contrats standards. On doit faire avec ce qu'on nous donne.

Ça n’apparaît pas dans mon schéma car on ne gère pas le stockage centralisé. Il s'agit d'une équipe admins/« experts » qui ne font que ça et qui proposent des solutions totalement redondées, clusters ou HPC aware.
Le problème c'est que je ne peux pas dire à cette équipe de passer la présentation de la LUN SAN en mode cluster car mes deux serveurs applicatifs doivent fonctionner en simultané pour suffire à la charge que demandent les utilisateurs.

[EDIT]
J'ai consulté quelques documentations intéressantes sur : http://forum.hardware.fr/hfr/syste [...] tm#t108802
Ces doc', notamment MS-FSRM, MS-SMB2 et MS-SWN m'ont permis d'explorer d'autres possibilités et de confirmer que FSUTIL sera insuffisant pour synchroniser des journaux USN.

Donc, la synchronisation des changements dans les journaux USN se font au commit de la transaction. S'il y a plusieurs machines sur un même volume le plus simple c'est d'utiliser le mode cluster MSCS pour synchroniser les journaux. Sinon, il faut développer une surcouche synchronisante développée sur des méthodes FSRM et qui vient s'intercaler entre le système de fichiers et l'application. Ca s'appelle réinventer la poudre et génèrerait beaucoup trop de boulot pour le besoin d'origine.

Je vais tenter une approche différente avec JBOSS sans trop retoucher à l'architecture en place :

1) J'essaye de voir avec les dev' si l'application gère les BLOB SQL. Ca serait pratique, même si je doute que les performances ne seront pas trop au rendez-vous.

2) J'essayerais de faire pointer l'application vers un partage de fichiers (SMB v2.1) hébergé sur un cluster Windows Server 2008 R2 distant.

3) L'application doit recevoir une mise à jour majeure qui va upgradé JBoss vers la version 5.1 (soit des spécifications de Java EE 5 avec capacité à Java EE 6). Il est possible que cette simple mise à jour corrige le problème de communication avec SMB v1 en cluster.

666) Je vais défoncer le crâne du technico-commercial qui a validé l'architecture utilisée par son application sans rien dire sur ce détail super important !

Caytraykon hein le full cloud hein ? Tu sais qu'en présentation cluster tu peu non seulement faire du failover (comme précisé) mais aussi du loadbalancing géré sur les liens FC/Iscsi ? :> Mais bon, si tu gère pas tout le process, aucuns intérêt <_< (et le temps que les mecs a l'autre bout comprennent, ben t'aura passé tes délais)

Voilà, dans mon équipe on est pris en sandwich entre d'un côté des techos manu pilus qui défendent leur bout de steak et de l'autre côté un jeu de commerciaux/acheteurs qui veulent juste faire passer les trucs en force.

La semaine prochaine, si j'ai le temps pour ce projet, j'effectuerais les quelques tests mentionnés en dernier.
Ca promet des retours intéressants dans tous les cas.