Planning a DFS Architecture, Part 2
In the first part of this article series, I talked about the differences between a stand-alone DFS namespace and a domain based DFS namespace. The next thing I want to discuss is the replication topology that will be used by your DFS servers.
When I have introduced the concept of DFS to clients in the past, one of the first questions that they always ask me is why in the world they need multiple DFS servers. Technically, you don’t have to have multiple DFS servers, but there are some advantages to using multiple replica servers. For starters, using multiple replicas provides you with a degree of scalability. Rather than having every user in your organization access their files from the same server, you can distribute the user workload across multiple DFS replicas rather than over burdening a single server.
Another reason for having multiple DFS replicas is because doing so provides you with a degree of fault tolerance. For example, suppose that you need to install a service pack onto your servers. Most of the time when you install a service pack for Windows, the installation process requires you to reboot the server when you’re done. Normally, rebooting a server is disruptive to the users who are accessing files on that server. If you know that you’re going to be doing maintenance on one of your servers though, you can remove the server from the DFS namespace, and perform your maintenance without disrupting the users. When you’re done, you can designate the server to act as a part of the namespace once again.
DFS can also provide fault tolerance from the standpoint of protecting you against network link failures. For example, suppose that your company has a branch office that is connected to the main office by means of a WAN link. Normally, if the WAN link were to fail then users in the branch office would lose access to any of the servers in the main office. If you place a DFS replica in the branch office though, then the users in the branch office can continue to access their files even during a WAN link failure. When the link is eventually reconnected, any modifications to files in either office will be synchronized with the other server.
Windows Server 2008 supports a couple of different types of replication topologies for DFS servers. Each of these topologies have their good points and their bad points. If you are having trouble deciding which replication topology is right for your organization, then you should give serious consideration to using the same DFS replication topology as you’re using for your Active Directory infrastructure.
The Hub and Spoke Topology
One of the most popular replication topologies is the hub and spoke topology, shown in Figure A. The hub and spoke topology involves placing the initial master in the middle of the topology. Each replica performs two way replication with the initial master, but does not replicate with any of the other replicas. This type of topology tends to be very efficient, but the problem with it is that if the initial master were to fail, then all replication would cease to function until it came back online.
Figure A This is what the hub and spoke topology looks like.
The Full Mesh Topology
Another commonly used replication topology is the full mesh topology. This topology, shown in Figure B, allows every replica to replicate with every other replica. The advantage of using this topology is that replication will still continue to function even if a server drops off-line. Of course the disadvantage to using this method is that it can result in an excessive amount of replication traffic.
Figure B The full mesh topology provides replication connectivity between every replica.
When you configure a replication group in Windows Server 2008, one of the topology options that Windows allows you to choose from is No Topology. As strange as it might sounds to not define a replication topology, there is actually a really good reason for using this option. The No Topology option allows you to create a replication group without defining a replication topology. This allows you to create your own custom replication topology later on.
As you can see, the replication topology plays an important part in the overall DFS architecture. In Part Three of the series, I will talk about some best practices for planning your DFS architecture.
Got a question? Post it on our Windows Server 2008 forums!