FWIW Even full-mesh redundancy doesn't help you if your telco pushes some incorrect config to their core routers, or pushes some bad firmware to devices etc. You still end up with split network.
Referral ordering relies on all users being able to access the current "top" target simultaneously. Once some users are accessing one "top" target, and other users think that a different target is the current "top" target, you run the risk of double edit issues. Main way to avoid that is to have a highly redundant #1 target (or individual site-specific targets which are backed by the highly redundant target as #2). You can replicate the content to additional servers (e.g. in another DC), but don't publish these as targets unless your highly redundant target (and any protocol-aware load balancers you have) go down. Cheers Ken From: Kennedy, Jim [mailto:kennedy...@elyriaschools.org] Sent: Tuesday, 30 April 2013 10:57 PM To: NT System Admin Issues Subject: RE: DFSR When my WAN sh*ts itself it is cut into 13ths and it is all over anyway. Full mesh redundancy is not on our radar. The ROI isn't there for us. We pay for 4 hour from Cisco and 24 hour from our fiber provider. But if I was meshed and had distributed servers my referral ordering would still work. The top priority server dies or that part of the network dies peeps would go to the second ordered referral. .com] Sent: Tuesday, April 30, 2013 8:50 AM To: NT System Admin Issues Subject: RE: DFSR What happens when the WAN sh*ts itself, and your environment is cut in half? Cheers Ken From: Kennedy, Jim [mailto:kennedy...@elyriaschools.org] Sent: Tuesday, 30 April 2013 10:04 PM To: NT System Admin Issues Subject: RE: DFSR That can be mitigated with setting referral ordering on the namespace for common shares. I don't DFSR to load balance, I do it for uptime. All of the shares are referral ordered to just one server. To date, we have not had any double edit issues. Although I probably just jinxed myself. From: Michael B. Smith [mailto:mich...@smithcons.com] Sent: Monday, April 29, 2013 5:18 PM To: NT System Admin Issues Subject: RE: DFSR The big deal with DFS (IMO) is the "double-edit" issue. Two people can edit the same file at the same time and the last one that saves the file "wins". From: David Lum [mailto:david....@nwea.org] Sent: Monday, April 29, 2013 5:03 PM To: NT System Admin Issues Subject: DFSR I resolved my DFS issue from last week (pilot error :)). My question is this: Is there a reason not to leverage DFS for most file shares? It seems to me like it's a good way to be able to down a server (read: patch and reboot) and keep the file shares available, but I also know with something that's new to me makes it easy to overlook something simple. I'd guess it's not a good idea to DFS *every* file share, just mission-critical ones? In the scenario I care about the sites are all connected at 10Mbit or better and there's no more than 40 users connected to any one server at a time and 55 is the total user count. All storage is local, no SAN /iSCSI, etc. I did find this too: http://blogs.technet.com/b/askds/archive/2010/11/01/common-dfsr-configuration-mistakes-and-oversights.aspx Seems like the only downside - as long as you're paying attention to things listed in the link above - is using 2x/3x+ of the overall disk space as without DFSR, and possible traffic if you are a huge environment with very slow connections. David Lum Sr. Systems Engineer // NWEATM Office 503.548.5229 // Cell (voice/text) 503.267.9764 ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
