Déployez une solution multicloud split-stack sur OCI, AWS et GCP

Implémentez une architecture split-stack multicloud hautes performances à l'aide d'Oracle Autonomous Database, pour les applications hébergées sur des fournisseurs de cloud public, avec un minimum de modifications sur l'architecture et la plate-forme technologique existantes.

Remarque :

Avec une solution multicloud, la mise en réseau est un déterminant clé des performances globales du système. Il incombe au client de s'assurer que le réseau Cloud-to-Cloud (bande passante et latence) est entièrement testé pour s'assurer que les performances de l'application répondent aux exigences métier définies.

Cette architecture de référence décrit une solution split-stack multicloud inspirée par le client. Avec une base d'abonnés d'applications de 2 millions d'utilisateurs en expansion rapide, le client recherchait des options pour migrer sans temps d'arrêt vers un environnement capable de l'aider à évoluer à la demande. L'entreprise souhaitait disposer de la flexibilité nécessaire pour répondre à la demande et réaliser des économies par rapport à son déploiement existant.

Les exigences des clients ont été satisfaites avec une solution multicloud split-stack par :
  • Migration de la base de données vers Oracle Autonomous Database, qui offre les avantages d'une disponibilité, de performances, d'une évolutivité, d'une sécurité et d'une productivité maximales.
  • Conservation de la pile d'applications dans Amazon Web Services (AWS) et Google Cloud Platform (GCP), respectivement, pour minimiser le changement des intégrations avec d'autres applications.
  • Utilisation d'Oracle Cloud Infrastructure (OCI) GoldenGate pour migrer de la base de données sur AWS EC2 vers Oracle Autonomous Database sans temps d'inactivité.

Architecture

Dans cette architecture de référence, la base de données de production est déployée dans OCI US-East (Ashburn) et les applications sont déployées dans AWS US-East (N.Virginia) et GCP US-East (Ashburn). La connectivité dédiée utilisant OCI FastConnect était essentielle. Equinix, partenaire d'OCI FastConnect, a été engagé pour connecter les charges de travail OCI à AWS et GCP dans la même région.

Dans cet exemple, le client a utilisé Equinix Fabric pour connecter OCI FastConnect à AWS Direct Connect et Google Interconnect directement. Latence réseau testée entre OCI et AWS à 2-4 ms et entre OCI et GCP à Ashburn.

Une connexion multicloud similaire peut être configurée par n'importe quel fournisseur OCI FastConnect qui dessert l'emplacement du centre de données, tel que Megaport, AT&T, Lumen, NTT, Verizon ou n'importe quel atelier avec un fournisseur d'échange de télécommunications.

Cette solution s'applique à un scénario de cloud hybride dans lequel le centre de données client est colocalisé avec le centre de données OCI ou à moins de 30 à 40 miles du voisinage.

Architecture multicloud Split-Stack

La base de données de production est déployée sur OCI dans Autonomous Database pour le traitement transactionnel. La réplication OCI GoldenGate est préparée dans un sous-réseau distinct à utiliser à la demande entre les sites. Le service informatique du client accède aux ressources OCI via le service Bastion via le VPN privé ou via FastConnect vers OCI.

AWS héberge les bases de données AWS EC2, RDS Oracle et PowerBuilder Apps se connectant à la base de données avec AWS DirectConnect via le partenaire OCI Fastconnect à OCI.

GCP héberge .NET, Go-Lang et d'autres applications open source se connectant à la base de données avec Google Interconnect via le partenaire OCI Fastconnect vers OCI.

La récupération après sinistre est implémentée à l'aide d'Autonomous Data Guard pour synchroniser la base de données dans une autre région où plusieurs fournisseurs cloud disposent de centres de données situés à proximité, tels qu'OCI US-West (San Jose) et AWS US-West (N). Californie). Pour l'implémentation de la récupération après sinistre, vous pouvez héberger les bases de données AWS EC2, RDS Oracle et PowerBuilder Apps on AWS et vous connecter à la base de données avec AWS DirectConnect via le partenaire OCI FastConnect pour OCI.

Le diagramme de topologie d'architecture suivant illustre l'architecture multicloud :



oci-aws-gcp-split-stack-oracle.zip

Migration du cloud d'AWS vers OCI

La migration sans temps d'inactivité est effectuée à l'aide de la réplication bidirectionnelle OCI GoldenGate. OCI GoldenGate permet la configuration de la base de données active-active, dans laquelle deux systèmes avec des ensembles de données identiques peuvent être modifiés par les utilisateurs d'application sur l'un ou l'autre système. OCI GoldenGate réplique les modifications des données transactionnelles d'une base de données à l'autre pour maintenir les deux ensembles de données à jour.

La section suivante décrit les étapes principales de la migration du cloud d'AWS vers OCI :
  1. Configurez OCI GoldenGate pour Oracle Cloud et démarrez les extractions à partir de la base de données sur la base de données AWS EC2.
  2. Effectuez une sauvegarde de la base de données AWS EC2 et importez la sauvegarde dans la base de données Oracle Autonomous Transactional Processing - Base de données partagée (ATP-S).
  3. Démarrez la réplication pour les modes unidirectionnel et bidirectionnel si nécessaire.
  4. Pour la mise en service, arrêtez le trafic d'application vers l'instance AWS EC2 et pointez-le vers la base de données OCI ATP-S.

Le diagramme suivant illustre la migration cloud d'AWS vers OCI.



aws-oci-cloud-migration-arch-oracle.zip

L'architecture comprend les composants suivants :

  • Oracle Autonomous Transaction Processing

    Oracle Autonomous Transaction Processing est un service de base de données auto-piloté, auto-sécurisé et auto-réparateur optimisé pour les charges de travail de traitement des transactions. Vous n'avez pas besoin de configurer ou de gérer du matériel ni d'installer un logiciel. Oracle Cloud Infrastructure gère la création de la base de données, ainsi que la sauvegarde, l'application de patches, la mise à niveau et le réglage de la base de données.

  • Oracle Cloud Infrastructure GoldenGate

    OCI GoldenGate est un service cloud natif entièrement géré qui déplace les données en temps réel et à grande échelle. OCI GoldenGate traite les données lors de leur déplacement à partir de systèmes de gestion des données vers des bases de données cible. OCI GoldenGate fournit une réplication de données bidirectionnelle et unidirectionnelle. Une réplication active-active est utilisée pour la migration haute disponibilité et sans temps d'arrêt.

  • Service Bastion

    Oracle Cloud Infrastructure Bastion fournit un accès sécurisé limité et limité dans le temps aux ressources qui ne disposent pas d'adresses publiques et qui nécessitent des contrôles d'accès stricts aux ressources, tels que Bare Metal et les machines virtuelles, Oracle MySQL Database Service, Autonomous Transaction Processing (ATP), Oracle Container Engine for Kubernetes (OKE) et toute autre ressource autorisant l'accès SSH (Secure Shell Protocol). Avec le service Oracle Cloud Infrastructure Bastion, vous pouvez activer l'accès aux hôtes privés sans déployer ni gérer d'hôte Jump. En outre, vous gagnez en sécurité grâce aux autorisations basées sur l'identité et à une session SSH centralisée, auditée et limitée dans le temps. Oracle Cloud Infrastructure Bastion élimine le besoin d'une adresse IP publique pour l'accès aux bastions, éliminant ainsi les tracas et la surface d'attaque potentielle lors de la fourniture d'un accès à distance.

  • FastConnect

    Oracle Cloud Infrastructure FastConnect permet de créer facilement une connexion privée dédiée entre votre centre de données et Oracle Cloud Infrastructure. FastConnect offre des options de bande passante plus élevée et une expérience réseau plus fiable par rapport aux connexions Internet.

  • Stockage d'objets

    Object Storage fournit un accès rapide à d'importantes 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 tel que des images et des vidéos. Vous pouvez stocker les données, puis les extraire directement à partir d'Internet ou de la plate-forme cloud, et ce, en toute sécurité. Vous pouvez mettre à l'échelle le stockage de manière transparente sans que les performances ou la fiabilité du service ne soient dégradées. Utilisez le stockage standard pour le stockage "à chaud" auquel vous devez accéder rapidement, immédiatement et fréquemment. Utilisez le stockage d'archives pour le stockage "à froid" que vous conservez pendant de longues périodes et auquel vous accédez rarement.

  • Dynamic routing gateway (DRG)

    Le DRG est un routeur virtuel qui fournit un chemin pour le trafic de réseau privé entre des réseaux cloud virtuels de la même région, entre un VCN et un réseau extérieur à la région, tel qu'un VCN dans une autre région Oracle Cloud Infrastructure, un réseau sur site ou un réseau d'un autre fournisseur cloud.

  • Composants Amazon Web Services (AWS)

    AWS Cloud héberge les bases de données Oracle AWS EC2 et RDS, ainsi que les applications PowerBuilder avec AWS Direct Connect. Pour plus d'informations, reportez-vous à la documentation AWS.

  • Composants de Google Cloud Platform (GCP)

    GCP héberge .NET, Go-Lang et d'autres applications open source qui se connectent à la base de données avec Google Interconnect. Pour plus d'informations, reportez-vous à la documentation GCP.

  • Région

    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 les unes des autres et de grandes distances peuvent les séparer (elles peuvent se trouver dans des pays voire des continents différents).

  • Domaines de disponibilité

    Les domaines de disponibilité sont des centres de données indépendants et autonomes 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 aux pannes. Les domaines de disponibilité ne partagent pas les mêmes infrastructures : réseau d'alimentation ou de refroidissement ou réseau interne. Ainsi, il est peu probable qu'un échec sur un domaine de disponibilité compromette les autres domaines de disponibilité de la région.

  • Réseau cloud virtuel (VCN) et sous-réseaux

    Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux de centres de données traditionnels, les réseaux cloud virtuels vous permettent de contrôler entièrement votre environnement réseau. Un VCN peut avoir plusieurs blocs CIDR qui ne se chevauchent pas que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, qui peuvent être ciblés sur une région ou sur 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é.

  • Liste de sécurité

    Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui indiquent la source, la destination et le type de trafic à autoriser vers et depuis le sous-réseau.

  • Table de routage

    Les tables de routage virtuelles contiennent des règles permettant d'acheminer le trafic de sous-réseaux vers des destinations situées en dehors d'un VCN, généralement via des passerelles.

  • Cloud Guard

    Vous pouvez utiliser Oracle Cloud Guard pour surveiller et maintenir la sécurité de vos ressources dans Oracle Cloud Infrastructure. Cloud Guard utilise des recettes de détecteur que vous pouvez définir pour examiner vos ressources afin de détecter les failles de sécurité et pour surveiller les opérateurs et les utilisateurs pour les activités à risque. Lorsqu'une erreur de configuration ou une activité non sécurisée est détectée, Cloud Guard recommande des actions correctives et les aide à effectuer ces actions, en fonction des recettes de répondeur que vous pouvez définir.

Recommandations

Utilisez les recommandations suivantes comme point de départ. Vos besoins peuvent différer de l'architecture décrite ici.
  • VCN

    Sélectionnez les blocs CIDR qui ne chevauchent aucun autre réseau (dans OCI ou un autre fournisseur cloud) sur lequel vous souhaitez configurer des connexions privées.

  • Choix de l'emplacement d'interconnexion

    Cette architecture requiert un ou plusieurs emplacements géographiques pour ses composants : la région OCI et le noeud de périphérie OCI FastConnect associé, la région AWS et le noeud de périphérie AWS Direct Connect associé, ainsi que la région GCP et le noeud de périphérie Google Interconnect associé. Pour optimiser la latence de bout en bout, nous vous recommandons de sélectionner un métro qui dispose de chacun de ces éléments architecturaux à proximité.

Remarques

Lorsque vous implémentez un déploiement split-stack, tenez compte des options suivantes.

  • Performances
    Testez et réglez les requêtes d'application dans ATP-S pour éviter toute modification des plans de requête en raison de l'introduction du stockage Exadata.
    • Pour le cas d'emploi client dans cette architecture de référence, les performances des requêtes d'application globales ont été améliorées par un facteur 5-20x.
    La latence du réseau est la clé de la performance. Vérifiez et mesurez la latence du réseau dans le cadre du test des performances des applications.
    • La latence réseau entre les applications et la base de données hébergée dans différents centres de données cloud doit être inférieure à 10 ms. Pour obtenir des performances de bout en bout optimales, nous vous recommandons de sélectionner un métro qui dispose de centres de données cloud de bases de données et d'applications à proximité immédiate.
    • Pour le cas d'emploi client dans cette architecture de référence, la latence réseau induite pour le déploiement multicloud était comprise entre 2 et 4 ms dans OCI US-East.
  • Coût

    Le redimensionnement automatique d'Oracle CPU (OCPU) dans Oracle Autonomous Transaction Processing permet de gérer les pics de charge de travail lorsque cela est nécessaire et réduit également considérablement les coûts de licence. Les autres facteurs de sauvegarde et d'automatisation au sein d'Oracle Autonomous Transaction Processing permettent aux administrateurs de base de données de se concentrer sur les problèmes réels.

  • Sécurité

    L'interconnexion multicloud illustrée dans cette architecture est basée sur une connexion privée, qui est plus sécurisée que l'Internet public.

Accusés de réception

  • Author: Vinit Menon
  • Contributors: Raghavendra S, Wei Han