次の方法で共有

How many DFS-N namespace servers do you need?

  • [アーティクル]

Introduction

Whenever you’re deploying Windows Server DFS-Namespaces, you will need to figure out how many servers will be required.
Since I moved to the role of DFS-N PM, I noticed that the specific information on how many namespace servers you need is something that isn’t clearly posted anywhere.
Although we never really had any problems with performance of the namespace server themselves, the question of where to place them is quite common.
Hopefully, this blog post will help clarify the topic.

Note: We're not discussing here the type of namespace you should be using (standalone, 2008 domain mode, 2000 domain mode).
We assume you already made that call and you're now deciding how many namespaces servers you need and where they should be.

Performance

A single namespace server can typically handle thousands of referrals per second (the exact number will depend on details like the number of targets per link, the server configuration, the network bandwidth).
Since DFS-N clients will cache those referrals, you will be hard-pressed to find a scenario where a single dedicated namespace server would become a significant performance bottleneck.
However, there’s a lot more to this than raw referral performance.

Zero?

The first option for you is not to deploy any additional servers specifically for DFS-N.
If you have a small environment, you can simple enable the DFS-N role on an existing domain controller or file server (you are likely to have some of those already).
In that case, you need zero new servers. Let’s look into the two options: DCs or file servers.

Deploy DFS-N on the DCs

Domain controllers seem like a good candidate to become namespace servers, since they are usually not too busy on small environments.
Domain controllers are likely to also be running other services like DNS.
The typical distribution of domain controllers will also help with your namespace site awareness.
Having a DC nearby will also do wonders for the performance of your domain queries.
On the other hand, domain controllers are sometimes run by dedicated teams that are not too keen on adding unrelated services to their boxes.
You could argue that DFS-N and AD are closely related, since DFS-N domain namespaces use AD for storage. You might lose that argument :-).
Domain controllers are usually heavily secured (for good reasons) and getting permissions to manage a service on those boxes might be a tough one, specially on larger enterprises.
It might also be a little harder to troubleshoot root referrals when the namespace server and DC are collocated (not so easy to get a network trace).

Deploy DFS-N on the file servers

File Servers are also an easy option here. If you already have a few file servers, you could simple add the DFS-N role to a few of them.
The team that manages file servers typically will also be in charge of namespaces, so that helps.
Also, if you have consolidated your file servers, you’re probably OK consolidating your namespace service as well.
This might perpetuate the myth that the file service and the namespace service are the same thing, but that’s just a minor thing :-)
One issue is that the file servers might not be running Windows (they could be some type of NAS appliance), so you could not load DFS-N on them.
As already mentioned, a single namespace server can handle a lot of load, so you will definitely not need this service on every file server. You should aim for two (for high availability).

Two

If you couldn’t talk the owners of either the domain controllers or the file server into hosting the DFS-N service, you can have your own dedicated namespace servers.
If you do decide to install them separately, you would typically not need more than one server, from a referral performance standpoint.
However, due to high availability requirements, it’s strongly recommend to configure two of them.
If you use domain namespaces, they will naturally cover for each other.
If you use standalone namespaces, you should configure them as a failover cluster.

One per site

One reason to have more than two dedicated namespace servers is to resolve referrals within a site.
If you are using domain namespaces, clients will get their referrals from the nearest namespace server and the AD site configuration is used to determine that.
In that case, you should consider having one namespace server per site.
To further improve on that, you could have at least one domain controller per site and enable DFS-N “root scalability”. This will make the namespace server work with the nearest DC.
Keep in mind that, if you enable “root scalability” and you update the namespace root, your users might see outdated information until the site DC gets updated via AD replication.
This also provides fault tolerance, because if the namespace server on your site fails, you can still get referrals by contacting a namespace server on another site.
This is definitely not driven by the load on the server, but by the requirements for site independency and by WAN bandwidth concerns.
Have I mentioned that you could try to talk the people manage the DCs into let you run the DFS-N service on their boxes? :-)

Two per team

You might also end up with multiple namespace servers if multiple teams in an enterprise stand up their own set, typically using standalone namespaces.
Since each team will need to provide high availability by clustering their standalone namespace servers, you will end up with two namespace servers per team.
As you can imagine, this not a good way to go. Keep in mind that DFS-N servers can host multiple namespaces and you can delegate management per namespace.
This makes even less sense for domain namespaces, since by definition you would be trying to consolidate the namespaces.
Again, this would not be driven by the load on the server or any other technical requirements.
In short, if you have one or two namespace servers per team you should probably go back to the drawing board and reconsider your consolidation options.

Conclusion

I hope this helped with your DFS-N design. For additional details on DFS-N, see  my other blog posts at https://blogs.technet.com/josebda/archive/tags/DFS/default.aspx

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    Lucid as always.  Nicely stated.
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    The comment has been removed