Qu'est-ce que la reprise après sinistre ?

La reprise après sinistre (DR) est l'une des facettes des plans globaux de continuité des activités élaborés et maintenus par les différents secteurs d'activité d'une entreprise. Un plan efficace de reprise après sinistre atténue l'impact des pannes imprévues - ou même planifiées - des systèmes essentiels à la mission et à l'activité d'une entreprise sur sa capacité à fonctionner et à continuer à générer des revenus.

Pour ce faire, un plan de DR fournit aux entreprises une structure flexible qui leur permet de fonctionner de manière unifiée et collaborative pour restaurer, réaménager et revitaliser leurs systèmes et construire une infrastructure plus résiliente.

Pourquoi la reprise après sinistre est-elle importante ?

Combien de temps une entreprise pourrait-elle continuer à fonctionner si elle perdait son système de paie juste avant le calcul de la paie et le financement des comptes ? Quelles pénalités une entreprise encourrait-elle en raison du retard de paiement des impôts fédéraux, étatiques et locaux ? Quelles seraient les conséquences pour l'entreprise de ne pas payer ses collaborateurs à temps - et combien de temps les travailleurs continueraient-ils à travailler ?

Faire ou ne pas faire une reprise après sinistre ? Ce n'est plus la question. La vraie question est de savoir quel est le coût réel de la perte en un instant de minutes, de jours ou de semaines de données importantes et de la confiance construite au fil des ans.

La reprise après sinistre ne peut plus être envisagée uniquement lorsque le budget est suffisant, car les entreprises d'aujourd'hui doivent réagir rapidement aux événements perturbateurs et rester opérationnelles. Plutôt que d'être dissuadées par le coût de la mise en œuvre d'un plan de résilience, les entreprises doivent aller plus loin et évaluer le coût réel de l'absence totale de plan. Par exemple, examinez les contrats de niveau de service (SLA) qui ne pourraient pas être respectés ou les pénalités et la perte de revenus qui résulteraient d'une panne. Si l'on compare le coût de la mise en œuvre de la reprise après sinistre aux pénalités, à la perte de revenus et à la perte de confiance des clients, le choix est clair.

L'image est intitulée "Revenu, productivité et perte de loyauté". Trois statistiques clés sont affichées dans cette image. Ces statistiques sont issues d'une étude commandée par Forrester Consulting pour le compte d'IBM en 2019. La question posée aux personnes interrogées était : « Parmi les coûts suivants, quels sont ceux auxquels votre entreprise doit faire face en raison des temps d'arrêt planifiés et non planifiés ? »
Sur le côté gauche, la statistique affichée montre que 53 % des personnes interrogées ont répondu "Perte de revenus". Au milieu, la statistique montre que 47 % ont répondu "Perte de productivité". Sur la droite, la statistique montre que 41 % ont répondu "Perte d'équité ou de confiance dans la marque".

Coupures non planifiées

Que la panne soit due à une catastrophe naturelle, à des erreurs de l'opérateur informatique ou du fournisseur de services, à la corruption de données ou à des attaques par ransomware, une entreprise doit être en mesure de se prémunir contre les perturbations de ses opérations commerciales qui entraînent des pertes catastrophiques, le remplacement par des concurrents opportunistes et la perte de réputation et de bonne volonté.

Si ces conséquences semblent dramatiques, elles reflètent les expériences récentes de nombreuses entreprises bien connues qui n'ont pas réussi à se rétablir en temps voulu et ont perdu de grandes quantités de données transactionnelles essentielles, d'informations client et de confiance.

Une grande variété de scénarios et de causes profondes peuvent perturber les opérations commerciales.

Cette image est intitulée "Principales causes des temps d'arrêt non planifiés". L'image affiche un diagramme à barres qui montre les causes des interruptions non planifiées. Le diagramme à barres est segmenté en trois catégories : défaillances opérationnelles, catastrophes naturelles et événements d'origine humaine. Les défaillances opérationnelles sont regroupées dans la partie la plus à gauche du diagramme à barres, les catastrophes naturelles au milieu et les événements d'origine humaine dans la partie la plus à droite. La source de ce graphique est Forrester Research, Inc..

Coupures planifiées

La reprise après sinistre en tant que service (DRaaS) dans le cloud offre aux entreprises des options inégalées en matière de flexibilité opérationnelle. Les entreprises utilisent plus souvent des solutions de reprise après sinistre pour des pannes planifiées que pour se remettre d'événements catastrophiques.

Points faibles typiques

• Les approches traditionnelles de la reprise après sinistre nécessitent des investissements dans l'automatisation.
• Même les systèmes de gestion dans les datacenters de niveau 1 peuvent être affectés par les coupures de courant, qui sont trop fréquentes. Combien de fois un incident banal, comme une panne de courant, a-t-il entraîné une perte de productivité d'un jour ou deux ? Le personnel informatique finit par passer des heures, voire des jours, en conférence téléphonique pour remettre les systèmes en état de marche en utilisant des solutions provisoires. • Certaines entreprises consacrent une part importante de leur budget informatique au développement d'une automatisation interne de la gestion de la reprise après sinistre, mais n'osent pas l'utiliser, ni même la tester périodiquement pour s'assurer qu'elle fonctionne comme prévu. • Il faut souvent un jour (ou plusieurs jours) pour se remettre d'une fenêtre de maintenance planifiée. • Même les plans de reprise après sinistre bien documentés peuvent entraîner des jours de perte de productivité pendant que le personnel des opérations informatiques accomplit des actes héroïques pour remettre les choses en marche.

Objectifs clés de la reprise après sinistre

Les deux principaux objectifs de la reprise après sinistre sont de remettre les systèmes affectés dans un état opérationnel aussi rapidement que possible et de le faire avec le moins de pertes de données possible après un événement catastrophique ou une panne planifiée. Les mesures de ces deux objectifs clés sont universellement connues sous le nom d'objectif de temps de récupération (RTO) et d'objectif de point de récupération (RPO) respectivement.

Chaque système de gestion aura des exigences différentes pour ces deux mesures, en fonction du contrat de niveau de service entre les opérations informatiques et les propriétaires de l'entreprise.

L'image est intitulée "Terminologie relative à la protection des données". La tolérance à la perte de données et la tolérance au temps d'arrêt sont représentées par une ligne droite qui s'étend dans des directions opposées à partir du centre de l'image. A gauche, vous avez "Perte de données" et à droite, vous avez "Temps d'inactivité".

Objectif de temps de récupération

L'objectif de temps de récupération est le temps nécessaire pour remettre un système de gestion dans un état pleinement opérationnel après des pannes planifiées ou non planifiées.

Objectif de point de récupération

Un objectif de point de récupération est la quantité maximale de données qui peut être perdue avant de causer des dommages préjudiciables à un système de gestion donné. Le RPO est généralement mesuré en temps à partir du delta de la dernière sauvegarde de données, de la dernière réplication ou du dernier instantané.

Reprise après sinistre ou haute disponibilité

Traditionnellement, la haute disponibilité (HA) protège contre les points de défaillance uniques, tandis que la reprise après sinistre protège contre les points de défaillance multiples. Dans le cloud computing, la protection contre les points de défaillance uniques au niveau de l'infrastructure physique, notamment l'alimentation, le refroidissement, le stockage, les réseaux et les serveurs physiques, est complètement abstraite dans l'architecture globale grâce aux domaines de disponibilité et de défaillance.

Dans ce cas, la haute disponibilité est évolutive et hautement résiliente à la perte de données ou à la perte de performance de traitement. Presque tous les fournisseurs de services cloud destinés aux entreprises intègrent la haute disponibilité dans leur offre.

Les solutions de reprise après sinistre à haute disponibilité qui assurent une protection des bases de données sans perte de données et sans temps d'arrêt deviennent coûteuses lorsque des technologies complexes de mappage et de réplication des données sont utilisées. Ces solutions n'offrent pas de protection contre les ransomwares, qui est assurée par une sauvegarde complète avec un objectif de point de récupération ponctuel et un stockage immuable.

Les solutions HA traditionnelles fonctionnent bien en conjonction avec une solution CDR (Cloud DR) à faible coût. La technologie CDR complémentaire offre une couche supplémentaire de protection pour les bases de données qui ne doivent subir aucune perte de données, aucune interruption de service et qui ont besoin d'une protection contre les ransomwares avec un retour en arrière incrémentiel à long terme.

La reprise après sinistre sur site est une solution peu flexible et coûteuse en raison du coût élevé de la duplication de l'infrastructure informatique dans un site source et dans un datacenter cible fixe. Elle ne peut pas fonctionner sur le WAN ou migrer des serveurs entre des environnements disparates, et nécessite donc un circuit dédié entre les datacenters source et cible pour fonctionner comme un seul environnement LAN interconnecté. La reprise après sinistre traditionnelle ne permet pas non plus de migrer les serveurs entre des environnements hétérogènes disparates, tels qu'un environnement sur site et une plateforme cloud ou entre deux plates-formes cloud différentes.

DRaaS utilise un patchwork de solutions de sauvegarde fournies par les fournisseurs et d'outils de migration open source pour créer un environnement étroitement contrôlé et très spécifique. L'utilisateur final peut uniquement récupérer les charges de travail dans l'environnement d'hébergement traditionnel du fournisseur DRaaS à partir de son environnement VMware sur site. Ces solutions fournies par les fournisseurs peuvent être coûteuses et limitées dans la gamme des charges de travail qu'elles peuvent protéger et dans les environnements informatiques qu'elles peuvent prendre en charge.

Workflows, runbooks et plans de reprise après sinistre

Oracle fait généralement référence à un workflow de reprise après sinistre comme à un plan de reprise après sinistre. Un plan de reprise après sinistre (ou runbook) est une liste d'étapes ou de tâches prédéterminées qui doivent être accomplies pour transférer l'instance de calcul, la plate-forme, la base de données et les applications vers une région de reprise prédéterminée dans le cloud. Il s'agit de toutes les tâches ou étapes individuelles qui sont exécutées par un humain ou une sorte d'automatisation au cours d'une opération de reprise après sinistre, telle qu'une commutation ou un basculement. Les termes "plan de reprise après sinistre", "runbook de reprise après sinistre" et "workflow de reprise après sinistre" sont interchangeables.

Opérations de reprise après sinistre (commutation ou basculement)

Une opération de reprise après sinistre est le processus d'exécution de chaque étape ou tâche prédéterminée dans un plan de reprise après sinistre qui est nécessaire pour rétablir l'infrastructure, la base de données et les applications dans un état pleinement opérationnel. Deux termes différents sont utilisés pour décrire la transition d'une pile d'applications vers un autre emplacement : le basculement et la commutation.

Basculement

Un basculement implique une panne non planifiée où les applications, les bases de données et les machines virtuelles sont tombées en panne et où toutes les ressources, y compris le stockage, les données et les systèmes d'exploitation invités, sont dans un état incohérent. Dans ce cas, la région cloud principale est supposée être complètement inaccessible et indisponible, ce qui indique qu'une véritable opération de reprise après sinistre doit être déclenchée.

Par conséquent, toutes les tâches de reprise après sinistre d'un plan de reprise après sinistre ne peuvent être exécutées que dans la région cloud de secours. Il est essentiel que la solution DRaaS d'un fournisseur de cloud soit conçue pour une haute disponibilité dans la région de secours afin de garantir qu'elle soit accessible et fonctionnelle en cas de catastrophe.

Commutation

La commutation implique un temps d'arrêt planifié qui comprend une fermeture ordonnée des applications, des bases de données et des machines ou serveurs virtuels. Dans ce cas, les régions principale et de secours fonctionnent normalement, et le personnel des opérations informatiques se concentre probablement sur le "déplacement" d'un ou plusieurs systèmes d'une région à l'autre à des fins de maintenance ou de mise à niveau.

Stratégie de déploiement cloud

Les entreprises innovantes peuvent tirer parti d'un ou de plusieurs des modèles de déploiement cloud suivants pour diverses raisons, notamment le coût, les performances et les exigences en matière de continuité des activités. Une stratégie solide de déploiement cloud devient de plus en plus prévalente à mesure que les entreprises continuent à transférer leurs opérations vers le cloud.

Solutions de reprise après sinistre transrégionales

Les solutions de reprise après sinistre transrégionales protègent les entreprises contre les pannes complètes qui auraient un impact sur l'accès aux systèmes de gestion hébergés dans l'infrastructure cloud d'un fournisseur cloud unique. Comme son nom l'indique, une pile d'applications complète pour un système de gestion donné, y compris les machines virtuelles, les bases de données et les applications, peut être transférée à la demande vers une région cloud entièrement différente dans un autre lieu géographique.

Les solutions DRaaS doivent être capables de transférer un système de gestion entier, tel qu'un portail de ressources humaines, un portail de services financiers ou une application de gestion des ressources d'entreprise, vers une région cloud entièrement différente. Les solutions DRaaS doivent être en mesure de répondre aux objectifs de temps et de points de récupération requis par les contrats de niveau de service pour chaque application individuelle.

Les solutions de reprise après sinistre interrégionales telles que Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery protègent des applications d'entreprise entières contre la perte catastrophique de l'accès à l'ensemble d'une région cloud, y compris la perte de tous les domaines de disponibilité dans cette région.

Solutions de reprise après sinistre cloud hybrides

La reprise après sinistre dans un cloud hybride est une solution très populaire qui permet aux entreprises de transférer des charges de travail et des machines virtuelles de leurs propres datacenters vers une infrastructure cloud. Un cloud hybride est souvent utilisé comme solution de reprise après sinistre pour protéger les données et la viabilité des systèmes de gestion essentiels d'une entreprise.

Pour les clients Oracle, le cloud hybride est une confédération lâche entre OCI et les serveurs physiques, les appliances Oracle cloud ou d'autres systèmes dans le datacenter physique d'une entreprise. Les appliances Oracle Cloud, comme Oracle Private Cloud Appliance X9-2 et Oracle Exadata Cloud@Customer, sont d'excellents exemples de systèmes sur site qui s'intègrent parfaitement à OCI.

Certains produits des partenaires Oracle, tels que Rackware, peuvent être utilisés pour réaliser la reprise après sinistre entre l'infrastructure sur site et OCI. Rackware est disponible sur Oracle Cloud Marketplace.

Solutions de reprise après sinistre multicloud

Les solutions de reprise après sinistre multicloud protègent les applications et les données en répartissant les différents composants d'une pile d'applications sur les infrastructures cloud de deux ou plusieurs fournisseurs cloud. Le partenariat d'Oracle avec Microsoft Azure est un bon exemple de relation multicloud.

La reprise après sinistre en tant que service doit pouvoir prendre en charge la reprise après sinistre interrégionale, la reprise après sinistre cloud hybride et la reprise après sinistre multicloud. OCI peut actuellement fournir des DRaaS pour les reprises après sinistre interrégionales et les reprises après sinistre cloud hybride.

Cohérence des données pour les bases de données

Les solutions viables de reprise après sinistre impliquant des bases de données doivent toujours inclure les moyens d'assurer la cohérence des données. Le point auquel une base de données peut être récupérée jusqu'à la cohérence totale des données, y compris les transactions en cours, définit l'objectif du point de récupération.

La cohérence des données est beaucoup moins problématique pour les bases de données sans serveur ou les bases de données de fichiers plats, mais la récupération de bases de données relationnelles sophistiquées, telles que Oracle Database ou MySQL, dans un état de cohérence des données à un moment donné est très complexe, mais toujours cruciale.

Considérations relatives à la reprise après sinistre des bases de données MySQL

Lors de l'utilisation de MySQL Database Service dans OCI, un système de base de données MySQL est un conteneur logique pour une ou plusieurs instances MySQL. Il fournit une interface qui permet de gérer des tâches telles que l'approvisionnement, les sauvegardes automatiques et la récupération ponctuelle.

Les technologies de journalisation binaire et de réplication native de MySQL permettent une récupération ponctuelle, une haute disponibilité et une reprise après sinistre. La réplication de groupe MySQL est généralement utilisée pour créer des clusters locaux tolérants aux pannes pour la haute disponibilité, tandis que la réplication asynchrone MySQL est généralement utilisée pour la reprise après sinistre géo-distribuée.

Un système de base de données dont la haute disponibilité est activée possède trois instances MySQL placées dans différents domaines de disponibilité ou domaines de défaillance. Le système de base de données garantit que si une instance tombe en panne, une autre prend le relais, sans perte de données et avec un temps d'arrêt minimal. Pour la reprise après sinistre dans différentes régions, il est également possible de créer des canaux de réplication entrants entre deux systèmes de base de données.

Utilisez les liens suivants pour en savoir plus sur la reprise après sinistre pour MySQL dans le cloud.

• Présentation de la continuité des activités pour MySQL
• Présentation de la haute disponibilité pour MySQL
• Présentation de la réplication entrante pour MySQL

Considérations relatives à la reprise après sinistre des bases de données Oracle

Oracle Maximum Availability Architecture (MAA) fournit les meilleures pratiques en matière d'architecture, de configuration et de cycle de vie pour les bases de données Oracle, permettant des niveaux de service de haute disponibilité pour les bases de données résidant dans des configurations sur site, dans le cloud ou hybrides.

Utilisez les liens suivants pour en savoir plus sur l'architecture Oracle Maximum Availability pour la reprise après sinistre dans le cloud.

• Oracle Maximum Availability Architecture page d'accueil
• Oracle Maximum Availability Architecture architectures de référence
• Oracle Maximum Availability Architecture meilleures pratiques pour Oracle Fusion Middleware
• Oracle Maximum Availability Architecture meilleures pratiques pour les applications

Architectures de déploiement basées sur le cloud

L'architecture de déploiement décrit la manière dont les divers composants, tels que les ordinateurs, les plates-formes/bases de données et les applications, sont déployés entre les régions cloud afin de créer un moyen résilient de récupérer après la défaillance totale d'un datacenter. L'architecture de déploiement décrit l'endroit où tout se trouve pendant le fonctionnement normal d'une suite d'applications et ce qui doit être récupéré dans la région de secours pour que tout fonctionne à nouveau.

Oracle estime que les solutions DRaaS doivent avoir la flexibilité d'incorporer toute combinaison d'architectures de déploiement de reprise après sinistre afin de répondre aux exigences de niveau de service de chaque système de gestion unique. Les fournisseurs de services cloud devraient offrir à leurs clients la liberté de choisir des solutions "tout ce qui précède" pour respecter les contrats de niveau de service pour la grande variété de systèmes de gestion que les entreprises prennent généralement en charge.

De nombreux termes sont utilisés pour décrire les stratégies de reprise après sinistre et les architectures de déploiement. Cependant, les différentes approches et les différents modèles décrivant la manière de déployer l'infrastructure, la plate-forme et les applications pour la reprise après sinistre se répartissent en deux grandes catégories stratégiques : la reprise après sinistre active/active et la reprise après sinistre active/de secours.

Le tableau suivant décompose les termes communs utilisés pour décrire les différentes architectures de déploiement qui relèvent des deux grandes stratégies de reprise après sinistre.

Stratégie	Architecture de déploiement	Objectif de point de récupération	Objectif de temps de récupération
Active/secours	Secours à froid	Heures	Heures
Active/secours	Lampe témoin	Quelques minutes	Heures
Active/secours	Secours chaude	Secondes	Heures
Active/secours	Secours à chaud	Secondes	Quelques minutes
Active/active	Active/active	Près de zéro	Près de zéro

Cette section tente de démystifier certaines des variations des approches actives/actives et actives/de secours de la reprise après sinistre. Les deux stratégies de reprise après sinistre ont leur place dans l'arsenal d'armes disponibles pour assurer la continuité des opérations.

Architectures de déploiement actif/secours

Il existe de nombreuses variantes d'architectures de déploiement actif/secours. Les déploiements actifs/de secours, parfois appelés déploiements actifs/passifs, sont souvent caractérisés comme des déploiements de lampe témoin, à froid, à chaud et de secours à chaud.

Les scénarios de lampe témoin, de secours à froid, de secours à chaud et de secours à chaud représentent tous une forme du même thème où 100 % d'une pile d'applications fonctionne dans la région principale tandis que moins de 100 % du même système de gestion s'exécute activement dans la région de secours.

La série suivante de diagrammes conceptuels de très haut niveau a pour but d'illustrer certaines différences fondamentales entre les architectures de déploiement courantes et n'est pas conçue comme une architecture de référence ; elle ne décrit pas comment mettre en œuvre la reprise après sinistre pour une pile d'applications.

Secours à froid

Dans ce scénario, les machines virtuelles (VM), la base de données et les applications n'existent que dans la région principale actuelle. Les groupes de volumes de stockage de fichiers et de blocs contenant le disque de démarrage et tout autre disque virtuel de chaque VM sont répliqués dans la région de secours.

Affiche une image avec la région principale à gauche et la région de secours à droite. La région principale comporte trois blocs : application, base de données et infrastructure, chacun contenant ses icônes respectives. Les deux régions comportent une icône représentant un équilibreur de charge au sommet. L'icône de l'équilibreur de charge dans la région de secours est plus claire que celle de la région principale. La région de secours comporte trois blocs : application, base de données et infrastructure. Dans la région de secours, seul le bloc d'infrastructure est peuplé d'icônes - une pour le stockage d'objets, une pour le stockage de blocs et une pour le stockage de fichiers. Les blocs de base de données et d'applications de la région de secours sont vides. Deux flèches représentant la réplication du stockage objet et la réplication du stockage sont montrées entre les deux blocs d'infrastructure. Ces flèches représentent la réplication de la région principale vers la région de secours.

Lors d'une opération de reprise après sinistre, telle qu'une commutation ou un basculement, le stockage répliqué contenant les mêmes VM est activé dans la région de secours, et les mêmes VM sont relancées à l'endroit où elles ont été arrêtées ou se sont écrasées. Les machines virtuelles sont identiques aux machines virtuelles exécutées précédemment dans la région active.

Cette architecture de déploiement présente plusieurs avantages, notamment une réduction des coûts de déploiement, des frais de maintenance et des coûts d'exploitation. Cette solution peut toutefois ne pas être la meilleure pour les applications qui reposent sur des bases de données relationnelles pour le back-end, car la seule façon de garantir la cohérence des données est d'effectuer des sauvegardes à froid périodiques. Cette approche fonctionne bien pour les applications qui peuvent tolérer des pannes occasionnelles courtes et complètes.

La plupart des services informatiques résolvent ce problème en arrêtant périodiquement la base de données, en prenant un instantané du stockage en bloc, puis en reprenant les opérations normales. Cela définit l'objectif du point de récupération puisque vous ne pouvez restaurer qu'au moment où la sauvegarde a été effectuée

Le temps de récupération est légèrement plus long et le risque de perte de données est beaucoup plus élevé, mais c'est une solution viable pour la bonne charge de travail. Par exemple, il peut s'agir d'une excellente solution pour les applications qui reposent sur une base de données de type fichier plat, une base de données sans serveur ou aucune base de données, ou pour les clients qui souhaitent simplement rendre un ensemble de machines virtuelles mobiles entre les régions pour une plus grande flexibilité.

Exemple de workflows de reprise après sinistre pour cette architecture de déploiement

Les deux scénarios suivants décrivent le déroulement des opérations de reprise après sinistre pour les déploiements de secours à froid.

Dans le cas d'une commutation, les tâches suivantes sont effectuées dans les régions principale et de secours :

• Les applications principales sont mises en veille.
• Les bases de données principales sont mises en veille et synchronisées avec la région de secours.
• Les machines virtuelles principales sont stoppées net.
• Le stockage principal est synchronisé avec la région de secours.
• Le stockage répliqué est mis en ligne, la réplication est inversée, et il est maintenant principal dans la région de secours.
• Les copies répliquées des machines virtuelles principales sont lancées, et toutes les applications ou outils système requis par la pile d'applications sont démarrés et sont maintenant principaux dans la région de secours.
• Les copies répliquées des bases de données principales sont récupérées dans la région de secours à l'aide de la dernière sauvegarde à froid ou des journaux de transactions et de redo du stockage répliqué.
• Les copies répliquées des bases de données principales sont démarrées et montées et sont maintenant principales dans la région de secours.
• Les copies répliquées des applications principales sont lancées et validées et sont désormais principales dans la région de secours.
• Toute modification du DNS et des équilibreurs de charge est effectuée pour permettre l'accès à l'application sur le réseau public.

Dans le cas d'un basculement, les tâches suivantes ne sont exécutées que dans la région de secours :

• Le stockage répliqué est mis en ligne, la réplication est inversée, et il est maintenant principal dans la région de secours.
• Les copies répliquées des machines virtuelles principales sont lancées, et toutes les applications ou outils système requis par la pile d'applications sont démarrés et sont maintenant principaux dans la région de secours.
• Les copies répliquées des bases de données principales sont récupérées dans la région de secours à l'aide de la dernière sauvegarde à froid ou des journaux de transactions et de redo du stockage répliqué.
• Les copies répliquées des bases de données principales sont démarrées et montées et sont maintenant principales dans la région de secours.
• Les copies répliquées des applications principales sont lancées et validées et sont désormais principales dans la région de secours.
• Toute modification du DNS et des équilibreurs de charge est effectuée pour permettre l'accès à l'application sur le réseau public.

Secours chaude

Dans ce scénario, les machines virtuelles existent à la fois dans la région principale et dans la région de secours, mais elles sont complètement indépendantes les unes des autres et ont leurs propres noms d'hôtes uniques et leurs adresses IP préaffectées. Les VM de la région de secours existent et peuvent être arrêtées ou en cours d'exécution selon les préférences du client.

Affiche une image avec la région principale à gauche et la région de secours à droite. La région principale comporte trois blocs : application, base de données et infrastructure, chacun contenant ses icônes respectives. Les deux régions comportent une icône représentant un équilibreur de charge au sommet. L'icône de l'équilibreur de charge dans la région de secours est plus claire que celle de la région principale. La région de secours comporte trois blocs : application, base de données et infrastructure. Dans la région de secours, le bloc d'infrastructure est peuplé d'icônes - une pour le stockage d'objets, une pour le stockage de blocs et une pour le stockage de fichiers. Il existe également une icône pour les machines virtuelles au niveau de l'infrastructure, mais elle est plus claire. Les icônes de la base de données et de l'application dans la région de secours sont également plus claires. Deux flèches représentant la réplication du stockage objet et la réplication du stockage sont montrées entre les deux blocs d'infrastructure. Ces flèches représentent la réplication de la région principale vers la région de secours.

Les bases de données doivent fonctionner à la fois sur la région principale et sur la région de secours.

Pour les bases de données Oracle, nous recommandons d'utiliser Oracle Data Guard pour répliquer la base de données principale et la base de données de secours. Reportez-vous à notre architecture de référence Gold MAA pour plus de détails.

Pour les bases de données non-Oracle, les technologies de réplication natives respectives seront utilisées pour maintenir la synchronisation des bases de données entre les régions principale et de secours.

Les applications existent également dans la région cloud de secours, mais ne sont pas exécutées ou accessibles.

Exemple de workflows de reprise après sinistre pour cette architecture de déploiement

Les deux scénarios suivants décrivent comment le flux de processus pour les opérations de reprise après sinistre pour les déploiements de secours à chaud pourrait se dérouler.

Dans le cas d'une commutation, les tâches suivantes sont effectuées dans les régions principale et de secours :

• Les applications principales sont mises en veille.
• Les bases de données principales sont mises en veille et synchronisées avec la région de secours.
• Les machines virtuelles principales sont stoppées net.
• Le stockage principal est synchronisé avec la région de secours.
• Le stockage répliqué est mis en ligne, la réplication est inversée, et il est maintenant principal dans la région de secours.
• Les machines virtuelles de secours sont lancées si elles ne sont pas déjà en cours d'exécution, et toutes les applications ou outils système requis par la pile d'applications sont lancés et sont maintenant principaux dans la région de secours.
• Les bases de données de secours sont passées en accès complet en lecture/écriture et sont maintenant principales dans la région de secours.
• Les applications de secours sont lancées et validées et sont maintenant principales dans la région de secours.
• Toute modification du DNS et des équilibreurs de charge est effectuée pour permettre l'accès à l'application sur le réseau public.

Dans le cas d'un basculement, les tâches suivantes ne sont exécutées que dans la région de secours :

• Le stockage répliqué est mis en ligne, la réplication est inversée si possible, et il devient principal dans la région de secours.
• Les machines virtuelles de secours sont lancées si elles ne sont pas déjà en cours d'exécution, et toutes les applications ou outils système requis par la pile d'applications sont lancés et sont maintenant principaux dans la région de secours.
• Les bases de données de secours sont récupérées à l'aide des dernières transactions et des derniers redo logs du stockage répliqué.
• Les bases de données de secours sont passées en accès complet en lecture/écriture et sont maintenant principales dans la région de secours.
• Les applications de secours sont lancées et validées et sont maintenant principales dans la région de secours.
• Toute modification du DNS et des équilibreurs de charge est effectuée pour permettre l'accès à l'application sur le réseau public.

Secours à chaud

Dans ce scénario, les machines virtuelles existent et fonctionnent à la fois sur le site principal et sur le site de secours, avec leurs propres noms d'hôtes uniques et leurs adresses IP préaffectées.

Affiche une image avec la région principale à gauche et la région de secours à droite. La région principale comporte trois blocs : application, base de données et infrastructure, chacun contenant ses icônes respectives. Les deux régions comportent une icône représentant un équilibreur de charge au sommet. L'icône de l'équilibreur de charge dans la région de secours est plus claire que celle de la région principale. La région de secours comporte trois blocs : application, base de données et infrastructure. Les régions principale et de secours ont toutes deux des icônes dans les blocs d'application, de base de données et d'infrastructure. Le bloc d'infrastructure comporte des icônes pour les machines virtuelles, le stockage de fichiers, le stockage d'objets et le stockage de blocs dans les régions principale et de secours. Seules les icônes de la base de données dans la région de secours sont plus claires. Deux flèches représentant la réplication du stockage objet et la réplication du stockage sont montrées entre les deux blocs d'infrastructure. Ces flèches représentent la réplication de la région principale vers la région de secours.

Les bases de données doivent fonctionner à la fois sur la région principale et sur la région de secours.

Pour les bases de données Oracle, nous recommandons d'utiliser Oracle Data Guard pour répliquer la base de données principale et la base de données de secours. Reportez-vous à notre architecture de référence Gold MAA pour plus de détails.

Pour les bases de données non-Oracle, les technologies de réplication natives respectives seront utilisées pour maintenir la synchronisation des bases de données entre les régions principale et de secours.

Les applications sont exécutées dans la région cloud de secours, mais ne sont pas accessibles sur le réseau public.

Exemple de workflows de reprise après sinistre pour cette architecture de déploiement

Les deux scénarios suivants décrivent comment le flux de processus pour les opérations de reprise après sinistre pour les déploiements de secours à chaud pourrait se dérouler.

Dans le cas d'une commutation, les tâches suivantes sont effectuées dans les régions principale et de secours :

• Les applications principales sont mises en veille.
• Les bases de données principales sont mises en veille et synchronisées avec la région de secours.
• Les machines virtuelles principales sont stoppées net.
• Le stockage principal est synchronisé avec la région de secours.
• Le stockage répliqué est mis en ligne, la réplication est inversée, et il est maintenant principal dans la région de secours.
• Les machines virtuelles de secours sont déjà en cours d'exécution, et toutes les applications ou outils système requis par la pile d'applications sont démarrés et sont maintenant principaux dans la région de secours.
• Les bases de données de secours sont passées en accès complet en lecture/écriture et sont maintenant principales dans la région de secours.
• Les applications de secours sont lancées et validées et sont maintenant principales dans la région de secours.
• Toute modification du DNS et des équilibreurs de charge est effectuée pour permettre l'accès à l'application sur le réseau public.

Dans le cas d'un basculement, les tâches suivantes ne sont exécutées que dans la région de secours :

• Le stockage répliqué est mis en ligne, la réplication est inversée si possible, et il devient principal dans la région de secours.
• Les machines virtuelles de secours sont lancées si elles ne sont pas déjà en cours d'exécution, et toutes les applications ou outils système requis par la pile d'applications sont lancés et sont maintenant principaux dans la région de secours.
• Les bases de données de secours sont récupérées à l'aide des dernières transactions et des derniers redo logs du stockage répliqué.
• Les bases de données de secours sont passées en accès complet en lecture/écriture et sont maintenant principales dans la région de secours.
• Les applications de secours sont lancées et validées et sont maintenant principales dans la région de secours.
• Toute modification du DNS et des équilibreurs de charge est effectuée pour permettre l'accès à l'application sur le réseau public.

Architecture de déploiement actif/actif

Dans ce scénario, l'ensemble de la pile d'applications est entièrement fonctionnelle et gère une charge de travail à la fois sur le site principal et sur le site de secours.

Affiche une image avec la région principale à gauche et la région de secours à droite. La région principale et la région de secours ont chacune trois blocs : application, base de données et infrastructure, contenant chacun leurs icônes respectives. Les deux régions comportent une icône représentant un équilibreur de charge au sommet. Aucun des blocs n'est grisé. Les icônes des blocs d'application, de base de données et d'infrastructure dans les régions principale et de secours sont affichées en couleur. Une flèche représentant la réplication optionnelle du stockage est indiquée entre les deux blocs d'infrastructure. Cette flèche représente la réplication de la région principale vers la région de secours.

Les bases de données doivent fonctionner à la fois sur la région principale et sur la région de secours.

Pour les bases de données Oracle, nous recommandons d'utiliser Oracle GoldenGate pour avoir une configuration active/active des applications. En dehors de cela, nous recommandons d'avoir des bases de données de secours locales dans chaque région en utilisant Oracle Data Guard pour obtenir un RTO et un RPO proches de zéro. Consultez notre architecture de référence MAA platine pour plus de détails.

Pour les bases de données non-Oracle, la réplication native et les technologies actives/actives respectives seront utilisées pour maintenir la synchronisation de la base de données entre les régions principale et de secours.

Les applications sont en cours d'exécution et accessibles sur le réseau public de la région cloud de secours et ont une charge de travail en cours d'exécution.

Automatisation des tâches de reprise après sinistre avec DRaaS

Les équipes d'Oracle ont déployé des efforts considérables pour intégrer la haute disponibilité dans leurs produits - y compris la grande majorité des bases de données et des applications d'entreprise d'Oracle - et conçoivent souvent les meilleures pratiques et les architectures de déploiement pour assurer la reprise après sinistre dans les environnements traditionnels sur site et dans le cloud. Chaque ligne de produits élabore une approche de reprise après sinistre pour ses applications individuelles, qui comprend des étapes étroitement liées pour récupérer tous les composants nécessaires à la prise en charge de l'application.

La reprise après sinistre basée sur le cloud en tant que service permet de regrouper toutes les étapes peu complexes conçues par les développeurs, les architectes cloud et les architectes de solutions de produits en un workflow unique et transparent qui peut être lancé d'un simple clic. OCI propose une solution DRaaS appelée Full Stack Disaster Recovery qui est flexible, hautement évolutive et hautement extensible.

OCI Full Stack Disaster Recovery gère la transition de l'infrastructure, des bases de données et des applications entre les régions OCI, de n'importe où dans le monde, en un seul clic. Les clients peuvent déployer des environnements de reprise après sinistre sans avoir à reconfigurer ou redéployer l'infrastructure, les bases de données ou les applications existantes, tout en éliminant le besoin de serveurs de gestion ou de conversion spécialisés.

• En savoir plus sur OCI Full Stack Disaster Recovery
• En savoir plus sur Reprise après sinistre pour OCI