Home Forums HAast (High Availability for Asterisk) Configuration & Optimization Optimal configuration and synchronization interval Reply To: Optimal configuration and synchronization interval

Avatar photoTelium Support Group
Post count: 262

By design HAAst does not use disk mirroring (e.g. DRBD) or disk sharing (e.g. NFS, SMB, iSCSI). The reason is that with these protocols file corruption on a failing peer would immediately corrupt files on the other peer, and thereby destroy the entire cluster.

Instead, HAAst brings the peers into sync at regular intervals. These intervals should leave enough time for HAAst to detect if a peer is failing, and then prevent synchronization if a peer is unhealthy. Do not use short sync intervals to simulate a mirrored disk (that defeats the benefit of this design).

So your sensor intervals and sync intervals should work hand-in-hand. Keep in mind that HAAst’s internal sensors run at 0.5 second intervals, but external sensors (which you define) can run anywhere from seconds to hours apart. If you are only using internal sensors then synchronization no less than 15 seconds apart is usually sufficient (but 15 seconds is unusually low/short). If you are using external sensors then set your synchronization intervals to no less than 1/2 the sensor interval time. As well, set your sync intervals to non-multiples of one another; for example, 1,2,4 minute intervals are sub-optimal (as syncs will overlap), while 2,5,7 minute intervals are better (less chance of sync overlap).

As well, set your synchronization intervals to match the value of the file/data being synchronized. For example, it doesn’t make sense to synchronize a MySQL database every 10 seconds if it only holds configuration data that might be changed once per day. Or, if you have a very large AstDB file (eg: 10,000 FreePBX users and devices on the host) then ensure your sync duty cycle is less than 30%; for example, if it takes 30 seconds to sync your AstDB then set your sync interval to no less than 90 seconds.

Your interval settings need to balance the benefit of keeping both peers in sync quickly, with avoiding cluster failure in the event of file corruption, and adding too much load to a host. There are of course exceptions to every rule, but the above should serve as a guideline.

The bottom line is NO – don’t make the interval as short as possible. When Telium is engaged to setup a cluster we usually set intervals in minutes (not seconds), other than for unusual circumstances.