Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Win 2003 Svr Clustering / NLB advice please?

Status
Not open for further replies.

Badgeroonie

IS-IT--Management
Mar 26, 2003
32
0
0
GB
Hi all,

I'm after some advice. I wish to provide full redundancy to my file servers, so that if say the motherboard goes boom, then our files would remain available on another server.

Some form of clustering seems to be the way to go, but more specifically the NLB (Network Load Balancing) route appears to be more specific to my needs. From what I read 'clustering' (in Win2003) would use a shared external storage which isn't what I have. I need (ideally I currently believe) to have two similar servers, both of which have a local store of all the files shared on the LAN, so if either one goes down, the other is still there to provide service. One question mark I have though is that the literature I've read thus far seems to apply NLB to internet servers, so I therefore question if it'll suffice in my case?

I have two 'test servers' sat here ready to go with Win2003 installed. I'd really appreciate anyones thoughts or advice toward achieving what I am after.

My thanks in advance!
 
You are correct. What you want to do is the NLB setup. You'll want to use DFS to ensure that the two network shares remain in sync, so that all files available on one, are available on the other.

When setting up NLB for file servers follow the same procedure as for web servers, put instead of load ballancing port 80, you'll want to load ballance port 135-139.

It sounds like you are on the correct path however.

Denny

--Anything is possible. All it takes is a little research. (Me)

[noevil]
(My very old site)
 
Hmm you shouldn't really use NLB for file servers, unless the files are static/read-only. NLB is designed for stateless apps which are apps that don't change dynamically. The obvious example is a web-page which is why it's the one used in most NLB examples.

But apps where the data changes frequently (such as a backend database or file server) aren't suitable as there is no synching between server in an NLB cluster. If you change a file on one NLB server then you need to change the file on the other NLB server either manually or through something like Robocopy. You might be able to keep them synch'd but it's not recommended.

If you want true automated fail-over clustering then you'll need to use a server cluster which as you say requires shared storage. Personally we don't cluster our file servers we just make sure no single server has more than 100GB of data so we can restore from tape to a DR server in a few hours.
 
Thanks for the info guys!

Nickferrar - whats your thought on using DFS as suggested by mrdenny? This would provide the synching you mention as missing in an NLB cluster. I can see the logic myself and would easily be able to configure high speed replication to ensure the two storage sets are concurrent.

 
Hmm I actually missed the part about DFS. I can't say I've done much with DFS personally but my understanding is you configure the fail over of link replicas etc from within DFS itself. How the fail over actually works I'm not sure but I've never come across doing it via NLB clustering - it's always an integral feature of DFS.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top