Tachyon Single-Server system
In the most basic setup there is a single server which hosts both a Master Stack and a Response Stack and this can be deployed by selecting the default settings in Tachyon Setup.
The following table shows the Tachyon Server components for each type of Stack, and also shows the DMZ Server discussed below.
Component | Master Stack | Response Stack | DMZ Server |
---|---|---|---|
Master database | 1 (optionally Remote) |
| |
Coordinator service | 1 | ||
Authentication | 1 |
| |
Registration | 1 |
| |
Explorer | 1 |
| |
Consumer API | 1 |
| |
Core (including Core Internal) | 1 | ||
Background Channel | 1 | 1 | |
Switch(es) (also includes a single Switch Host service) | up to 5 (optionally Remote) | up to 5 | |
Responses database | 1 (optionally Remote) |
The picture opposite shows a Tachyon Single-Server System with databases optionally installed locally or on remote SQL Server instance(s). The Master Stack has a Master database, and the Response Stack has a Responses database
There are six web components, four in the Master Stack: Authentication, Registration, Explorer and Consumer API; and two in the Response Stack: Background Channel and Core.
Other components are Master Stack Coordinator and the Response Stack Switches. The Switches also have a Switch Host service.
The DMZ Server has only the Agent facing components of the Response Stack, the Background Channel and Switches.
Tachyon Multi-Stack system
The picture opposite shows a Tachyon Multi-Stack System. Here the Tachyon Master Stack communicates with one ore more Tachyon Response Stacks. The Response Stack local to the Tachyon Server is optional if there is at least one remote Response Stack.
As with a single-server system, the databases are optionally installed locally or on remote SQL Server instances(s).
Tachyon components
Let's take a look at each of the Tachyon components in slightly more detail.
Component | Description | |
---|---|---|
IIS Components | The following components are IIS Web Applications that reside on a single-server under the Tachyon website.
| |
Core | The Core component has two web applications, Core and Core Internal. Core does the following:
Core Internal does the following:
| |
Background Channel | The Background Channel provides a means for the Tachyon Agents to retrieve large data items from Tachyon without loading the Tachyon Switch:
| |
Switch | The Switch component provides the following:
The Switch Host service is responsible for starting local Switches. | |
Explorer | Tachyon users browse to the Tachyon Explorer to ask questions, retrieve responses and run actions. See Using Tachyon. Tachyon administrators browse to the Tachyon Explorer to access the administration pages to configure Permissions, Product Packs, manage Consumers, define Custom Properties and manage devices registered for Two-factor authentication. They can also view the Administration Log and system status Dashboard. See Maintaining Tachyon. The Explorer component is a Consumer that provides the following:
All subsequent requests are made by the Tachyon Explorer running in the browser:
| |
Consumer API | The Consumer API provides the following:
| |
Coordinator | The Coordinator service has two modules, Workflow and Instrumentation. The Workflow module provides the following:
The Instrumentation module processes instrumentation data from the following components:
And responds to requests for instrumentation data from the Consumer API. | |
Authentication | Supports the two-factor authentication feature. | |
Registration | Enables mobile devices with the Tachyon App installed to register for two-factor authentication. | |
Consumers | The primary example of a Consumer is the Tachyon Explorer and Administration portal, other examples include external consumers such as Configuration Manager extensions. | |
SQL Server | Tachyon has two databases:
These are used by the following components:
| |
Tachyon Agents | Each Tachyon Agent runs on one of the devices you want to include in your Tachyon managed estate. The Tachyon Agents communicate with the Tachyon Switches and the Background Channel to provide responses to instructions (questions and actions). |
Tachyon single-server architecture
The following diagram shows the basic single-server architecture for Tachyon:
Tachyon instrumentation layer
The following diagram shows the instrumentation layer overlaid on the Tachyon Server architecture. The instrumentation layer provides feedback on how the components are performing:
Tachyon architecture for Internet-facing devices
Enabling Tachyon to support devices that are external to your company network is done by slightly extending the default single-server architecture.
The Responses Stack handles communications between the Master Stack and the Tachyon Agents. The Background Channel and Switches components handle the direct communication with the Tachyon Agents, the Core processes the information in both directions between the Master Stack and the Switches.
To enable external Tachyon Agent devices to interact with Tachyon you need to put the Background Channel and at least one Switch into the DMZ.
You would then need to configure the internal firewall to allow two-way communication between:- The Core on the Internal Response Stack and the Switch(es) in the DMZ
- The Instrumentation module of the Coordinator on the internal Response Stack and the Switch(es) in the DMZ
- The Consumer API on the internal Master Stack and the Background Channel in the DMZ
You would then need to configure the external firewall to allow incoming connections for:
- The external Tachyon Agents and the Background Channel in the DMZ
- The external Tachyon Agents and the Switch(es) in the DMZ
You would then need to make the following changes:
- The Tachyon Master database would need to be modified to enable Tachyon to recognize and additionally use the DMZ Background Channel and Switch(es) and raise the security level of the Core and Switch communications to use HTTPS.
- The configuration files for the Switch host on the Internal Tachyon Server and on the Tachyon Server in the DMZ would need to be changed to enable the Switch(es) to communicate with the Core.
- The configuration file for the Background Channel on the DMZ would need to be changed to enable the Background Channel to communicate with the Consumer API.
The DMZ picture shows a dual firewall design, but single firewall is also supported.