WorkSite application architecture is mainly a client-server communication. The client (FileSite or DeskSite) communicates only with the WorkSite Server. The WorkSite server then delegates requests out to the SQL Server, the File Server, and the Indexer to fulfill the client’s requests.
This product design provides scalability: but it also adds complexity and scenarios for possible failures.
DNS Alias reduces pain of connection change
Luckily, an administrator has some configuration options that reduce the pain of changing these connection points – whether it’s because of a planned update, or an emergency replacement. Define a DNS Alias to represent the intended server, so that swapping in a new server only requires updating the alias with a new target. With the new target in place, your internal network’s Domain Name System itself re-routes the request to the replacement.
Setting it up
There are four servers suited to this type of indirection: the WorkSite server, the database (SQL) server, the file server, and the indexer.
There are several types of DNS entries that can be created. For the purposes of this post we will focus on two, A records and CNAME records. An A record is something that matches a machine name with an IP address. These are the most common records created in DNS and is what is created for every machine and server on a domain. A CNAME record serves as an alias or shortcut to another machine.
Typically A records are used for the DMS as you’ll likely have multiple and want to reference them in some sort of Round Robin. In the above example, you would create two A records, each called FirmDMS and point each record to a unique IP of a DMS. CNAMEs come in handy when you have multiple machines that serve the same role. In the above example, we have FirmIDX01 and FrimIDX02. Let’s say these servers are independant servers indexing side by side. The DMS server points to an active indexer, but needs to be able to fail over to the other indexer should the need arise. In this case, we create a CNAME called FirmIDX and point it to FirmIDX01 (the active node).
The third and most important element in this process is the Time to live (TTL) value for these records. The TTL value determines how often a client machine will check in with DNS to see if the record has changed. By default, the TLL for all entries is 1 day (24 hours). If we don’t modify this value, that means that the server will cache the DNS entry for 24 hours before checking back in with DNS to see if there is a new value. …. [Instead] I commonly recommend one minute or less..