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)

Info

It is possible to implement the senhasegura architecture using the following:

The senhasegura architecture is designed to minimize interruptions caused by hardware or software failures. In this way, senhasegura provides continuity of services through high redundancy components.

High availability Principles

  • Elimination of single points of failure. This means adding or building redundancy into the system so that the failure of a component does not mean the failure of the entire system.
  • Reliable crossover. In redundant systems, the crossover point becomes a single failure point. Reliable systems must provide for reliable crossover.
  • Detection of failures as they occur. If the two principles above are observed, a user may never see a failure – but the maintenance activity must.

Replication technologies

There are many replication layers in senhasegura architecture to grant all data to be available in all senhasegura instances.

LayerDescription
Native database replicationsenhasegura uses MariaDB Galera Cluster to grant database data replication, configured by default to support high latency networks
File system replication using RsyncAll instances will echo their files between all cluster members
Kernel layer replication*When working with PAM Crypto Appliances, you also have a DRBD implemented

*Only for PAM Crypto Appliances



Architectures

Appliances




You can implement using the following:

scenarioDescription
Two PAM Virtual Appliances
  • Failover is done manually with synchronous automatic synchronization
  • In case of failure, the contingency environment will enter read-only mode, waiting for the manual failover by the user or load-balancer rules
Two PAM Crypto Appliances
  • Devices have a heartbeat connection for fault detection and synchronization cables
  • When one device must assume the role of the other, the process is automatic and occurs within a maximum of 120 seconds
  • If the cause of the PAM Crypto Appliance shutdown is a temporary failure, it will be reset automatically
  • In case of hardware failure, the return will be manual
Hybrid Scenario with PAM Crypto Appliances and Virtual Appliances
  • Failover is done manually with synchronous automatic synchronization
  • In case of failure, the contingency environment will enter read-only mode, waiting for the manual failover to be done by the user or load-balancer rules
Hybrid Scenario with on-premise and cloud instances
  • Failover is done manually with synchronous automatic synchronization
  • In case of failure, the contingency environment will enter read-only mode, waiting for the manual failover to be done by the user or load-balancer rules




Scenarios

Info
A Member is a senhasegura instance

Two Members (no arbitrator)

ScenarioTypeApplication StatusFailOverAutomatic Resync
1Fall Member 2Available

Automatic

Available
2

Fall Member 1

Available (Member 2)

Manual

Available

3

Link Failure (between sites)

Available (Member 1)

Automatic

Available

4

Fall Node 1 and 2

Not available

Not available

Not available

Examples

Scenario 1 - Fall Member 2

  • Application Status: The application will stay running on the first member
  • FailOver: Automatic
  • Unavailable Members Recovery: Automatic once the instance is powered back on or regains connectivity

Scenario 2 - Fall Member 1

  • Application Status: The application will stay running on the second member
  • FailOver: Manual
  • Unavailable Members Recovery: Automatic once the instance is powered back on or regains connectivity

Scenario 3 - Link Failure (Between sites)

  • Application Status: The application will keep running on the first member
  • FailOver: Automatic
  • Unavailable Members Recovery: Automatic once the instance is powered back on or regains connectivity

Scenario 4 - Fall Node 1 and 2

  • Application Status: The application is unavailable
  • FailOver: None
  • Unavailable Members Recovery: It is necessary to activate senhasegura support to restore members
  • In case of failure of all members, the master key and credential backup procedure should be used.

Two Nodes (with arbitrator)

ScenarioTypeApplication StatusFailOverAutomatic Resync
1Failure Member 2Available (Member 1) Automatic

Available

2

Failure Member 1

Available (Member 2)

Automatic

Available

3

Link Failure (between sites)

Available (Member in the same arbitrator's location) 

Automatic

Available

4

Failure Members 1 and 2

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 - Fall Member 2

  • Application Status: The application will stay running on the first member
  • FailOver: Automatic
  • Unavailable Members Recovery: Automatic once the instance is powered back on or regains connectivity

Scenario 2 - Fall Member 1

  • Application Status: The application will stay running on the second member
  • FailOver: Automatic
  • Unavailable Members Recovery: Automatic once the instance is powered back on or regains connectivity

Scenario 3 - Link Failure (Between sites)

  • Application Status: The application will keep running on the member on the same site as the Arbitrator
  • FailOver: Automatic
  • Unavailable Members Recovery: Automatic once the instance is powered back on or regains connectivity

Scenario 4 - Fall Node 1 and 2

  • Application Status: The application is unavailable
  • FailOver: Not available
  • Unavailable Members Recovery: It is necessary to activate senhasegura support to restore members
  • In case of failure of all members, the master key and credential backup procedure should be used.

Scenario 5 - Failure Arbitrator

  • Application Status: The application will be available to both senhasegura members members
  • FailOver: Automatic
  • Unavailable Members Recovery: Automatic once the instance is powered back on or regains connectivity

Scenario 6 - Failure Arbitrator

  • Application Status: The application is unavailable
  • FailOver: Not available
  • Unavailable Members Recovery: Not available, It is necessary to activate senhasegura support to restore members
    • In case of failure of all members, the master key and credential backup procedure should be used.

Three Nodes

ScenarioTypeApplication StatusFailOverAutomatic Resync
1Failure Member 2Available (Members 1 and 3)

Automatic

Available
2

Failure Member 1

Available (Members 2 and 3) 

Automatic

Available

3

Failure Member 3

Available (Members 1 and 2) 

Automatic

Available

4

Link Failure with one member

Available (All the other members)

Automatic

Available

5

Link Failure (Between all members)

Available (Member 1)

Not available

Not available

6

Failure of all members

Not available

Not available

Not available

Examples

Scenario 1 - Fall Member 2

  • Application Status: The application will stay running on members 1 and 3
  • FailOver: Automatic
  • Unavailable Members Recovery: Automatic once the instance is powered back on or regains connectivity

Scenario 2 - Fall Member 1

  • Application Status: The application will stay running on members 2 and 3
  • FailOver: Automatic
  • Unavailable Members Recovery: Automatic once the instance is powered back on or regains connectivity

Scenario 3 - Fall Member 3

  • Application Status: The application will stay running on members 1 and 2
  • FailOver: Automatic
  • Unavailable Members Recovery: Automatic once the instance is powered back on or regains connectivity

Scenario 4 - Link Failure with one member

  • Application Status: The application will stay running on the other members connected with the cluster
  • FailOver: Automatic
  • Unavailable Members Recovery: Automatic once the instance is powered back on or regains connectivity

Scenario 5 - Link Failure (Between all members)

  • Application Status: The application will stay running on the first member
  • FailOver: Not available
  • Unavailable Members Recovery: Automatic once the instance is powered back on or regains connectivity

Scenario 6 - Failure of all members

  • Application Status: The application is unavailable
  • FailOver: Not available 
  • Unavailable Members Recovery: Not available, It is necessary to activate senhasegura support to restore members
    • In case of failure of all members, the master key and credential backup procedure should be used.



Disaster Recovery (DR)

Disaster recovery involves a set of policies and procedures that allow the recovery of the data or infrastructure in case of a natural or artificial disaster. It enables the redefinition of senhasegura resources in an alternative environment when it is impossible to recover the primary environment reasonably.

The difference in data will depend on the quality and speed of the links about the volume of data generated by a cluster. If these variables are inappropriate, there may be data loss, production environment shutdown, and DR environment activation. In case of hardware failures, resetting and returning occur manually.


Hot-Spare features

senhasegura instances have monitoring and administrative URLs to monitor their status that load-balancers can use to switch instances into an unavailability scenario automatically.

self Load balancer

You can use a proprietary load balancer or acquire the senhasegura Load-balancer into your cluster scenario. See more in senhasegura Load-balancer manual.



Was this article helpful?