Forum Replies Created
-
First of all, AWS Lightsail has hidden access to some features that you will need to make this work, so you will instead need to setup a couple of EC2 instances. Since you want to share a VoIP NIC (shared IP) between nodes, your two nodes must reside in the same region but can reside in different Availability Zones (AZ’s).
Since (in most configurations) each node will have two IP addresses, and each address cannot be in the same subnet as the other (basic routing limitation), you must create 2 subnets within your VPC. If you want your two nodes to reside in separate AZ’s, then you will have to create 2 subnets per AZ (since subnets cannot span AZ’s). You might have to manually ad private IP(s) to NIC(s) in Linux depending on your design. You must then setup a security group encompassing both nodes, which allows SSH traffic into the management IP, and VoIP traffic in/out of the VoIP IP.
And finally you have some choices around how many NIC’s and public addresses your want in your setup. The more you want, the more complex the setup. We have created four basic designs you can chose from (but there are more):
- Dual NIC, Dual public IP
- Single NIC, Dual public IP
- Dual NIC, Dual Private IP, Single public IP
- Single NIC, Single Private IP, Single public IP.
The first option is the one we normally implement as it is easy to manage, separates traffic across NIC based on traffic type, avoid loss of management connection in case of VoIP IP issues, etc. But this is also the hardest to implement for AWS EC2 novices. As well, setting up routing rules can be a challenge for someone who doesn’t do network management as part of their job. We also prefer only a single VoIP IP (not dual public VoIP IP’s).
The fourth option is by far the simplest (almost trivial) to setup and you won’t have to worry about routing rules, but you will NOT have external access to the management IP’s of your nodes. To work around this you would either have to create a VPN into your VPC, or setup a third host whose sole purpose is to allow SSH relay to the internal hosts (management IP’s). We can also swap public IP’s between nodes if this makes life easier – to ensure continued direct external access to both nodes (but this is painful to use during setup).
Here’s an overview of the four designs:
1. Dual NIC, Dual public IP
2. Single NIC, Dual public IP
3. Dual NIC, Dual Private IP, Single public IP
4. Single NIC, Single Private IP, Single public IP
Once you have received the USB dongle(s) containing your license,
1. Plug each dongle into the appropriate physical machine. (The dongle will have a tag attached showing the machine name, in case you have multiple dongles).
2. From the VMware console edit the virtual machine, and add a new USB device:
3. Select the device name which should be something similar to “Phillips Elite”, and click save. (On some occasions you have to shut down and restart the VM for the hardware to be added).
4. From the VM’s command line, confirm in Linux that the USB dongle is present using the “lsusb” command. Notice the Phillips (NXP) device is present – that is the USB dongle.
5. Telnet to the local PBXSync instance and issue the “license usbdongle” command and follow the steps presented on screen.
Once you have received the USB dongle(s) containing your license,
1. Plug each dongle into the appropriate physical machine. (The dongle will have a tag attached showing the machine name, in case you have multiple dongles).
2. From the VMware console edit the virtual machine, and add a new USB device:
3. Select the device name which should be something similar to “Phillips Elite”, and click save. (On some occasions you have to shut down and restart the VM for the hardware to be added).
4. From the VM’s command line, confirm in Linux that the USB dongle is present using the “lsusb” command. Notice the Phillips (NXP) device is present – that is the USB dongle.
5. Telnet to the local HAAst/SecAst instance and issue the “license usbdongle” command and follow the steps presented on screen.
The problem you are encountering has nothing to do with HAAst, and everything to do with the basics of networking. You have setup 2 NIC’s in each PC, but they are on the same subnet! That means that Linux has no idea where (out which NIC) to route traffic for your 192.168.1.0/24 subnet. You should not do this as it confuses Linux. This topic is part of what’s known as “multihoming”, and I would suggest you research this topic a bit further before you continue to setup your networks. As well, reread the HAAst installation guide – there’s a bit more information on this topic there. (This isn’t the first time we’ve seen this issue in the support group).
By shutting down NIC1 on either PC you allow Linux to figure out how to properly route, but then your management NIC is gone so the cluster fails over.
The solution (for 2 NIC’s per PBX) is to ensure that each NIC is on it’s own subnet. For example:
