High availability and disaster recovery
- 5 minutes to read
-
Print
-
DarkLight
-
PDF
High availability and disaster recovery
- 5 minutes to read
-
Print
-
DarkLight
-
PDF
High availability (HA) and disaster recovery (DR)
Info
It is possible to implement the senhasegura architecture using the following:
- PAM Crypto Appliances running into on-premises data centers;
- PAM Virtual Appliances running into on-premises data centers;
- PAM Virtual Appliances running into cloud providers;
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.
| Layer | Description |
|---|---|
| Native database replication | senhasegura uses MariaDB Galera Cluster to grant database data replication, configured by default to support high latency networks |
| File system replication using Rsync | All 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:
| scenario | Description |
|---|---|
| Two PAM Virtual Appliances |
|
| Two PAM Crypto Appliances |
|
| Hybrid Scenario with PAM Crypto Appliances and Virtual Appliances |
|
| Hybrid Scenario with on-premise and cloud instances |
|
Scenarios
Info
A Member is a senhasegura instance
Two Members (no arbitrator)
| Scenario | Type | Application Status | FailOver | Automatic Resync |
|---|---|---|---|---|
| 1 | Fall Member 2 | Available | 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)
| Scenario | Type | Application Status | FailOver | Automatic Resync |
|---|---|---|---|---|
| 1 | Failure Member 2 | Available (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 |
| 5 | Failure Arbitrator | Available (Both Members) | Automatic | Available |
| 6 | Failure 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
| Scenario | Type | Application Status | FailOver | Automatic Resync |
|---|---|---|---|---|
| 1 | Failure Member 2 | Available (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?
