Announcement

Collapse
No announcement yet.

DFS Replication Dilemna

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • DFS Replication Dilemna

    Hello all. I find myself in a bit of a bind with DFS Replication. I have made limited use of DFS and FSR in the past.

    It's a fairly simple setup. The office has about 900GB - 1TB of files in four shares, and growing. The end users wanted the best possible reliability and seamless fault tolerance.

    So, I set up DFS Replication to replicate the data between two servers, and published the replication sets in a DFS Namespace. So if one server fails, operations can continue as usual while the problem is rectified. It is working quite well, in fact I am pleasantly surprised how well, but there is a problem.

    The majority of the edits and updates are on AutoCAD drawings. AutoCAD evidently uses lock files to prevent contention between users. AutoCAD creates a .DWL file in the folder with the drawing when it is first opened. It looks for lock files when opening files; if another user tries to open the file, AutoCAD will see the .DWL and only allow the second user to open the file read only.

    I believe the problem is that the .DWL files are not always visible to the second user, presumably because DFS has routed the two users to different servers. If the second user opens the file before the .DWL has replicated, a second .DWL will be created, and confusion will ensue when replication occurs, possibly causing one user or the other to lose their work.

    I found a product called Peersync that addresses this problem, but it is quite expensive so I am considering alternatives.

    It occurred to me to configure one server as read-only. This would be not be entirely seamless; if I understand correctly, in the event the read-write server failed, the users would only have read-only access to files on the remaining server. However that is probably close enough to suit their needs. I am not sure what I have to do to make this change.

    I also considered having the users access the shares directly on one server under normal circumstances, and only use the DFSN names in the event of an emergency. Since the DFSN UNCs are long and unfamiliar, I think they'd comply.

    I am open to any and all comments and suggestions, including using some tool other than DFS Replication and DFS Namespaces. The goal is to provide access to the file shares even in the event of a single server failure. Thanks in advance for your remarks.

    Last edited by admagik; 17th June 2015, 19:15.

  • #2
    I would deal with this by setting up one folder target as "preferred" in DFS, so all client referrals will get directed to it preferentially to the other server. There are options for "preferred within this site" or "preferred among all sites"

    Have done this with 2 DFS folder targets in one site without issues - for me Excel is the main issue rather than AutoCAD but the same rules apply
    Tom Jones
    MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
    PhD, MSc, FIAP, MIITT
    IT Trainer / Consultant
    Ossian Ltd
    Scotland

    ** Remember to give credit where credit is due and leave reputation points where appropriate **

    Comment


    • #3
      Excel, Word, PowerPoint, Project, they all lock files for single-user-only editing. For our DFS, we've had to use both the preferred target weighting Ossian mentions, as well as PeerLock software. Once we got it all together, it's been running fine (touch wood though, we haven't had a file server fall over, YET).
      *RicklesP*
      MSCA (2003/XP), Security+, CCNA

      ** Remember: credit where credit is due, and reputation points as appropriate **

      Comment


      • #4
        Thanks very much for your input.

        I went into the namespace, and under "Folder Targets" chose one and in the Advanced Properties set it to override referral ordering and set it as first among all targets.

        I have the end users testing it, their preliminary tests have gone well - so far it's handling open files properly. We'll beat on it a bit and with a little luck this may work OK.

        Comment


        • #5
          Originally posted by admagik View Post

          AutoCAD evidently uses lock files to prevent contention between users. AutoCAD creates a .DWL file in the folder with the drawing when it is first opened. It looks for lock files when opening files; if another user tries to open the file, AutoCAD will see the .DWL and only allow the second user to open the file read only.

          I believe the problem is that the .DWL files are not always visible to the second user, presumably because DFS has routed the two users to different servers. If the second user opens the file before the .DWL has replicated, a second .DWL will be created, and confusion will ensue when replication occurs, possibly causing one user or the other to lose their work.
          This is false. DWL files are only used internally by AutoCAD. File locking is handled by the O/S.
          This can be proven (on a single server, or even a local workstation) by removing the O/S lock on the DWL files, then delete them, then try to open the associated DWG file.
          The O/S will still prevent you from opening the DWG for WRITE.
          You can also create dummy DWL files for a DWG that is not open, and then open it. The O/S will not tell you it's read only or locked because of the presence of the dummy DWL files.

          Comment

          Working...
          X