.png)
Reference architectures
Overview
Installing Nexthink requires taking architectural decisions with respect to the location of the Nexthink components and their connectivity. The choice of a particular architecture depends mainly on the geographical distribution of the assets and the network topology of an organization. Whereas global organizations have assets distributed all over the world, with regional offices typically interconnected through dedicated lines or VPN technology, local organizations have all or most of their assets placed in a single location and connected to a single LAN. The appropriate architecture for each type of organization will thus be different, although some basic architectural principles stay the same for all kinds of installations.
To help you choose the right architecture for your organization, consider the following factors and possible scenarios:
Location and connectivity of Appliances
Appliances are placed in one location on premises (recommended).
Appliances can connect to the Internet (recommended online installation).
Appliances have no access to the Internet (offline installation).
Appliances are in several geographically dispersed locations on premises (not recommended).
Appliances are located in external data centers (cloud installation).
Location, connectivity and total number of Collectors
Collectors in the intranet.
Roaming Collectors in the Internet (home office, travelling, etc).
Connected through VPN or similar (including Microsoft Direct Access or Always On VPN).
With no VPN connection.
Data anonymization
Anonymized analytics.
GDPR compliance.
Integrations
Integrations inside the intranet (e.g. SCCM, SMTP, Active Directory)
Integrated software in the Internet (e.g. cloud services such as ServiceNow).
While an exhaustive description of all the possible combinations is beyond the scope of this article, we present below a set of reference architectures on which you can base your own deployment. Choose the reference architecture that suits best to your specific setup.
Basic architectural principles
Once the hardware requirements for running Nexthink are met, the quality of the network connections between the different Nexthink components mainly determines the overall performance and responsiveness of a Nexthink setup. For architectural purposes, we can classify these connections according to the communicating Nexthink components:
Nexthink visualization and query tools with the Nexthink Appliances:
Finder to Portal and Engines.
Browser (web front-end) to Portal.
Among Nexthink Appliances themselves:
Portal to Engine.
Engine to Engine.
Collector with Nexthink Appliances:
Collector with Engine (UDP and TCP connection)
Collector with Portal (TCP connection, if rule-based Collector assignment is used)
With the introduction of the Cross-Engine features in V6.19, a good connectivity between the Finder and the Nexthink Appliances and between the Appliances themselves has become fundamental to offer Nexthink users a satisfactory experience. Apply thus the following recommendations, especially when using the Cross-Engine features:
Place all your Nexthink Appliances in the same data center. If this is not possible, ensure that the connectivity between the Portal and the Engines is equivalent to that of a local network.
Ensure a good connectivity between the Finder and the Nexthink Appliances, both Portal and Engine.
The rationale for these recommendations in Cross-Engine scenarios is the following:
All the queries from Finder that require an answer from multiple Engines are routed through the Portal, which gathers and merges the responses of every Engine.
The slowest of the connections between the Portal and the Engines determines the overall query time (the Portal waits up to 3 minutes for the Engines to respond).
Finder users will face responsiveness issues and suffer long waiting times if the communication with the Portal and the Engines is not fluid, which leads to a poor user experience.
On their part, the connections between the Collectors and the Appliances are much less demanding in terms of network bandwidth and latency. Therefore, the main concern is to ensure that Collector data reach their intended destination through the network:
Ensure that Collectors can reach their correspondent Engine and, if rule-based Collector assignment is used, that Collectors can reach the Portal as well.
Use either VPN technology or traffic redirection for Collectors that are not directly connected to the same network as the Appliances.
Configure firewalls and proxies appropriately so they do not block the Collector communications.
Avoid fragmentation of UDP traffic, as it may cause significant loss of Collector data.
Global organizations
Global organizations extend over several locations in different countries. To create a private network over a wide area, the local area networks of a global organization are connected through dedicated lines or, more often, through VPN technology. A Virtual Private Network (VPN) enables devices and servers in distant places to connect through shared or public networks as if they were all directly connected to a single local network.
The reference architecture for a global organization looks thus as follows:
The key points of the reference architecture for global organizations are the following:
All Nexthink Appliances, whether physical or virtual, reside in the same data center.
Multiple Engines are required, as global organizations typically deploy a large number of Collectors.
Regional offices are interconnected to form a single private network (through VPN in the example figure).
The IT department (Finder and Portal users) is preferably located next to the Nexthink Appliances to have good connectivity.
Using the Finder from a distant regional office is still possible, although the Finder may lose responsiveness if connectivity is not good (Finder icon displayed dimmed in the example figure).
Remote Collectors connect to the global private network through the Internet (using VPN client technology in the example figure).
Appliances in different locations
If for some reason you really need to have Appliances distributed among different locations, place the Portal in the office with the highest number of end-user devices or Engines (generally these two numbers go hand in hand), or with the highest number of Finder users.
The connection between offices should offer enough bandwidth and low latency for Nexthink users to work comfortably with the Finder or with the Portal front-end while connected to the Engines or the Portal located in another office. Remember though that this is not the recommended architecture for global organizations, especially in the case that Cross-Engine features are enabled.
Regional and Local organizations
For regional organizations with several data centers, preferably place your Nexthink Appliances in the data center where most of your Finder users work. For local organizations that do not extend over several locations, all Nexthink Appliances are naturally placed together in the same data center.
Depending on the total number of deployed Collectors, install one or several Engines and one Portal on separate physical or virtual appliances and federate your secondary Appliances (Engines) with the primary (Portal).
Small local organizations
For setups with fewer than one thousand end-user devices, it is possible to host both the Portal and the Engine in a single appliance, as depicted below.
Remote or roaming devices
When the end-user devices and the Nexthink Appliances are in the same intranet, every machine can directly reach each other over the network: Collectors can talk to their assigned Engine and, in turn, Engines can communicate with the Portal because they all reside in the same intranet.
The fact that the intranet is implemented as a Local Area Network (LAN) in a single office or as a Wide Area Network (WAN) extending over several regional offices is probably important for network performance, but irrelevant to our discussion. It does not matter either if the Nexthink Appliances are deployed on physical or virtual servers. The most important property for a simplified deployment is to have direct connectivity among computers, as it is the case in an intranet.
Regardless of the size of an organization, it is common these days to have employees working from remote locations. The reasons may vary: home office, commuting, visiting customers, etc. When an end-user device is outside the corporate network, the Collector running on the device may lose the connectivity to its assigned Engine, as the Engine is usually not reachable through the Internet because of security reasons. If the Collector cannot reach the Engine, activity information is irremediably lost while the device is roaming.
Running VPN client software
One way for the Collector to not lose the connectivity with the Engine is to run VPN client software on the roaming device so that it always stays connected to the corporate network, even when the device is out of the office. Of course, the use of VPN client software in your roaming devices requires that you have a VPN infrastructure ready in your corporate network. Establishing a VPN connection is the preferred solution to deal with roaming devices if you already use VPN technology.
For instance, if you have Microsoft DirectAccess (for Windows 7 clients) or Always On VPN (for Windows 10 clients) or any other VPN technology, benefit from it to keep the Collector connected to the Engine on roaming devices. Remember to configure your Nexthink setup to support DirectAccess if you use this particular solution.
See the diagram on global organizations for an example of roaming devices connected through VPN.
Forwarding UDP Collector traffic
As an alternative to VPN technology, configure a Nexthink Appliance to forward Collector traffic to your Engines. The redirection service is a feature in the Engine Appliance that lets you forward UPD traffic from the deployed Collectors to one or more instances of the Engine, optionally anonymizing sensible data on the fly.
To forward Collector traffic from the Internet to your corporate network, place the additional Engine Appliance in the DMZ and use it exclusively for redirection.
Because the Collector is configured to point to a specific Engine, the DNS name of the Appliance that performs the redirection in the Internet must match the DNS name of the Engine in the corporate intranet. It is therefore mandatory for this case to use DNS names and not IP addresses to configure the External DNS name of the Engine and the Collector assigned Engine. In this way, regardless of the device being inside the corporate intranet or out in the Internet, the Collector is pointing to the correct DNS name of the Engine.
In Nexthink, the last IP address of a device is determined by the source address of the UDP datagrams that it sends to the Engine. While roaming without a VPN, however, a device is usually behind a NAT router that hides the private IP address assigned to the device. Moreover, the redirection service can modify the source IP address in the UDP datagrams of roaming devices, so they can be redirected to the intranet without being rejected. This has implications on how devices are assigned to entities and Engines depending on whether devices are roaming or not. Contact the Customer Success Services of Nexthink to find out the best configuration possible for your particular case.
Starting from V6.21, the redirection service can deal with data sent through either the UDP or the TCP channel of the Collector, but it exclusively handles the end-user data part of the TCP channel. Therefore, features such as Engage, Act or the automatic updates, which are sent through the TCP channel, do not work for roaming devices with the redirection service. If you need these features to work on roaming devices, prefer a VPN solution or configure a TCP reverse proxy as indicated in the next section.
Forwarding TCP Collector traffic
To enable features such as the Engage or Act modules and the automatic updates on roaming devices that cannot connect through VPN, enable the TCP channel between the Collectors and the Engine by installing a reverse proxy in the same Appliance that redirects Collector traffic.
Starting from V6.21, if all your Collectors send all their data through the TCP channel only, you do not require the redirection service (Nxredirect) to be running on the Appliance, as no UDP traffic is sent and the reverse proxy configuration is able to redirect the full TCP channel of the Collector.
Connection to online services
Independently of your particular setup and the reference architecture that you choose, the deployed Nexthink Appliances must connect to the online services provided by Nexthink to receive updates, get security information about binaries and domains, and validate their licenses.
Moreover, the Appliances optionally connect to NTP servers to synchronize their clocks. By default, the Appliances that run the Portal or the Engine connect to official CentOS NTP servers. Change the configuration in the Web Console if you prefer to synchronize with NTP servers that are geographically closer to your Appliances, or even located within your own corporate network.
In addition to the Nexthink Appliances, the device that runs the Finder must have access to the Nexthink online services to download library packs from the Nexthink Library.
Offline Nexthink Appliances
In setups with special security concerns, Nexthink Appliances have no direct connection to the Internet. To update your offline Appliances, mirror the Nexthink repository in a server under your control and then apply the updates to the Appliances.
Because mirroring the Nexthink repository requires a formal agreement with Nexthink, contact your Nexthink representative or Customer Success Services to proceed with this method and get technical assistance.
RELATED TASKS
RELATED REFERENCES