In the infrastructure design process we were focusing on our main goal – to develop it very simple with true UNIX-way in mind => e.g. each subsystem should do only one thing and should do it well. This, in addition to the highest level of HA allowed us to avoid dependencies on any single point of failure.
Based on our experience with administration of Wialon Hosting system now operating in multiple distributed data centers we divided HA into few levels:
On a hardware level, we made the maximum possible – there are two switches in each rack, each server is connected via bond wires to both of them and comes with two separate power outlets. For system drives, we use MD RAID-1.
Now two servers hosting gateway services are filtering and distributing traffic from external IP addresses to other LAN subsystems. Servers are controlled by Pacemaker, in addition, there is a third server storing static daily archive and history in case of malfunction of the main ones.
To gain software HA we use different techniques: first of all most sensitive data is stored in PostgreSQL database which is running in HA mode on multiple database servers. Not all the data, because this RDBMS is slow when we talk about our volumes of telematics data, but just most of the metadata. Then, each system is fully autonomous and communicates with other systems via internal HTTP REST API. These independent subsystems are nowadays called microservices and become a very convenient architectural approach. The only important thing in microservices is the API, and it has been standardized. We developed guidelines for it and were following these guidelines during API development. All other internals are not so important. It’s up to the subsystem developer to select this or another approach, or even test a few variations of implementations on parallel nodes. As long as they both operate under the same API, it is absolutely ok.
flespi platform architecture can be described by the following chart:
Currently, we have the following subsystems operating:
And here is the operation scheme for GW subsystem, consisting of “tg” and “tgctl” processes. “tgctl” processes are responsible for REST API method, while “tg” processes deal with real communications with telematics devices.
Each system comprises multiple processes running on different hardware servers, and there is no single point of failure. They are all designed for just one thing – to function the best possible way. I will describe all our systems in detail in the next posts, and for now, I’ll just provide you with a few insights:
Try it yourself and stay connected!
The phone number is enough to start device configuration. The visual interface facilitates settings changes and enables convenient debugging.