Déployer une base de données Bare Metal hautement disponible
Oracle Data Guard garantit la haute disponibilité, la protection des données et la récupération après sinistre des données d'entreprise. Avec Data Guard, le basculement de la base de données principale vers la base de données de secours peut être effectué manuellement à l'aide de l'interface de ligne de commande Data Guard Broker (CLI DGMGRL) ou d'Oracle Enterprise Manager, ou automatiquement en configurant un noeud Compute pour agir en tant qu'observateur FSFO (Fast-Start Failover). L'observateur peut déclencher automatiquement le basculement et rétablir automatiquement une base de données principale défaillante en tant que base de données de secours. Le fait d'avoir des observateurs FSFO dans le déploiement élimine la nécessité d'une intervention manuelle lorsque le basculement de la base de données est nécessaire.
Architecture
Cette architecture de référence montre comment déployer deux systèmes Bare Metal DB et les composants d'infrastructure nécessaires pour configurer FSFO pour une base de données Oracle 12c version 2 (12.2) déployée sur Oracle Cloud Infrastructure dans deux régions.
Cette architecture de base de données cloud peut être utilisée comme niveau de base de données résilient pour de nombreuses applications, y compris Oracle E-Business Suite, JD Edwards et PeopleSoft.
Le diagramme suivant illustre cette architecture de référence.
Description de l'illustration ha-db.png
- Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient un ou plusieurs centres de données, appelés domaines de disponibilité. Les régions sont indépendantes des autres régions et de vastes distances peuvent les séparer (d'un pays à l'autre ou même d'un continent à l'autre).
- Domaine 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 permet de tolérer les pannes. Les domaines de disponibilité ne partagent pas d'infrastructure comme l'alimentation ou le refroidissement, ou le réseau de domaine de disponibilité interne. Il est donc peu probable qu'un échec dans un domaine de disponibilité affecte les autres domaines de disponibilité de la région.
Les domaines de disponibilité ne sont pas affichés dans le diagramme d'architecture.
- Domaines d'erreur
Un domaine de panne est un regroupement de matériel et d'infrastructure au sein d'un domaine de disponibilité. Chaque domaine de disponibilité dispose de trois domaines de pannes dotés d'une alimentation et d'un matériel indépendants. Lorsque vous distribuez des ressources dans plusieurs domaines de pannes, vos applications peuvent tolérer la panne du serveur physique, la maintenance du système et les pannes d'alimentation dans un domaine de panne.
Les domaines de pannes ne sont pas affichés dans le diagramme d'architecture.
- Réseau cloud virtuel (VCN) et sous-réseaux
Un VCN est un réseau personnalisé et défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux traditionnels de centres de données, les VCN vous donnent un contrôle complet sur votre environnement réseau. Un VCN peut avoir plusieurs blocs CIDR sans chevauchement que vous pouvez modifier après avoir créé VCN. Vous pouvez segmenter un VCN en sous-réseaux, qui peuvent être étendus à 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 de VCN. Vous pouvez modifier la taille d'un sous-réseau après la création. Un sous-réseau peut être public ou privé.
- Listes de sécurité
Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui spécifient la source, la destination et le type de trafic qui doivent être autorisés dans et hors du sous-réseau.
- Observateurs
Les observateurs sont des noeuds de calcul dont le logiciel Oracle Database nécessaire est installé et configuré pour lancer FSFO d'Oracle Database exécuté sur le système de base de données Bare Metal. Une pratique exemplaire de FSFO consiste à exécuter le processus d'observation sur un hôte situé dans un centre de données différent de la base de données principale ou de secours. Pour répondre à cette pratique exemplaire, cette architecture de référence déploie trois noeuds d'observateur. La version 12.2 ou supérieure d'Oracle Database est requise pour cette configuration.
- Systèmes de base de données principal et de secours
Ces systèmes Bare Metal DB disposent d'une base de données Oracle Database 12c version 2 (12.2) configurée pour la réplication Data Guard.
Recommandations
Vos exigences peuvent différer de l'architecture décrite ici. Utiliser les recommandations suivantes comme point de départ.
- Formes du système de base de données
Cette architecture de référence utilise la forme Bare Metal BM.Standard2.52 pour les systèmes de base de données. Cette forme comporte 51.2 To de disques SSD NVMe attachés localement avec une faible latence. Nous avons sélectionné la forme Bare Metal car elle nous permet de créer plusieurs répertoires de base de données et bases de données.
- Calculer les formes
Cette architecture de référence utilise une forme de machine virtuelle de base VM.Standard2.1 (VM) pour les noeuds d'observateur. Le noeud observateur est un client Oracle Call Interface à faible empreinte intégré à la CLI DGMGRL. Une forme de machine virtuelle unique suffit pour cette architecture.
- VCN
Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez d'attacher à des sous-réseaux dans VCN. Utilisez les blocs CIDR qui se trouvent dans l'espace d'adresse IP privé standard.
Sélectionnez des blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur site ou un autre fournisseur de cloud) auquel vous avez l'intention de configurer des connexions privées.
Une fois que vous avez 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é. Attachez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, qui peut servir de limite de sécurité.
Utilisez des sous-réseaux régionaux.
- Listes de sécurité
Utilisez les listes de sécurité pour définir les règles d'entrée et d'évacuation qui s'appliquent à l'ensemble du sous-réseau. Par exemple, cette architecture de référence permet ICMP en interne pour l'ensemble du sous-réseau privé.
- Cloud Guard
Cloner et personnaliser les recettes par défaut fournies par Oracle pour créer des recettes de détecteur et de réponse personnalisées. Ces recettes vous permettent de spécifier quel type de violation de sécurité génère un avertissement et quelles actions sont autorisées pour ces violations. Par exemple, vous pouvez détecter les buckets Object Storage dont la visibilité est définie sur Public.
Appliquer Cloud Guard au niveau de la location pour couvrir la portée la plus large et réduire la charge administrative de la maintenance de plusieurs configurations.
Vous pouvez également utiliser la fonction Liste gérée pour appliquer certaines configurations aux détecteurs.
- Security Zones
Pour les ressources nécessitant une sécurité maximale, Oracle vous recommande d'utiliser des zones de sécurité. Une zone de sécurité est un compartiment associé à une recette de stratégies de sécurité définie par Oracle basée sur les meilleures pratiques. Par exemple, les ressources d'une zone de sécurité ne doivent pas être accessibles à partir d'Internet public et elles doivent être cryptées à l'aide de clés gérées par le client. Lorsque vous créez et mettez à jour des ressources dans une zone de sécurité, Oracle Cloud Infrastructure valide les opérations par rapport aux stratégies de la recette de zone de sécurité et refuse les opérations qui violent l'une quelconque des stratégies.
Remarques
Tenez compte de ces points lors du déploiement de cette architecture de référence.
- Performances
Pour obtenir les meilleures performances pour vos charges de travail d'application, assurez-vous que votre système de base de données Bare Metal principal dispose de suffisamment de coeurs pour prendre en charge l'application et la configuration Data Guard.
- Disponibilité
Les noeuds d'observateur sont déployés dans plusieurs régions de disponibilité afin de s'assurer que la FSFO peut se produire automatiquement même si l'un des noeuds d'observateur est hors ligne. Après le basculement, la base de données de secours devient la base de données principale.
- Coût
Taille des CPU sur les systèmes Bare Metal DB en fonction de vos besoins. Vous pouvez commencer par deux coeurs ou plus et mettre à l'échelle jusqu'à 52 coeurs sur une forme BM.DenseIO2.52. Vous pouvez également augmenter dynamiquement les cœurs sans temps d'arrêt.