Telium Support Group

Glad you are up and running. If you need SecAst to recreate its iptables rules just restart the SecAst service (it will restore all banned IP since it keeps those in a recovery file). We’ll have to think about how/if SecAst should monitor the iptables. It’s unusual for the iptables rules to be lost (so SecAst shouldn’t have to check that) – but it’s on our discussion list.

In regards to downloading, what error exactly are you experiencing? (Corrupt download, or download won’t start, etc). Downloading by browser is often unreliable for large files, but FTP normally works perfectly. We just tried FTP (pull) and the file downloaded perfectly (no corruption, etc). We also tried downloading with Firefox version 53 (32 bit) and browser download worked fine 2 of 3 times (one time download was corrupt so it would not untar). Similarly downloading by Chrome worked 3 of 4 times. You can see why we offer FTP…browsers aren’t great for this kind of thing. (Since this is a different topic feel free to email support@autocommander.aws2.ocg.ca if you have more details on file transfer issue)

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.

The automatic upgrade feature of FreePBX poses a number of risks to your system, including changing the cluster members to incompatible states. Telium recommends that you disable the automatic upgrades and only perform upgrades following the steps outlined in the HAAst operations guide (see https://autocommander.aws2.ocg.ca/topic/upgrade-to-configuration-generator-freepbx/).

Aside from risks to the cluster, configuration generators sometimes release updates that break the PBX (only to be fixed by updates a week later). Many commercial installations using configuration generators avoid updates altogether, unless absolutely necessary (for a feature or security update). Even then, updates should be carefully tested before being promoted to production servers.

In our experience most mid to large Asterisk(TM) installations do not use configuration generators, so this problem will primarily affect home office and small office users.

• This reply was modified 4 years, 9 months ago by WebMaster.

If you are willing to accept the risks of placing new single points of failure in your call path, and you are not using the OEM edition of HAAst (which includes call survival features), then yes you still have options. The key to this solution is to ensure directmedia (RTP flowing directly between endpoints). It’s also quite likely that your endpoints will expect to see the SIP channel responsive as well (or they may drop the call).

Establishing directmedia involves:

• Ensuring the media anchor points are accessible to one another without NAT.
• Ensuring Asterisk is configured to use re-invites/directmedia
• Ensuring your Asterisk dialplan does not force Asterisk to remain in the RTP stream
• Ensuring your endpoints do not require transcoding (performed by Asterisk)

Optional: ensuring the SIP endpoints continue to see active SIP connections involves:

• Placing a B2BUA (or gateway/proxy/SBC) between endpoints and the cluster – this device must place itself into the SIP stream and optionally allow NAT traversal
• Configuring the B2BUA to allow the interior leg of the SIP call to drop, but keep the outer leg of the SIP call to remain active
• Configuring the B2BUA to use UDP for SIP (at least for cluster facing leg). This is not always required

For example (this shows two B2BUA’s for clarity, but you can adjust to fit your need):

There are open source B2BUA products which might be modifiable to do what you want (eg: the SIPpy project available at: https://github.com/sippy/b2bua). Keep in mind that you are creating a free version of the commercial solution we do not recommend. If this is a critical call center you may be better off developing a proper B2BUA from scratch to do what you want, including moving calls through the new active HAAst node, etc but that is a large undertaking.

HAAst OEM edition creates a call anchor on the PBX, so that even if Asterisk fails the calls don’t drop. HAAst will move the calls to the other node in an orderly fashion (move by IP or SIP redirect), or HAAst will grab the calls by force should the entire PBX server fail.

• This reply was modified 4 years, 9 months ago by WebMaster.
• This reply was modified 4 years, 9 months ago by WebMaster.

Although it’s not listed on the website, we do offer a special Commercial Unlimited edition license to be used only for preproduction / testing environments. This license includes all functionality of the CU edition, but is limited to 5 simultaneous calls. This license is 1/2 the price of the regular CU edition, and optional maintenance agreement (for updates) is also 1/2 price. Please contact support@autocommander.aws2.ocg.ca with your current customer number to purchase this license. (This version is only available to customers with at least 1 CU license).

If your customer wants to run a high volume of calls over the testing system then they would have to buy a full CU license. We don’t distinguish between testing and production systems if both need full features and full call volume. (We also have to prevent license fraud – so a full license has to be full price).

Since the Peerlink protocol verion has changed, the peers will not be able to talk to each other (over Peerlink) until both peers are upgraded. So if both peers are online at the same time they will not be able to communicate – and both peers will try to take over as active. Consequently, your upgrade procedure must ensure both peers are NOT online at the same time.

Since the license version has changed, you will need to request new licenses from Telium. To avoid bringing down the entire cluster you should upgrade and re-license one peer at a time.

The overall steps to performing such an upgrade are:

1. Upgrade A
   1. Stop HAAst on peer A, wait for stop
   2. Run the install_files/updatefiles.sh script from the newly downloaded package
   3. Unplug the network connection from A
   4. Restart HAAst on peer A
   5. Request and apply new license to A if required, then restart A
2. Switchover
   1. Stop HAAst on peer B, wait for stop
   2. Replug the network connection to A, ensure A takes over as active
3. Upgrade B
   1. Run the install_files/updatefiles.sh script from the newly downloaded package
   2. Restart HAAst on peer B, ensure cluster forms
   3. Request and apply new license to B if required, then restart B
4. Fallback to preferred peer (optional)
   1. Use the telnet/web interface to make the preferred peer active. (Or wait for automatic fallback during the maintenance window if enabled in the haast.conf file)

The answer depends on the location of your two PBX’s. If the PBX’s are located in the same data center (i.e. using the same external IP address), then no change is necessary as they will connect to the same IP address. If you need to modify your firewall/router internally to direct traffic to the active peer then see the answer to the question on locating the PBX for internal phones. On the other hand, if the PBX’s are located in different data centers (i.e. accessible using different public IP addresses) then your options are:

1. SRV records: Assuming your user agents (phone sets) support SRV records (which most do), then you should create SRV records for your two PBX’s. Most user agents will perform a DNS lookup for SRV records to find available PBX’s, and try them in order of priority until they successfully register with a PBX. For example, if you have PBX’s located in data centers dc1 and dc2, then create to DNS entries (in your public DNS server) as follows:

   
type=srv
name=_sip._udp.mydomain.com
priority= 10
weight=0
port=5060
hostname=dc1.mydomain.com

   
   and
   
type=srv
name=_sip._udp.mydomain.com
priority= 20
weight=0
port=5060
hostname=dc2.mydomain.com

2. DNS update: Use the pre/post asterisk start/stop event handlers to update a public DNS entry. Be sure to set the TTL value low enough that phones will lookup the new IP in a reasonable timeframe.
3. MPLS: If you use MPLS then you can simply move the label (to move IP between routers of your two DC’s). We don’t provide any further detail on this option (i.e. if you don’t understand how to do this with MPLS, then there’s too much to explain in one post)

Note: Using SRV records or DNS entries makes it easy for users with softphones to move on and off LAN and resume a PBX connection without manual intervention.