Clustering aiScaler: United We Stand …
Posted by Max Robbins on October 25th, 2010Most web site deploy aiCache in multiples, for a number of reasons. Even if your site’s traffic doesn’t warrant multiple Aicache servers, you’re still advised to have at least two, so that one can go down or be taken down for maintenance, without affecting the site.
With more than one aiScaler server deployed, it makes sense to manages such collection of servers as a “cluster” – so that certain commands are applied cluster-wide, without having to repeat them on each server separately. Most noticeably, when we expire content on-demand, manually via CLI or Expire-Header response-driven expiration, we want to make sure requested content is expired on all of the aiScaler servers.
Likewise, should we ever need to place site into administrative fallback mode, we’d want each and every aiScaler server to go into fallback mode without having to do it at each server separately.
To support this type of behavior, aiScaler uses notion of a peer. When one or more peers are defined, aiScaler notifies all defined peers about both expiration and fallback commands – no matter how they were triggered, CLI or otherwise.
To enable and define peers, simply add one or more of “peer peer_IP [optional peer_PORT#]” directives in the global section of the configuration file. For example the following snipped defines 3 peers, all running on port 81:
peer 1.2.3.4 81
peer 1.2.3.5 81
peer 1.2.3.6 81
The port setting is optional, it defaults to port 80. So the following snippet defines same 3 peers running on standard port 80:
peer 1.2.3.4
peer 1.2.3.5
peer 1.2.3.6
To communicate expire and fallback commands to peers, aiScaler sends a specially crafted HTTP request to each configured peer. Peer request is identified by a special URI prefix with default value of “xaicachepeer”. You can change it via peer_prefix configuration setting in the global section:
peer_prefix supersecretpeerprefix
You might want to change it to your own string to safeguard peer commands. Clearly all of the peers must have peer_prefix setting set to the same value. Please make sure peer_prefix and stat_url settings are set to different values so that one is not a prefix of the other.
With peers enabled, aiScaler servers communicate with each other upon receiving expire and fallback commands. Proper messages are shown and/or logged on both the sending Aicache instance and receiving aiScaler instance(s). The command, command’s parameters, the sending aiScaler server and the receiving aiScaler server(s) are all identified.
The commands received from peers are not retransmitted, it is the sender that communicates to each defined peer via a one-to-many communication. You can have aiScaler identify it’s own IP address as a peer – in case you want to maintain the same, bit-for-bit identical aiScaler configuration file on a number of aiScaler servers.