Высокая доступность для Звездочки

Часто задаваемые вопросы о HAAst

ХААСТ

»

Вопросы и ответы

Теме

Часто задаваемые вопросы

Yes, it's called the Free Edition, and is suitable for companies wanting to test if the basic product functionality & compatibility meet their needs. In addition, the Free Edition is a functional and useful high availability add-on for SOHO environments, more capable that any other DIY scripts, etc. You can download the Free Edition directly from the Downloads tab. If you need help during installation you can post your questions on the support forum. (Telium support staff check and respond to forum questions at least once per week).

If you require access to the advanced features of the Commercial Edition we offer a time limited trial package which consists of an Unlimited trial license and support to help you get up and running (priced at 50% of the Unlimited).
No. Support is reserved for paying customers only. If you are doing a proof of concept (POC) then we recommend downloading the Free Edition of HAast and purchasing 4 hours of Telium support for your POC, which will allow us to support you just as if you had purchased a full commercial license. If your POC is successful then this investment can carry forward to your production environment since there is no difference between the Free and Commercial Editions of HAast in terms of setup and configuration. If the Free Edition meets your needs and you are just looking for some help or advice during installation and configuration, then please visit the support forums. You might find the answers to your questions are already there.
One. A single HAast license applies to a pair of servers, so if you buy a single license you can install HAast on 2 servers (creating a clustered pair). It should be noted that the 2 servers can be configured as equals (either server can remain active) or as primary/backup (one server is only a backup and must return control to the primary when possible).
In order to keep HAast's price to a minimum, the product can be licensed by the "line". A line is equivalent to a call in progress. So if your PBX will never have more than 5 calls in progress at once, then you need only purchase 5 lines; if your PBX will have 20 calls in progress at once, then you need to purchase 20 lines. If your call volume will reach 50 calls in progress at once, then you can purchase the Unlimited edition instead, and not have to worry about call volumes. Note that the 'flex' edition of HAast introduces some other limitations to keep the edition price to a minimum.
HAast can use various mechanisms to help upstream and downstream devices (eg: phones, trunks) find the active server. First, HAast allows two peers to share a single IP address, so failover is transparent to downstream and upstream phones/peers. They automatically reregister with the same server IP address (or DNS name) and don't notice the changeover at the server. Similarly, when the new server takes over it reregisters itself with upstream ITSP's/peers and so incoming calls work immediately. Second, HAast can automatically updates routes, redirect traffic at switches/routers, update DNS entries, etc. allowing a single IP to be routed to separate peer IP's. Third, HAast can move an entire subnet between peers/sites allowing traffic to continue to the same IP transparently. Fourth, you can use DNS SRV records to help compatible phones find the HAast peers and register with the active peer. For more details please see the support forums.
No. HAast does not use any shared hardware, software, logical devices, etc. This design meets the most stringent of standards such as those demanded by 911/PSAP call centers. Inexpensive/do-it-yourself solutions use shared storage (eg: SMB,DRBD,NFS,iSCSI) to share a logical disk between peers, but this means that disk corruption caused by one failing peer immediately corrupts the data of other peer. Similarly, some simplistic solutions share a channel bank (eg: Astribank) between peers, but failure of the channel bank immediately brings down both peers. HAast does not use any shared devices, and only replicates changes between peers once the peers have passed health checks.
No. But you can if you want to! It's important to understand that load balancing and high availability are separate but related concepts. For example if you need to distribute calls to 10 different call centers using round robin, then a load balancer function is required. Then, if you wish to provide high availability within each call center, HAast is required at each call center.

Since a load balancer creates a single point of failure on the call path, many companies are replacing the load balancer with another pair of Asterisk servers. This pair will route the calls (reinvite) using intelligent rules on load, queues, round robin, etc. The advantage to this approach is that this Asterisk pair can be HA as well, avoiding the single point of failure.

HAast can work happily with load balancers (eg: LoDi, Kamailio) or without. The issue of proper design is beyond a simple FAQ; Telium would be pleased to provide design assistance on a fee for service basis.
A load balancer performs a different function from high availability / clustering. A load balancer distributes calls over multiple destinations, applying rules for load, sequence, etc. A load balancer does not monitor the health of peers, synchronize settings or call data, transfer control based on network route availability, etc. A load balancer can remove a PBX from the destination group if the PBX disappears completely, but it has no way of knowing if/what/how the destination PBX is able to handle the calls or even assess the health of the destination PBX.

HAast on the other hand creates a high availability cluster out of a pair of Asterisk servers. It monitors the health of the servers, neighbouring devices, network routes, the ability of the PBX to bridge calls, etc. If a peers does not meet the health requirements then control is handed to the peer, and all configuration and call data is synchronized with the peer. HAast does not distribute calls to multiple PBX's like a load balancer does.

High availability is often used in conjuntion with load balancing in very large deployments but they are not viewed as alternatives. HAast has been combined with load balancers in large scale deployments and we can provide more details or design assistance if you require.
Yes, HAast can be extended to test almost anything that offers an API/CLI/ReST interface, etc. This involves a custom event handler and can be created by the client or by Telium as a custom development project. Note that this custom sensor feature is only available in the Unlimited edition of HAast.
Yes. Unlike simplistic 'clustering' solutions, HAast allows pair members to be any distance apart. HAast does not use any LAN-centric protocols like NFS, DRBD, SMB, etc. which break down over WAN's or variable latency networks.

HAast is ideal for remote backup data centers and cross-state/country/continent disaster recovery centers. HAast automatically adjusts to compensate for high network latency, server responsiveness, connection variability, etc. to prevent accidental failover due to geographically distant peers.
There are many ways to handle this, but our clients have had success using PRI-to-SIP converters (eg: Digium and RedFone), or network / PC controllable AB switches (eg: beroNet 'berofos' failover switch, Electro Standards Laboratories 'Path Way' switch).
There are many ways to handle this, but our clients have had success using Analog-to-SIP gateways (eg: BeroNet FXO VoIP Gateway), or PC controllable A/B switches (eg: beroNet 'berofos' failover switch, Electro Standards Laboratories 'Path Way' switch). For best results use an Analog-to-SIP gateway, particularly if in an area with older Telco switching equipement.
The time from failure detection on one peer until Asterisk starts on the other peer is normally 0.5 seconds. After Asterisk starts on the other peer the system becomes operational once it has loaded your hardware drivers, asterisk settings, etc. which can take several seconds. A typical failover on a properly sized machine is under 7-15 seconds from detection until the peer has completely taken over. However, some Asterisk modules like chan_pjsip may delay startup by up to 30 seconds.

If failover exceeds 30 seconds you may have hardware performance issues, peripheral device driver loading/unloading issues, etc. We cannot guarantee a failover time for every possible hardware and software configuration but the above should serve as a reasonable guideline. If you need assistance optimizing your failover time (or simply diagnosing the cause of failover delays) we would be pleased to assist you through our optional hourly support services.