Feeds

Quick and dirty file-clustering-for-idiots

DFSR is safe for work

  • alert
  • submit to reddit

Top 5 reasons to deploy VMware with Tegile

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. ®

Beginner's guide to SSL certificates

More from The Register

next story
Ellison: Sparc M7 is Oracle's most important silicon EVER
'Acceleration engines' key to performance, security, Larry says
Oracle SHELLSHOCKER - data titan lists unpatchables
Database kingpin lists 32 products that can't be patched (yet) as GNU fixes second vuln
Lenovo to finish $2.1bn IBM x86 server gobble in October
A lighter snack than expected – but what's a few $100m between friends, eh?
Ello? ello? ello?: Facebook challenger in DDoS KNOCKOUT
Gets back up again after half an hour though
Troll hunter Rackspace turns Rotatable's bizarro patent to stone
News of the Weird: Screen-rotating technology declared unpatentable
prev story

Whitepapers

Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Storage capacity and performance optimization at Mizuno USA
Mizuno USA turn to Tegile storage technology to solve both their SAN and backup issues.
The next step in data security
With recent increased privacy concerns and computers becoming more powerful, the chance of hackers being able to crack smaller-sized RSA keys increases.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.
A strategic approach to identity relationship management
ForgeRock commissioned Forrester to evaluate companies’ IAM practices and requirements when it comes to customer-facing scenarios versus employee-facing ones.