Editing the System Registry incorrectly can cause serious issues that may require you to reinstall the operating system. We cannot guarantee that problems resulting from the incorrect use of the Registry Editor can be solved. Use the Registry Editor at your own risk.

Introduction

Up to six active servers can form one redundant vsmStudio System. Within a vsmStudio Server cluster, one server takes the primary role, while all others server remain in an active secondary state. With VSM’s proprietary sophisticated software logic, the system also automatically load-balance all connected vsmGear amongst the servers, able to automatically optimize system performance.

In case the primary Server fails, the connected hardware and active protocol connections are automatically and seamlessly moved to an alternative server in the cluster without the loss of operation or performance. Crosspoint, Parameter and logic states are always synchronized across all servers in the cluster, for seamless operation in case of an automatic failover.

Single Server Mode

By default, a vsmStudio server install runs in single server mode. That means that all configured protocol connections are active and can be used to communicate with the connected devices. When several servers are within the same network, they don't communicate with each other and do not synchronize any data. Every server runs standalone.

Multiple standalone control instances connected to and controlling the same equipment may have undesired effects due to differing states and internal logic.

Multi Server Mode

Multiple vsmStudio servers can be joined and operated in a cluster to provide redundancy. The primary server is master for active protocol connections and communicates with connected devices. Primary and Secondary Servers communicate with each other and are synchronized in terms of live status and operational data. With release 25.2.1 the configuration and management of Communication Ports changed in multiple aspects. Changes done to the configuration of the communication ports are now synchronized at runtime with all other servers in the cluster.

Set up a Server Cluster

Before 25.2.1 release, some settings were still stored within the local Windows Server registry and one local file folder. These settings were not synced or automatically transferred between Servers and had to be copied in a manual process. To avoid varying local settings (e.g., Communication Port Settings, vsmGear settings) between Servers of one Live vsmStudio Cluster, it was recommended to execute these parts of the configuration with only one active Server. Either in Single Server mode or, if the Cluster is already set up, with only one Server running the vsmStudio application. Otherwise different local settings on the Cluster Servers may could cause unexpected behavior.

Preparation

Export and Copy Data from Registry

After finalizing the setup of communication ports and vsmGear settings on one vsmStudio Server, open the Windows Registry of the respective Server and navigate to "HKEY_LOCAL_MACHINE\SOFTWARE\VirtualStudioManager\vsmStudio".

Export subfolders "Connections", "Ports" and "Registered Devices".

Do never copy/export the whole vsmStudio folder.

Paste the copied Registry folders to all other vsmStudio Servers in the cluster.


Export and Copy Data from Mapping folder

Via Windows File Explorer, navigate to the vsmStudio installation folder "D:\vsm\vsmStudio\Mapping" and copy the folder "Mapping".

Paste the copied Mapping folder to the same location on all other vsmStudio Servers in the cluster.

Joining Servers

Start the vsmStudio application on all Servers that shall be part of the Server Cluster.

Open Command Prompt (CMD) on one of the Servers and enter: "telnet localhost 8001" and confirm with ENTER.
Enter: join 192.168.xxx.xxx (IP-Address of the other VSM Server) and confirm with ENTER.

Repeat this step for all Servers that shall join the Cluster.

Open the desired Configuration file on one of the Servers.
Click the Transfer Config icon on the main vsmStudio toolbar. With execution of this function, the current running configuration of the respective Server is pushed to all joined vsmStudio Servers in the Cluster. Subsequently the current running configuration on all Secondary Servers is closed automatically and the received updated configuration state is opened.

Start vsmStudio and check if everything is ok on all Servers in the Clusters --> maybe "only one connection per zone" has to be enabled on some of the ports because the 3rd Party may just support one connection at a time (has to be done an all Servers independently)

Parameter sync is currently not supported. Only the current Primary Server manages the Parameters of a connected device. If, e.g. in case of a load-balancing reconnection, a panel connects to a Secondary Server in the cluster, parameters may show "offline" on the respective panel. 

Un-Joining Servers

Exit the vsmStudio application on all Servers in the Cluster. In the local Windows Registry on each Cluster Server, navigate to "HKEY_LOCAL_MACHINE\SOFTWARE\VirtualStudioManager\vsmStudio" and delete the subfolder “\Registered Servers”
It is mandatory to follow this steps on all Cluster Servers before starting vsmStudio on any of the Servers. Otherwise the deleted folder and included files will be immediately created again by the system and the redundancy will be effectively active again.

Server Roles and Configuration transfer

If one or more Servers are joined to form a vsmStudio Cluster, only one Server takes the Primary Server role while all other servers act as Secondary instances. There are several rules to determine the primary server role. 

  • 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, within a cluster and any other server is already marked as Primary, it will stay in Secondary 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 assigned the Primary server role, it will become Secondary to avoid that there is more than one Primary Server active in the cluster.
  • Whenever the Transfer Config icon is pressed on the vsmStudio top toolbar of any Server in the Cluster, no matter if already the Primary or being a Secondary at this time, it is immediately elevated to be Primary Server. All other servers will get in the Secondary State.
  • Once the Transfer Config icon is pressed on the vsmStudio top toolbar, the current running configuration of the respective Server is pushed to all other Servers in the Cluster. Subsequently the current running configuration on all Secondary Servers is closed automatically and the received configuration state is opened.

The transferred configuration is always received and written to the MultiServer.vmc file, the original local filename of the sending server is not transferred.

Zone Map and vsmPanel/ vsmGear interactions during a config transfer or network/connection issue

The Zone Map contains all IP addresses of all Servers in one System/Zone along with some state information.

The device side

  • The manually entered list of Server addresses in vsmPanel and vsmGear is used at start-up until the Zone Map has been received.

  • Once the Zone Map has been received, the manual entered Server list is subsequently ignored, unless all Servers in the Zone Map become inaccessible.

  • The Zone Map is updated by the Servers and acts as an exclusion list where any Server that is deemed unfit by the rest of the Servers is marked "off limits" to the vsmGear devices.

  • vsmGear devices (including vsmPanel) will connect to at least two of the Servers from the Zone Map at any given time.

  • One of these connections is the devices primary and the others are its secondary connections - not to be confused with the Server states!

  • If a Server is marked as unfit by the Zone Map or if the device looses connection to that Server, the device will immediately switch to one of the previously secondary Server connections (if this Server was the primary connection at the time), abandons the connection to the lost Server and will try to connect to another Server from the Zone Map.

  • vsmPanels and hardware LBP panels run though an enforced "reset" visual to let the user know that the panel changed Server (This will go away with the over next release).

On push and sync

  • When a configuration is pushed, the pushing Server becomes the primary Server and the other Servers go though a offline phase while unloading and loading the new configuration,

  • After loading a configuration, Servers enter a sync window. This window ensures e.g. that Servers that are simultaneously started have the chance to detect each other and establish hierarchy before becoming active too early and start working based on possibly false assumptions. It also stops hardware from flooding triggers into the starting system before the global state has been established, by holding off device connections until the "truth" has been synchronized.

  • The sync window is closed as soon as the Servers have been synchronized. The sync window on an isolated Server feels longer than in a working cluster.