Create and Add GigaVUE-FM Instances to HA Group
To add instances and to configure the HA group:
1. | Go to ![]() |
2. | Click Create. The High Availability wizard appears. |
3. | In the Group Name field, enter a unique name for the HA group. |
Note: Avoid using functionality names as the group alias when creating an FMHA group. Functionality names typically refer to actions or operations within the system and can cause confusion and conflicts. Choose a unique and descriptive name instead.
4. | Choose any one of the following options to encrypt the communication between nodes: |
Pre-shared Secret Key – Encrypts communication between GigaVUE‑FM nodes using an application-managed shared secret key. Refer to Encryption of Communication between FMHA Nodes. |
Certificate Based – Encrypts communication between GigaVUE‑FM nodes using manually uploaded certificates. Refer to Encryption of Communication between FMHA Nodes. |
5. | In the Add GigaVUE-FM Instance section, the details of the GigaVUE-FM instance from which the HA group is created will be fetched automatically. |
6. | Enter the External IP Address and Third-Party Authentication details, if required. Click the save icon to save the configuration. |
7. | Click Add New Node to add the GigaVUE-FM instances. Enter the following details.: |
IP Address/DNS Name - IP address/DNS name of the GigaVUE-FM instance (s for communication between the GigaVUE-FMs and to configure the HA group). It is always recommended to use the DNS name while creating the GigaVUE-FM High Availability group. |
External IP Address - External IP address of the GigaVUE-FM instance (for accessing the GigaVUE-FM HA from outside the internal network.). |
Role - Role of the GigaVUE-FM instance. Can be configured as either: |
• | Active Eligible- provides resiliency and load distribution. |
• | Supporting Node- provides scalability and performance. |
Username - GigaVUE-FM Username. |
Password - GigaVUE-FM GUI password. |
Third Party Authentication - Third-party authentication URL. |
8. | Click Save Node ![]() |
Once three active instances are added to the HA group, the Submit button is enabled.
Note: When creating a HA group, all the existing data on the first configured GigaVUE-FM instance will be preserved, allowing the system to continue using the data after it is fully set up. However, the data on the subsequent nodes will be lost during the setup.
9. | Use the Add New Node button to continue to add the GigaVUE-FM HA instances. When adding the instances, define the role of the instances either as: |
- Active Eligible
- Supporting Node
10. | Review the details of the GigaVUE-FM instances. Use the Back button to go back and change the details. |
11. | Click the Edit Node icon to edit the details of the GigaVUE-FM instances, if required. |
After adding the instances to the HA group, click Submit. The HA group is configured and will be displayed as follows:
Note: When switching between the Pre-shared Secret Key and Certificate-Based options for encrypting communication between nodes, it's important to refresh the GigaVUE-FM to see the updated tunnel status. By clicking the link in the Tunnel Status, GigaVUE-FM displays the health status of the FMHA nodes.
Click the ellipses on a GigaVUE-FM instance to perform the following tasks:
- Edit: Edit the instance details.
- Reboot: Reboot a GigaVUE-FM instance.
- Remove from group: Remove an instance from the HA group.
The HA page displays the following details:
Field |
Description |
Status and Reachability |
Status of the GigaVUE-FM instances. Can be:
Reachability:
|
IP Address/DNS Name |
IP address/DNS name of the GigaVUE-FM instances |
Role |
Role of the GigaVUE-FM instance. Can be configured as follows:
|
Entity ID |
Entity ID of GigaVUE-FM. It is a unique alpha-numeric ID that must be configured for SSO authentication. |
Host Name |
Host name of the GigaVUE-FM instance. |
Application Status |
Status of application services that are responsible for handling the user requests:
|
Software Version |
Software version of the GigaVUE-FM instance. |
System Uptime |
Time since the instance is up and active. |
Third Party Authentication URL |
Third party authentication URL required for SSO configuration. |
Upgrade Status |
Upgrade status of GigaVUE-FM. This is displayed only when the upgrade is triggered. Otherwise, this field is empty. |
You can add instances to the HA group by clicking the Add New Node button, as required. You can also remove the instances from the HA group and reduce the size of the HA group as required. However, while removing the instances ensure to retain the quorum1 number of instances.
Note: To scale components such as Fabric Health Analytics, topology visualization and to improve the performance of GigaVUE-FM by fully utilizing the resource available, it is recommended to configure three active eligible instances and additional supporting instances.
The following are the behavioral changes observed in the HA group with active, standby and supporting instances:
Task | Scenario | Behavior |
---|---|---|
Backup and Restore Operation |
All active-eligible instances are up and few or all supporting instances are up. |
Backup will happen in active instance. During restore, all active-eligible GigaVUE-FMs will be rebooted and will perform the restore operation. Supporting instances will not participate in the restoration. |
Few active-eligible instances are up (Quorum number of instances are up) | Backup will happen in active instances. Restore will not be initiated in this case. | |
Upgrade Operation | Few instances not being up (either active-eligible or supporting instances not up) | Upgrade will not be initiated. |
Few supporting instances are removed from the HA group after formation of the group | Upgrade will be initiated, and the supporting instances present in HA group will be upgraded first followed by the active-eligible instances. | |
All instances are up and running | Upgrade will be initiated in an active instance. Upgrade will be done in a rolling fashion starting with supporting instances and ending with the active-eligible instances. | |
System Configurations | All instances are active-eligible | All GigaVUE-FM's GUI will be accessible, and user can configure the system through the same |
HA with active-eligible and few Supporting instances | For supporting instances, GUI will not be available (as application service is shut down). An option is provided in the GUI to turn on the application service and its dependent service(s) and the status can be seen in HA page. You can then configure the system related configuration from the logged in GigaVUE-FM instance once the application status of the supporting instance is up. | |
Background processes | ||
-FM Service Distribution | All GigaVUE-FMs are active-eligible instances. | Services will be equally distributed/redistributed among the instances based on the availability of the instances. |
HA group with active-eligible instances and supporting instances. | Services will be distributed/re-distributed only to active eligible instances | |
-Load Balancer | All GigaVUE-FMs are active-eligible instances. | All GigaVUE-FM API requests will be distributed to all instances in the HA group. |
With supporting instances. | All GigaVUE-FM API requests will be distributed only to active-eligible instances. |

Keep in mind the following recommendations and notes when working with the HA group.
GigaVUE-FM cannot support more than 7 active-eligible nodes (this is due to the underlying constraint in MongoDB).
- When reducing the size of a HA group that has both active-eligible and supporting instances, it is always recommended to remove the supporting instances first so that the active-eligible instances remain intact in the HA group. If active-eligible instances are removed first from the HA group, then the HA group will become unstable. This, however, depends on the number of active-eligible and supporting instances in the HA group. Consider a GigaVUE-FM HA group with 7 instances. The number of active and supporting instances in a HA group may be as follows:
- When reducing the size of HA group from 7 instance to 5 instance or 3 instance, the quorum is re-computed and adjusted accordingly. This is to ensure that the HA group remains intact with the available set of instances.
- When reducing the size of the HA cluster, during removal of an instance make sure to give time for the OpenSearch to rebalance and return to a complete (100%) healthy state before removing the next instance. If you remove the instances subsequently one after the other, the health state of the HA group will turn red as there will be no time for shard rebalancing amongst the available instances.
Login to GigaVUE-FM CLI as a root user and execute the following command to check the ES cluster health:
Shrinking the size of the HA group:
HA group 1 | With 3 active instances and 4 supporting instances | The recommendation is specifically applicable for HA group 1 in which there are only 3 active eligible instances in the group. Removing the active-eligible instances may cause the HA group to become unstable. |
HA group 2 | With 5 active instances and 2 supporting instances. | The recommendation is not applicable for HA group 2 as removing the active-eligible instances will not impact the stability of the HA group. |
For a HA group to be stable, it must have a minimum of two active-eligible instances in the group.
curl -XGET "http://localhost:9200/_cluster/health?pretty"
Supporting GigaVUE-FM Instances:
- When a supporting instance is added to the HA group, its system information will not be available immediately and will be available only after a minute.
- When the HA group is upgraded, application services of the supporting instances will be turned on automatically for the upgrade and once GigaVUE‑FM HA upgrade is completed it will be turned off automatically. Application services will be turned off automatically irrespective of the upgrade completion status, that is, either success or failure.
- For supporting instances, system information will be populated into MongoDB as the Application Service is down by default (scheduler populates the system information every minute into MongoDB). Hence any changes in the system hostname or GigaVUE-FM version will be reflected in the GUI only after a minute.
- In case of suspended mode, MongoDB will go into write protected mode. Therefore, any system related updates performed in the supporting nodes will not be reflected in the GUI.
- If the supporting instance is not reachable, all system related information that is populated in the GUI reflects the previous known values and not the latest values for Application Status, Up Time, and other system related information.
- Whenever the application services are up and running, events will be logged in the Events page (with the severity level - Info)