High availability and disaster recovery
  • 5 minutes to read
  • Dark
    Light
  • PDF

High availability and disaster recovery

  • Dark
    Light
  • PDF

Article Summary

High availability (HA) and disaster recovery (DR)

Note

You can implement senhasegura's architecture using any of the options below:

senhasegura's architecture was designed to contain redundancies that can withstand hardware or software failures to minimize unplanned downtime.

The Principles of High Availability

  • Eliminating single points of failure (SPOF). By building redundancies, the entire system remains operational even if a component fails.
  • Reliable crossover. In redundant systems, the crossover point may become a SPOF itself. A truly reliable system must be able to switch from one component to another without losing data or impacting performance.
  • Real-time failure detection. If the above two principles are observed, any failures will probably go unnoticed by users. However, maintenance teams must still be able to detect failures as soon as they occur.

Replication technologies

senhasegura's architecture includes several replication layers that ensure data is accessible in all your senhasegura instances.

LayerDescription
Native database replicationBy default, senhasegura uses MariaDB Galera Cluster to replicate databases and support even higher-latency networks.
File system replication using RsyncAll senhasegura instances synchronize their files with the other members of the cluster.
Kernel layer replication*PAM Crypto Appliances also include a DRBD.

*Only available for PAM Crypto Appliances



Architectures

Appliances




Implementation strategies may vary depending on the Appliances you use:

Appliance CombinationDescription
Two PAM Virtual Appliances
  • Failover is performed manually, with automatic synchronous replication
  • In case of failure, the backup environment will provide read-only access to the data until the user or Load Balancer completes the failover
Two PAM Crypto Appliances
  • The devices connect via sync cables and use a heartbeat connection to detect failures

  • When the standby device needs to assume the primary role, the change takes place automatically within 120 seconds or less

  • In case your PAM Crypto Appliance was shut down due to a temporary failure, it will restore the role of primary device
  • If, instead, the problem was caused by malfunctioning hardware, you will have to reassign the primary device manually

PAM Crypto Appliances and Virtual Appliances Combined

  • Failover is performed manually, with automatic synchronous replication
  • In case of failure, the backup environment will provide read-only access to the data until the user or Load Balancer completes the failover

On-premises and Cloud Instances Combined

  • Failover is performed manually, with automatic synchronous replication

  • In case of failure, the backup environment will provide read-only access to the data until the user or Load Balancer completes the failover




Scenarios

Note
Each Member represents an instance in senhasegura.

Two Members (no arbitrator)

ScenarioTypeApplication StatusFailOverAutomatic Resync
1Member 2 FailsAvailable (Member 1) 

Automatic

Available
2

Member 1 Fails

Available (Member 2)

Manual

Available

3

Connection Failure (Between sites)

Available (Member 1)

Automatic

Available

4

Members 1 and 2 Fail

Not available

Not available

Not available

Examples

Scenario 1 - Member 2 Fails

  • Application Status: The application continues to run on the first member
  • FailOver: Automatic
  • Unavailable Members Recovery: Automatic once the instance reboots or regains connectivity 

Scenario 2 - Member 1 Fails

  • Application Status: The application continues to run on the second member
  • FailOver: Manual
  • Unavailable Members Recovery: Automatic once the instance reboots or regains connectivity 

Scenario 3 - Connection Failure (Between sites)

  • Application Status: The application continues to run on the first member
  • FailOver: Automatic
  • Unavailable Members Recovery: Automatic once the instance reboots or regains connectivity 

Scenario 4 - Fall Node 1 and 2

  • Application Status: The application becomes unavailable
  • FailOver: None
  • Member Failure Recovery: contact senhasegura's support team to restore these members 
  • If all members fail simultaneously, use the master key and credential backup procedure

Two Members (with arbitrator)

ScenarioTypeApplication StatusFailOverAutomatic Resync
1Member 2 FailsAvailable (Member 1) Automatic

Available

2

Member 1 Fails

Available (Member 2)

Automatic

Available

3

Connection Failure (Between sites)

Available (Member at the same site as the arbitrator) 

Automatic

Available

4

Members 1 and 2 Fail

Not available

Not available

Not available

5Failure ArbitratorAvailable  (Both Members)

Automatic

Available

6Failure Arbitrator and any other Member

Not available

Not available

Not available

Examples

Scenario 1 - Member 2 Fails

  • Application Status: The application continues to run on the first member
  • FailOver: Automatic
  • Member Failure Recovery: Automatic once the instance reboots or regains connectivity

Scenario 2 - Member 1 Fails

  • Application Status: The application continues to run on the second member
  • FailOver: Automatic
  • Member Failure Recovery: Automatic once the instance reboots or regains connectivity

Scenario 3 - Connection Failure (Between sites)

  • Application Status: The application continues to run on the member that is at the same site as the Arbitrator 
  • FailOver: Automatic
  • Member Failure Recovery: Automatic once the instance reboots or regains connectivity

Scenario 4 - Members 1 and 2 Fail

  • Application Status: The application is unavailable
  • FailOver: Not available
  • Member Failure Recovery: contact senhasegura's support team to restore these members 
  • If all members fail simultaneously, use the master key and credential backup procedure

Scenario 5 - Arbitrator Fails

  • Application Status: The application becomes available on both senhasegura members
  • FailOver: Automatic
  • Member Failure Recovery: Automatic once the instance reboots or regains connectivity

Scenario 6 - Arbitrator Fails

  • Application Status: The application becomes unavailable
  • FailOver: Not available
  • Member Failure Recovery: Not available, contact senhasegura's support team to restore these members
  • If all members fail simultaneously, use the master key and credential backup procedure

Three Members

ScenarioTypeApplication StatusFailOverAutomatic Resync
1Member 2 FailsAvailable (Members 1 and 3)

Automatic

Available
2

Member 1 Fails 

Available (Members 2 and 3) 

Automatic

Available

3

Member 3 Fails

Available (Members 1 and 2) 

Automatic

Available

4

Connection Failure with one member

Available (All the other members)

Automatic

Available

5

Connection Failure (Between all members)

Available (Member 1)

Not available

Not available

6

All Members Fail

Not available

Not available

Not available

Examples

Scenario 1 - Member 2 Fails

  • Application Status: The application continues to run on members 1 and 3
  • FailOver: Automatic
  • Member Failure Recovery: Automatic once the instance reboots or regains connectivity

Scenario 2 - Member 1 Fails

  • Application Status: The application continues to run on members 2 and 3
  • FailOver: Automatic
  • Member Failure Recovery: Automatic once the instance reboots or regains connectivity

Scenario 3 - Member 3 Fails

  • Application Status: The application continues to run on members 1 and 2
  • FailOver: Automatic
  • Member Failure Recovery: Automatic once the instance reboots or regains connectivity

Scenario 4 - Connection Failure with one member

  • Application Status: The application continues to run on the members still connected to the cluster
  • FailOver: Automatic
  • Member Failure Recovery: Automatic once the instance reboots or regains connectivity

Scenario 5 - Connection Failure (Between all members)

  • Application Status: The application continues to run on the first member
  • FailOver: Not available
  • Member Failure Recovery: Automatic once the instance reboots or regains connectivity

Scenario 6 - Failure of all members

  • Application Status: The application becomes unavailable
  • FailOver: Not available 
  • Member Failure Recovery: Not available, contact senhasegura's support team to restore these members  
  • If all members fail simultaneously, use the master key and credential backup procedure



Disaster Recovery (DR)

Disaster recovery involves a set of policies and procedures to recover data or restore infrastructure in case of a natural or artificial disaster. DR allows customers to reconfigure senhasegura resources using an alternative environment when it proves impossible to recover the primary environment as required.

Data integrity is subject to the quality and speed of a connection and the amount of data in a cluster. If any of these variables fail to meet the requirements, it may result in data loss, production environment shutdown, and the activation of the DR environment. A manual reboot and recovery process is required if the failure was caused by hardware problems.




Hot-Spare features

senhasegura instances include monitoring and administrative URLs that monitor their status. Load balancers can use these features to switch instances automatically in case one of the instances is down.

In-house Load balancer

You can choose to use a proprietary load balancer or add senhasegura's load balancer to your clustered environment. Click here to learn more about senhasegura's Load Balancer.



Was this article helpful?