Configure a cluster

Requirements

Steps to create cluster

1. Download the senhasegura application from the PAM Solution Center in the Virtual Appliances section.
2. Change the default application password.
3. Configure the application's Hostname.
4. Configure the NTP Server.
5. Configure DNS.
6. Configure the Network.
7. Define a backup drive.
8. Back up your data and get a snapshot of the instance as a guarantee.

9. Go to Orbit Config Manager ➔ Replication ➔ Settings.
10. Set Operating Mode to Cluster and enable replication.
11. Enable File Synchronizers and set the Sync Timeout.
12. Add Cluster Member IPs.

13. Check if Members are in different data centers.
14. Set a recovery screen display message for failure cases.
15. Click Save.
16. Click Yes to confirm that you want to change your database settings and restart the service.

17. If this is the primary instance, click on Take over as master.

18. Check the status that the system has already been restored and that the first node of the cluster has been successfully created and proceeded.
19. Repeat the process with the subsequent cluster instances.

Automatic instance switching

Instances of senhasegura can be remotely activated and deactivated through HTTP requests that can be made from your load balancer. This control allows an instance that is under maintenance, which is unavailable for some reason, not to be considered in the redirection of loads.

To configure IPs allowed to perform such query and operation, you must register the list of IPs in the field Remote system activation of the Orbit Config Manager ➔ Settings ➔ Recovery menu.

1. Enable the Allow Remote System Wakeup parameter.
2. Add the list of IPs allowed to perform the request in the Allowed source IPs for remote system activation field.
3. Click Save.

From this moment, registered IPs can access the monitoring URL GET /flow/orbit/mntr .E.g., https://mysenhasegura/flow/orbit/mntr.

This URL will respond to the current state of the instance. It can vary between:

• HTTP 200: Active and available application for users to use.
• HTTP 203: Active application is available for users but not the master.
• HTTP 403: The application is inactive and unavailable for users to use.
• HTTP 451: Expired activation license.
• HTTP 503: Application unavailable.

Thus, in a practical case, if the administrator disables the application of an instance, it starts to respond to HTTP 403 to the load balancer, which will no longer forward traffic to that instance. Just as if any instance loses communication between other cluster members, the database becomes unavailable. That instance will respond to HTTP 503 to the load balancer, which will no longer forward traffic to that instance.

Automatic instance activation and deactivation

Another interesting control is allowing an external system to control which instances should be activated and deactivated automatically. Imagine a scenario where the load of an entire network must be redirected to a contingency data center. Interestingly, the instance of this target data center is active and ready to receive the load of requests, and the old production instance loses its role as the main one.

In this way, you can switch between the roles of the instances through the activation/deactivation URL.

Activate

Activates users' instances as long as the activation license is valid. If successfully executed, the instance that previously played the role of Primary in the cluster loses its relevance, and this new instance receives the title of Primary. The other instances will not be automatically disabled.

Example: https://mysenhasegura/flow/orbit/mntr/activate.

Deactivate

 Inactivates the instance for users. If this instance is the Primary, it will be inactivated without electing any other cluster members as the new Primary. This action will also not activate the other instances if they are inactive.

Example: https://mysenhasegura/flow/orbit/mntr/deactivate