Running Visionect Software Suite in production

Visionect HA support / dual server support

The Visionect Software Suite supports HA scenarios, where it is possible to replicate services across multiple servers.

When using the HTML backend, it is possible to split HTML engines across multiple physical, virtual servers or containers. If there is enough capacity, an engine can shut down and device sessions will migrate to the other available servers. It is also possible to create a fully self-managed infrastructure with the help of Kubernetes (or a similar container orchestration solution).

The Visionect Software Suite also provides endpoints for testing server health (/api/ping) which, in the of failure, can be used to confirm that the server setup is running or run automatic measures.

It is also possible to transfer devices from a server to a secondary server setup in the advent of system failure - you can replicate the complete Visionect Software Suite installation on a secondary server, and connect the setup to the same backend database. In the advent of a system failure, you can simply reconfigure the DNS or IP configuration and your devices will automatically reconnect after losing connectivity to the secondary server.

An important consideration in providing HA scenarios is also the database layer used to store all Visionect Software Suite data. To provide an adequate level of HA, we recommend running the PostgreSQL server on a secondary server, with replication at the database level as well (PostgreSQL supports master-slave and master-master configurations).

Additional documentation regarding HA can be provided pending information about your specific target scenario and target system uptime - this is highly dependant on the tolerated level of image update delay. We run production systems which can be fully shut down for short maintenance periods (up to 2 minutes) without our customers noticing due to the low update speed and tolerance for image updates - all devices keep the last image displayed until the connection is re-established.

To properly implement HA, there are additional design considerations when implementing your Visionect Software Suite application in relation to the device session state. The application developer should consider the device session as transient, as it can always be killed - the same as with any general web application (gmail,...) where the application makes sure that state is stored in cookies or the server-side session storage.

Log aggregation

The Visionect Software Suite supports log redirection. To enable this feature, three additional parameters are required when running the Visionect Software Suite container.

Check out quick start before running command.

The example below uses fluentd for log aggregation.

# run docker container with logging redirection
docker run --privileged --cap-add=MKNOD --cap-add SYS_ADMIN -v /dev/shm:/dev/shm --device /dev/fuse -d --restart=always -p 8081:8081 -p 11112:11112 -p 11113:11113 --link vserver_postgres:db2_1 --log-driver=fluentd --log-opt fluentd-address={IP of a log driver}:24224 -e "VISIONECT_SERVER_LOGS_TO_STDOUT=1" --volumes-from vdata --name vserver visionect/visionect-server-v3

Additional parameters explanation:

# sets fluentd as log driver
--log-driver=fluentd
# sets fluentd address where logs are forwarded
--log-opt fluentd-address={IP of a log driver}:24224
# flag to enable log aggregation
-e "VISIONECT_SERVER_LOGS_TO_STDOUT=1"