|
1 | 1 | --- |
2 | | -title: "3-AZ resilience - Mechanisms and reference architectures" |
| 2 | +title: "3-AZ resilience: Mechanisms and reference architectures" |
3 | 3 | excerpt: "Understand 3-AZ resilience mechanisms and explore OVHcloud reference architectures" |
4 | 4 | updated: 2025-03-21 |
5 | 5 | --- |
@@ -30,18 +30,18 @@ The table below lists the services offered, their scope (zonal or regional), and |
30 | 30 |
|
31 | 31 | | Service | Zonal/Local | Regional | Architecture/Configuration Best Practices | In case of AZ failure | |
32 | 32 | | ------- | ----------- | -------- | ---------------------------------------------- | ------------------------------------------------------------------------------------ | |
33 | | -| Instances | X | | As instances are zonal services, they are only deployed in a single availability zone. To ensure resilience, customers must manually distribute their instances over several availability zones. Depending on your architecture and services, a regional load balancer may be the solution. For example, an active/passive clustered database distributed over two AZs can automatically switch from one instance to the other without a Load Balancer. | In the event of failure of one AZ, with resilience mechanisms, service continuity is ensured by your instances in the other AZs. | |
34 | | -| Private Network | | X | | DHCP/DNS agents operate in two AZs. If one AZ fails, they will be automatically reactivated in the AZ where they are not already running. | |
35 | | -| Public Cloud Load Balancer ( Octavia ) | | X | The regional Load Balancer consists of an active Load Balancer and a passive Load Balancer, each deployed in a separate AZ. | The service will remain available without interruption. In the event of failure of an AZ containing a Load Balancer node, the latter will automatically be moved to the last AZ. | |
36 | | -| Gateway | | X | The regional gateway consists of an active and a passive gateway, each deployed in a separate AZ. If an AZ containing a Gateway node fails, it will not be recreated in another AZ. | The service will remain available without interruption. | |
37 | | -| Floating Ip | | X | The customer can attach a multi-AZ Floating IP to any instance or Load Balancer in any AZ. | The service will remain available without interruption. | |
38 | | -| Object Storage ( Standard class) | X | | Object Storage is a regional service offering advanced data protection options, including integrated off-site replication via the Control Panel and S3-compatible asynchronous replication via the API for custom configuration. | No impact on Object Storage service or data. Data remains available for read and write operations, even in the event of an AZ failure. This configuration is ideal for high-availability, fault-tolerant applications. Once the AZ is restored, chunks are moved to the affected AZ. Learn more [here](/pages/storage_and_backup/object_storage/s3_regions_comparison). | |
39 | | -| Block storage High Speed | X | | HighSpeed is a zonal service with triple replication within a single AZ. To ensure resilience, customers must manually deploy HighSpeed Block Storage on several AZs to ensure service continuity. The use of volume backups (local or distant) can also be interesting in some use cases to restore local block storage. | In the event of a major outage, as the service is zonal, customers could lose their data and will have to recreate their Block volume (from backups for example) when the AZ is restored. | |
40 | | -| Block storage Classic Multi-Zone | | X | Block Storage Classic is a regional service using distributed erasure coding across several AZs. Off-site replication is recommended to protect against regional failure. | Block Storage data will remain available without impact or downtime. In the event of a major incident, chunks will be recreated as soon as the AZ is restored. | |
41 | | -| Managed Kubernetes Service | | X | With the Managed Kubernetes on 3-AZ regions, the Control Plane is distributed over 3 AZs. The customer must deploy worker nodes on several AZs and use Multi-Zone/Regional Block Storage for persistent volumes. | In the event of an AZ failure, the Control Plane remains available and the customer's workload is rescheduled on the nodes on another available AZ. <br> Note that workloads using persistent volumes of single-zone classes cannot be migrated to other AZs. When the AZ is restored, the Control Plane will become available again in the AZ and the unmigrated workload will resume. | |
42 | | -| DBaaS | | X | Database nodes are distributed across several nodes in different AZs. Backup is useful in the event of regional failure or for a single-node database. | In the event of an AZ failure, databases and data will remain available. The Production and Advanced offerings include at least two nodes, ensuring no service interruption. Backups are automatically managed by our services and stored off-site. Learn more [here](/pages/public_cloud/public_cloud_databases/databases_05_automated_backups). | |
43 | | -<!-- | Private Registry | | X | Based on S3, with a Control Plane distributed over several geographical zones. Off-site replication is recommended in the event of regional failure. | In the event of AZ failure, the registry remains available. <br> On the basis of S3 3-AZ/regional storage, the data will remain available without impact. <br> The chunks will be recreated once the AZ is operational again. | --> |
44 | | -<!-- | Rancher | | X | Rancher managed service is a “global” service | No impact | --> |
| 33 | +| Instances | <center>X</center> | | As instances are zonal services, they are only deployed in a single availability zone. To ensure resilience, customers must manually distribute their instances over several availability zones. Depending on your architecture and services, a regional load balancer may be the solution. For example, an active/passive clustered database distributed over two AZs can automatically switch from one instance to the other without a Load Balancer. | In the event of failure of one AZ, with resilience mechanisms, service continuity is ensured by your instances in the other AZs. | |
| 34 | +| Private Network | | <center>X</center> | | DHCP/DNS agents operate in two AZs. If one AZ fails, they will be automatically reactivated in the AZ where they are not already running. | |
| 35 | +| Public Cloud Load Balancer ( Octavia ) | | <center>X</center> | The regional Load Balancer consists of an active Load Balancer and a passive Load Balancer, each deployed in a separate AZ. | The service will remain available without interruption. In the event of failure of an AZ containing a Load Balancer node, the latter will automatically be moved to the last AZ. | |
| 36 | +| Gateway | | <center>X</center> | The regional gateway consists of an active and a passive gateway, each deployed in a separate AZ. If an AZ containing a Gateway node fails, it will not be recreated in another AZ. | The service will remain available without interruption. | |
| 37 | +| Floating IP | | <center>X</center> | The customer can attach a multi-AZ Floating IP to any instance or Load Balancer in any AZ. | The service will remain available without interruption. | |
| 38 | +| Object Storage ( Standard class ) | <center>X</center> | | Object Storage is a regional service offering advanced data protection options, including integrated off-site replication via the Control Panel and S3-compatible asynchronous replication via the API for custom configuration. | No impact on Object Storage service or data. Data remains available for read and write operations, even in the event of an AZ failure. This configuration is ideal for high-availability, fault-tolerant applications. Once the AZ is restored, chunks are moved to the affected AZ. Learn more [here](/pages/storage_and_backup/object_storage/s3_regions_comparison). | |
| 39 | +| Block storage High Speed | <center>X</center> | | HighSpeed is a zonal service with triple replication within a single AZ. To ensure resilience, customers must manually deploy HighSpeed Block Storage on several AZs to ensure service continuity. The use of volume backups (local or distant) can also be interesting in some use cases to restore local block storage. | In the event of a major outage, as the service is zonal, customers could lose their data and will have to recreate their Block volume (from backups for example) when the AZ is restored. | |
| 40 | +| Block storage Classic Multi-Zone | | <center>X</center> | Block Storage Classic is a regional service using distributed erasure coding across several AZs. Off-site replication is recommended to protect against regional failure. | Block Storage data will remain available without impact or downtime. In the event of a major incident, chunks will be recreated as soon as the AZ is restored. | |
| 41 | +| Managed Kubernetes Service | | <center>X</center> <br> <center>(Coming soon)</center> | With the Managed Kubernetes on 3-AZ regions, the Control Plane is distributed over 3 AZs. The customer must deploy worker nodes on several AZs and use Multi-Zone/Regional Block Storage for persistent volumes. | In the event of an AZ failure, the Control Plane remains available and the customer's workload is rescheduled on the nodes on another available AZ. <br> Note that workloads using persistent volumes of single-zone classes cannot be migrated to other AZs. When the AZ is restored, the Control Plane will become available again in the AZ and the unmigrated workload will resume. | |
| 42 | +| DBaaS | | <center>X</center> <br> <center>(Coming soon)</center> | Database nodes are distributed across several nodes in different AZs. Backup is useful in the event of regional failure or for a single-node database. | In the event of an AZ failure, databases and data will remain available. The Production and Advanced offerings include at least two nodes, ensuring no service interruption. Backups are automatically managed by our services and stored off-site. Learn more [here](/pages/public_cloud/public_cloud_databases/databases_05_automated_backups). | |
| 43 | +<!-- | Private Registry | | <center>X</center> | Based on S3, with a Control Plane distributed over several geographical zones. Off-site replication is recommended in the event of regional failure. | In the event of AZ failure, the registry remains available. <br> On the basis of S3 3-AZ/regional storage, the data will remain available without impact. <br> The chunks will be recreated once the AZ is operational again. | --> |
| 44 | +<!-- | Rancher | | <center>X</center> | Rancher managed service is a “global” service | No impact | --> |
45 | 45 | <!-- | File storage | | | File Storage is a zonal service with EC/triple replication within a single AZ. It is recommended to set up a backup or snapshot in another AZ. | In the event of a major outage, as the service is zonal, customers could lose their data and will have to recreate their file (from backups for example) when the AZ is restored. | --> |
46 | 46 |
|
47 | 47 | ## Reference architecture for Multi-AZ deployment |
|
0 commit comments