Table of Contents
The Tungsten Dashboard can be directed to any IP address or domain of a Tungsten cluster. Upon establishing the initial connection, the system performs a topology discovery process. This process generates a list of dataservices and datasources within the Tungsten cluster.
Subsequent connection attempts are made to the node names that were returned during the topology discovery process. These node names must be Fully Qualified Domain Names (FQDNs) or be otherwise resolvable to the Dashboard backend process.
Please make sure that you have your DNS set up properly and have no misconfigurations. The initial host
must be reachable from the server hosting the Dashboard as well as other hosts in the cluster. Make sure
the internal DNS and /etc/tungsten/tungsten.ini of the cluster is configured properly and if using shortnames, then
hostname -f should always return the FQDN.
In cases where the node names are not directly resolvable, a mechanism is provided to create a mapping between the node names and their corresponding IP addresses. This mechanism is included as part of the Helm chart or docker-compose installation processes.
To utilize this feature, please refer to the values.yaml file in the case of a Helm chart
installation, or the docker-compose.yml file for a docker-compose installation.
The dashboard uses a custom communication protocol over a TCP socket. Please be aware that launching and connecting
Dashboard to a Tungsten Cluster will cause the Dashboard to show up as a router in
/api/v8/manager/cluster/topology endpoint as well as the API v2 endpoint.
The Dashboard will not behave like the other routers in this list and it can be only talked to from the TCP connection between the cluster and the Dashboard. While the dashboard will acknowledge any commands sent to it via the TCP connection, it will only act on a very select few of them. Avoid applying any of your customized logic to the dashboard through it's listing as a router.
Operations ran by the Dashboard users are effectively the same as sending RestAPI requests to the cluster's api. For more information about how to best manage the impact of the Dashboard to the clusters it is connected to checkout Chapter 9, Best Practices