Concevoir pour la sauvegarde et la récupération
Les organisations comme Tailwind Traders demandent un niveau élevé de fiabilité pour leurs applications stratégiques. Afin d’obtenir la fiabilité souhaitée pour les applications locales, l’achat de ressources de calcul supplémentaires, telles que des serveurs et du stockage, est tout ce qu’il y a de plus normal. L’achat d’autres ressources informatiques crée une redondance dans une infrastructure locale.
Il est également vital que toute application stratégique, et ses données associées, soient récupérables à la suite d’une défaillance. Cette récupérabilité est souvent assurée par une sauvegarde, des composants de restauration et des procédures. Pour les organisations avec des applications hébergées dans Azure, ou des organisations avec des déploiements d’applications hybrides, il existe d’autres options et points à prendre en considération.
Les applications fiables sont :
Résilientes au défaillance des composants.
Hautement disponibles et capables de s’exécuter dans un état sain sans temps d’arrêt significatif.
Pour obtenir la résilience et la haute disponibilité souhaitées, vous devez d’abord définir vos exigences.
Notes
Ce module utilise le terme « résilience » comme la capacité d’un système à gérer et à récupérer correctement à la suite de défaillances, fortuites et malveillantes.
Définir vos exigences
La définition de vos exigences implique :
L’identification de vos besoins métier.
La création de votre plan de résilience pour répondre à ces besoins.
Utilisez le tableau de points à prendre en considération ci-après pour avoir des conseils sur ce processus.
| Considération | Description |
|---|---|
| Quelles sont vos charges de travail et leur utilisation ? | Une charge de travail est une fonctionnalité ou une tâche distincte qui est séparée logiquement des autres tâches, en termes d’exigences de logique métier et de stockage des données. Chaque charge de travail a probablement des exigences différentes en matière de disponibilité, de scalabilité, de cohérence des données et de reprise d’activité après sinistre. |
| Quels sont les modèles d’utilisation de vos charges de travail ? | Les modèles d’utilisation peuvent déterminer vos besoins. Identifiez les différences en besoins entre des périodes critiques et non critiques. Pour garantir la disponibilité, planifiez une redondance entre plusieurs régions en cas de défaillance d’une région. Inversement, pour minimiser les coûts pendant les périodes non critiques, vous pouvez exécuter votre application dans une seule zone géographique. |
| Quelles sont les métriques de disponibilité ? | Le temps moyen de récupération (MTTR, mean time to recovery) et le temps moyen entre les défaillances (MTBF, mean time between failures) sont les métriques généralement utilisées. Le MTBF indique la durée pendant laquelle un composant peut raisonnablement fonctionner entre deux pannes. Le MTTR est la durée moyenne nécessaire à la restauration d’un composant après une défaillance. Utilisez ces métriques pour déterminer où vous devez ajouter la redondance et pour identifier les contrats de niveau de service (SLA) pour les clients. |
| Quelles sont les métriques de récupération ? | L’objectif de délai de récupération (RTO, recovery time objective) est la durée maximale acceptable pendant laquelle une de vos applications peut être indisponible suite à un incident. L’objectif de point de récupération (RPO, recovery point objective) est la durée maximale de perte de données acceptable pendant un sinistre. Prenez également en compte l’objectif de niveau de récupération (RLO, recovery level objective). Cette métrique détermine la précision de la récupération. En d’autres termes, si vous devez être capable de récupérer une batterie de serveurs, une application web, un site ou juste un élément spécifique. Pour déterminer ces valeurs, procédez à une évaluation des risques. Veillez à bien comprendre le coût et le risque d’un temps d’arrêt ou d’une perte de données dans votre organisation. |
| Quels sont les objectifs de disponibilité des charges de travail ? | Pour vous assurer que votre architecture applicative répond à vos besoins métier, définissez les contrats SLA cibles pour chaque charge de travail. Prenez en compte le coût et la complexité de répondre aux exigences de disponibilité, en plus des dépendances d’application. |
| À quoi servent les contrats de niveau de service ? | Dans Azure, un contrat SLA décrit les engagements de Microsoft en matière de disponibilité et de connectivité. Si le contrat SLA lié à un service particulier est de 99,9 pour cent, le service doit être disponible 99,9 pour cent du temps. |
Conseil
Si le MTTR d’un composant critique dans un scénario de haute disponibilité dépasse le RTO du système, une défaillance du système peut entraîner une interruption inacceptable de l’activité. En d’autres termes, vous ne pouvez pas restaurer le système dans le RTO défini.
Définissez vos propres contrats SLA cibles pour chaque charge de travail de votre solution en répondant aux questions précédentes. Cela permet de vous assurer que l’architecture répond à vos besoins métier. Par exemple, si une charge de travail demande 99,99 % de disponibilité alors qu’elle dépend d’un service avec un contrat SLA de 99,9 %, ce service ne peut pas être un point de défaillance unique dans le système.
Après la définition de vos exigences de récupération, vous pouvez sélectionner une technologie de récupération appropriée.