First published on TechNet on Sep 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 most common customer DFSR configuration is the classic hub and spoke data collection topology. This is:
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:
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.
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.
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.
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.
- Ned “full mesh” Pyle
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.