Remarques concernant la conception
Evaluez les options de conception permettant de construire une topologie cloud sécurisée et hautement disponible.
Isolement du réseau
- Scénario 1 : utiliser uniquement des sous-réseaux privés
Pour les déploiements en production qui ne nécessitent pas d'adresses Internet, attachez toutes les ressources aux sous-réseaux privés. Impossible d'accéder directement aux ressources à partir du réseau Internet public. Ce type de déploiement est utile lorsque vous voulez déployer une topologie hybride, la topologie cloud étant une extension de votre centre de données on-premise.
Pour accéder à la topologie cloud à partir de votre environnement sur site, vous pouvez utiliser des tunnels VPN IPSec ou des circuits virtuels FastConnect. La création d'un bastion permet d'accéder à tous les serveurs attachés aux sous-réseaux privés.
- Scénario 2 : utiliser des sous-réseaux publics et privés
Vous pouvez attacher quelques instances à un sous-réseau public et le reste aux sous-réseaux privés. Ce type de déploiement est utile lorsque les applications ont à la fois des adresses Internet et des adresses sans proxy.
Par exemple, certaines applications peuvent être utilisées par des utilisateurs internes et d'autres applications peuvent servir des utilisateurs externes. Attachez les instances d'application qui traitent le trafic interne aux sous-réseaux privés et attachez les serveurs d'applications qui traitent le trafic externe à un sous-réseau public.
En outre, pour les instances d'application Internet, au lieu d'attacher les serveurs d'applications à un sous-réseau public, vous pouvez utiliser un équilibreur de charge public.
Si vous créez un hôte de base et que vous l'attachez à un sous-réseau public dans cette topologie, vous pouvez accéder aux instances de calcul associées aux sous-réseaux privés via l'hôte de base.
- Scénario 2 : utiliser uniquement des sous-réseaux publics
Pour les essais ou les démonstrations rapides, ou pour les déploiements à production qui ne nécessitent pas d'adresses internes, vous pouvez choisir d'attacher toutes les ressources aux sous-réseaux publics. Ce déploiement est adapté si vous ne disposez pas de votre propre centre de données, ou si vous ne pouvez pas accéder au cloud à l'aide de tunnels VPN IPSec ou de circuits virtuels FastConnect. Dans ce déploiement, toutes les instances, y compris les instances d'application et de base de données, sont attachées aux sous-réseaux publics. Chaque instance dispose d'une adresse IP publique. Vous pouvez réguler l'accès réseau aux ressources privées à l'aide de listes de sécurité ou de groupes de sécurité réseau.
Pour contrôler l'accès administrateur à ce type de topologie cloud, il est conseillé de créer un hôte de base par le biais duquel vous pouvez accéder à tous les serveurs de la topologie. Avec cette approche, vous ouvrez les ports d'administration uniquement sur l'hôte de base (et non sur le réseau Internet public), en utilisant des listes de sécurité ou des groupes de sécurité réseau.
Haute disponibilité
- Le service Oracle Cloud Infrastructure Load Balancing crée une paire primary-standby de noeuds d'équilibreur de charge. Les noeuds sont déployés dans des domaines de disponibilité distincts. Dans les régions comportant un seul domaine de disponibilité, les noeuds d'équilibreur de charge sont créés dans des domaines de pannes distincts. L'équilibreur de charge n'est donc pas affecté par les pannes matérielles et les coupures du centre de données.
- Fournir les infos de paramétrage de ressources redondantes dans le niveau Web, le niveau Applications et le niveau Base de données. Si vous décidez de déployer la topologie dans un domaine de disponibilité unique, vous pouvez alors distribuer les ressources entre les domaines de pannes au sein du domaine de disponibilité. Si votre région comporte plusieurs domaines de disponibilité, vous pouvez profiter de l'isolement du centre de données que ces régions offrent et provisionner les ressources redondantes et de production dans des domaines de disponibilité distincts.
- Pour la haute disponibilité des bases de données, vous pouvez créer un système de base de données de machine virtuelle 2-node, qui fournit Oracle Real Applications Clusters (RAC). Par défaut, les deux noeuds sont créés dans des domaines de pannes distincts. Vous pouvez explicitement choisir un domaine d'erreur pour les noeuds RAC lors de la fourniture d'infos de paramétrage de base de données. Par conséquent, les noeuds de base de données ne s'exécutent pas sur le même matériel physique. Ce déploiement protège les bases de données contre les pannes dans les hôtes physiques sous-jacents et le commutateur supérieur du rack.
- Pour la récupération après sinistre, envisagez de déployer une topologie de secours dans une région distante.
Stratégie de sauvegarde
Implémenter une stratégie de sauvegarde fiable pour la base de données et les applications, afin de permettre une récupération efficace de vos données et applications en cas de coupure.
Vous pouvez configurer les sauvegardes automatiques et à la demande des bases de données sur Oracle Cloud Infrastructure Object Storage. Toutes les sauvegardes de base de données sont cryptées à l'aide de la même clé maître que celle utilisée pour le cryptage de portefeuille de cryptage transparent des données. Le service de sauvegarde automatique de base de données utilise une stratégie de sauvegarde incrémentielle hebdomadaire pour sauvegarder les bases de données, avec une stratégie de conservation que vous pouvez personnaliser.
Pour les applications, vous pouvez configurer des sauvegardes basées sur des stratégies des volumes de blocs. Chaque stratégie de sauvegarde comporte une fréquence de sauvegarde et une durée de conservation prédéfinies. Choisissez une stratégie qui vous aide à respecter vos exigences de conformité et vos contraintes réglementaires.