Ensuring high availability of the GUI service

You need multiple GUI nodes to be configured in the system to ensure high availability of the GUI service. You also need to set up a cluster configure repository (CCR) when you plan to configure multiple GUI nodes in the cluster. The CCR is used to store certain important configuration details that must be shared among all GUI nodes.

The following figure illustrates the GUI high availability configuration with two GUI nodes.

High availability configuration of GUI that contains two GUI nodes — Figure 1. High availability configuration of GUI with two GUI nodes

The following list provides the configuration requirements to ensure high availability of the GUI service:

Up to three GUI nodes can be configured in a cluster. Perform the following steps to set up a GUI node:
- Install the GUI package on the node. For more information about latest packages, see Manually installing IBM Storage Scale management GUI.
- Start the GUI service and either log in or run /usr/lpp/mmfs/gui/cli/initgui to initialize the GUI database. Now, the GUI becomes fully functional and it adds the node to the GUI_MGMT_SERVERS node class.
The GUI nodes are configured in the active/active configuration. All GUI nodes are fully functional and can be used in parallel.
Each GUI has its own local configuration cache in PostgreSQL and collects configuration changes individually.
One GUI node is elected as the master node. This GUI instance exclusively performs some tasks that must be run only once in a cluster such as running snapshot schedules, sending email, and SNMP notifications. If services that are run on the master GUI node are configured, the environment for all the GUI nodes must support these services on all nodes. For example, it needs to be ensured that access to SMTP and SNMP servers is possible from all GUI nodes and not only from the master GUI node. You can use the following utility function, which displays the current master GUI node:
```
[root@gpfsgui-11 ~]# /usr/lpp/mmfs/gui/cli/lsnode
Hostname             IP          Description     Role               Product version Connection status GPFS status Last updated
gpfsgui-11.novalocal 10.0.100.12 Master GUI Node management,storage 5.0.0.0         HEALTHY           HEALTHY     7/10/17 10:19 AM
gpfsgui-12.novalocal 10.0.100.13                 storage,ces        5.0.0.0         HEALTHY           HEALTHY     7/10/17 10:19 AM
gpfsgui-13.novalocal 10.0.100.14                 storage,ces        5.0.0.0         HEALTHY           HEALTHY     7/10/17 10:19 AM
```
All GUI nodes are equal from the user’s perspective. If a GUI node fails, the user must manually connect to the other GUI. The master role fails over automatically. But there is no failover for the IP address of the other GUI server.
Data that cannot be gathered from GPFS is stored in CCR as shared-cluster repository. This includes GUI users, groups and roles, snapshot schedules, email notification settings, policy templates, and ACL templates.
All GUI nodes must run on the same software level.
If an external authentication method such as AD or LDAP is used to store the GUI user details and authenticate them, you must configure AD/LDAP on all GUI nodes to ensure high-availability. The Trustore key that is used during external authentication, must be created by using the public keys generated by all the GUI nodes in the cluster. If internal authentication method is used, the GUI nodes get the user information from the CCR.
To display the performance monitoring information, install performance monitoring collector on each GUI node and these collectors must be configured in the federated mode. The data collection from the sensors can be configured in such a way that the details are sent either to all collectors or only to a single collector.
The Mark as Read operation can be performed on events that are stored locally on the GUI node. The changes that are made to the events are not visible through the other GUI node.
Each GUI has its own local configuration cache and collects configuration changes individually.
A corrupted cache database affects only the local GUI. Other GUIs continue working. Most of the configuration changes are simultaneously reported in the GUI. Some configuration changes are gathered through the individually scheduled refresh tasks, which might result in displaying unsynchronized information.