Partager via

Documentation sur la fiabilité Azure

  • Article

La fiabilité se compose de deux principes : la résilience et la disponibilité. L’objectif de la résilience est d’éviter les défaillances et, s’il en y a quand même, de faire en sorte que l’application retrouve un état entièrement fonctionnel. L’objectif de la disponibilité est de fournir un accès cohérent à votre application ou charge de travail. Il est important de planifier une fiabilité proactive en fonction des besoins de votre application.

Azure propose des services de fiabilité intégrés que vous pouvez utiliser et gérer en fonction des besoins de votre entreprise. Quelle que soit l’ampleur de la défaillance (un seul nœud matériel, tout un rack, un centre de données ou une région à grande échelle), Azure fournit des solutions qui améliorent la fiabilité. Par exemple, les groupes à haute disponibilité garantissent que les machines virtuelles déployées sur Azure sont distribuées sur plusieurs nœuds matériels isolés dans un cluster. Les zones de disponibilité protègent les applications et les données des clients contre toute défaillance du centre de données dans plusieurs emplacements physiques au sein d’une région. Les régions et les zones de disponibilité sont au centre de votre stratégie de conception et de résilience des applications. Elles sont abordées plus en détail plus loin dans cet article.

La documentation sur la fiabilité Azure fournit des conseils de fiabilité pour les services Azure. Ces conseils incluent des informations sur la prise en charge des zones de disponibilité, les conseils de récupération d’urgence et la disponibilité des services.

Pour obtenir des conseils détaillés sur la fiabilité spécifique aux services, notamment les zones de disponibilité, la récupération d’urgence ou la haute disponibilité, consultez Vue d’ensemble des conseils de fiabilité spécifique aux services Azure.

Pour plus d’informations sur les principes de fiabilité et de fiabilité et l’architecture dans les services Microsoft Azure, consultez Microsoft Azure Well-Architected Framework : Fiabilité.

Exigences de fiabilité

Le niveau de fiabilité requis pour une solution Azure dépend de plusieurs éléments. Ce sont le contrat de niveau de service (SLA, Service-Level Agreement) de disponibilité et de latence ainsi que d’autres exigences métier qui déterminent les choix architecturaux et le niveau de résilience. Ils doivent donc être considérés en premier. Les exigences en matière de disponibilité couvrent le temps d’arrêt acceptable (ainsi que le coût pour votre entreprise) ainsi que la quantité d’argent et le temps que vous pouvez de manière réaliste investir pour rendre une application hautement disponible.

La création de systèmes fiables sur Azure constitue une responsabilité partagée. Microsoft est responsable de la fiabilité de la plateforme cloud, et notamment de son réseau global et de ses centres de données. Les clients et partenaires Azure assument la responsabilité de la résilience de leurs applications cloud, en appliquant les meilleures pratiques architecturales en fonction des besoins de chaque charge de travail. Bien qu’Azure s’efforce continuellement de garantir la résilience la plus élevée possible dans le contrat SLA de la plateforme cloud, vous devez définir vos propres objectifs SLA pour chacune des charges de travail de votre solution. Un contrat SLA permet d’évaluer si l’architecture répond aux exigences de l’entreprise. Plus vous vous efforcez d’obtenir des ratios élevés de disponibilité garantie par contrat SLA, plus le coût et la complexité associés augmentent. Une durée de bon fonctionnement de 99,99 % se traduit par environ 5 minutes de temps d’arrêt total par mois. Ce niveau justifie-t-il une augmentation de la complexité et du coût ? La réponse dépend des exigences de chaque entreprise. Lorsque vous décidez des engagements SLA finaux, prenez connaissance des contrats SLA pris en charge par Microsoft. Chaque service Azure possède le sien.

Diagram showing the shared responsibility model for Azure business continuity.

Dans le modèle local traditionnel, toute la responsabilité de la gestion, du matériel pour le calcul, le stockage et les réseaux à l’application, vous incombe. Vous devez planifier différents types de défaillances et la façon de les traiter en créant une stratégie de récupération d’urgence. Avec IaaS, le fournisseur de services cloud est responsable de la résilience de la base de l’infrastructure, notamment le stockage, les réseaux et le calcul. Quand vous passerez d’IaaS à PaaS, puis à SaaS, vous verrez que vous aurez moins de responsabilités et que le fournisseur de services en aura plus.  

Pour plus d’informations sur les principes de fiabilité, consultez la documentation sur la fiabilité de Well-architected Framework.  

Développement de la fiabilité

Définissez les exigences de fiabilité de votre application au début de la planification. Si vous savez quelles applications n’ont pas besoin d’une haute disponibilité de 100 % pendant certaines périodes, vous pouvez optimiser les coûts pendant ces périodes non critiques. Identifiez les types de défaillances possibles d’une application et leurs effets potentiels. Un plan de récupération doit couvrir tous les services critiques en finalisant la stratégie de récupération au niveau de chaque composant et au niveau de l’application globale. Concevez votre stratégie de récupération de façon à vous protéger contre les défaillances zonales, régionales et applicatives. Effectuez des tests de l’environnement d’application de bout en bout pour mesurer la fiabilité et la récupération des applications en cas de défaillance imprévue.

La liste de vérification suivante couvre l’étendue de la planification de la fiabilité.

Planification de la fiabilité
Définissez des objectifs de disponibilité et de récupération répondant aux besoins de l’entreprise.
Concevez les fonctionnalités de fiabilité de vos applications en fonction des exigences de disponibilité.
Alignez les plateformes d’applications et de données sur vos besoins de fiabilité.
Configurez les chemins de connexion de façon à promouvoir la disponibilité.
Utilisez si nécessaire les zones de disponibilité et la planification de la récupération d’urgence pour améliorer la fiabilité et optimiser les coûts.
Rendez l’architecture de vos applications résiliente par rapport aux défaillances.
Analysez ce qui se passe si les exigences SLA ne sont pas satisfaites.
Identifiez les points de défaillance possibles dans le système. La conception des applications doit tolérer les échecs de dépendance en déployant le coupe-circuit.
Concevez des applications qui fonctionnent sans leurs dépendances.

RTO et RPO

Deux métriques importantes sont à prendre en considération : l’objectif de délai de récupération et l’objectif de point de récupération, puisqu’ils entrent dans le cadre de la reprise d’activité.  Pour plus d’informations sur les exigences de conception fonctionnelle et non fonctionnelle, consultez Exigences fonctionnelles et non fonctionnelles de Well-Architected Framework.

  • L’objectif de délai de récupération (RTO) est la durée maximale acceptable pendant laquelle une application peut être indisponible après un incident.

  • L’objectif de point de récupération (RPO) est la durée maximale de perte de données acceptable pendant une panne.

Les objectifs RTO et RPO sont des exigences non opérationnelles d’un système et doivent être définis selon les besoins de l’entreprise. Pour dériver ces valeurs, évaluez les risques ainsi que le coût d’une perte de données et d’un temps d’arrêt.  

Régions et zones de disponibilité

Les régions et les zones de disponibilité constituent une partie importante de l’équation de fiabilité. Les régions présentent plusieurs zones de disponibilité physiquement distinctes. Ces zones de disponibilité sont connectées par un réseau hautes performances offrant moins de 2 ms de latence entre les zones physiques. La faible latence permet à vos données d’être synchronisées et accessibles en cas de problème. Vous pouvez utiliser cette infrastructure de manière stratégique quand vous concevez des applications et une infrastructure de données qui se répliquent automatiquement et fournissent des services ininterrompus entre les zones et les régions.

Les services Microsoft Azure prennent en charge les zones de disponibilité et permettent de piloter vos opérations cloud avec une haute disponibilité optimale tout en répondant à vos besoins de stratégie de continuité d’activité et de récupération interrégionale.

Pour la planification de la récupération d’urgence, les régions appairées à d’autres régions offrent uneréplication interrégionale et fournissent une protection en répliquant de manière asynchrone les données sur d’autres régions Azure. Les régions non appairées suivent les instructions de résidence des données et offrent une haute disponibilité avec des zones de disponibilité et un stockage localement redondant ou redondant interzone. Les clients devront planifier leur récupération d’urgence interrégionale en fonction de leurs besoins de RTO/RPO.

Choisissez la région la plus adaptée à vos besoins en fonction de considérations techniques et réglementaires (fonctionnalités du service, résidence des données, exigences de conformité et latence) pour progresser dans votre stratégie de fiabilité. Pour plus d’informations, consultez Régions et zones de disponibilité Azure.

Dépendances du service Azure

Les services Microsoft Azure sont disponibles dans le monde entier pour gérer vos opérations cloud à un niveau optimal.

Les services Azure déployés dans des régions Azure sont répertoriés sur la page des produits d’infrastructure globale Azure. Pour mieux comprendre les régions et les zones de disponibilité dans Azure, consultez Régions et zones de disponibilité dans Azure.

Les services Azure sont conçus pour assurer la fiabilité, notamment la haute disponibilité et la récupération d’urgence. Aucun service n’est dépendant d’un centre de données logique unique (pour éviter les points de défaillance uniques). Les services non régionaux répertoriés dans les produits Azure Global Infrastructure sont des services pour lesquels il n’existe aucune dépendance vis-à-vis d’une région Azure spécifique. Les services non régionaux sont déployés dans deux régions ou plus et, en cas de défaillance régionale, l’instance du service dans une autre région continue de traiter les clients. Certains services non régionaux permettent aux clients de spécifier la région dans laquelle la machine virtuelle sous-jacente sur laquelle s’exécute le service sera déployée. Par exemple, Azure Virtual Desktop permet aux clients de spécifier la région où se trouve la machine virtuelle. Tous les services Azure qui stockent les données client permettent au client de spécifier les régions dans lesquelles leurs données seront stockées. L’exception est Microsoft Entra ID, qui a un emplacement géographique (par exemple, Europe ou Amérique du Nord). Pour en savoir plus sur la résidence du stockage des données, consultez le mappage de résidence de données.

Si vous avez besoin de comprendre les dépendances entre les services Azure pour mieux concevoir vos applications et services, vous pouvez demander la documentation sur les dépendances de service Azure en contactant votre commercial Microsoft ou un représentant client. Ce document répertorie les dépendances pour les services Azure, y compris les dépendances sur tous les principaux services internes, tels que les services de plan de contrôle. Pour obtenir cette documentation, vous devez être client Microsoft et avoir l’accord de confidentialité approprié avec Microsoft.

Étapes suivantes