Forum Replies Created
-
AuthorPosts
-
in reply to: OK to use rsync or NFS share for cluster data #6688
You are welcome to use rsync,NFS,samba, etc. in your cluster. However, we generally recommend keeping data on each peer and allowing HAAst to control all synchronization, and here’s why:
- HAAst only synchronizes data between peers if peers have passed a health check. That means if one node is failing and starts to accidentally corrupt data, it will not be copied to the other peer! Tools like rsync, NFS, DRBD, etc. will immediately share/mirror all data including, corrupt data.
- By allowing HAAst to control synchronization, the HAAst event handler system will allow you to customize inbound data following a synchronization (e.g. update trunk information, modify the dialplan, customize TFTP files for the local network, etc)
You should not place databases on any block level sharing device (NFS/SAMBA), or do block level mirroring (DRBD,iSCSI), as corruption by one peer will destroy the database for the other peer! Even worse, a failure midway through a write will corrupt both peers! Note that HAAst performs SQL transactions (not block level access) for database synchronization, so even if a peer fails midway through a database write neither peer will be left with an invalid database state.
The one exception to this rule is if you need to archive a high volume of files, or very large files, that are written once and thereafter only read. A perfect example of this is call center call recordings or logs. A call center can easily generate gigabytes of recordings every minute, to be referenced in the future in case of dispute or for quality assurance. Since these are large files written once and then archived, they are the perfect example of data that should be written to a server share, common iSCSI device, etc. It would not make sense to generate the high network load and disk load required to continually create a second copy of this data.
in reply to: License violation but no calls in progress #6687The fact that the license violation occurs close to the time of a log rotation is a red herring (no relationship).
SecAst does not track calls in progress; it asks Asterisk to report the number of calls in progress. You can perform the same query from the command line:
asterisk -vx ‘core show calls’
So the question is why is your Asterisk installation reporting 8 calls in progress. This can be due to:- Valid users making calls in or out
- Valid user starting the conference feature
- Incoming callers leaving a voicemail
- Automated calls
- Hackers calling in to probe your dialplan
- Asterisk incorrectly not releasing channels
- Dialplan errors
If the number of calls reports higher than you expect, you can delve deeper into the calls in progress using a command like:
asterisk -vx ‘core show channels’If you are using FreePBX then Sangoma recently started making automatic calls in the background to set ‘time condition’ variables. In essence FreepBX is making invisible calls, and Asterisk will report these as calls in progress; nothing we can do about it, and that won’t explain 8 calls in progress.
So…in a nutshell SecAst does not count calls – it gets that number from Asterisk. Something else is going on with your Asterisk setup. Repeat the first command above once every 30 seconds and watch if your ‘calls processed’ count is increasing even when users aren’t making calls. That should help you figure out why Asterisk is reporting a count you don’t expect!
And now the bad news…it sounds like you’re struggling with some basic Linux admin and Asterisk admin tasks. If this is a commercial installation I would recommend purchasing 2 hours of support so we can help you through setup. If this is a home installation you probably have a big learning curve ahead of you in terms of Ubuntu and Asterisk – I’m not sure if it’s worthwhile for you to continue but we can’t really offer free support for Asterisk (or Ubuntu). I’m not sure if you are using a configuration generator either (you don’t offer any details of your system), but if this is a commercial installation you may want to move up to a package like xCALLY which provides a very professional turnkey solution without many of the headaches involved with many smaller packages (you don’t need to know anything about Linux or Asterisk).
in reply to: Thank you! #6686You’re very welcome. It was a great project, and I’m glad we were your partner for this important project.
in reply to: Which peers takes over when cluster reassembles #6685When the peers are in a state of dual-active contention one of the peers is considered improperly active (invalid state). In other words, it should not be processing calls at all. Usually trunks (E1/T1/SIP/IAX/etc) are forced to one peer or the other which means one peer will not be getting (more) calls. If your configuration allows both peers to handle calls simultaneous then you are in the minority (this is not typical).
For this reason the number of active calls is not a criteria in determining which peer to demote.
in reply to: Which peers takes over when cluster reassembles #6683When the cluster reassembles HAAst will discover 2 peers active (called ‘dual-active contention’). HAAst will then try to pick the peer with the lowest likelihood of long-term success (probability of staying active) and demote it. The determination of which peer is least likely to succeed considers:
- Which peer caused the previous failover
- How many failures has each peer had
- How long has each peer been running
- What was the last health score of each peer
- And more…
This works well when the peers are configured as equals (primary/primary), which implies that the cluster would be happy with either peer running. However, when the peers are not configured as equals (primary/backup), the determination of which peer should demote may result in the backup server remaining active. This describes the situation you encountered, and this is normal behavior (by design).
As of version 2.3.2.14 the administrator can override the demotion decision, ignoring the criteria listed above. If the ‘autodemote’ key is set to true in the [backuprole] stanza of either peer, then HAAst will always demote that peer.
in reply to: Peerlink fails for PBX’s in AWS #6682The peerlink error means that the two peers are unable to talk to one another. This is most likely due to Security Group misconfiguration within AWS. As a simple test, try to telnet from one peer to the other peer on port 3002; for example:
telnet 10.1.2.3 3002This command will likely fail/timeout, which confirms the Security Group misconfiguration. To resolve this, and assuming both peers are in the same Security Group, and iptables/firewalld is disabled, set that Security Group to allow “itself” traffic on all ports (in AWS). After doing so the peers should quickly find each other and the Peerlink indicators in the GUI will turn green.
If you decide you want the highest level of security possible, only enable destination port 3002 TCP access between the peers (plus ports needed for file/directory/database sync as optionally defined in your haast.conf). But if the peers are in the same Security Group you should be fine allowing all traffic.
No. Split brain usually refers to a mirrored file system (e.g.: DRBD) in which the two sides have gone out of sync. Proper recovery from split brain usually involves manually choosing which files to keep, one file at a time (or risk losing all data from one side if you blindly accept once site as correct). Since other products use block level mirroring, an interruption in the mirroring can leave files/databases in an inconsistent state and prevent Asterisk from starting or operating correctly.
HAAst on the other hand does not use a mirrored file system. In fact HAAst is the only HA system for Asterisk that does not use block level mirroring. HAAst synchronizes files/directories/databases/tables from Active to Standby only, and only when the peers are both confirmed healthy. Files use differential analysis and compression to send only changes, and databases use SQL level transactions to ensure databases are always in a consistent state.
With HAAst data is not sent if a node is detected to be in an unhealthy state, so potentially damaged files/databases are never sent to the other peer. Once a node recovers from a failure, the data from the healthy node will be sent to the recovered node to bring it back into sync. You will never have a split brain scenario with HAAst.
If that didn’t answer your question please provide more details.
in reply to: Where should I block attackers #6680No. The best place to block attackers is at the network edge; i.e. at your firewall.
Although SecAst supports using iptables to block IP’s at the PBX, it does so primarily for testing / prototypes / proof of concepts etc. In general you should not allow attackers that far into your network.
SecAst is designed to block attackers at the firewall, and is compatible with most firewalls through its event handler system. SecAst includes a sample event handler for the ‘Mikrotik’ and ‘pfSense’ firewalls, and these scripts can be modified for most other firewalls. We also invite customers to submit their firewall event handlers to become templates for other users.
The answer to this question depends on the specific product you are referring to. However, here are some points to consider:
- Most manufacturers require that only a single copy of a license be in use at one time. Since HAAst keeps only one Asterisk peer active at a time, you should be ok keeping the same license on both computers peers at once and remain compliant.
- Some manufacturers require that only a single copy of a license be installed at once. Using the pre-start & post-stop event handlers you can move the licenses into place before Asterisk starts, and out of place after Asterisk stops, and remain compliant.
- A few manufacturers require that you purchase a license for each host regardless of whether it is used for standby/clustering/testing/development/etc. However, most manufacturers will offer such a license at no/minimal charge.
When you evaluate licensed products for purchase, the above should be one of your evaluation criteria. Most manufacturers are reasonable and recognize that charging for a standby license is excessive – and only antagonizes their customers. Still…we know of one manufacturer in particular that takes a rather hostile view towards their customers and expects a full price license even for standby servers. In some cases you may find open source alternatives that help alleviate unfair license restrictions (for example see: https://autocommander.aws2.ocg.ca/topic/g729-licenses-invalidated-after-cluster-failover/)
Note that SecAst (Security for Asterisk) includes a second no-charge license for use in a HAAst cluster; so one license covers 2 peer installations.
Please note that the above is not legal advice – you should check with your legal counsel for all matters of license compliance, etc.
-
This reply was modified 4 years, 11 months ago by
WebMaster.
in reply to: G729 licenses invalidated after cluster failover #6678The most likely cause is that you have incorrectly configured synchronization between your peers; you are mistakenly synchronizing the G729 license files which is causing Asterisk to refuse them. First, take a look at the Asterisk (full) log to look for G729 related errors on startup – you will likely see one relating to a hardware change.
Digium stores the G729 license files in the directory /var/lib/asterisk/licenses. Be sure that this directory is excluded from HAAst synchronization. If you are synchronizing a parent directory then you must exclude this directory; for example:
; Asterisk support
elastix-astsupport/description=Asterisk support
elastix-astsupport/type=directory
elastix-astsupport/directory=/var/lib/asterisk
elastix-astsupport/excludepattern=lost+found | licenses
elastix-astsupport/interval=3600
elastix-astsupport/compression=9
elastix-astsupport/debug=off
elastix-astsupport/postsynccondition=never
elastix-astsupport/recurse=trueAlternatively, some companies choose to use open source G729 codec implementations which are not encumbered by Digium’s licensing, as outlined on web sites like this http://asterisk.hosting.lv/ . Many people don’t realize that the g.729 compression algorithm is not protected by copyright (expired patent was held by Intel), though Digium’s implementation is patented (and the fee is for licensing their implementation). Please note that you should check with your own legal counsel to determine if the open source G729 codec can be used in your jurisdiction without requiring royalty payments.
in reply to: Support hours #6630Support hours available to you depend on the edition of HAAst you are using, whether you have an active maintenance agreement, and whether you have a 24/7 support contract:
- All users: Telium offers self-serve forums for users of non-commercial and commercial editions of its products. These forums are monitored by Telium support and questions are answered on a best effort basis.
- Maintenance Agreements: Telium offers e-mail support during business hours for users with an active maintenance agreement. Telium business hours are 9am-5pm Eastern time, Monday to Friday (except holidays). Typical response times are under an hour, and typical problem resolution is less than 30 minutes. Telium may also respond up to 11pm Eastern time on weekdays, and anytime on weekends – depending on whether an on-call support rep was already activated for a 24/7 Support Contract (and answers outstanding questions before wrapping up).
- 24/7 Support Contract: Telium offers 24/7 support for users who have a 24/7 support agreement in place. Support is offered by phone / skype / teamviewer / email / chat / etc, and includes rapid callback from the account manager / support lead / on-call technician (depending on time of day). Typical response times are under 20 minutes, and typical problem resolution is less than 30 minutes. Note that remote desktop connections are only for simple viewing/assistance, not complex work or complete installations.
So if it’s 2am Pacific time and you don’t have a 24/7 support contract in place then your only course for immediate support is the online forums.
Please note: If you are doing an installation and would like to book assistance from Telium professional services outside of normal business hours, we would be happy to work with you anytime from 8am to 2am Eastern time to perform your installation.
in reply to: License file rejected due to hardware change on AWS #6677On Dec 15 2016 Amazon made a change in how they present their hardware to licensing applications. Our license library vendor is aware of the change and has already provided us with an update.
If you encounter this problem on AWS please contact support for an updated product and license.
(Your product must be covered by a maintenance agreement for any product updates / new licenses. If you do not have a maintenance agreement in place please contact AWS support and ask them to return your image to the previous platform/version).
in reply to: Saving license file from Windows to Linux #6676The license file contains a ‘signature’ to verify the license has not been changed. You are inadvertently changing the license file; there are subtle differences between Linux text files and Windows text files. (In particular, Windows uses CRLF while Linux uses CR only.) You don’t need to know the details, but even opening the file in Notepad and then saving it again is changing the file!
This time go to your mail client and save the attachment directly from the message (without opening in Notepad) to the PBX. Your license should then work fine.
in reply to: firewalld support #6646Yes. Many people don’t realize ‘firewalld’ is not really a firewall, so much as it is a group of functions which apply iptables rules to the local system. (It offers nothing beyond iptables rules). You can tell SecAst to continue to work with iptables directly, or, you can tell SecAst to treat firewalld as an external firewall and use the firewalld event handler provided by Telium.
However, we generally recommend that you block traffic at a real firewall, and not at the PBX. Support for local iptables is offered primarily for SOHO users or people experimenting with Asterisk. By the time a PBX is ready for production you should let SecAst block IP’s at the firewall.
We include sample event handlers, for example the Mikrotik firewall interface. If you use this event handler as a sample you should be able to interface with almost any firewall. If you need help getting your own firewall event handler working just contact support. Once your firewall event handler is complete please consider donating it to the collection of scripts included with SecAst.
in reply to: Can’t start Asterisk exit code 158 #6675Exit code 158 means that HAAst is unable to find the service/executable file needed to control Asterisk. Since you installed Asterisk from source, I assume you are not using any configuration generator (eg: Elastix) as well. If that’s the case then the ‘distribution’ setting in the [asterisk] stanza of the haast.conf file should be set to 2 (Digium Asterisk). Confirm that setting – then proceed to the steps below if the error remains.
Next ensure that you installed an Asterisk service file appropriate for your Linux distribution. Most recent Linux distributions have switched to systemd, which requires you use an asterisk.service file. If you are using an older Linux distribution then you require a SysV / initd style service file.
While Asterisk includes a sample SysV style service file for Asterisk, it might not include a systemd style service file just yet (as of Dec 2016). You can find one by searching the Digium support forums, but here’s an example you can use:
[Unit]
Description=Asterisk PBX and telephony daemon
Documentation=man:asterisk(8)
Wants=network.target
After=network.target
[Service]
Type=simple
User=asterisk
Group=asterisk
ExecStart=/usr/bin/asterisk -f -C /etc/asterisk/asterisk.conf
ExecStop=/usr/bin/asterisk -rx ‘core stop now’
ExecReload=/usr/bin/asterisk -rx ‘core reload’
[Install]
WantedBy=multi-user.target
Save the above as ‘asterisk.service’ and place it in /etc/systemd/system/ and set file permissions to 755. Don’t add restart directives (like you might find on the internet) since HAAst should be responsible for restarting Asterisk when necessary. You will also have to tell Linux about the new service file with the ‘systemctl daemon-reload’ command (or similar depending on your Linux distro).
If you want to use the SysV / initd style service file that’s ok too, but you’ll need to tell HAAst which style of service file you are using. To do so contact Telium support and we will provide you with details specific to your Linux distribution. (But in general if your Linux distro uses systemd, stick with systemd service files).
-
AuthorPosts
