Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(deployment): create guide en & fr for the deployment modes #7311

Draft
wants to merge 4 commits into
base: develop
Choose a base branch
from
Draft

feat(deployment): create guide en & fr for the deployment modes #7311

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
6839f63
feat(deployment): create general guide for the deployment comparison …
OvhValentin Dec 16, 2024
9598811
feat(deployment): create guide en & fr for the deployment modes
OvhValentin Dec 17, 2024
f3f76e6
v2 fr and gb
OvhValentin Dec 20, 2024
34ff01a
add a description of the redundancy architecture for regions
OvhValentin Dec 24, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions pages/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -566,6 +566,7 @@
+ [Public Cloud Instances - Shared Responsibility](public_cloud/compute/responsibility-model-instances)
+ [Public Cloud FAQ - Change of monthly billing method](public_cloud/compute/faq_change_of_monthly_billing_method)
+ [Local Zone Compute - Features, Capabilities and Limitations](public_cloud/compute/local-zones-capabilities-limitations)
+ [Comparison and resilience of Deployment Modes - Understanding 3-AZ / 1-AZ / Local Zones](public_cloud/compute/deployment_modes_comparison_resilience_details/)
+ [Project management](public-cloud-compute-project-management)
+ [Securing and Structuring your public cloud projects](public_cloud/compute/securing_and_structuring_projects)
+ [How to increase Public Cloud quotas](public_cloud/compute/increasing_public_cloud_quota)
Expand Down
241 changes: 241 additions & 0 deletions ...lic_cloud/compute/deployment_modes_comparison_resilience_details/guide.en-gb.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,241 @@
---
title: "Comparison and resilience of Deployment Modes - Understanding 3-AZ / 1-AZ / Local Zones"
excerpt: "Explore OVHcloud's deployment modes"
updated: 2024-12-18
---

<style>
details>summary {
color:rgb(33, 153, 232) !important;
cursor: pointer;
}
details>summary::before {
content:'\25B6';
padding-right:1ch;
}
details[open]>summary::before {
content:'\25BC';
}
</style>

## Objective

OVHcloud offers several deployment models to meet different needs in terms of resilience, availability, performance and latency. This guide provides an overview of the main features of the deployment options available: 1-AZ, 3-AZ and Local Zones. It details their specific features, benefits and limitations to help you make the best strategic choices for your cloud deployments.

By offering a clear and detailed comparison, this guide will enable users to make an informed decision based on their specific priorities, whether it's ensuring high availability for critical applications, minimizing costs while providing fault tolerance, or meeting local compliance and ultra-low latency requirements.

Additionally, we will highlight the real-world challenges users may face, such as impacts on business continuity, scalability of services, and cost management in each deployment mode. This guide is particularly useful for cloud architects, IT managers, and developers looking to optimize their infrastructure based on specific business and technical needs.

## Concepts

OVHcloud provides a robust and adaptable infrastructure, designed to meet a wide variety of use cases through deployment models that balance cost-effectiveness, redundancy and fault tolerance. These different options allow users to choose the approach best suited to their resilience, availability and performance requirements.

1. **1-AZ Region**: These single-zone regions are ideal for workloads where cost optimisation is a priority. They are ideally suited to general needs such as storage, backup or applications whose availability requirements do not call for multi-zone redundancy. They offer a good compromise between reliability, performance and cost control.
2. **3-AZ Region**: This model is designed for mission-critical applications requiring high availability and resilience. By replicating data across three distinct availability zones, 3-AZ regions significantly reduce the risk of downtime, guaranteeing business continuity even in the event of incidents affecting one or more zones. This level of redundancy is particularly well suited to demanding production environments.
3. **Local Zones**: These infrastructures are specifically designed to meet needs requiring ultra-low latency or strict geographical constraints. By placing resources close to end-users, Local Zones are ideal for use cases such as high-end computing, video games, content delivery or solutions requiring local regulatory compliance.

Each of these options is based on the fundamental principles of resilience, performance and fault tolerance.

## Deployment modes

> [!primary]
>
> OVHcloud offers a number of regional deployment models, designed to meet the varying needs of businesses by offering different levels of redundancy, fault tolerance and geographical distribution. These options provide flexibility, scalability and resilience, enabling customers to align their infrastructure with their operational and strategic priorities.

### 1-AZ Region

#### Infrastructure and Redundancy

A 1-AZ region is **a single availability zone made up of several data centres in the same geographical area**. It uses a 2N+1 redundancy architecture, designed to ensure resilience against local hardware failures, such as disk or server failures. However, this configuration remains vulnerable to failures affecting the entire data centre.

Services and data are protected against localised incidents thanks to effective internal redundancy, but a major or total breakdown of a data centre could compromise the availability of services.

#### Characteristics

- **Erasure Coding:** Implements mechanisms such as replication or erasure coding (depending on the service) to ensure continuity in case of hardware failures. Data is distributed across multiple servers and storage units within the availability zone to mitigate the impact of localized issues.
- **Cost-Effectiveness:** This deployment model is cost-efficient, ideal for general-purpose workloads, development environments, and backups. It prioritizes affordability over enhanced fault tolerance provided by multi-AZ configurations.
- **Operational simplicity**: A single zone of availability facilitates management while offering minimal tolerance to internal failures.

#### Limitations

**Risk of outage:** Dependence on a single availability zone can affect critical services if the data centre suffers a complete outage.
**No regional redundancy**: Unlike multi-AZ deployments, there is no replication of data or services between different availability zones in the region.

> [!success]
>
> To improve resilience for critical applications in a 1-AZ Region, consider using asynchronous replication for added protection. This can help reinforce both application and data resiliency. Another option to mitigate this risk is using a [**3-AZ deployment mode**](#3azregion).

#### Redundancy Specifications for 1-AZ

| Specification | Description |
|-------------------|---------------------------------------------------------------------------|
| **Redundancy Type** | 2N+1 architecture distributed across several interconnected data centres. |
| **Fault Tolerance** | Protects against disk and server failures, but not against total data centre failure. |
| **Data protection** | Data replicated within the AZ to guarantee local resilience. |
| **Limits** | No inter-regional or inter-zone protection; dependent on a single AZ. |

**2N+1 architecture:**

This architecture doubles the resources required (2N) and adds an extra unit (+1) to guarantee continuity of service in the event of a local failure (server, disk). Resources are distributed between several datacentres in the same AZ, ensuring low latency and local resilience. However, it does not protect against a global failure of the AZ.

#### Scaling

In a 1-AZ Region, scaling options are somewhat limited due to the single availability zone. Here's how scaling works in this setup:

- **Vertical scaling:** Increasing the capacity of existing resources (CPU, memory) is a common solution, but it does not guarantee increased fault tolerance.
- **Horizontal scaling:** Although this is possible within the AZ, it does not provide redundancy between several availability zones.
- **Geographical constraint:** All resources remain confined to the same availability zone.

#### Architecture example

/// details | Internal management application

> [!primary]
>
> **Scenario:**
>
> An organization utilizes the 1-AZ Region mode for its internal management application and backup services. This setup is ideal for applications that do not require high availability 24/7, but still need redundancy to protect against hardware failures.

Architecture:
- **Single Availability Zone (AZ):** Made up of several interconnected data centres, it guarantees resilience in the face of localised breakdowns, while at the same time providing a model suited to moderate application requirements.
- **Internal replication:** Data is replicated internally to protect against disk or server failures within the zone.
- **Backup integration:** The application uses object storage for regular backups, ensuring that data can be restored if necessary.
- **Compute Instances:** Basic application tasks are handled by compute instances in the same AZ, with auto-scaling for resource management.

///

### 3-AZ Region

#### Infrastructure and Redundancy

3-AZ Regions consist of **three independent availability zones**, each with isolated power, cooling, and network systems, providing true fault isolation. This setup ensures service availability even in the event of an entire availability zone failure. The architecture enables the replication of data and services across zones, ensuring that if one zone goes down, the others can continue to serve traffic and maintain application performance.

#### Characteristics

- **High Availability:** Data remains available for both read and write operations, even in the event of a zone failure. This architecture is ideal for applications requiring fault tolerance, as the data is replicated across all three availability zones. Even in the event of a disruption in one zone, service continuity is maintained.
- **Fault isolation:** Each availability zone is independent in terms of power, networking, and cooling, which means issues in one zone won’t directly impact the others. This leads to a higher level of redundancy and ensures that service interruptions are minimized.
- **Optimised latency:** Low latency between zones ensures fast, reliable communications, ideal for demanding workloads.

#### Limits

- **Higher cost:** This configuration requires a higher initial investment, due to the duplication of services and the implementation of inter-zone replication mechanisms.
- **Not resilient to a complete regional failure:** Although robust in the face of local failures, a 3-AZ Region does not guarantee tolerance in the event of a failure affecting the entire region.
- **Management complexity:** Workloads must be designed to take advantage of this architecture, which may require additional expertise and effort.

#### Redundancy Specifications for 3-AZ

| Specification | Description |
|-------------------|---------------------------------------------------------------------------|
| **Type of redundancy** | 3N avec réplication inter-zones. |
| **Fault tolerance** | Guarantees resilience against the loss of an entire zone, with automatic failover. |
| **Data protection** | Data replicated synchronously between zones to guarantee continuous availability. |
| **Limits** | Does not protect against complete regional failure; requires multi-regional architecture for maximum resilience. |

**3N with inter-zone replication :**

In this architecture, resources are tripled (3N) and distributed between three distinct availability zones (AZ). Data is replicated synchronously between zones, guaranteeing total resilience against the loss of an entire zone thanks to automatic failover. However, this architecture does not protect against a complete regional failure.

#### Scaling

In a 3-AZ Region, scaling is more flexible, offering the ability to scale horizontally across multiple availability zones. Here’s what you can expect:

- **Optimized horizontal scaling:** With replication and distribution of services across three independent zones, horizontal scaling becomes more seamless, ensuring high availability, optimal performance, and efficient resource distribution.
- **Optimized load balancing:** With multiple availability zones, load balancing and traffic distribution are optimized, ensuring better performance and resilience.
- **Increased resilience:** The ability to scale between zones means you can meet growing demand while maintaining fault tolerance.

#### Architecture example

/// details | E-commerce platform

> [!primary]
>
> **Scenario:**
>
> An e-commerce platform that demands high availability and performance. This deployment mode ensures service continuity even in the event of a failure in one entire availability zone.

Architecture:
- **Three availability zones (AZs):** Each zone is geographically isolated to avoid the impact of a local disaster.
- **Data replication:** Synchronous replication of data between the three zones to guarantee continuous availability.
- **Distributed instances:** Application instances are deployed in each zone, ensuring redundancy and high availability.
- **Load balancers:** Load balancers manage user traffic by distributing requests between zones, even in the event of a failure.
- **Regional backups:** Backups are outsourced to a regional S3 solution to protect against total data loss.

///

### Local Zones

#### Infrastructure and design

Local Zones bring OVHcloud services closer to end users by reducing latency and enabling data to be processed locally. They are designed to offer optimal performance for applications requiring low latency and proximity to users, while meeting local compliance requirements.

Each Local Zone is an extension of a core region and operates as a single availability zone, making it ideal for scenarios where latency is a priority, but multi-AZ redundancy is not essential.

#### Characteristics

- **Reduced latency:** Local Zones ensure fast response times, ideal for real-time applications such as online gaming or video conferencing.
- **Local compliance:** Data can be processed and stored in specific locations, making it easier to comply with location and regulatory requirements.
- **Regional extension:** Local Zones act as an extension of the main regions to complete critical workloads locally, while benefiting from the services of the parent region.

#### Limits

- **No inter-zone redundancy:** Unlike multi-AZ regions, Local Zones do not offer redundancy between several zones, which limits service continuity in the event of a failure.
- **Single zone limitation:** Local Zones operate within a single availability zone, making them vulnerable to local failures.
- **Dependency on the main region:** In the event of a failure affecting the main region, Local Zones may also be affected for certain critical services.

#### Redundancy Specifications for Local Zones

| Advantage | Description |
|------------------|-------------------------------------------------------|
| **Type of redundancy** | Triple local replication within the zone to guarantee resilience in the event of hardware failure. |
| **Fault tolerance** | Guarantees continuity of operations in the event of a disk or server failure within the zone, but does not protect against a total failure of the availability zone. |
| **Data protection**| Data replicated in the zone to guarantee local availability. |
| **Limits**| No protection against global or regional failures, dependent on a single Local Zone. |

**Triple local replication:**

Data is replicated three times in the same Local Zone, offering resilience against hardware failure (disk or server). However, this architecture does not protect against a complete zone failure and remains dependent on a single Local Zone.

#### Scaling

In Local Zones, scaling is designed to meet the demands of low-latency applications while being restricted to a single availability zone. Here’s how scaling is structured:

- **Horizontal and vertical scalability options:** Local Zones support instance scaling, but are limited by local capacity and the lack of additional zones for load balancing.
- **Ultra-low latency:** Scaling is focused on keeping latency to a minimum, ideal for real-time workloads.
- **Planning required:** Because it is limited to a single zone, careful planning is essential to avoid saturating available resources and guarantee stable performance.
- **Regional dependency:** For more complex or redundant scaling requirements, Local Zones may be dependent on the resources of the main region. This can introduce additional latency if external resources are required.

#### Architecture example

/// details | Online gaming platform or video streaming service

> [!primary]
>
> **Scenario:**
>
> A real-time online gaming platform or a video streaming service that requires ultra-low latency and high performance for users within a specific geographic region.

Architecture:
- **Local Zones:** located near the user base, significantly reducing latency and improving overall performance.
- **Internal replication:** Critical data is replicated locally within the zone to ensure resilience in the event of hardware failure.
- **Localized processing:** Application and processing servers are deployed in Local Zones to deliver optimal performance.
- **Regulated Data:** Stored within the Local Zones for compliance with data localization laws, reducing bandwidth costs.
- **Load balancers:** Traffic redirected to other Local Zones (if available) or main regions to ensure minimum service continuity in the event of a local failure.

///

### Comprehensive Comparison Table

| Characteristics | 1-AZ Region | 3-AZ Region | Local Zones |
|------------------------|-------------------------------------|---------------------------------|------------------------------------------|
| **Deployment Structure** | Single availability zone | Three independent availability zones | Single availability zone |
| **Redundancy** | 2N+1 internal (resources in a single AZ) | Cross-zone redundancy (resources replicated between zones) | Local triple replication (replication of resources in a single zone) |
| **Data Availability** | Limited during data center outages, protected against server/disk failures | Maintained across zones, resilient to zone outages | Limited during data center outages, protected against server/disk failures |
| **Latency** | Low for close end-users | Low for close end-users and ultra low between availability zones | Low for close end-users |
| **Ideal Use Cases** | Development, staging environments, cost-sensitive applications, non-critical services | High-availability applications, critical business services, disaster recovery, and mission-critical workloads | Real-time applications, edge computing, gaming, video streaming, regulatory-compliant services |
| **Cost** | Lower | Higher due to increased redundancy | Dependent on the specific Local Zones and required latency performance |

## Go Further

If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) to get a quote and ask our Professional Services experts for assisting you on your specific use case.

Join our [community of users](/links/community) and visit our [Discord channel](https://discord.gg/ovhcloud).
Loading