Replacing DFSR Member Hardware or OS (Part 1: Planning)

Article
09/03/2010

Hello folks, Ned here again to kick off a new five-part series on DFSR. With the release of Windows Server 2008 R2, the warming of economies, and the timing of hardware leases, we have started seeing more questions around replacing servers within existing DFSR Replication Groups.

Through the series I will discuss the various options and techniques around taking an existing DFSR replica and replacing some or all of its servers. Depending on your configuration and budget, this can range from a very seamless operation that users will never notice to a planned outage where even their local server may not be available for a period of time. I leave it to you and your accountants to figure out which matters most.

This series also gives updated steps on validated pre-seeding to avoid any conflicts and maximize your initial sync performance. I will also speak about new options you have in this replacement cycle for clusters and read-only replication.

Finally: people get nervous when they start messing around with gigabytes of user data scattered across a few continents. I’ll be cutting out most of the wacky Ned’isms here and sticking to business in a “TechNet-Lite” style. Hopefully it’s not too boring.

The Scenario

The most common customer DFSR configuration is the classic hub and spoke data collection topology. This is:

Multiple branch file servers that hold user data in the field and are replicating data back to a single main office hub for backup purposes.
Some data may flow from the hub out to the branches but that will generally be very static, such as application installation packages or HR paperwork.
The storage on the branch servers is local fixed disks.
The storage on the hub server is a SAN.
The servers are mostly (if not all) currently running Windows Server 2003 R2 SP2.

There are variations possible where you might have more SAN’s or no SAN’s or 50 servers or 5 hubs. None of that really matters once you understand the fundamentals that are explained here in these simplified examples. Just focus on how this works at the micro and you will have no trouble at the macro.

In my diagrams below the following holds true:

All DFSR servers are Windows Server 2003 R2 SP2.
The hub uses a fiber-attached SAN, the branch servers have local disks.
The topology is hub and spoke. BRANCH-01 and BRANCH-02 replicate with HUB-DFSR, each in their own replication group.
All my replacement OS’ are Windows Server 2008 R2 (so that it is possible to use cluster and read-only).
The domain is running Windows Server 2008 R2 DCs (so that it is possible to use read-only).
The replacement hubs are clustered to provide higher availability.

The Options

There are a number of ways you can replace your servers with new hardware and operating systems. I have ordered these in least to most disruptive to the replication. As is often the case, there is an inverse correlation between this and cost/effort. In the follow-on articles I go into the specifics of these methods.

Note: the diagrams are simplified for understanding and are not a complete set of steps. Do not use these diagrams as your sole planning and methodology; keep reading the other articles in the series.

You may find that you implement a combination of the options depending on your time, budget, and manpower.

N + 1 Method (Hardware, OS)

The “N+1” method entails adding a new replacement server in a one-to-one partnership with the server being replaced. This allows replication to be configured and synchronized between the two nodes without end users being interrupted for long periods. It also allows both the hardware and OS to be replaced with newer versions. Pre-seeding is also possible. When the servers are synchronized the old server is removed from replication and the new one renamed. The con is that you will need enough storage for two hubs, which may be costly if you are low on capacity currently.

Figure 1 – Existing environment with old hub and branches
Figure 2 – New hub cluster replicates with old hub only

Figure 3 – Old branch servers now replicate with new hub
Figure 4 – New branch server replicates with old branch server

Figure 5 – New branch server now replicates with new hub server
Figure 6– Old Servers removed

Data Disk Swap Method (Hardware, OS)

The “Data Disk Swap” method does not require twice the storage capacity of the old hub and instead moves an existing disk (typically a LUN) from an old to a new node. This also means you get pre-seeding for free. The downside to this method is that replication to the hub will be interrupted during that disk move process and during the non-authoritative sync will have to happen between the hub and its partners, putting the branches at risk during that timeframe.

Figure 1 – Existing environment with old hub and branches
Figure 2 – New hub cluster built

Figure 3 – Old hub server removed, new hub attached to storage
Figure 4 – New branch server replicates with old branch server

Figure 5 – New branch server now replicates with new hub server
Figure 6– Old Servers removed

Reinstall Method (OS Only)

The “Reinstall” method can be used to lay down a later operating system over a previous edition without upgrading. Files are pre-seeded as the data will not be touched in this method, but replication will be halted until the installs are done and replication is reconfigured, leading to a potentially lengthy downtime. Previous OS versions installed will be immaterial to this method.

Figure 1 – Existing environment with old hub and branches
Figure 2 – OS’ reinstalled and DFSR rebuilt

Upgrade Method (OS only)

Finally, the “Upgrade” is what it sounds like – an in-place increasing of the OS version using setup. As long as your servers meet the requirements for an in-place upgrade then this is a supported option. It will not cause replication to synchronize again but there will be downtime during the actual upgrade itself. It’s also not possible to deploy Win2008 R2 if the old computers are running 32-bit OS. As with any upgrade, there is some risk that the upgrade will fail to complete or end up in an inconsistent state, leading to lengthier troubleshooting process or a block of this method altogether. For that reason upgrades are the least recommended.

Figure 1 – Existing environment with old hub and branches
Figure 2 – OS’ Upgraded

Series Index

- Ned “full mesh” Pyle

Comments

Anonymous
September 03, 2010
The comment has been removed
Anonymous
September 03, 2010
The comment has been removed
Anonymous
September 03, 2010
The comment has been removed
Anonymous
October 12, 2014
Replacing DFSR Member Hardware or OS (Part 1: Planning) - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
October 24, 2014
Replacing DFSR Member Hardware or OS (Part 1: Planning) - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
November 02, 2014
Replacing DFSR Member Hardware or OS (Part 1: Planning) - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
November 03, 2014
Replacing DFSR Member Hardware or OS (Part 1: Planning) - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
November 03, 2014
Replacing DFSR Member Hardware or OS (Part 1: Planning) - Ask the Directory Services Team - Site Home - TechNet Blogs
Anonymous
May 27, 2015
The comment has been removed
Anonymous
May 27, 2015
The comment has been removed
Anonymous
May 27, 2015
The comment has been removed

Share via