For each branch to have DHCP redundancy, it will require splitting the subnet. Take the following example for Branch 1.
Subnet is 172.xx.45.0. The existing pool of addresses would be changed to 172.18.45.50 – 172.18.45.145. A new subnet would be created for 172.xx.45.146 and a new pool of available addresses would be created in the range of 172.xx.45.147 – 172.18.45.240. The newly created subnet would be assigned to a dhcp server at our corporate office. Once these modifications are made, dhcp services require a restart on both the Branch 1 and Corporate servers. It is normally recommended to use the 80/20 rule for subnets. This means that 80% of the available addresses go to the primary server and 20% to the secondary server. But since the largest branch has only 38 workstations, it should be safe to assign 50% to each since there are a little more than double available addresses to workstations.
While this configuration would not make up for a shortage of IP addresses should a large number of workstations be added, it will not make the situation any worse, either. If a server has no addresses left in its scope, it will simply ignore requests from clients for an address. When both servers are up and running, they can both reply to requests if they have available addresses. Likewise, when the servers run out of addresses, they run out. It is no different than how a single DHCP server would operate in this respect.
A dhcp helper address must be configured on the router at each branch to forward dhcp requests to the external dhcp server configured with the second subnet for that branch. Client machines multicast a request for an address. The local dhcp server receives the request and the request is forwarded by the router directly to the secondary DHCP Server. Since the server on the local network replies faster than the remote server, the clients should receive their addresses from the local server. Should the local server run out of addresses or crash, then it will no longer service the requests and the clients will receive their addresses from the remote server. Once the local server is back online or has addresses available, it will begin to service requests once more. The following diagram demonstrates this model.
It is extremely important that you insure without a doubt that SLP is functioning 100% via DHCP OR by setting static SLP settings in the Novell Client. It is also extremely important that under the novell client’s advanced settings, the Server be left blank. If the server name is filled in with the branch server name, the client will attempt to log into the client to that server. If the server is down, the client will simply fail. If it is blank, it will attempt login to the servers it receives from DHCP in the order listed. If the branch server is listed first and it is down, then the client will attempt login to the secondary server.
DHCP plays a vital role in the failover functionality for the services. The following options should be set in DHCP.
Authoritative yes Pool Options: 3 routers xxx.xxx.xxx.xxx 6 domain-name-servers xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx 15 domain-name acmeinc.com 78 slp-directory-agent xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx 79 slp-service-scope YOURSCOPE 85 nds-servers xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx 86 nds-tree-name ACME_TREE
Option 85 is the Novell Servers to log into in the order you would like for the clients to attempt login. The branch server’s address should be listed first.
Client DNS Redundancy:
Each workstation receives 3 DNS server entries. If one of the servers is down, it will go to the next, therefore, this redundancy is built into the manner in which the client resolves names naturally.
File Access Redundancy:
Each Branch Server has the user data rsync’d back to NWHQ-PRD-1 on a nightly basis. Should the branch server fail or become available, then the user drive mappings can be automatically switched to the NWHQ-PRD-1 Server. The manner by which the client determines which server to map to is by determined by the login server. The login server is determined from a list of servers given out by DHCP. If the branch server is up, it will be the first server in the list and the client will log into the branch server. If the branch server is down, the client will log into NWHQ-PRD-1. There is a built in login script variable called %FILE_SERVER. This variable is populated based upon which server the client logs into. Therefore, we can create directives in the login script like the sample that follows:
If %FILE_SERVER==LATL-PRD-1 Then map root U:=\\LATL-PRD-1\VOL1\USERS\%CN ELSE MAP ROOT U:=\\NWHQ-PRD-1\VOL1\ATLANTA\USERS\%CN END IF
This can be repeated for each drive to be mapped.
If a branch is down for an extended amount of time, then a “manual” reverse rsync should be performed to place the updated files on NWHQ-PRD-1 back on the branch server.
As a general rule, printing is not as much of a show stopper as the other items mentioned above. If there was a complete hardware failure of the branch server, and it appeared that there would be an extensive down time of more than 1 day, the servers could be reconfigured on another server and the users could manually install the printers through the iPrint Management web page on the new server for us until the branch server could be brought back online.