Quick and dirty file-clustering-for-idiots
DFSR is safe for work
Sysadmin blog DFSR was one of Server 2003 R2’s hidden gems. It is more robust in Server 2008 R2, but the fundamentals haven’t changed. You mostly use it for collecting data from shares on branch sites to a centralized site for backups. Alternately, it is a method of providing centrally published information to branches.
That’s what the white papers say.
I have found other uses for this technology. Yes, I shuffle branch backups back to head office for archiving, but this is not the most critical use in my environment. For me DFSR is most important as file clustering for idiots.
DFSR is a “moderate availability” technology. True “high availability” clustering requires specialized hardware, software and skills. To provide HA file storage you generally need a SAN. The SAN, of course, is vulnerable to failure as well, so somewhere along the line it has to consist of at least two nodes which replicate information between them. This is in addition to the (at least) two front-end nodes which post CIFS shares for user consumption.
The other alternative, what I would consider “low availability,” is a single server with a RAID card. The RAID may protect you from loss of a disk, but if you lose a DIMM, CPU fan, or other component you could be down for anything from hours to days. Downtime here depends on the time to diagnose the problem, obtain spares and replace the failed component.
To contrast, moderate availability technologies allow failover of less than 15 minutes to switch from primary to backup. They often require some manual intervention from the sysadmin, but require neither additional skills nor specialized technologies. This is where DFSR comes in.
I use DFSR to “twin” file servers. At each of my locations I have two identical file servers. Each system runs a copy of Server 2003 R2 Enterprise. The primary file server at each site serves up about 10 terabytes of RAIDed storage across 20 shares. All of the shares are a subfolder of E:\Local Shares. DFSR is set to replicate all E:\Local Shares to the backup (“twin”) file server, using a dedicated network card.
Making the twinned systems replicate over a dedicated link is trivial. Each system has two NICs. The dedicated replication NICs work on a dedicated storage subnet. Enter the storage subnet information of both twins into the hosts file. Voila: replication traffic over a dedicated link, and the backup file server no more than fifteen minutes behind the primary.
When the primary file server dies, I take it out of service, delete its active directory computer account and force a replication on our domain controllers. Wait five minutes, then rename the secondary file server to the name of the former primary file server. Change the hosts file and check the share permissions. I am now back online in less than 15 minutes; the longest part is the wait for the Adaptec controller kernel to boot upon name change of the backup file server.
It isn’t for purists. If you have time on your hands, or a dedicated Linux admin, you could use DRBD to offer a block-level version of the same thing for free. It’s a quick and dirty “but it works” solution for those who just need a problem to go away. More importantly, I have yet to find the limits of this solution. So far it has handled 60 million files and 10 terabytes of data in a single replication group without blinking.
I have been using this for three years now with 15 “twinned” setups. Combined with a strict backup regimen, and despite some interesting failure scenarios, it hasn’t let me down yet. ®
Sponsored: Customer Identity and Access Management