Fiabilité
Imaginons que vous dirigez un système clinique pour une organisation médicale. Les cliniciens et les soignants ne peuvent pas se permettre de temps d’arrêt. Ils doivent avoir accès en permanence aux systèmes informatiques cliniques pour garantir à tout moment la qualité optimale de leurs soins.
Pour répondre aux demandes des cliniciens 24 h/24, les applications doivent être capables de gérer les défaillances tout en minimisant l’impact sur les utilisateurs. Comment garantir le bon fonctionnement des applications, à la fois lors d’incidents localisés et de sinistres à grande échelle ?
Dans cette unité, vous allez apprendre à inclure des éléments du pilier de fiabilité dans la conception de votre architecture.
Qu’est-ce que la fiabilité ?
Dans une application complexe, de nombreux problèmes peuvent se produire, à petite ou grande échelle. Les serveurs et les disques durs peuvent connaître une panne. Un problème de déploiement peut causer la suppression involontaire de toutes les tables d’une base de données. L’intégralité d’un centre de données peut devenir inaccessible. Un ransomware peut chiffrer toutes vos données à des fins malveillantes. Il est essentiel que votre application reste fiable et puisse gérer tant des incidents localisés que des incidents à large impact.
La conception qui vise à garantir la fiabilité doit pouvoir maintenir la disponibilité des serveurs, aussi bien lors d’incidents à petite échelle que lors de problèmes temporaires tels que les pannes de réseau partielles. Vous pouvez garantir que votre application gère les défaillances localisées en intégrant la haute disponibilité à chaque composant. Cette conception d’application élimine les points de défaillance uniques. Ce type de conception permet également de réduire l’impact de la maintenance de l’infrastructure. En général, les conceptions à haute disponibilité visent à éliminer rapidement et automatiquement l’impact des incidents et à garantir que le système continue de traiter les demandes dont l’incidence est insignifiante.
Les conceptions axées sur la fiabilité doivent aussi permettre la récupération, aussi bien en cas de perte de données que de sinistres importants. Après ces types d’incidents, la récupération implique souvent une intervention active, bien que les étapes de récupération automatisée réduisent le délai de récupération requis. Ces types d’incidents peuvent entraîner un certain temps d’arrêt ou une perte définitive de données. La reprise d’activité après sinistre demande tout autant de planification que d’exécution.
En intégrant la haute disponibilité et la capacité de récupération dans la conception de votre architecture, vous protégez votre entreprise des pertes financières liées aux temps d’arrêt et à la perte de données. Ils protègent également votre entreprise contre une perte de réputation causée par une perte de confiance de vos clients.
Le fait de concevoir une architecture garantissant la fiabilité vous permet de tenir vos engagements auprès de vos clients. Vous voulez garantir que vos systèmes sont accessibles aux utilisateurs finaux et récupérables en cas de défaillance.
Créer une architecture à haute disponibilité
Pour la disponibilité, identifiez le contrat de niveau de service (SLA) sur lequel vous vous engagez. Comparez les fonctionnalités potentielles de haute disponibilité de votre application aux termes de votre contrat SLA, afin de déterminer celles qui respectent les termes et celles pour lesquelles des améliorations sont nécessaires. Votre objectif est d’intégrer la redondance aux composants de l’architecture, afin de réduire les risques d’indisponibilité.
Les composants d’une conception pour la haute disponibilité sont, par exemple, le clustering et l’équilibrage de charge :
Le clustering remplace une machine virtuelle par un ensemble de machines virtuelles coordonnées. Quand une machine virtuelle échoue ou devient inaccessible, les services basculent vers une autre machine qui peut traiter les requêtes.
L’équilibrage de charge répartit les requêtes entre plusieurs instances d’un service, ce qui permet de détecter les instances qui ont échoué et d’empêcher que les requêtes ne soient acheminées vers elles.
Créer une architecture capable de récupérer après une défaillance
Pour la capacité de récupération, vous devez effectuer une analyse qui examine les scénarios possibles de perte de données et de temps d’arrêt important. Votre analyse doit inclure une exploration des stratégies de récupération, ainsi que le rapport coûts-avantages pour chacune d’elles. Cet exercice vous permettra d’y voir plus clair dans les priorités de votre organisation et dans le rôle que joue votre application. Les résultats de votre analyse doivent inclure ces valeurs de durée pour votre application :
Objectif de point de récupération (RPO) : durée maximale de perte de données acceptable. Le RPO est mesuré en unités de temps et non en volume. Par exemple, « 30 minutes de données », « quatre heures de données », etc. Le RPO concerne la limitation et la récupération des pertes de données, et non des vols de données.
Objectif de délai de récupération (RTO) : durée maximale acceptable d’un temps d’arrêt, où votre spécification définit le « temps d’arrêt ». Par exemple, si la durée acceptable du temps d’arrêt est de huit heures en cas de sinistre, votre RTO est de huit heures.
Lorsque le RPO et le RTO sont définis, vous pouvez concevoir des fonctionnalités de sauvegarde, de restauration, de réplication et de récupération dans votre architecture afin d’atteindre ces objectifs.
Chaque fournisseur de cloud propose une suite de services et de fonctionnalités que vous pouvez utiliser pour améliorer la disponibilité et la capacité de récupération de votre application. Lorsque cela est possible, utilisez les services existants et les bonnes pratiques qui leur sont associées, et résistez à la tentation de créer vos propres services.
Les disques durs peuvent échouer, les centres de données peuvent devenir inaccessibles, et des pirates peuvent commettre des attaques. Il est important de garder une bonne réputation auprès de vos clients, ce que permettent la disponibilité et la capacité de récupération. La disponibilité vise à garantir le maintien de la disponibilité des serveurs en cas de problèmes, comme des pannes réseau, et la capacité de récupération vise à garantir la récupération des données après un sinistre.