Define the Server Setup
Use the VTScada Thin Client/Server Setup dialog -> Server Setup tab, to identify each VTScada Thin Client Server in your system. These are the machines where you have installed a copy of VTScada licensed for thin client connections. (See notes later in this topic as well as Server Requirements and Licensing)
Refer to the notes that follow these instructions before configuring your list of servers.
- In the VAM, click on the VTScada Thin Client/Server Setup button.
The VTScada Thin Client/Server Setup dialog opens.
- Select the Server Setup tab.
Colors within the list have meaning. Refer to the notes later in this topic.
- Enter the name of the first server you wish to add to the VTScada Thin Client Server list in the Server field.
The list can be reordered later.
In general, it is better to use a name than an IP address.
- Click OK. The Add Server dialog closes, and you are returned to the Server Setup tab, where the server has been added to the server list.
- Repeat steps 2 through to 5 to add any other servers that should be part of this license cluster.
The list can be configured only from a machine that is a member of the list, and will remain a member after configuration.
If you attempt to remove the last local server, the entire server list and all related connection addresses will be removed from the local machine.
Notes:
The Server Setup tab defines a "cluster" of thin client servers. (VTS/IS Clusters and Server Lists)
For example, the following image shows a cluster with two members: Bridge-PC and Engineering-PC.
Color Coding:
After saving the list, entries are color-coded as follows:
- Black text: VTScada has contacted the listed server and all is well.
- Gray text: The server cannot be reached. It may be offline or there may be network issues.
- Red text: The server can be reached and has been found to be a member of another cluster.
Servers cannot be members of two clusters simultaneously. It must be removed from one or the other.
In installations with many servers, there is no requirement that all of the servers be listed in a single license cluster. You might decide to maintain two or more smaller server lists in order to better manage license clusters.
If the Load Balancing option is selected, client connections will be distributed between servers automatically, reducing the load on any one particular server.
Configuration updates:
Thin client servers in a cluster share information about all the connected thin client sessions across the cluster, along with license and configuration details. Updates to either the Realms or the Server Setup on any one server in the cluster are automatically propagated to all. Changes on the Connection Addresses tab are automatically sent to all client sessions.
Clusters and Thin Client Connection licenses:
A cluster is a group of servers that serve Thin Clients. The servers in the cluster provide redundant failover for thin clients should one of the servers fail or be taken offline. You can have multiple clusters. As each thin client periodically tests the connection to each server in the cluster it is using, the more servers you have in a cluster, the higher the network traffic will be. A thin client that starts up and cannot contact all servers near the top of the server list for the cluster rapidly will have a slow startup. Therefore the number of servers in a cluster is a balance between redundancy and performance. If you have many thin client servers, it is better to organize the servers into small clusters. Note that a thin client cannot fail over across clusters - only to servers within a cluster.
License counts are combined within a cluster. You can connect more clients to any one server than would otherwise be allowed by its license limit, so long as the total number of connections within the cluster does not exceed the cluster’s license limit.
If only one server in the list holds Thin Client Connection licenses, that machine must be added to the list first. If that machine is removed from the list, the remaining machines do not retain the ability to act as VTScada Thin Client Servers.
If a server fails, you do not lose its license count from the total during the time it is offline. All VIC connections to that machine are immediately re-routed to the remaining servers in the cluster that are running the application, even if this would exceed the licenses available on the remaining machines.
If sub-networks within the organization become isolated such that the servers are temporarily unable to communicate with each other, each server will maintain the full license compliment of the cluster, even though this may exceed the license limit of that one machine.
When isolated servers reconnect, if the combined total number of connections exceeds the license cluster limit, no new connections can be made, but existing connections in excess of the limit are maintained.
While the server list maintains excess connections, an event will be logged in the alarm history every 10 minutes, warning of this state.
Realm session limits are maintained across a cluster such that the total number of connections to a realm throughout the cluster may not exceed the configured limit.
Redundancy and Fail-Over
The following applies only to VIC and Anywhere connections. Both will receive a list of Connection Addresses from whichever server it connects to and will periodically test each Connection Address. If the Connection Address the client is connected to fails, the client will automatically connect to the next server in the Connection Addresses list. (See Connection Addresses tab).
If the server to which a Mobile client (MIC) is connected fails, the connection is simply lost. The MIC makes no attempt to connect to an alternate server.
Server List / License Cluster Examples:
Reminder: The term "thin client cluster" refers to a pool of thin client servers that provide redundancy and can share thin client licenses.
The list can be configured only from a machine that is a member of the list, and will remain a member after configuration.
If you attempt to remove the last local server, the entire server list and all related connection addresses will be removed from the local machine.
Servers A, B, C, D and E are all part of one network. VTScada is able to communicate across all.
On any of A, B or C, the following list is defined:
Server List
| A
| B
| C
This constitutes cluster 1. VTScada shares the thin client licenses from each of these servers between all three.
On any of D or E, the following list is used to define cluster 2:
Server List
| D
| E
If D were to be added to the server list for cluster 1, it would appear as follows:
Server List
| A
| B
| C
| D
The red color indicates that D is already of member of another cluster and cannot be added to cluster 1. Its status in cluster 2 does not change. Cluster 1 cannot "steal" a server from another cluster.
If your intent is to move D from Cluster 2 to Cluster 1, then first remove it from Cluster 2. Then add it to Cluster 1. Note that you cannot perform the second part of this action while working on machine D, as per the earlier warning. D cannot force itself into a cluster. This is a security feature - you must have the ability to edit the server list for a cluster in order to add a new server to it.
