I want to configure file server in MS Windows Server 2012 R2 environment, which would load balance traffic.

I have got a SAS disk array with 2 SAS controllers which is connected to 2 Hyper-V cluster nodes by 4 redundant SAS multipaths:

controller1 <-> node1, controller1 <-> node2,

controller2 <-> node1, controller2 <-> node2.

I don't know whether the SAS load balancing would be noticable if I would NOT balance the network, which means, that just one server on the network would handle all file I/O requests. Balancing network seems to be complicated, beacuse I don't want to have 2 file servers with identical copy of data (redundancy is guaranteed on RAID level of disk array). What I want is one bunch of data split to two disjoint scopes, each one on separate file server (each virtual server on one node of cluster), which would act as a single server or SMB share.

User shloudn't know which data is on server A or B, the SMB path should be something like \\domain.com\home\username or \\domain.com\share\department and homes or departments should be distributed across two servers (for example those starting with "A-P" on first and the rest on the second one).

I have a central network core switch and each cluster node has 5 GB/s aggregated link to it. The rest of the network is connected to this switch (each access switch is connected by 2 GB/s link, clients are connected by 1 GB/s link).

My questions are:

  • If I don't do network load balancing and keep SAS load balancing, would the SAS load balancing be noticeable or not?
  • Is there some network load balancing clustering technique by which I would achieve mentioned results?
  • I know that there are many factors which depends on specific situation (such as maximum number of simultaneous connections or frequency of separate, possibly short connections; whether read operations are dominant etc. etc.), but are there any general best practices I should respect?
  • Isn't the easiest (and possibly the best one) way to don't load balance anything and have simple management?


Thank you very much! Actually DFS was one of the first think I have searched for, but I have ended up with a result that what I want is impossible with DFS.

After playing with it for a while, I have following configration:

One DFS namespace HOME, both file servers added to it as a namespace servers, so on each there is share named "home" physically under "C:\DFSRoots\home". On each server also have a hidden basic shared folder named "home$", physically placed in disk array. In hidden share of first server I see one half of HOMEs on the other the rest of HOMEs. In home DFS share (of both servers) I see only links (distributed to hidden shares), but to all of HOMEs.

When a client conntacts the root (\domain.com\root) one of DFS namespace servers responds to a client. In my situation it is allways the same server, because I have only one site. But it doesnt matter, because it only lists content of a DFS root. When then client navigates to one of the listed links, DFS estabilishes connection with hidden folder target, which is one of the servers, so then load balancing is accomplished.

Is this configuration correct, optimal?

And the last question is: How much faster is SAS generally compared to LAN (for example 5GB/s aggregated by LACP)?

  • Just added a whole whack of details.. – GregL Apr 17 '15 at 15:34

You should really look at Microsoft DFS to do what you're talking about.

It provides a way to abstract the physical location of data by bringing everything together in one place.

So, for example you would have:

  1. 2 cluster nodes (FSCL1, FSCL2)
  2. 2 clustered file services (FS1, FS2), running on the above nodes
  3. 2 domain-based DFS namespaces (HOMES, SHARES), hosted on the above nodes

Each file service can have any number of shares you want and you would simply create links in DFS for them as needed.

Here's how it's setup where I work. This may not be the best thing ever, but it's very functional for us.

Our namespaces are hosted off dedicated servers, but that's not really a requirement. It just means we don't have name collisions between DFS shares and target shares.

On our file servers (FS1, FS2, etc...) we use mount points for data volumes because otherwise we'd run of letters (~28 data volumes, ~7 mount-point roots, utility volumes & quorum). Let's just say for FS1, with 2 data volumes, we'd have something like this:

Mount Point root: 2GB volume assgined as a X:\
Data volume 1: 2TB, mounted as X:\FS1_VOL1
Data volume 2: 2TB, mounted as X:\FS1_VOL2

On each data volume, there's a "base" folder for all the shares, whether group or user.
For group shares: X:\FS1_VOL1\FS1_V1_SHARE and X:\FS1_V2_VOL2\FS1_V2_SHARE
For user shares: X:\FS1_VOL1\FS1_V1_HOME and X:\FS1_V2_VOL2\FS1_V2_HOME

These are then shared hidden, to create these 4 shares:


Inside those shares, would exist any number of user or group folders as needed.



This is where all the "magic" of load-balancing happens.

If you have a LOT of shares/users, you'll likey want to create a folder structure in the namespace. We just created 26 top-level folders, A-Z.

In the SHARE namespace, you'd then create links to your shares like this:

\\example.com\SHARE\H\HR           =>  \\FS1.example.com\FS1_V1_SHARE$\HR
\\example.com\SHARE\E\Engineering  =>  \\FS1.example.com\FS1_V2_SHARE$\Engineering
\\example.com\SHARE\F\Finance      =>  \\FS1.example.com\FS1_V1_SHARE$\Finance
\\example.com\SHARE\I\ITOPS        =>  \\FS1.example.com\FS1_V2_SHARE$\ITOPS

And the HOME namespace would look like this:

\\example.com\HOME\P\John.Public    =>  \\FS1.example.com\FS1_V1_HOME$\John.Public
\\example.com\HOME\O\Barak.Obama    =>  \\FS1.example.com\FS1_V2_HOME$\Barak.Obama
\\example.com\HOME\H\Stephen.Harper =>  \\FS1.example.com\FS1_V1_HOME$\Stephen.Harper
\\example.com\HOME\S\Paul.Smith     =>  \\FS1.example.com\FS1_V2_HOME$\Paul.Smith

When a client browses to the namespace, you're right, he gets put on one of the namespace root servers. A given client won't always end up on the same one, but he will cache it for a set amount of time, during which all operations happen ont he same system. The cache duration is configurable in the DFS snapin. In our environment, we see very smooth distribution between the root servers. Root Server #1 Root Server #2

That's the gist of it.

It means that you need to create DFS links for every single share/user but also gives you infinite flexibility in where your data resides, while making it all appear to be in the same place.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.