Définir l’objectif de délai de récupération et l’objectif de point de récupération
La compréhension des objectifs de temps de récupération et de point de récupération est cruciale pour votre plan HADR (haute disponibilité et reprise d’activité après sinistre), car ils constituent la base de toute solution de disponibilité.
Objectif de temps de récupération
L’objectif de délai de récupération (RTO) est la durée maximale dont vous disposez pour remettre les ressources en ligne après une panne ou un problème. Si ce processus prend plus de temps que le RTO, il peut y avoir des conséquences telles que des sanctions financières, des travaux non réalisés, etc. Le RTO peut être spécifié pour l’ensemble de la solution, c’est-à-dire toutes les ressources, ainsi que pour des composants individuels tels que les instances et les bases de données SQL Server.
Objectif de point de récupération
L’objectif de point de récupération (RPO) est l’instant dans le passé auquel une base de données doit être récupérée. Il équivaut à la perte maximale de données que l’entreprise est prête à accepter. Supposons par exemple qu’une machine virtuelle IaaS contenant SQL Server subisse une panne à 10h00 et que les bases de données de l’instance SQL Server aient un RPO de 15 minutes. Quelle que soit la fonctionnalité ou technologie utilisée pour restaurer cette instance et ses bases de données, la perte de données attendue est de 15 minutes maximum. Cela signifie que la base de données peut être restaurée à l’instant passé correspondant à 9h45 (ou plus tard) pour garantir une perte de données minimale ou nulle compte tenu du RPO déclaré. Plusieurs facteurs peuvent déterminer si ce RPO est réalisable.
Définition des objectifs de délai de récupération et de point de récupération
Les objectifs RTO et RPO sont déterminés par les besoins de l’entreprise, mais ils sont également basés sur différents facteurs technologiques et autres, notamment les compétences et les capacités des administrateurs (pas seulement des administrateurs de base de données). Même si une entreprise souhaite éviter à tout prix les temps d’arrêt et la perte de données, cet objectif peut être irréaliste voire impossible à atteindre pour diverses raisons. La détermination du RTO et du RPO de votre solution doit faire l’objet d’une discussion ouverte et honnête entre toutes les parties concernées.
L’un des points critiques du RTO et du RPO est l’établissement du coût d’un temps d’arrêt. En définissant ce chiffre ainsi que l’impact global de l’arrêt ou de l’indisponibilité sur l’entreprise, il est plus facile de définir des solutions. Par exemple, si l’entreprise peut perdre 10 000 € par heure ou se voir infliger une amende par une agence gouvernementale si quelque chose ne peut pas être traité, vous avez un moyen mesurable de définir le RTO et le RPO. Les dépenses consacrées à la solution doivent être proportionnelles au montant, ou coût, du temps d’arrêt. Si votre solution HADR coûte X dollars et que l’impact d’un problème sur votre entreprise se mesure en secondes et non en heures ni en jours, considérez-la comme amortie.
D’un point de vue technique, l’objectif RTO (objectif de temps de récupération) doit être défini au niveau du composant (par exemple SQL Server) ainsi que pour l’ensemble de l’architecture de l’application. La capacité à récupérer après une panne dépend du maillon le plus faible. Par exemple, si SQL Server et ses bases de données peuvent être mis en ligne en cinq minutes alors qu’il faut 20 minutes pour les serveurs d’applications, le RTO global est de 20 minutes (pas cinq). L’environnement SQL Server peut toujours avoir un RTO de cinq minutes ; cela ne change toujours pas le temps global de récupération.
Le RPO porte spécifiquement sur les données et influence directement la conception de toute solution HADR, ainsi que les stratégies et procédures administratives. Les fonctionnalités utilisées doivent prendre en charge le RTO et les RPO définis. Par exemple, si des sauvegardes de journaux des transactions sont planifiées toutes les 30 minutes, et s’il existe un objectif RPO (objectif de point de récupération) de 15 minutes, une base de données ne peut être récupérée qu’à partir de la dernière sauvegarde du journal des transactions disponible, qui dans le meilleur des cas remonte à 30 minutes. Cette chronologie part du principe qu’il n’y a pas d’autres problèmes et que les sauvegardes ont été testées et sont considérées comme correctes. Bien qu’il soit difficile de tester chaque sauvegarde générée pour chaque base de données dans votre environnement, une sauvegarde n’est qu’un fichier dans un système de fichiers. Si vous n’effectuez pas au moins des restaurations périodiques, rien ne prouve que les sauvegardes sont correctes. La mise en place de vérifications pendant le processus de sauvegarde peut vous donner un certain degré de confiance.
Les fonctionnalités spécifiques utilisées, comme un groupe de disponibilité Always On ou une instance de cluster de basculement Always On, affectent également vos RTO et RPO. Selon la façon dont les fonctionnalités sont configurées, les solutions IaaS ou PaaS peuvent basculer ou non automatiquement vers un autre emplacement, ce qui peut entraîner des temps d’arrêt plus longs. En définissant le RTO et le RPO, la solution technique qui prend en charge cette exigence peut être conçue en tenant compte des allocations de temps et de perte de données. Si ces allocations ne sont pas réalistes, vous devez ajuster les RTO et RPO en conséquence. Par exemple, si le RTO souhaité est de deux heures et que la copie d’une sauvegarde sur le serveur de destination pour restauration prend trois heures, l’objectif est déjà manqué. Vous devez tenir compte de ces types de facteurs pour déterminer vos RTO et RPO.
Des RTO et des RPO doivent être définis pour la haute disponibilité et la reprise d’activité. La haute disponibilité est considérée comme un événement plus localisé qui peut être récupéré plus facilement. Un exemple de haute disponibilité est un groupe de disponibilité qui bascule automatiquement d’un réplica à un autre au sein d’une région Azure. Cela peut prendre quelques secondes. À ce stade, vous devez vérifier que l’application peut se connecter une fois les basculements effectués. Le temps d’arrêt de SQL Server est minime. Un RTO ou RPO local peut éventuellement être mesuré en minutes en fonction de la nature critique de la solution ou du système.
La reprise d’activité revient à mettre en place un tout nouveau centre de données. Ce puzzle comporte beaucoup de pièces, et SQL Server n’est que l’une de ces pièces. Tout remettre en ligne peut prendre des heures voire plus. C’est pourquoi les RTO et les RPO sont distincts. Même si de nombreuses technologies et fonctionnalités utilisées pour la haute disponibilité et la reprise d’activité sont les mêmes, le niveau d’effort et le temps nécessaires peuvent varier.
Tous les RTO et RPO doivent être explicitement documentés et révisés régulièrement ou au besoin. Une fois qu’ils sont documentés, vous pouvez réfléchir aux technologies et fonctionnalités à utiliser pour l’architecture.