Forum Replies Created
-
Telium software uses “activation” to turn on the features you have paid for, and to prevent software theft (or pirating). In order to offer the greatest possible flexibility to customers, and minimize inconvenience, Telium offers four different activation types:
- Hardware Fingerprint: This type of activation is used by Microsoft Windows and is now the industry stadard. Telium’s software computes a fingerprint of your computer at the time of licensing, and that fingerprint is used to uniquely identify your computer. If someone copies the software and tries to run it on another computer then it will fail to start (since the fingerprints won’t match). This type of activation does not require any special hardware or access to the internet, and is suitable to emergency / public safety phone service operators, PBX’s on secure networks, stand alone physical servers, etc. Note that if your computer is not fingerprintable (eg: if you run the software inside a container or virtual machine) then this type of activation is not available to you. However, if you are running the Telium software in a commercial hosting environment (eg: AWS, Azure) then this option works perfectly (even though the cloud provider uses virtualization), and this option is ideal as Telium has worked with major hosting providers to ensure fingerprint consistency as your instance moves from host to host.
- USB Dongle: This type of activation uses a USB device (known as a “dongle”) which we courier to you after completing your purchase. Telium’s software will recognize the dongle plugged into a USB port and then start normally. If someone copies the software and tries to run it on another computer without the USB dongle present then it will fail to start. This type of activation is suitable to computing environments where hardware is not fingerprintable (eg: if your run the software inside a container or virtual machine), or where hardware changes frequently. You can still move your VM guest across different hosts by sharing your USB dongle over the network (eg: using usbip) – you do not need to plug the dongle into a particular host, but you can.
A USB Dongle looks similar to this:
- Cloud:This type of activation does not have any dependence on computing hardware or USB devices. Upon start the software will contact Telium’s servers in the cloud to request permission to run. So long as you are running only the number of licensed copies you have purchased then Telium’s servers will give permission to the software to start. This type of activation is suitable to computing environments where hardware is not fingerprintable (eg: if you run the software inside a container or virtual machine), or where hardware changes frequently. This type of activation is not suitable to emergency / public safety phone service operators since such environments are not permitted to depend on the internet/cloud in order to operate.
- Volume License Server: This type of activation does not have any dependence on computing hardware, USB devices, or the cloud. Upon start the software it will contact a Volume License Server (VLS) running in your data center to request permission to run. So long as you are running only the number of licensed copies you have purchased then the VLS will give permission to the software to start. This type of activation is best suited to customers running a large number of Telium products, such as Internet Telephone Service Providers (ITSP). Note that a Telium VLS must be purchased and installed separately.
Telium licenses are perpetual; in other words, they never expire. As a result you cannot change activation types after we have issued your license. (If we were to issue a second license with a different activation type then the second license could be used to run a second copy of the software.) Please be sure to select the right activation type when you initially request your license.
If you lose or damage the USB Dongle then you would have to purchase an entirely new license at full price. Be sure that software loss is included in your office fire/damage/theft insurance policy, so that you can replace your software in case of loss. The USB key contains a CPU with hacking detection (EAL 5+) and will lock itself after repeated hack attempts. A USB dongle which has been locked due to hacking is considered damaged and can only be replaced through purchase of an entirely new license at full price.
There are products which allow a Linux OS to connect to a USB dongle over a network/internet. Although such products (e.g. http://usbip.sourceforge.net/, https://www.eltima.com/share-usb-dongle-over-network.html) are not officially support by Telium, we have been told these work with our USB dongles.
It sounds like you want the local HAAst node to monitor the health of an external device. The way to accomplish this is with a HAAst health sensor.
At the simplest level I would suggest you create a sensor to monitor whether or not the device is responding to pings. For example, pasted the following code to /etc/xdg/telium/haast.conf.d/mydevice.sensors.conf
; Test if mydevice is reachable and responsive
network-connection/description=Ensure mydevice is reachable and responsive
network-connection/type=ping
network-connection/input=received
network-connection/parameters=count:3 | interface:ens1 | host:1.2.3.4
network-connection/scoring= =3:0 | =2:30 | =1:50 | :70
network-connection/warningscore=30
network-connection/errorscore=70
network-connection/resetcumulativescore=0
network-connection/interval=10
Restart HAAst and the sensor will become live. You should now see the local peer health score change based on the result of the above sensor.
I’ll explain the example more:
- The sensors pings the device 3 times through interface ens1.
- If 3 responses are received, then the health score for this sensor is 0; if 2 are received the health score is 30; if 1 is received the health score is 50; if none are received the health score is 70.
- If there is a warning from the ping (eg: no route) then a score of 30 is used. If there is a error (eg: ping cant run) then a score of 70 is used.
- The sensor runs every 10 seconds. (Since the ping command runs for 3-4 seconds that would be a 40% duty cycle).
- If the score ever returns 0, then the cumulative score for this sensor is reset to 0. Remember that each sensor’s score is cumulative, so it grows over time if the sensor keeps failing.
To make the above work, you also have to adjust your sensors settings in haast.conf If this is the only sensor in use then it is quite simple, but you may wish to create many such sensors to monitor other critical devices. In this case you could set your haast.conf settings as follows:
- criticallevel=70
- criticalresetlevel=40
- failurelevel=100
Note that the level settings in haast.conf check totals cores (across all sensors), and that individual sensor scores are cumulative. So in the example above missing 1 ping out of 3 each time the sensor runs will cause the sensor’s cumulative score to go 0 -> 30 -> 60 -> 90 -> 120. When it reaches 70 a critical alert can be sent (an event handler can run), and when it reaches 100 the local peer will declare failure and initiate a fail over.
As scoring tends to be more difficult to understand, here another example. The following graph shows the health score of the sensor over time (seconds). You can see from the blue boxes when a sensor starts (every 10 seconds), and when it ends (approx 4 seconds later). Based on the result of the ping responses (pongs), the number of packets received will cause a score to be calculated. The cumulative health score (in yellow) grows over time as the sensors detects missed pongs.
You can see at time 34s that all pongs where received and the cumulative score returns to 0. At time 64s the cumulative score has reached the critical level (70) and the critical event handler is trigger. At time 74s the cumulative score has reached the failure level and the node triggers the fail over process to the peer. Once the other node is active the local health score returns to 0 around time 84s.
This example is a simple ping test, but if your device offers health information through a REST API, telnet interface, etc. then you could create an even more sophisticated sensor.
I would suggest you experiment with disabling the ens1 NIC on your host, and watch the health score increase and then failover in HAAst. (Through the HAAst GUI or through the HAAst telnet interface). Once it works perfectly you could create similar sensors for HAAst on the other peer.
For example, if you copy the text below and place it into the file /etc/xdg/telium/haast.conf.d/network_cable.sensors.conf then you can test the sensors graph on the GUI. This sensors checks if the network connection on ‘eth1’ is down. If the connection is down the health score increases by 5 points. If the connection is up the health score remains unchanged for that cycle. (i.e. 0 health points).
If HAAst can’t read the NIC, then an error score of 20 is used. If HAAst can talk to the NIC but not extract a state then the warning score of 10 is used. If the sensors reports 0, then the cumulative score for this sensors is reset to 0. This sensor runs every 5 seconds.
So restart HAAst with this sensor in place and open up the graph on the HAAst GUI. Unlpug the network cable and watch your score, then replug the cable and see it reset to 0. If you leave the cable unplugged long enough and the health score reaches the critical level, then your cluster will fail-over to the peer.
; Test to ensure a network cable is plugged into the NIC, and that the cable is live (i.e. other end is plugged in)
network-cable/description=Cable plugged in
network-cable/type=nic
network-cable/input=state
network-cable/parameters=state:ethernet | interface:eth1
network-cable/scoring= =up:0 | :5
network-cable/warningscore=10
network-cable/errorscore=20
network-cable/resetcumulativescore=0
network-cable/interval=5
network-cable/debug=false
Yes HAAst can manage the power for other devices like amplifiers, radio equipment, etc.
Using the “event hander” system in HAAst, HAAst can control IP controlled power strips and UPS’s. By doing so HAAst can turn on power to these devices when switching to active, and power off these devices when switching to standby. For example, customers have used this Synaccess NP-05B IP Managed Remote Power Switch/Strip:
You will find 120v, 240v, 15A/20A, and more models depending on what you want to switch. APC and Tripplite sell a variety of these (called switched PDU’s) so I’m sure you can find one that meets your power requirements.
HAAst can even serialize power up (to avoid current draw spikes) as the devices are turned on. Please contact the support group (support@autocommander.aws2.ocg.ca) for further assistance.
HAAst includes approximately 18 “internal sensors” which are used to determine if the PBX and it’s environment are within normal parameters, and allow the PBX to properly offer telephony services. These sensors are used to assess whether or not the node can keep operating or must demote and let the peer take over. This is a binary decision (yes/no) determined by HAAst. This assessment and determination are made behind the scenes, and have nothing to do with the sensors graph in the GUI.
Aside from the internal sensors, HAAst also has the ability to monitor optional “external sensors”. These sensor are defined by you (the administrator) and can sense just about anything. For example, clients have used external sensors to measure:
- Performance of a network path: Counting pings lost from source IP to destination IP. This can be used to measure route quality, or even something as simple as sense an unplugged network cable.
- Calls in progress: Some large call centers never have less than X calls per second coming in from their carrier. If this drops to 0 it might mean an upstream carrier issue, 800 number failure, etc.
- Data center environmental temperature: If the data center room temperature exceeds X degrees HAAst can initiate a fail over.
- Custom: Anything from a contact closure (big red fail over button), to a local CRM systems being down, to power supply voltages out of range, etc.
Each of the above sensors turns an input value (number/string/etc) into a numeric value, which adds to the health score. That health score is what you see on the GUI’s sensors graph as show below. If the score reaches a danger threshold set by you (the administrator), HAAst can automatically run scripts or take some other action. And if that score reaches the fail over threshold, then HAAst will transfer control to the peer.
You can define as many or as few sensors as your like, and weight their scores as you like, to create a health scoring system meaningful to your environment. Similarly, you can set the critical and fail over thresholds to suit your needs.
Telium would be pleased to assist you in designing and setting up sensors. As well, we would be happy to create custom sensors to gather input from any device/service you wish (as a professional services project). We have interfaced with serial devices, thermostats, 1-wire networks, Bluetooth devices, and more.
Please remember that external sensors are completely optional and need to be tailored to your unique environment. Many clients run without any additional (external) sensors.
