This chapter describes the redundancy concept of vsmGadgetServer and which mechanisms are used to discover the services within a local network.

Service Identification

The vsmGadgetServer is a service that manages the communication with 3rd party devices of any kind. The structure of each device supported can be accessed through a proxy protocol, which is a kind of gateway for control systems. The proxy protocols translate the device structure into a single protocol. That way, every implemented protocol can be accessed and controlled through a single protocol proxy. Examples are Pro-Bel SW-P08 and Ember+.

Almost every system that is running in a productive environment requires a backup or fall back, which takes over when the primary system fails. The vsmGadgetServer also allows defining a cluster of several servers. Within that cluster, one server is the primary server, while all others are passive and periodically evaluate whether the primary server is still available.

To be able to define a cluster, there must be a possibility to uniquely identify the servers within a network. Some networks do not support DNS, so the server name isn’t the best choice here. Additionally, it may change. The same problem occurs when using the IP addresses instead; they may also be changed. And, when not configured correctly, there might be address conflicts.

When started for the first time, the vsmGadgetServer generates a globally unique identifier, which is only valid for the machine it has been created on. This handle is dispatched across the servers within a network and can be used to identify the servers. That way, their hostname and even the IP addresses may change, and the server can still be identified. Only when the configuration file is being deleted, the identification will be lost. When the server is started again without nay configuration file, a new handle will be created, and the server will appear as new server that is not known within the network. To avoid that, the configuration file should never be deleted.

The server settings are stored in a file called “vsmGadgetServer.store”. It should never be edited manually, since this might prevent the service from running correctly or might event destroy the license information.

Discovery

To avoid that a user must enter the servers within a network manually, a discovery service has been implemented. This service uses a UDP broadcast at port 50040 and is used to collect information of the servers within a network.

When a server first starts up, it sends its local information to all other servers. Later, a message will be sent periodically, which requests the server information of all other servers.

The data packet contains the server description, which includes the global handle, the hostname, the active IP addresses, the service version and the URL that is required to connect to the server. As soon as a server receives this information, it connects to that server by using the WCF (Windows Communication Foundation) interface and the specified URL. If the connection failed, the server will retry to connect every 30 seconds.

The discovery mechanism may fail if the port is blocked by the firewallFirewall or if a VPN connection is active. In the latter case, the UDP packets often get lost.

Every server that has been discovered that way will be displayed in the web interface of the vsmGadgetServer configuration client. It can be used to manage the clusters.

Connection between Servers

When a server receives service information through the Service Discovery Protocol, it establishes a connection to that service. That way, all servers within a network are connected with each other and can monitor each other. The connection is kept alive with a keep-alive message.

Single Server Mode

By default, a server runs in single server mode. That means that all protocols are active and can be used to communicate with the remote devices. When several servers are within the same network, they communicate with each other but do not synchronize any data. Every server runs on its own.

Multi Server Mode

Multiple servers are operated in a cluster to provide redundancy. Use the web interface to define a cluster.

Joining Servers

When selecting the local server, go to “Add server to cluster”. A list of known servers appears. Select the servers that should be member of the new cluster by clicking the + symbol. Finally, click the "Apply" button to confirm the changes.

The server, which has been selected first and has been added with further servers, automatically is elevated to primary server. All servers that have been added will automatically run in passive mode and synchronize their configuration by copying the configuration from the primary server. All protocols that only exist on one of the passive servers will be deleted. After the synchronization process, all servers should host the identical set of protocols and the same configuration.

From that moment, the servers will adapt all changes that are being made on any of the servers within that cluster. This includes:

  • Protocol creation
  • Protocol deletion
  • Protocol settings modifications
  • Protocol file changes (when a protocol uses a configuration file, like DHD)
  • Server Node settings, like the list of joined servers, location and comment.

Unjoining Servers

To remove a server from the cluster, simply remove it from the list of joined server via the web interface. When the server that is being removed is the current primary, a new primary will be determined by the remaining server nodes. The removed server will keep its configuration but will no longer synchronize its data with the cluster it has been removed from. Instead, it becomes the primary server in single server mode.

Determining the Primary Server

As already described, a server becomes the primary server when other servers are added to form a cluster. Within a defined cluster, there are several rules to determine the primary server, and a backup server:

  • When a server starts up and has no connection to any other server within a specified period, it will elevate itself to the primary server.
  • When a server starts up, successfully connected to the servers within a cluster and any other server is already marked as primary, it will stay in backup mode.
  • When no server is marked as primary or the connection to the primary server is lost, the server that has been running for the longest time within the cluster will be elevated to primary.
  • Whenever a server receives a notification that another server has been elevated to the primary server, it will become passive to avoid that more than one server is marked as primary.

Server Roles

The Primary Server

The primary server role is exclusive within a cluster. There is always only one primary server within a cluster. That is, because some controlled devices only support a single connection. This is also the case when using a vsmSmartHub. The active server allows all protocols and protocol proxies to be active. For device connections, that means that they connect to the remote devices. On the other side, the proxies bind to a configured port, so the control system can connect to them and access the devices that are mapped to that proxy.

The Backup Server

The backup server disables all protocols that establish a connection to remove devices. However, it allows control systems to connect to the proxy protocols. They are marked passive and may not process any requests sent by the control system. They are only allowed to keep the connection alive. This allows the control system to connect to both servers and if the active connection fails, it can immediately talk with the new primary server instead of having to establish a new connection first. As soon as a passive server becomes the primary, it activates all protocols, tries to connect to the remote devices and allows controlling them through the configured proxy protocols.

However, depending on the controlled device it might take some time until the device is available.

Configuring a redundant vsmGadgetserver connection in vsmStudio

From vsmGadgetserver v5.6.1.185 onwards it is mandatory to actively link redundant vsmGadgetServer provider connections in vsmStudio to achieve service redundancy. See here, how to link Communication Ports in vsmStudio.