Conception d'une topologie de récupération après sinistre pilote

Si une panne à grande échelle affecte vos applications de production, vous devez pouvoir restaurer rapidement les charges globales. Votre plan de continuité de l’activité doit inclure une stratégie de récupération après sinistre qui répond à vos objectifs de point de récupération, de temps de récupération et de budget. Une topologie pilote-light offre un équilibre entre les coûts et les besoins de recouvrement.

Le terme lumière pilote désigne une petite flamme qui est toujours allumée dans des dispositifs tels que des dispositifs de chauffage à gaz et qui peut être utilisée pour démarrer les dispositifs rapidement lorsque cela est nécessaire. Dans le contexte de la récupération après sinistre, un environnement pilote-lumière contient les principaux composants d'une charge globale donnée, avec les dernières données de configuration et critiques, exécutées à une échelle minimale à un emplacement distant du site principal. En cas de sinistre sur le site principal, vous pouvez utiliser les composants pilote-lumière à l'emplacement distant pour restaurer rapidement un environnement de production.

Oracle Cloud Infrastructure fournit une infrastructure et des services hautement disponibles et évolutifs qui vous permettent de concevoir une topologie de récupération après sinistre pilote.

Architecture

Cette architecture présente une topologie à plusieurs niveaux avec des ressources redondantes réparties dans deux régions Oracle Cloud Infrastructure.

Le diagramme suivant illustre cette architecture de référence.

Description de l'image x-region-pilot-light-topology.png

Description de l'illustration x-region-pilot-light-topology.png

L'architecture comporte les composants suivants :

Régions
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient des centres de données, appelés domaines de disponibilité. Les régions sont indépendantes d'autres régions et de grandes distances peuvent les séparer (dans les pays voire les continents).
Domaines de disponibilité
Les domaines de disponibilité sont des centres de données autonomes et indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées des ressources des autres domaines de disponibilité, ce qui assure la tolérance de pannes. Les domaines de disponibilité ne partagent ni infrastructure telle que l'alimentation ou le refroidissement, ni réseau interne. Par conséquent, il est improbable qu'un problème affecte les autres domaines de disponibilité de la région.

Le diagramme d'architecture n'affiche pas les domaines de disponibilité. Toutefois, dans les régions comportant plusieurs domaines de disponibilité, vous pouvez répartir les ressources de chaque région entre les domaines de disponibilité, à des fins de haute disponibilité.
Domaines de pannes
Un domaine de pannes est un regroupement de matériel et d'infrastructures au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines de pannes avec une alimentation et un matériel indépendants. Lorsque vous distribuez des ressources entre plusieurs domaines de pannes, vos applications peuvent tolérer les pannes de serveur physique, la maintenance du système et les pannes d'alimentation au sein d'un domaine de pannes.

Le diagramme d'architecture n'affiche pas les domaines de pannes. Mais pour vous protéger contre les pannes au sein d'un domaine de pannes, vous pouvez répartir les ressources de chaque disponibilité entre les domaines de pannes.
Réseaux cloud virtuels (VCN) et sous-réseaux
Un VCN est un réseau personnalisable et défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux cloud virtuels traditionnels, vous bénéficiez d'un contrôle total sur votre environnement réseau. Un VCN peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, qui peuvent être ciblés vers une région ou un domaine de disponibilité. Chaque sous-réseau se compose d'une plage contiguë d'adresses qui ne chevauchent pas les autres sous-réseaux du VCN. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.

Dans cette architecture de référence, toutes les ressources de chaque région sont associées à un seul VCN.
Bastion
L'hôte de base est une instance de calcul qui sert de point d'entrée sécurisé et contrôlé vers la topologie en dehors du cloud. Le bastion est généralement provisionné dans une zone démilitarisée (DMZ). Il permet de protéger les ressources sensibles en les plaçant dans des réseaux privés inaccessibles directement depuis l'extérieur du cloud. La topologie possède un seul point d'entrée connu que vous pouvez surveiller et auditer régulièrement. Ainsi, vous pouvez éviter d'exposer les composants les plus sensibles de la topologie sans compromettre l'accès à ces composants.
Equilibreur de charge
Le service Oracle Cloud Infrastructure Load Balancing fournit une répartition de trafic automatisée à partir d'un seul point d'entrée vers plusieurs serveurs du back-end.
Passerelle Internet
La passerelle Internet autorise le trafic entre les sous-réseaux publics d'un VCN et le réseau Internet public.
instances de calcul
La région principale comprend deux instances de calcul pour le niveau d'application.

La région de secours dispose d'une instance de calcul pour le montage du stockage de fichiers répliqué. Les deux autres instances de calcul de la région de secours représentent des serveurs que vous pouvez créer en utilisant des volumes d'initialisation et des volumes de blocs répliqués, en cas de sinistre dans la région principale.
volumes de blocs
Avec les volumes de stockage de blocs, vous pouvez créer, attacher, connecter et déplacer des volumes de stockage, et modifier leurs performances pour répondre à vos exigences en matière de stockage, de performances et d'application. Après avoir attaché et connecté un volume à une instance, vous pouvez l'utiliser comme un disque dur classique. Vous pouvez également déconnecter un volume et l'associer à une autre instance sans perdre de données.

L'architecture affiche les volumes d'initialisation et les volumes de blocs de la région principale en cours de réplication vers la région de secours. Avec cette conception, en cas de sinistre dans la région principale, vous pouvez restaurer rapidement le niveau d'application dans la région de secours en provisionnant des instances de calcul à l'aide des volumes de blocs et d'initialisation répliqués.
File Storage
Le service Oracle Cloud Infrastructure File Storage offre un système de fichiers réseau durable, évolutif, sécurisé et adapté à l'entreprise. Vous pouvez vous connecter à un système de fichiers de service File Storage à partir de n'importe quelle instance Bare Metal, de machine virtuelle ou de conteneur dans un VCN. Vous pouvez également accéder à un système de fichiers en dehors du VCN à l'aide d'Oracle Cloud Infrastructure FastConnect et du VPN IPSec.

L'architecture affiche le stockage de fichiers dans la région principale en cours de réplication vers la région de secours à l'aide d'un script.
Object Storage
Object Storage fournit un accès rapide à de grandes quantités de données structurées et non structurées de tout type de contenu, y compris des sauvegardes de base de données, des données analytiques et du contenu enrichi, comme des images et des vidéos. Vous pouvez stocker des données en toute sécurité, puis les extraire directement à partir d'Internet ou de la plate-forme cloud. Vous pouvez faire évoluer le stockage de manière transparente sans subir de dégradation des performances ou de la fiabilité du service. Utilisez le stockage standard pour le stockage à chaud auquel vous devez accéder rapidement, immédiatement et fréquemment. Utilisez le stockage d'archive pour un stockage "à froid" que vous conservez pendant de longues périodes et rarement ou rarement accès.

L'architecture affiche automatiquement le stockage d'objets dans la région principale en cours de réplication vers la région de secours à l'aide d'une stratégie de réplication inter-région.
Serveur d'applications
Les serveurs d'applications utilisent un pair secondaire qui, comme la base de données, prendra en charge le traitement en cas de sinistre. Les serveurs d'applications utilisent la configuration et les métadonnées stockées à la fois dans la base de données et dans le système de fichiers. Le clustering de serveur d’applications offre une protection dans le cadre d’une seule région, mais les modifications en cours et les nouveaux déploiements doivent être répliqués sur le site secondaire de manière continue en vue d’une récupération après sinistre cohérente.
Base de données
L'architecture inclut une base de données dans chaque région. Oracle Data Guard est utilisé pour la réplication des données et garantit que la base de données de secours est une copie cohérente sur le plan transactionnel de la base principale.

Data Guard maintient automatiquement la synchronisation entre les bases de données en transmettant les données redo de la base principale à la base de données de secours et en les appliquant. En cas de sinistre dans la région principale, Data Guard bascule automatiquement vers la base de données de secours.
Passerelle de routage dynamique
DRG est un routeur virtuel qui fournit un chemin pour le trafic réseau privé entre un VCN et un réseau en dehors de la région, tel qu'un VCN dans une autre région Oracle Cloud Infrastructure, un réseau sur site ou un réseau dans un autre fournisseur cloud.
passerelle NAT
La passerelle NAT permet aux ressources privées d'un VCN d'accéder aux hôtes sur Internet sans les exposer aux connexions Internet entrantes.
Passerelle de service
La passerelle de service fournit l'accès d'un VCN à d'autres services, tels qu'Oracle Cloud Infrastructure Object Storage. Le trafic du VCN vers le service Oracle circule sur la structure réseau Oracle et ne parcourt jamais Internet.

Recommandations

Utilisez les recommandations suivantes comme point de départ pour concevoir votre topologie DR pilote-light. Vos besoins peuvent être différents de ceux de l'architecture décrite ici.

VCN
Lorsque vous créez chaque VCN, déterminez le nombre d'adresses IP nécessaires à vos ressources cloud dans chaque sous-réseau. A l'aide de la notation CIDR (Classless Inter-Domain Routing), indiquez un masque de sous-réseau et une plage d'adresses réseau suffisamment grande pour les adresses IP requises. Utilisez une plage d'adresses comprise dans l'espace d'adresse IP privée standard.

Sélectionnez des blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données on-premise ou un autre fournisseur cloud) auquel vous souhaitez configurer des connexions privées.

Après avoir créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR.

Lorsque vous concevez les sous-réseaux, tenez compte de vos exigences en matière de flux de trafic et de sécurité. Associez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, ce qui peut servir de limite de sécurité.

Utilisez des sous-réseaux régionaux.
Liste de sécurité
Pour permettre la réplication inter-région de la base de données et du stockage de fichiers, configurez les listes de sécurité requises. Notez que la réplication des volumes d'initialisation et des volumes de blocs ne nécessite pas de communication entre les hôtes auxquels les volumes sont attachés.
Stratégie de sauvegarde de volumes de blocs
Configurez une stratégie pour effectuer les sauvegardes des volumes de blocs aussi souvent que nécessaire pour répondre à votre RPO.
Serveurs d'applications et applications personnalisées exécutés sur Oracle Platform as a Service (PaaS)
Les services PaaS, tels qu'Oracle SOA Cloud Service et Oracle WebLogic Server for Oracle Cloud Infrastructure, utilisent la plupart des ressources mentionnées ci-dessus en interne (calcul, volumes de blocs, stockage de fichiers, mise en réseau, base de données). Elles nécessitent des stratégies de récupération après sinistre spécifiques qui protègent toutes les différentes couches de manière cohérente. Oracle fournit des meilleures pratiques détaillées destinées à créer des architectures de disponibilité maximale (MAA) et à protéger ce type de systèmes contre les catastrophes. Reportez-vous à Explorer plus pour obtenir une documentation spécifique sur la récupération après sinistre pour PaaS.

Remarques

Lors de l'implémentation de votre configuration de récupération après sinistre pilote, tenez compte des facteurs suivants :

Performances
Lors de la planification du RPO et du RTO, tenez compte du temps nécessaire à la copie des sauvegardes de volume entre les régions.
Disponibilité
Vous pouvez utiliser la gestion de pilotage DNS pour rediriger le trafic client vers la région de production actuelle après un basculement.

Si vous utilisez des formes de calcul qui fournissent des périphériques NVMe connectés localement, vous pouvez sauvegarder les données sur ces périphériques à l'aide de solutions de sauvegarde traditionnelles qui utilisent le stockage d'objets.
Coût
En cas de basculement de la région principale vers la région de secours, vous pouvez provisionner rapidement l'infrastructure requise à l'aide de scripts Terraform. Vous pouvez redimensionner les systèmes de base de données après les avoir provisionnés. Indiquez donc la forme minimale requise initialement et passez à une forme plus grande après le basculement.

Voir plus

En savoir plus sur la récupération après sinistre et la résilience dans Oracle Cloud Infrastructure.

Consultez les présentations techniques de récupération après sinistre MAA pour les services Oracle PaaS suivants :

Récupération après sinistre de SOA Suite sur Oracle Cloud Infrastructure Marketplace

Récupération après sinistre d'Oracle WebLogic Server pour Oracle Cloud Infrastructure