Archived - Introduction to multi-server configuration (Entuity v20.0)

Introduction

To establish connections between servers

User permissions requirements

Multi-server configuration page

Cloning Entuity servers

Considerations for setting up multiple servers

Monitoring multiple Entuity servers

Example multi-server setup

Recommended best practices for setting up user groups and user permissions across multiple servers

Incidents and events

Introduction:

Entuity enables you to create trusts between servers. This means that one server can use the resources of another server or of multiple servers.

Entuity servers can act as both a central and a remote server. With a multi-server configuration, you can use an Entuity server to:

• act as a non-polling central server (consolidation or 'upstream' server) that uses remote servers ('downstream' servers) to poll the network.
• act as a central license server for all of its remote servers. Although you can have more than one central licensing server, a remote server can only accept license credits from one central licensing server at any one time.
• use the flow collection capabilities of its remote servers.
• use network paths discovered by SurePath.
• view details of another server through the System Information page.
• launch the client of a remote Entuity server (although the administrator will have to log in).

Trust between servers is verified through an Administrator user account, which must have the same credential set on all connected servers. Both Administrators and non-administrators can access the information in remote servers if they have user accounts on those servers.

To establish connections between servers:

From Entuity v20.0 upwards, connections between the non-polling central server (consolidation server) and the remote server (polling server) can be initiated in either direction:

• outgoing, or upstream to downstream - consolidation server initiating connection with the remote server.
• incoming, or downstream to upstream - remote server initiating connection with the consolidation server.

The method required to establish a connection between servers will depend on the direction of the connection. These connections can work if RSSO is enabled on either the upstream or downstream server, or both.

User permission requirements:

To access multi-server configuration functionality, you will need the Multi-Server Administration tool permission. Please see this section for further help and information on user permissions in Entuity.

Multi-server configuration page:

The Multi-Server Configuration page is accessed via Main Menu and then Administration.

1. Click the Main Menu, and then Administration.
2. On the Administration page, click Multi-Server Configuration.
   
   
   
   
3. The Multi-Server Configuration page will open.
   
   

The Multi-Server Configuration page consists of 4 tabs:

• Remote Servers
• Flow Collectors
• Incoming Connections
• Central Servers

Note regarding 'To add an INCOMING connection, install this file on the remove server' message:

At the bottom of each tab is a message 'To add an INCOMING connection, install this file on the remote server', and a link to the file. This functionality relates to adding a new downstream-to-upstream connection via the command line. Please see this section for help and information on this.

Remote Servers tab:

The Remote Servers tab is the default tab open when you access the Multi-Server Configuration page. This tab displays a table listing the remote servers that the central server can already access.

From this tab, you can also add, delete, show or hide connected servers. Please see this article for further help and information on adding remote servers to your multi-server configuration.

The table details the following information:

Licensing:

If you are on a license server, the Remote Servers tab displays some added functionality and information. For further help and information on licensing in Entuity, please see this article.

The tab has the following additional functionality:

• Licenses - click this button to open the Change License Allocation form on the right of the page. This is where you can assign or deallocate license credits to or from pollers when the server is acting as a central license server. Please see the following sections on central license servers and assigning license credits for further help and information on this topic. Depending on the license model, enter the number of device and object license credits to assign to the server.
  
  When using multiple Entuity servers, you can assign each Entuity server its own license, tied to its host identifier which specifies the modules and integrations permitted on that server. This standalone license can also set the object and device credits available to the server.
  
  Click OK to save, otherwise click Cancel. Note, a remote server that did not previously have a credit allocation will restart in a licensed mode. The Central License Server may temporarily report the remote server state as Down.
• Refresh - click this button to update the licensing information displayed on this page.

The tab has a collapsible Allocated License Consumption section, which is a visual representation of the selected server's licensing information, and the table displays the following additional information:

Flow Collectors tab:

The Flow Collectors tab lists the currently-assigned flow collectors. An Entuity server receives and displays flow data from the flow collectors assigned to it. A flow collector can only be assigned to one Entuity server at a time, but one Entuity server running IFA Premium can have as many collectors to it as its license permits. For further help and information on flow management in Entuity, please see this section.

To add flow collector to an Entuity server, click Add at the top of the page (or via the Overflow Menu). Please see this article for further help and information on adding a flow collector to an Entuity server.

The table in this tab contains the following information:

Incoming Connections tab:

The Incoming Connections tab lists all the remote servers that initiate connection with the local consolidation server. From this tab, you can approve the relationship between the remote and the consolidation server, and you can also assign and reassign roles to servers.

Remote servers with connection requests that have not yet been approved will be listed as 'Unassigned' in the Assigned Roles column. The number next to the title of the tab shows the total number of unassigned relationships:

For help and information on approving incoming connections and assigning roles to a remote server, please see this article.

The table on this tab displays the following information:

Central Servers tab:

The Central Servers tab displays all servers, including the current server itself, that can use this server as a poller, peer, and/or flow collector server.

The table under this tab displays the following details:

The Add Connection button is the means by which the current remote server can initiate a connection with a consolidation server (downstrean-to-upstream). Please see this article for further help and information on adding a new connection from a remote server to a consolidation server.

Cloning Entuity servers:

When installing multiple Entuity servers, you might want to clone an existing install, especially where Entuity is installed to a virtual machine. For example, you may want to clone a server that has the required View configuration, user profiles, and report definitions.

There are considerations regarding cloned Entuity servers, however:

• the cloned server may be managing devices, and usually you would not want multiple servers managing the same devices.
• the cloned server would include a license tied to the original server. When licensing is controlled through a Central Licensing Server, then you must assign the new cloned server a license, or when assigned locally you must then obtain a new license.
• the cloned server would have the same server identifier (serverid) as the original server.

After you have cloned an Entuity server that has been used to manage your network (i.e. it includes user profiles and is managing devices), you need to do the following:

• assign to the cloned server its own server identifier. This is important in multi-server environments where Entuity servers are identified through their server identifier.
  • to assign a server identifier, ensure the cloned server is not running, and then from the command line run the following:
    

    configure serverid new

• obtain a new license from your Entuity representative.

If you want to retain or remove details from the original server:

• if you want to retain the user permissions, View structures and report definitions, but not the device inventory, then you must remove all devices from the Device Inventory page.
• if you want to start with a fresh installation, during install and configure you will need to instruct Entuity to delete the database.

Considerations for setting up multiple servers:

In multi-server environments, you should determine how you intend to group devices before assigning them to an Entuity server.

• Root cause analysis is local to each Entuity server. All hops along critical traceroute paths should be managed on the same server.
• Maps only show and maintain connections between devices managed by the same Entuity server. You can include devices managed by different servers on the same map, but you will need to manually connect them through manual topology.
• Connected End Host IP address identification requires ARP cache information to be collected on the same Entuity server that is managing the switches to which the hosts are connected (please see below).

Collecting ARP cache information:

In multi-server environments, an Entuity server may not manage routers from which it requires ARP cache information to perform end host IP address resolution on devices that it does manage.

For example, if you have two separate offices and a core distribution network that joins the two, it makes sense to manage the core routers on the same server. You can then build maps to display the core distribution network. The two offices you can manage on separate Entuity servers. However, this might leave one of the servers (the one that does not manage the core) without distribution routers from which to extract ARP cache data, which is used to populate connected end host IP addresses.

Rather than have multiple Entuity servers managing the same routers, you can (through a device file) configure ipman to collect ARP cache information from these routers. By default, provost runs ipman with -f, but does not reference a device file. You must create a device file, and then through entuity.cfg identify it to ipman. ipman can then collect ARP cache information from the routers specified in the device file.

1. Create a tab delimited text file containing the hostname or IP address, and SNMP read community string, for each router that ipman polls.
   For example, the file entuity_home\etc\arp_cache_devices.cfg contains:
   

   10.12.12.1 public
   rLondon01 commstring

2. In entuity.cfg, specify the name of the device file, D:\Entuity\etc\entuity.cfg:
   

   [ipman]
   devicefile=D:\Entuity\etc\arp_cache_devices.cfg

The next time you run ipman, it will reference the device file.

Note, Entuity recommends that you use the example location and name of the device file to ensure it is maintained during Entuity upgrades.

Monitoring multiple Entuity servers:

An Entuity central server polls its remote servers to check their reachability. The polling mechanism checks all layers of the central and remote server connection. By default, if the response time of any given remote server drops below the predefined timeout:

• the central server will stop requesting information from the remote server, e.g. requests are automatically disabled for the remote server's events and incidents, managed object details etc.
• the remote server will be reported as having a connection failure on the Multi-Server Configuration page.
• the central server will continue to poll all remote servers for their availability. This allows the central server to start re-polling a remote server when it becomes reachable again. 

Example multi-server setup:

In this example, there is a network managed by 4 Entuity servers: Server 1, Server 2, Server 3 and Server 4. You want to grant Server 1 access to the other three servers, and you do this by logging into Server 1 and entering the details of the other three servers through the Remote Entuity Servers page.

When you log in to one of the remote servers, e.g. Server 3, then through its Central Entuity Servers page you can see which Entuity servers have access to Server 3, which in this example will only be Server 1.  You have the option of revoking the access of Server 1.

Entuity servers can act as both a central and a remote server. In this example, you may want to allow more than one server to access information collected by the other servers. You could therefore allow Server 3 access to Server 1 and Server 2. In this case, on Server 3:

• Server 1 appears as both a central and remote server, reflecting the mutual level of trust.
• Server 2 appears as only a remote server, reflecting the one-way trust relationship.
• Server 4 is not visible, because it was not added to Server 3 as a remote server.

Server 3 is added as a central server to Server 1 and Server 2.

It is possible to configure all Entuity servers to act as both remote and central servers. This allows users (with the appropriate access levels) to access information on all servers from any other Entuity server.

Recommended best practices for setting up user groups and user permissions across multiple servers:

Entuity recommends mirroring configuration across all servers as far as possible. This would require you to create the same user groups on each server, and then add the same permissions to each group on each server. Account Administration can be undertaken through the UI via the Account Management page, or via Entuity's RESTfulAPI functionality.

However, there are circumstances where you might want to have different permissions per server, for example in the case of MSPs who might want to keep access between customer servers separate. In this case, you will need to go to the individual server and change the permissions there, e.g. turning off permissions for Customer B on Customer A’s server.

Incidents and events:

The following incidents can be opened and events raised on the upstream (consolidated) server:

Remote Server Suspended

• opened by Background Reachability Check Failed event, which is raised if the expected incoming connection is not in place.
• closed by Background Reachability Check Succeeded event, which is raised if the expected incoming connection is now established after failure.