Wednesday , 26 October 2016
Breaking News
Home » Internet » Many services have failover or high-availability capabilities

Many services have failover or high-availability capabilities

Configuring Failover Services

To have a backup server take over the services of a failed master requires additional instructions. The instructions in “Configuring Failovers” simply bring a backup server on-line in place of a failed master; there’s nothing that makes it take over for services configured on the master.

Many services have failover or high-availability capabilities built in, and wouldn’t need to rely on the Apple IP Failover scheme. For instance, Open Directory has a Master and Replica configuration that provide a high availability configuration. MySQL has facilities for replication and may be better served by its native failover capabilities than by trying to use the Apple IP Failover.

Typically, good candidates for Mac OS X Server in an IP failover pair are services that do not fail over on their own. The specific service will determine how it should be configured. Generally, the master and backup in the pair will need some common storage to maintain state.

The following example uses AFP. For services other than AFP, you need to become familiar with the service, determine if server-based failover is appropriate, and plan a method for the backup server to take over for a failed master.

In the case of network disconnect, AFP can allow initially authenticated clients to reconnect to the server using a reconnect token rather then reauthenticating with user credentials. The reconnect token contains information that allows the server to verify session and user data on the server. When the client initially logs in (using user credentials), the server sends the client a reconnect token. This token is encrypted with the server reconnect key located in /etc/ AFP.conf and is only readable by the server.

Following a disconnect of an established session, the client attempts a reconnect by sending the reconnect key to the server. The server decrypts the reconnect token using the server reconnect key. Then the server verifies that it is a valid, authenticated session token, by verifying data in the reconnect token with data on the server (for example, user data obtained from the user record). When the information is verified, the server completes the reconnect. In the case of failover, the server reconnect key used to initially encrypt the reconnect token handed to the client must be used by the backup server to handle all reconnects. By default, the server reconnect key is stored in /etc/AFP.conf. This file must be placed on a shared storage that both servers can access.

The path to the key is specified by the reconnectKeyLocation attribute value, found in the preference file /Library/Preferences/com.AppleFileServer.plist. Changing the value of reconnectKeyLocation in the server preferences file ensures that both servers use the same reconnect server key.

About Emma G.

Working in the marketing industry since 2002. This blog is one of my hobbies.

Leave a Reply