Mark Minasi's Tech Forum
Register Calendar Latest Topics Chat
 
 
 


Reply
  Author   Comment  
anthony

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 44
Reply with quote  #1 
We have a file server that gets absolutely hammered. Lots of I/O, and it has a lot of shares on it. We have DFS setup and that is working, however many of the shares point back to the same server.

This server is a VM that runs on a Hyper-V cluster using 10gig iSCSI to the SAN.

We would like to spread out some of the shares across other servers. But my question is about the DFS. What determines if DFS namespace is "up"? Is that an AD function? Or is there some other service?

In other words, I dont want to spend a huge amount of time splitting out shares on a bunch od different servers, only to have the "weak spot" be DFS namespace.

Is scale out file server an option? Clustering a file server? Etc.

Thanks!

__________________
If Chewbacca lives on Endor - You must acquit!
0
wkasdo

Avatar / Picture

Administrator
Registered:
Posts: 179
Reply with quote  #2 
There is a bit more to it. DFS has three components:
1. namespace; hosted on all DCs of the domain
2. root servers; these hand out referrerals. You should have at least two.
3. target servers; these host the shares.

So for a working referral to happen, all three need to be alive.

> But my question is about the DFS. What determines if DFS namespace is "up"? Is that an AD function? Or is there some other service?

The client does. It gets a list of targets from a DFS root servers, and tries them one by one. The target referral process is site aware.

How will you distribute data to other file servers, did you consider that? DFS-R? Something else?


> Is scale out file server an option

Probably not, and clustering is also not going to relieve your IO needs. Distributing using DFS-N is not a bad option. The other is to throw more IOPS at the VM, if you can do it. What IOPS range are we talking about, anyway?

__________________
[MSFT]; Blog: https://blogs.technet.microsoft.com/389thoughts/
0
Phil-n-JaxFL

Avatar / Picture

Grumpy Old Men
Registered:
Posts: 75
Reply with quote  #3 
As wkasdo stated, DFS is site aware...any chance of your dispersing the load across sites?
IOPs, as you probably know, are disk related. Can you change your disk setup? Maybe add faster disks? Or a better RAID solution?
Have you done a deep dive to see what/where all the requests are coming from? Is it user or program based?

__________________
Phil
0
anthony

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 44
Reply with quote  #4 
Sorry for the delayed response. We are a single site entity. We don't use replication or anything.

We are running a Dell Compellent SAN, which is where the storage for this server lives. We have an application that runs an executable from the share (I know right?) and we have about 300 users running it at the same time. It just seems like sometimes there are TOO MANY files open or something and the server just sorta says "ENOUGH!" and stops responding to connections. You can ping it. You can RDP to it. But until a reboot happens on it - it won't allow people to connect to shares on it anymore. Even restarting services on it won't help.

So my thought was to move the application share to another server and let it be dedicated to that job (we have a Nimble SAN I was thinking of putting that share on). Then have the file shares that are word, excel, etc. be on it's own box. It's a bit hard to troubleshoot since this is a kind of random thing that happens. It might only happen once a month. But when it does happen, so many things rely on the shares on it - it's a ripple effect.

Just trying to get some redundancy there...



__________________
If Chewbacca lives on Endor - You must acquit!
0
wobble_wobble

Avatar / Picture

Associate Troublemaker Apprentice
Registered:
Posts: 741
Reply with quote  #5 
Anthony

I've seen occasions when Compellent will do weird like that
Is the Compellent dropping the data down onto lower staged disks or have you the data pinned to high performance disk?



__________________
Have you tried turning it off and walking away? The next person can fix it!

New to the forum? Read this
0
Wes

Senior Member
Registered:
Posts: 190
Reply with quote  #6 
What is the OS?  We were seeing this bug quote some time ago - only a reboot would fix it.  MS support was useless.  I want to say that upgrading to 2012r2 fixed it, but I could be wrong - it's been a good while...
0
anthony

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 44
Reply with quote  #7 
OS is 2012, when I get back to the office I can look if it's R2 or not. It might be just 2012. We have two levels of disk. 15k SAS and 7500 SAS. I'm not sure if it might be doing that or not.
__________________
If Chewbacca lives on Endor - You must acquit!
0
cj_berlin

Avatar / Picture

Senior Member
Registered:
Posts: 177
Reply with quote  #8 
Anthony,

since you are still able to access the files locally on the file server (are you? I am assuming now, it hasn't been metioned explicitly in the thread) when the sharing starts acting up, the underlying storage is most probably not an issue. Besides, you would be seeing millions of red entries in the event logs on the file server if the disk subsystem would refuse to serve blocks to it.

Moving the application share off the main file server is a very good idea. Is the application in question using the Jet Engine (Access MDB files) by any chance? There is an increaseable file locks maximum in Access that also applies to other Jet instances. But this issue usually manifests itself in the application, not the share stopping working. Still might be worth checking. For reference: https://support.microsoft.com/en-us/kb/815281

Here is a doc on performance monitoring and tuning of SMB file servers: https://msdn.microsoft.com/en-us/library/windows/hardware/dn567661%28v=vs.85%29.aspx#smbperftuning Might try recording some of the mentioned perf counters so you would see them hitting the ceiling just before the shares stop responding.

FWIW,

__________________
Evgenij Smirnov

My personal blog (German): http://www.it-pro-berlin.de/
My stuff on PSGallery: https://www.powershellgallery.com/profiles/it-pro-berlin.de/
0
Infradeploy

Avatar / Picture

Senior Member
Registered:
Posts: 165
Reply with quote  #9 
To add: Get rid of PST files if you have them
__________________
Have SpaceSuit, Will Travel

0
cj_berlin

Avatar / Picture

Senior Member
Registered:
Posts: 177
Reply with quote  #10 
Quote:
Originally Posted by Infradeploy
To add: Get rid of PST files if you have them

...regardles of whether you are having storage problems or not. They're just evil [wink]

__________________
Evgenij Smirnov

My personal blog (German): http://www.it-pro-berlin.de/
My stuff on PSGallery: https://www.powershellgallery.com/profiles/it-pro-berlin.de/
0
anthony

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 44
Reply with quote  #11 
Completely agree!
__________________
If Chewbacca lives on Endor - You must acquit!
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation: