- 3 minutes to read
Configure a cluster
- 3 minutes to read
- Update all cluster members; they must be on the same version.
- Activate instance licenses in Portal Affinity.
- The Backup drive must be accessible to all instances.
- Configure the instances on the same network; there must be a connection between the machines. See Configuring Network Interfaces and Hostname and Server Settings.
- Release the following ports on the Firewall between all instances:
- TCP (22, 443, 3306, 4444, 4567, 4568, 59022 e 9300)
- UDP (4567)
Steps to create cluster
- Download the senhasegura application from the PAM Solution Center in the Virtual Appliances section.
- Change the default application password.
- Configure the application's Hostname.
- Configure the NTP Server.
- Configure DNS.
- Configure the Network.
- Define a backup drive.
- Back up your data and get a snapshot of the instance as a guarantee.
You can create a new cluster or add instances to an existing cluster.
- Go to Orbit Config Manager ➔ Replication ➔ Settings.
- Set Operating Mode to Cluster and enable replication.
- Enable File Synchronizers and set the Sync Timeout.
- Add Cluster Member IPs.
Complete the IPs in the same order on all cluster members.
- Check if Members are in different data centers.
- Set a recovery screen display message for failure cases.
- Click Save.
- Click Yes to confirm that you want to change your database settings and restart the service.
- If this is the primary instance, click on Take over as master.
Configure only one instance as master. If the master instance fails, configure another instance as the master.
- Check the status that the system has already been restored and that the first node of the cluster has been successfully created and proceeded.
- Repeat the process with the subsequent cluster instances.
After configuring the first instance and configuring the following ones, they will have their system restarted and the database updated and added to the cluster. They are given the same password as the primary cluster member. To learn more, see also: Cluster Architecture.
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.
- Enable the Allow Remote System Wakeup parameter.
- Add the list of IPs allowed to perform the request in the Allowed source IPs for remote system activation field.
- Click Save.
Perform this operation on all cluster members.
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.
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.
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.
Always keep track of which instances are active and inactive in the cluster. Don't risk accidentally shutting down all instances, causing user operations to be interrupted.