Qu’est-ce que la reprise d’activité après sinistre ?
Un sinistre est un événement unique majeur avec un impact plus fort et durable que ce que peut gérer une application avec la partie « haute disponibilité » de sa conception. La récupération d’urgence (DR) consiste à récupérer des données suite à des événements à impact élevé, comme des catastrophes naturelles ou des échecs de déploiements, entraînant un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR.
Objectifs de récupération
Un plan de DR complet doit spécifier les exigences métier critiques suivantes pour chaque processus implémenté par l’application :
L’objectif de point de récupération (RPO) est la durée maximale d’une perte de données acceptable. Le RPO est mesuré en unités de temps, et non en volume, comme « 30 minutes de données » ou « quatre heures de données ». Le RPO vise à limiter la perte de données, et à récupérer suite à celle-ci, et non le vol de données.
L’objectif de délai de récupération (RTO)est la durée maximale acceptable d’un temps d’arrêt, où le « temps d’arrêt » est défini par votre spécification. Par exemple, si la durée acceptable du temps d’arrêt au cours d’un sinistre est de huit heures, le RTO est de huit heures.
Chaque processus ou charge de travail majeur implémenté par une application doit avoir des valeurs RPO et RTO distinctes en examinant les risques liés au scénario d’urgence et les stratégies de récupération potentielles. Le processus de spécification d’un RPO et d’un RTO crée efficacement des exigences de récupération d’urgence pour votre application en raison de vos préoccupations métier uniques (coûts, impact, perte de données, etc.).
Conception de systèmes de récupération d’urgence
La récupération d’urgence n’est pas une fonctionnalité automatique, mais doit être conçue, générée et testée. Pour prendre en charge une stratégie de DR solide, vous devez créer une application avec la DR à l’esprit dès le départ. Azure propose des services, des fonctionnalités et des conseils pour vous aider à prendre en charge la récupération d’urgence lorsque vous créez des applications.
Récupération de données
Lors d’un sinistre, il existe deux méthodes principales de restauration des données : les sauvegardes et la réplication.
La sauvegarde restaure les données à un point spécifique dans le temps. En utilisant la sauvegarde, vous pouvez fournir des solutions simples, sécurisées et rentables pour sauvegarder et récupérer vos données dans le cloud Microsoft Azure. Utilisez Sauvegarde Azure pour créer des données longues et en lecture seule instantané pour une utilisation dans la récupération.
La réplication des données crée des copies en temps réel ou en quasi-temps réel de données actives dans plusieurs réplicas de magasin de données avec une perte de données minimale à l’esprit. L’objectif de la réplication est de synchroniser les réplicas en réduisant au maximum la latence tout en conservant la réactivité de l’application. La plupart des systèmes de base de données et d’autres produits et services de stockage de données complets incluent un certain type de réplication sous la forme d’une fonctionnalité étroitement intégrée, en raison de ses exigences fonctionnelles et de performances. Par exemple, le stockage géoredondant (GRS) est un exemple.
Les différentes conceptions de la réplication donnent une priorité différente aux coûts, aux performances et à la cohérence des données.
Une réplication active implique d’exécuter les mises à jour sur plusieurs réplicas simultanément, ce qui garantit la cohérence au détriment du débit.
Une réplication passive effectue la synchronisation en arrière-plan : la réplication n’impacte plus les performances de l’application, mais accroît le RPO.
La réplication active/active ou multimaître permet d’utiliser plusieurs réplicas simultanément, offrant un équilibrage de charge mais au détriment de la cohérence des données.
La réplication active/passive réserve des réplicas pour les utiliser en direct pendant le basculement uniquement.
Remarque
La plupart des systèmes de base de données complets et d’autres produits et services de stockage de données incluent un type de réplication, tel que le stockage géoredondant (GRS), en raison de leurs exigences fonctionnelles et de performances.
Génération d’applications résilientes
Les scénarios d’incident entraînent généralement un temps d’arrêt, qu’il soit provoqué par des problèmes de connectivité réseau, des pannes au niveau du centre de données, des machines virtuelles endommagées ou le déploiement de logiciels corrompus. Dans la plupart des cas, la récupération d’application implique le basculement vers un déploiement distinct et opérationnel. Par conséquent, il peut être nécessaire de récupérer des processus dans une autre région Azure en cas de sinistre à grande échelle. D’autres considérations peuvent inclure : emplacements de récupération, nombre d’environnements répliqués et comment gérer ces environnements.
Selon la conception de votre application, vous pouvez utiliser plusieurs stratégies et fonctionnalités Azure différentes, telles qu’Azure Site Recovery, pour améliorer la prise en charge de votre application pour la récupération des processus après un sinistre.
Fonctionnalités de récupération d’urgence spécifiques au service
La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure, comme Azure App Service , fournissent des fonctionnalités et des conseils pour prendre en charge la récupération d’urgence. Dans certains scénarios, vous pouvez utiliser des fonctionnalités propres au service qui prennent en charge la récupération rapide. Par exemple, Azure SQL Server prend en charge la géoréplication pour restaurer rapidement un service dans une autre région. Azure App Service propose une fonctionnalité de sauvegarde et restauration, et la documentation comporte des conseils pour utiliser Azure Traffic Manager afin de prendre en charge le routage du trafic vers une région secondaire.