I would like to perform replication on 2 file servers using DFS. DFS uses a namespace to allow users to map to their own personal drive. I want to use only IP BASED namespace like 192.168.0.3peter. Is this achievable instead of using namespace domain like constr\peter? Will the 2 servers use the same IP? How does it work?
Yes, you can assign a dedicated IP address to your DFS and use it instead of file system name. The DFS configuration allows your shares to be referenced by \172.16.x.x\share instead of \server\share. Ensure you have installed PeerLock software so a DFS file can be locked once it was opened. http://www.peersoftware.com/products/dfsr-file-locking/peerlock.html
More about DFS drawbacks you can find here (copypasta from the link below)
1) Non-transparent failover
Using Microsoft DFS-R for Failover
In DFS failover, clients attempt to access another target in a referral after one of the targets fails to respond or is no longer part of the namespace. Clients must access a domain-based namespace by using the format \DomainName\RootName. If a client accesses a domain-based namespace directly on the root server (\RootServer\RootName), root target failover does not occur. DFS failover is only performed when a client opens a file or folder. If a client has files or folders open and attempts to read or write to them when the target server is unavailable, the application will receive a failure on that operation.
=> There's not much you can do here as DFS-R in kind of a maintenance mode, MSFT isn't releasing any updates for it.
2) Inability to replicate open files
DFS Replication: Frequently Asked Questions (FAQ)
*Does DFS Replication replicate files that are being used by another application?
If an application opens a file and creates a file lock on it (preventing it from being used by other applications while it is open), DFS Replication will not replicate the file until it is closed. If the application opens the file with read-share access, the file can still be replicated.*
Understanding (the Lack of) Distributed File Locking in DFSR
Since users can modify data on multiple servers, and since each Windows server only knows about a file lock on itself, and since DFSR doesn’t know anything about those locks on other servers, it becomes possible for users to overwrite each other’s changes. DFSR uses a “last writer wins” conflict algorithm, so someone has to lose and the person to save last gets to keep their changes. The losing file copy is chucked into the ConflictAndDeleted folder.
=> This is huge issue actually, say Hyper-V, SQL Server, Exchange, Veeam etc are out of game as they either never close their files or close them after very big amount of data copied to them, this means you can't manage your connections reliably, it will be "all-or-nothing" sync channel usage at best (Veeam), or inability to work at all (Hyper-V & SQL).
You can leverage this by using third-party software like say PeerLock but it's expensive and not very popular. There are rumors MSFT had locking-aware DFS-R replication but they never released it to public (see my "maintenance mode" comment for 1).
3) PITA to resolve manual conflicts [after different people will edit files at their locations]
Understanding DFSR conflict algorithms (and doing something about conflicts)
That’s all well and good. But how do I get my conflicted files back when the “wrong” one wins? You have a few options here: Use DPM – Data Protection Manager provides on-the-fly backups of files and near-line recovery. This way your odds are highest that the latest versions of the file have been backed up.Use Volume Shadow Copies – You can configure automatic backups of files on your DFSR servers. Then when users delete or conflict files, the data can be easily restored. With a little training, your users can even restore files themselves and not have to spend time with the help desk. Note also that if you are still running XP or (Dog forbid) Win2000, you need to install a client to let users restore their own files. See TechNet and Windows Help for configuring this on a per-OS basis and make sure you read through the best practices info. VSC does not replace regular backups!Use backups – Windows Server Backup, NT Backup (if still on Win2003 R2), or 3rd parties should be used to back up your data every day. This way no matter what, you can always get back to yesterday’s copy of a file.Use the restoredfsr.vbs script – Unsupported, as-is, and provided without warranty, this script may be your only hope if you have no created backups and shadow copies. Use it at your own risk. The script is hosted on Code Gallery (http://code.msdn.microsoft.com/restoredfsr). As always, the script requires you to edit a few variables before running – see the script for how-to documentation. You run it with:CSCRIPT.EXE restoredfsr.vbs => You kind of can live with it if you don't do frequent changes.
As an alternative, I suggest you a native File-Share build on top of storage being replicated/mirrored simultaneously on a block level.
StarWind Virtual SAN Free https://www.starwindsoftware.com/starwind-virtual-san-free
Both do the shared storage presenting as File Share available by a file server’s name or IP address.