Set Get Reply to Nearest Server 1

[SuperDaveDCF]

Guys,

We have a large tree with approx 400 servers throughout the state. I work on about 30 servers in our district. Our users are in satellite offices that have their own dedicated t1 and their own server. We are currently a mixed 4.11, 5.0 and 5.1 environment. 5.1 will be in place at all locations by October.

I'm getting conflicting view on how to set this parameter.
My boss is having me set this to off. Novell seems to say that this should be on. The client's do have preferred server set to the one in their building and their default location profile shows their server with no preferred context or tree.

Your opinions are apprecicated. Thanks in advance.

 

[salserocito]

My opinion...

I also support a NDS Tree with hundreds of NetWare Servers that are mixed v4.11, v4.2 and v5.1, though we are almost through our v5.1 migration, also.

I would recommend having SET REPLY TO NEAREST SERVER set to ON, but ONLY on the Server that acts as the Master for that part of the Partition. Any other Servers, whether they have a Replica copy or not, should have this turned off.

Having it turned on across all Servers creates way too much unnecessary traffic and you never know what Server your Users have been authenticated to. When only the Master has it turned on, it also gives you a centralized server that will handle your User authentication.

You should also make sure that your User objects all have a Default NDS Tree, NDS Context, and Server. If not, the Client is basically broadcasting across your Network searching for the first Server to resond, no matter its Context or physical location.

Hope this helps!

Good Luck.

 

[SuperDaveDCF]

Alright, let me through this into the equation. We just finished a server in our district HQ which will serve as a master nds server to hold master replicas for all the other servers as well as function as a workstation import/removal server for Zenworks 3.2 workstation objects. Each of the twenty districts in the state will have the same setup.

BTW, each location OU is already partitioned off on its own.
Most hold a R/W of themselves as the master has been moved to the master nds server I mentioned.

Would you still leave the servers set to off? I think the original reason this was done was to cut down on NDS traffic as we were using alot of ISDN WAN links.

Thanks again Salserocito!

 

[TheLad]

I would recommend having it set on more than just the Master server because you run the risk of having no server to authenticate to if the master is down.

Also, the heavy traffic load that this could cause on the master could affect performance on the server and anyone using it.

On most network routers/switches, you can configure GNS (Get Nearest Server) so that servers across WAN links do not respond - they only respond to requests onsite. -----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------

 

[salserocito]

If the Master resides on a Single "centralized" Server with at least a Read/Write replica of the partition, then I would have each Master at each of the sites with GET NEAREST SERVER = ON, everything else OFF. I wouldn't even have it turned ON on the "centralized" MASTER. But that just me.

The way we have it here is each location holds the Master of its own Partition, with a Read/Write copy of the Replica residing on the Master of the Tree. Each location has no more than 3 Servers. But we have MANY sites.

I agree with TheLad regarding a single point of failure if only one server is setup to reply to these requests. Depending on how many local servers there are in a particular area or region will help you determine how many Servers you will want to have the Reply set to ON.

Just my opinion.

Good Luck!

 

[DrGreen26]

Get nearest server reply. Ok this is how GNS works. When a user attempts to login to the network, it first looks to see if the server resides on the same subnet. If yes, that server must have a NDS replica, if it does, then GNS should be enabled to handle the login. (There is one scenario where this would be different and I will explain later). If the server the user needs to access is in a different subnet and a router(s) is in between (There better be if this is the case), then the router maintains what is called a Server Information Table (SIT), when a GNS request comes in, the router will start going through its SIT list of servers until the GNS request is acknowledged. What happens in the netware world is one additonal step, a server that does not hold a replica (and has GNS turned on) it will acknowledge the GNS request and then it will forward the GNS request to a server that does. This even applies if the server is in a different subnet.

Now, best practices are this: Servers that do not have replicas, GNS should be set to NO or OFF. If you use a server like Bordermanager to get to the internet or for VPN services, GNS should also be turned OFF (Performance reasons). But any server, wether it be a Master or Read/Write should have this turned on. Two reasons, fault tolerance as mentioned earlier and the second being load balancing again also mentioned earlier. Example: My master server is busy handling multiple login requests, if it cannot answer a GNS request, then the next available server holding a replica can anser the request.

Also another good rule of thumb, never specifiy a default server in either the client itself or the users NDS account. Doing this would force the client to login to that server only, as opposed to just letting NDS and the Client dynamically select a server that is not busy to log into the network.

Also, good practice, LAN Admins should be the only ones with designated servers to log into (holding replicas) and each should point to a server with a different read/write or master. Reason being is if NDS started having problems, you would never know if everyone hit the same server each time. This actually worked for me when a rogue server object popped up on the network and one replica had this object which did not appear on the other replicas. Easy fix though.

HTH (Good reference, Novell's troubleshooting IPX networks, this has a good section on GNS and SIT)


Mark C. Greenwood, CNE
m_jgreenwood@yahoo.com

CNE 4.11 and CNE 5 certified. BS Degree in MIS. Working in the industry for 8 years.

I work with NT servers, NDS for NT as well.

 

[damonuk]

You need a preferred tree and context for your local users set. Set GNS on for all local servers that have a Read/Write replica of you local partitions. Any read only or sub refs set GNS to OFF. I would look at the routing as a properly configured router shouldn't pass on the broadcasts etc only proper 'interesting' traffic.

 

[JamesATL]

Great thread! We're having (logic) problems using %FILE_SERVER in our container login scripts.

Right now we set the Preferred Server on our Clients and only turn on GNS on our primary server. However everybody seems to agree that the "preferred server" setting is a legacy setting that shouldn't be used if possible.

(Note: %FILE_SERVER is a reserved login script variable that is the server the user authenticated on.)

How can I map our user drives using %FILE_SERVER if I can't guarantee which server the user authenticates against -- without duplicating file systems?

If I don't use %FILE_SERVER to map drives and instead use server names, aren't I also creating a single point of failure?

TIA -James

 

[damonuk]

The only new single point of failure would be in the login script, which I don't think there is a way round. If the named server dies, then you are without the data anyway. In which case you can either restore the data to another server and modify the script or bring up a replacement server (with the same name) and all should be well.

With only one server having GNS on, if that server fails then no one can login. (until you set GNS=ON on a read/write or master replica. This I would see as being far worse than losing some filesystem due to name. You can do some scripting to ser a primary and backup type server, and all you do is change the primary and secondary variable. i.e

SET %primary = server1
SET %secondary = server2

and then change the server names in the event of failure -
SET %primary = server2
SET %secondary = server1

Your script would read

Map X: = %primary/vol1:{data path}

You will obviously need to keep a backup server and keep the data synchronised. We used to restore the previous nights backup onto the secondary server. Using 5 incrementals and one full, gives best performance in a disaster situation.

Hope this helps

Damon

How many users, how many servers and how many partitions? Also, are all of them on one site?

 

[DrGreen26]

In the world of GNS, it does not matter which server handles the gns request for the login. The Z drive and a couple others might be mapped to that particular server, but the network drives that point to specific servers should work just fine. Besides that, NDS will never authenticate a drive that the user does not have access to.

HTH
Mark C. Greenwood, CNE
m_jgreenwood@yahoo.com

With more than 10 years experience to share.