Check Cluster Configuration

<< Click to Display Table of Contents >>

Navigation:  Help Content > Administration > Cluster >

Check Cluster Configuration

Previous pageReturn to chapter overviewNext page

 

Purpose

 

The check cluster configuration tool is a very useful, one-click instrument to quickly checking that the current SARscape cluster configuration is working as expected. This tool carries out a series of simulated cluster operations to make sure that each required functionality is operative. We recommend to run this tool after each modification to the SARscape cluster configuration or to one of the machines that are part of it (e.g., after a system, driver, or network address update).

The check cluster configuration tool also performs some benchmark on the speed data is sent/received through the cluster nodes, on how fast is the storage available in each processing nodes, and on each processing node computational power. This information should help in the identification of potential resource shortage, contention, and other problems that might affect the performance of SARscape cluster.

In more detail, this item carries out a series of simple cluster connection tests, in which dummy files are copied to and from each cluster node. A failure of the test indicates a connection problem between the client machine and the cluster frontend (i.e., the machine on which the SarsXRoad application is running) or one of the cluster nodes (i.e., during peer-to-peer file copy). This could be due to incorrect IP addresses of the client machine and/or the SarsXRoad/SarsDaemon machines (see Cluster Preferences), or a network related issue (e.g., unavailable network connection or a firewall blocking specific port numbers).

In addition, a series of very large files is created on each cluster processing node to measure the storage read/write performance. This test is done first on a per-processing node basis, and then by having all the processing nodes do the same test together. If a significant difference in performance is detected between the single-node and the all-in variants, some storage might be shared among multiple processing nodes and lead to a decreased performance.

Similarly, a CPU stress test is performed by first running a series of simulated computations on a per-processing node basis and then by having all the processing nodes do the same test together. In this case, too, when a significant difference in performance is detected, it might be due to resource contention between different processing nodes running on one same machine and sharing the same computational resources.