Skip to content
Thirdlane

Servers

This screen is where the machines that make up a Thirdlane cluster are registered. Each one gets a row saying what it is and how the manager reaches it, and that set of rows is the description the whole cluster works from.

In a single-server deployment one machine handles everything and this screen does not appear. It becomes available once the system is installed as a cluster, which is normally done by the Thirdlane professional services team - contact sales@thirdlane.com for further information. See Thirdlane Deployment Options for the architectures available.

Why you would want it

Nothing in a cluster discovers anything by itself. The manager does not scan the network for machines, and a call-processing server has no way of knowing which machine fronts telephony for it. Every one of those facts has to be stated once, and this is where it is stated.

That makes the rows here the source the rest of the cluster depends on. A machine with no row is a machine the cluster does not know exists, and one with the wrong function set will be sent configuration meant for something else.

Two views of the same screen

The same servers can be shown two ways, and the selector at the top left switches between them. Your choice is remembered, so the view you use is the one you get next time.

  • Diagram - the cluster drawn as boxes and the paths configuration travels between them. Best for seeing the shape of the cluster and which machines are behind. Described in full under Topology.
  • List - the same servers as rows, with the columns the diagram cannot show: configuration version, how far behind each server is, provisioning state, and the number of tenants, users and numbers each carries.

Both views open the same settings for a server and both can add one, so neither is a read-only picture of the other.

Server types

Every server has a type, which decides what software it runs and what configuration it is sent.

  • Manager - runs the administration interface and is where cluster configuration is written.
  • User Access server - serves the user portal, Thirdlane Connect and the REST API.
  • Telephony frontend - fronts call traffic, and passes configuration on to the workers.
  • Telephony worker - processes calls.

A cluster holds one manager, one User Access server and one telephony frontend, and as many telephony workers as it needs. Once one of the single-instance types exists, it stops being offered, so the type cannot be duplicated by accident.

Which types are on offer also depends on the shape the cluster was installed with. A compact cluster is offered Manager and Telephony worker only, because the manager carries user access and telephony itself. See Cluster Configuration for the two shapes.

The type cannot be changed after the server is saved. It determines what was installed on the machine, so correcting it means rebuilding the server. Set it correctly when you add the row.

Adding a server

  1. Choose the type. In the diagram view each add button carries its own type, so the type is already filled in; in the list view use Add and pick it.
  2. Give it a Host name - the fully qualified name, for example pbx1.example.com. Certificates are issued for full names, so a short name will not match them.
  3. Fill in the Internal IP. The installer addresses servers by IP, so a cluster server without one cannot be built. Add the External IP as well if the machine is reachable from outside.
  4. Leave SSH Port and Agent Port at their defaults unless the machine was set up differently.
  5. Save, then publish the change - see below.

Fields reporting what a server is doing - its configuration version, how far behind it is, provisioning state and any provisioning error - appear only when editing an existing server. They are reported by the server itself and cannot be set here, so there is nothing to show while the row is still being created.

Publishing a change

Adding or editing a server changes a row in the Manager. It does not change the cluster. The other machines only learn about the change when the cluster description is published to them, which happens on the Cluster Configuration screen.

When there are changes that have not been published, both views show a notice saying so, and it takes you to the screen that publishes them. If you have edited a server and the cluster has not reacted, that notice is the thing to look for.

Best practices

  • Use full host names, not short ones. Certificates are issued for full names, and a short name produces connection failures that look like a network fault.
  • Check the diagram after adding a server. A server that appears in the wrong place has the wrong type, and the type cannot be changed afterwards.
  • Publish, then verify. After publishing, confirm the servers reached the new version in Data Sync rather than assuming they did.
  • Plan cluster changes with Thirdlane. Because this is a licensed feature usually deployed by professional services, coordinate additions and removals so topology, licensing and sync stay consistent.