Implante uma solução de pilha dividida multicloud em OCI, AWS e GCP

Implemente uma arquitetura de pilha dividida multicloud de alto desempenho usando o Oracle Autonomous Database, para aplicativos hospedados em provedores de nuvem pública, com alterações mínimas na arquitetura e na plataforma de tecnologia existentes.

Observação:

Com uma solução multinuvem, a rede é um determinante fundamental do desempenho geral do sistema. É responsabilidade do cliente garantir que a rede Cloud-to-Cloud (largura de banda e latência) seja totalmente testada para garantir que o desempenho do aplicativo atenda aos requisitos de negócios definidos.

Esta arquitetura de referência descreve uma solução de pilha dividida multicloud inspirada no cliente. Com a base de assinantes de aplicativos de 2 milhões de usuários e expansão rápida, o cliente estava procurando opções para migrar sem tempo de inatividade para um ambiente que possa ajudá-los a dimensionar sob demanda. Eles queriam flexibilidade para atender à demanda e também economizar custos, em comparação com a implantação existente.

Os requisitos do cliente foram atendidos com uma solução de pilha dividida multicloud:
  • Migrar o banco de dados para o Oracle Autonomous Database que fornece os benefícios de tempo de atividade, desempenho, escalabilidade, segurança e produtividade máximos do banco de dados.
  • Manter a pilha de aplicativos no Amazon Web Services (AWS) e no Google Cloud Platform (GCP) respectivamente para minimizar a mudança de integrações com outros aplicativos.
  • Usando o Oracle Cloud Infrastructure (OCI) GoldenGate para migrar do banco de dados no AWS EC2 para o Oracle Autonomous Database com tempo de indisponibilidade zero.

Arquitetura

Nesta arquitetura de referência, o banco de dados de produção é implantado no OCI US-East (Ashburn) e os aplicativos são implantados no AWS US-East (N.Virginia) e GCP US-East (Ashburn). A conectividade dedicada utilizando o OCI FastConnect foi essencial. A Equinix, parceira da OCI FastConnect, foi envolvida na conexão cruzada de cargas de trabalho da OCI com AWS e GCP na mesma região.

Neste exemplo, o cliente usou o Equinix Fabric para conectar o OCI FastConnect ao AWS Direct Connect e ao Google Interconnect diretamente. Latência de rede testada em 2-4 ms entre OCI e AWS e entre OCI e GCP em Ashburn.

Uma conexão multicloud semelhante pode ser configurada por qualquer provedor OCI FastConnect que atenda à localização do data center, como Megaport, AT&T, Lumen, NTT, Verizon ou qualquer base de atendimento com um provedor de intercâmbio de telecomunicações.

Esta solução é aplicável a um cenário de nuvem híbrida em que o data center do cliente está co-localizado no data center do OCI ou dentro de 30 a 40 milhas das proximidades.

Arquitetura de pilha dividida multicloud

O banco de dados de Produção é implantado no OCI no Autonomous Database para processamento transacional. A replicação do OCI GoldenGate é preparada em uma sub-rede separada para ser usada sob demanda entre sites. A TI do cliente acessa os recursos do OCI por meio do Serviço Bastion por meio da VPN privada ou FastConnect para o OCI.

A AWS hospeda os bancos de dados AWS EC2, RDS da Oracle e os Aplicativos PowerBuilder que se conectam ao banco de dados com o AWS DirectConnect por meio do parceiro OCI Fastconnect para a OCI.

O GCP hospeda o . NET, Go-Lang e outros aplicativos de código aberto que se conectam ao banco de dados com o Google Interconnect por meio do parceiro OCI Fastconnect para OCI.

A Recuperação de Desastres (DR) é implementada usando o Autonomous Data Guard para sincronizar o banco de dados em outra região em que vários provedores de nuvem têm data centers localizados próximos, como OCI US-West (San Jose) e AWS US-West (N. Califórnia). Para a implementação de DR, você pode hospedar os bancos de dados AWS EC2, RDS Oracle e PowerBuilder Apps no AWS e conectar-se ao banco de dados com o AWS DirectConnect por meio do parceiro OCI FastConnect para OCI.

O diagrama de topologia de arquitetura a seguir ilustra a arquitetura multicloud:



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

Migração para a nuvem do AWS para o OCI

A migração com tempo de inatividade zero é obtida com a replicação bidirecional GoldenGate do OCI. O OCI GoldenGate permite a configuração do banco de dados ativo-ativo, em que há dois sistemas com conjuntos de dados idênticos que podem ser alterados pelos usuários do aplicativo em qualquer sistema. O OCI GoldenGate replica alterações de dados transacionais de um banco de dados para o outro a fim de manter os dois conjuntos de dados atualizados.

A seção a seguir descreve as etapas de alto nível da migração para a nuvem do AWS para o OCI:
  1. Configure o OCI GoldenGate para Oracle Cloud e inicie as extrações do banco de dados no banco de dados AWS EC2.
  2. Faça um backup do banco de dados AWS EC2 e importe o backup para o Oracle Autonomous Transactional Processing Database - Shared Database (ATP-S).
  3. Inicie a replicação unidirecional e bidirecional conforme necessário.
  4. Para Go-live, interrompa o tráfego de aplicativos para a instância do AWS EC2 e aponte-a para o banco de dados OCI ATP-S.

O diagrama a seguir ilustra a migração da nuvem do AWS para o OCI.



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

A arquitetura tem os seguintes componentes:

  • Oracle Autonomous Transaction Processing

    O Oracle Autonomous Transaction Processing é um banco de dados independente, com segurança automática e auto-reparável, otimizado para cargas de trabalho de processamento de transações. Não é necessária a configuração ou o gerenciamento de qualquer hardware ou a instalação de qualquer software. O Oracle Cloud Infrastructure controla a criação do banco de dados, bem como o backup, a aplicação de patches, o upgrade e o ajuste do banco de dados.

  • Oracle Cloud Infrastructure GoldenGate

    O OCI GoldenGate é um serviço de nuvem totalmente gerenciado e nativo que move dados em tempo real em escala. O OCI GoldenGate processa dados à medida que eles mudam de um ou mais sistemas de gerenciamento de dados para bancos de dados de destino. O OCI GoldenGate fornece replicação de dados bidirecional e unidirecional. Uma replicação ativa-ativa é usada para alta disponibilidade e migração com tempo de inatividade zero.

  • Serviço Bastion

    O Oracle Cloud Infrastructure Bastion fornece acesso seguro restrito e por tempo limitado a recursos que não têm pontos finais públicos e que exigem controles rigorosos de acesso a recursos, como bare metal e máquinas virtuais, Oracle MySQL Database Service, Autonomous Transaction Processing (ATP), Oracle Container Engine for Kubernetes (OKE) e qualquer outro recurso que permita acesso SSH (Secure Shell Protocol). Com o serviço Bastion do Oracle Cloud Infrastructure, você pode ativar o acesso a hosts privados sem implantar e manter um jump host. Além disso, você obtém uma postura de segurança melhorada com permissões baseadas em identidade e uma sessão SSH centralizada, auditada e limitada a tempo. O Oracle Cloud Infrastructure Bastion elimina a necessidade de um IP público para acesso ao bastion, eliminando a confusão e a superfície de ataque potencial ao fornecer acesso remoto.

  • FastConnect

    O Oracle Cloud Infrastructure FastConnect fornece uma maneira fácil de criar uma conexão privada dedicada entre o data center e o Oracle Cloud Infrastructure. FastConnect fornece opções de maior largura de banda e uma experiência de rede mais confiável quando comparada com conexões baseadas na internet.

  • Object Storage

    O armazenamento de objetos fornece acesso rápido a grandes quantidades de dados estruturados e não estruturados de qualquer tipo de conteúdo, incluindo backups de bancos de dados, dados de análise e conteúdo avançado, como imagens e vídeos. Você pode armazenar de forma segura e depois recuperar dados diretamente da internet ou de dentro da plataforma da nuvem. Você pode dimensionar o armazenamento de forma integrada sem experimentar qualquer degradação no desempenho ou na confiabilidade do serviço. Use o armazenamento padrão para armazenamento de acesso frequente que você precisa para acessar de forma rápida, imediata e frequente. Use o armazenamento de arquivos compactados para armazenamento " frio" que você mantém por longos períodos de tempo e raramente acessa.

  • Gateway de roteamento dinâmico (DRG)

    O DRG é um roteador virtual que fornece um caminho para tráfego de rede privada entre VCNs na mesma região, entre uma VCN e uma rede fora da região, como uma VCN em outra região do Oracle Cloud Infrastructure, uma rede local ou uma rede em outro provedor de nuvem.

  • Componentes do Amazon Web Services (AWS)

    O AWS Cloud hospeda os bancos de dados AWS EC2 e RDS da Oracle, juntamente com os Aplicativos PowerBuilder com o AWS Direct Connect. Para obter mais informações, consulte a documentação da AWS.

  • Componentes do Google Cloud Platform (GCP)

    O GCP hospeda o . NET, Go-Lang e outros aplicativos de código aberto que se conectam ao banco de dados com o Google Interconnect. Para obter mais informações, consulte a documentação do GCP.

  • Região

    Uma região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominados domínios de disponibilidade. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).

  • Domínios de disponibilidade

    Os domínios de disponibilidade são data centers independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos dos outros domínios de disponibilidade, que fornecem tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia ou refrigeração, ou a rede interna do domínio de disponibilidade. Portanto, uma falha em um domínio de disponibilidade provavelmente não afetará os outros domínios de disponibilidade na região.

  • Rede virtual na nuvem (VCN) e sub-redes

    Uma VCN é uma rede personalizada e definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes de data center tradicionais, as VCNs dão a você controle total sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após criar a VCN. Você pode segmentar uma VCN em sub-redes, que podem ter escopo em uma região ou em um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobreem com as outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.

  • Lista de segurança

    Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego que deve ser permitido dentro e fora da sub-rede.

  • Tabela de roteamento

    As tabelas de roteamento virtual contêm regras para rotear o tráfego de sub-redes para destinos fora de uma VCN, geralmente por meio de gateways.

  • Cloud Guard

    Você pode usar o Oracle Cloud Guard para monitorar e manter a segurança dos seus recursos no Oracle Cloud Infrastructure. O Cloud Guard usa receitas do detector que você pode definir para examinar seus recursos em busca de pontos fracos de segurança e para monitorar operadores e usuários em busca de atividades arriscadas. Quando qualquer configuração incorreta ou atividade insegura é detectada, o Cloud Guard recomenda ações corretivas e ajuda a executar essas ações, com base nas receitas do respondedor que você pode definir.

Recomendações

Use as recomendações a seguir como ponto de partida. Seus requisitos podem ser diferentes da arquitetura descrita aqui.
  • VCN

    Selecione blocos CIDR que não se sobreponham a nenhuma outra rede (no OCI ou em outro provedor de nuvem) para a qual você pretende configurar conexões privadas.

  • Escolha da localização da interconexão

    Essa arquitetura requer uma ou mais localizações geográficas para seus componentes: a região OCI e o nó de borda FastConnect do OCI associado, a região AWS e o nó de borda AWS Direct Connect associado, e a região GCP e o nó de borda Google Interconnect associado. Para obter a latência de ponta a ponta ideal, recomendamos que você selecione um metrô que tenha cada um desses elementos arquitetônicos próximos.

Considerações

Ao implementar uma implantação de pilha dividida, considere essas opções.

  • Desempenho
    Teste e ajuste consultas de aplicativos no ATP-S para evitar qualquer alteração nos planos de consulta devido à introdução do armazenamento do Exadata.
    • Para o caso de uso do cliente nessa arquitetura de referência, o desempenho das consultas gerais do aplicativo melhorou em um fator de 5-20x.
    A latência de rede é a chave para o desempenho. Verifique e avalie a latência da rede como parte do teste de desempenho do aplicativo.
    • A latência de rede entre aplicativos e banco de dados hospedados em diferentes data centers na nuvem deve ser inferior a 10 ms. Para obter o desempenho ideal de ponta a ponta, recomendamos que você selecione um metrô que tenha os data centers de nuvem de aplicativos e banco de dados próximos.
    • Para o caso de uso do cliente nesta arquitetura de referência, a latência de rede induzida para a implantação multicloud estava entre 2-4 ms no OCI US-East.
  • Custo

    O Dimensionamento Automático do Oracle CPU (OCPU) no Oracle Autonomous Transaction Processing permite tratar cargas de trabalho de pico quando necessário e também reduz os custos de licença em grande medida como resultado. Os outros fatores de backup e automação no Oracle Autonomous Transaction Processing são úteis para que os DBAs se concentrem em problemas reais.

  • Segurança

    A interconexão multicloud mostrada nesta arquitetura é baseada em uma conexão privada, que é mais segura do que a internet pública.

Confirmações

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