1. Executar Recuperação de Desastre entre Regiões para o Banco de Dados Exadata no Oracle Database@Azure
  2. Execute a recuperação de desastres entre regiões para o Oracle Exadata Database Service no Oracle Database@Azure

Execute a recuperação de desastres entre regiões para o Oracle Exadata Database Service no Oracle Database@Azure

Ao projetar aplicativos, é essencial garantir a continuidade dos negócios, estabelecendo um mecanismo robusto de recuperação de desastres para restaurar operações em caso de interrupção.

Por muitos anos, os clientes confiam no Oracle Exadata Database Service usando a Oracle Maximum Availability Architecture (MAA) para potencializar aplicativos de missão crítica tanto no local quanto na Oracle Cloud Infrastructure (OCI). O Oracle Exadata Database Service no Oracle Database@Azure oferece paridade de recursos e preços com o Exadata na OCI e pode ser implantado em várias zonas de disponibilidade (AZs) e regiões do Microsoft Azure para garantir alta disponibilidade e recuperação de desastres.

Arquitetura

Essa arquitetura mostra um aplicativo AKS (Azure Kubernetes Service) em contêiner de alta disponibilidade com o Oracle Exadata Database Service no Oracle Database@Azure em uma topologia de recuperação de desastres entre regiões.

Um aplicativo AKS (Azure Kubernetes Service) em contêineres de alta disponibilidade é implantado em duas regiões do Azure: uma região principal e uma região stand-by. As imagens de contêiner são armazenadas no registro de contêiner do Azure e são replicadas entre as regiões principal e stand-by. Os usuários acessam o aplicativo externamente por meio de um balanceador de carga público.

Para proteção de dados, o Oracle Database está sendo executado em um cluster de máquina virtual (VM) Exadata na região principal, com o Oracle Data Guard ou o Oracle Active Data Guard replicando os dados para o banco de dados stand-by em execução em um cluster de VMs do Exadata na região stand-by.

As chaves de criptografia de dados transparente (TDE) do banco de dados são armazenadas no Oracle Cloud Infrastructure Vault e replicadas entre as regiões do Azure e do OCI. Os backups automáticos estão no OCI para as regiões principal e stand-by. Os clientes podem usar o Oracle Cloud Infrastructure Object Storage ou o Oracle Database Autonomous Recovery Service como a solução de armazenamento preferencial.

A rede Oracle Exadata Database Service no Oracle Database@Azure é conectada à sub-rede do cliente Exadata usando um gateway de roteamento dinâmico (DRG) gerenciado pela Oracle. Um DRG também é necessário para criar uma conexão de mesmo nível entre VCNs em diferentes regiões. Como apenas um DRG é permitido por VCN no OCI, uma segunda VCN com seu próprio DRG é necessária para conectar as VCNs principal e stand-by em cada região. Neste exemplo:

  • O cluster de VMs principal do Exadata é implantado na sub-rede do cliente da VCN Principal (10.5.0.0/24).
  • The Hub VCN Primary VCN for the transit network is 10.15.0.0/29.
  • O cluster de VMs stand-by do Exadata é implantado na sub-rede do cliente da VCN Stand-by da VCN (10.6.0.0/24).
  • A VCN Stand-by da VCN do Hub para a rede de trânsito é 10.16.0.0/29.

Nenhuma sub-rede é necessária para que as VCNs do Hub ativem o roteamento de trânsito. Portanto, essas VCNs podem usar uma rede muito pequena. As VCNs no site filho do OCI são criadas após a criação dos clusters de VMs do Oracle Exadata Database Service no Oracle Database@Azure para os bancos de dados principal e stand-by.

O diagrama a seguir mostra a arquitetura:


Descrição de exadb-dr-db-azure.png a seguir
Descrição da ilustração exadb-dr-db-azure.png

exadb-dr-db-azure-oracle.zip

O Microsoft Azure fornece os seguintes componentes:

  • Região do Microsoft Azure

    Uma região do Azure é uma área geográfica na qual um ou mais data centers físicos do Azure, chamados de zonas de disponibilidade, residem. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).

    As regiões do Azure e da OCI são áreas geográficas localizadas. Para o Oracle Database@Azure, uma região do Azure é conectada a uma região do OCI, com zonas de disponibilidade (AZs) no Azure conectadas a domínios de disponibilidade (ADs) no OCI. Os pares de regiões do Azure e do OCI são selecionados para minimizar a distância e a latência.

  • Zona de disponibilidade do Microsoft Azure

    Uma zona de disponibilidade é um data center separado fisicamente em uma região projetado para ser altamente disponível e tolerante a falhas. As zonas de disponibilidade estão próximas o suficiente para ter conexões de baixa latência com outras zonas de disponibilidade.

  • Rede Virtual do Microsoft Azure

    A Rede Virtual do Microsoft Azure (VNet) é o bloco de construção fundamental para uma rede privada no Azure. O VNet permite que muitos tipos de recursos do Azure, como máquinas virtuais (VM) do Azure, se comuniquem com segurança entre si, com a internet e com redes locais.

  • Sub-rede Delegada do Microsoft Azure

    A delegação de sub-rede permite que você injete um serviço gerenciado, especificamente um serviço de plataforma como serviço (PaaS), diretamente na sua rede virtual. Uma sub-rede delegada pode ser um home para um serviço gerenciado externamente dentro da sua rede virtual para que o serviço externo atue como um recurso de rede virtual, mesmo que seja um serviço PaaS externo.

  • VNIC do Microsoft Azure

    Os serviços nos data centers do Azure têm NICs (network interface cards) físicas. As instâncias de máquina virtual se comunicam usando NICs virtuais (VNICs) associadas às NICs físicas. Cada instância tem uma VNIC principal que é criada e anexada automaticamente durante a inicialização e está disponível durante o ciclo de vida da instância.

  • Tabela de Roteamento do Microsoft Azure

    As tabelas de roteamento virtual contêm regras para rotear o tráfego de sub-redes para destinos fora de um VNet, geralmente por meio de gateways. As tabelas de roteamento são associadas a sub-redes em um VNet.

  • Gateway de Rede Virtual do Azure

    O serviço de Gateway de Rede Virtual do Azure estabelece conectividade segura entre locais entre uma rede virtual do Azure e uma rede local. Ele permite que você crie uma rede híbrida que abrange seu data center e o Azure.

O Oracle Cloud Infrastructure fornece os seguintes componentes:

  • Região

    Região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominada 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ínio de disponibilidade

    Domínios de disponibilidade são data centers stand-alone e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, o que oferece 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 não deve afetar os outros domínios de disponibilidade na região.

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

    Uma VCN é uma rede personalizável definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs oferecem controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após a criação da VCN. Você pode segmentar uma VCN em sub-redes, com escopo definido para uma região ou para um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobrepõem a 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.

  • 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.

  • 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.

  • Gateway de roteamento dinâmico (DRG)

    O DRG é um roteador virtual que fornece um caminho para o 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.

  • Gateway de serviço

    O gateway de serviço fornece acesso de uma VCN a outros serviços, como o Oracle Cloud Infrastructure Object Storage. O tráfego da VCN para o serviço Oracle percorre a malha da rede Oracle e não passa pela internet.

  • LPG (Local peering gateway)

    Um LPG permite parear uma VCN com outra VCN na mesma região. Pareamento significa que as VCNs se comunicam usando endereços IP privados, sem o tráfego que passa pela internet ou que é roteado pela sua rede local.

  • Grupo de segurança de rede (NSG)

    O grupo de segurança de rede (NSG) atua como um firewall virtual para seus recursos de nuvem. Com o modelo de segurança de confiança zero do Oracle Cloud Infrastructure, todo tráfego é negado, e você pode controlar o tráfego de rede dentro de uma VCN. Um NSG consiste em um conjunto de regras de segurança de entrada e saída que se aplicam somente a um conjunto especificado de VNICs em uma única VCN.

  • 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 sem prejudicar o desempenho ou a confiabilidade do serviço. Use o armazenamento padrão para armazenamento "quente" que você precisa para acessar de forma rápida, imediata e com frequência. Use o armazenamento de arquivos compactados para armazenamento "frio" que você mantém por longos períodos de tempo e raramente acessa.

  • Data Guard

    O Oracle Data Guard e o Oracle Active Data Guard fornecem um conjunto abrangente de serviços que criam, mantêm, gerenciam e monitoram um ou mais bancos de dados stand-by e permitem que os bancos de dados Oracle de produção permaneçam disponíveis sem interrupção. O Oracle Data Guard mantém esses bancos de dados stand-by como cópias do banco de dados de produção usando replicação na memória. Se o banco de dados de produção ficar indisponível devido a uma interrupção planejada ou não planejada, o Oracle Data Guard poderá alternar qualquer banco de dados stand-by para a atribuição de produção, minimizando o tempo de inatividade associado à interrupção. O Oracle Active Data Guard fornece a capacidade adicional de descarregar cargas de trabalho de leitura principalmente em bancos de dados stand-by e também fornece recursos avançados de proteção de dados.

  • Oracle Database Autonomous Recovery Service

    O Oracle Database Autonomous Recovery Service permite fazer um snapshot pontual dos dados em volumes em blocos, volumes de inicialização e em Oracle Databases. Com a automação de backup e recursos aprimorados de proteção de dados para bancos de dados OCI, você pode transferir todos os requisitos de processamento e armazenamento de backup para o Oracle Database Autonomous Recovery Service, eliminando assim os custos de infraestrutura de backup e a sobrecarga de administração manual.

  • Exadata Database - Serviço

    O Oracle Exadata é uma plataforma de banco de dados empresarial que executa cargas de trabalho do Oracle Database de qualquer escala e criticidade com alto desempenho, disponibilidade e segurança. O design de expansão do Exadata emprega otimizações exclusivas que permitem que o processamento de transações, análises, machine learning e cargas de trabalho mistas sejam executados com mais rapidez e eficiência. A consolidação de diversas cargas de trabalho do Oracle Database em plataformas Exadata em data centers empresariais, na Oracle Cloud Infrastructure (OCI) e em ambientes multicloud ajuda as organizações a aumentar a eficiência operacional, reduzir a administração de TI e reduzir custos.

    O Oracle Exadata Database Service permite que você utilize o poder do Exadata na nuvem. O Oracle Exadata Database Service oferece recursos comprovados do Oracle Database em uma infraestrutura do Oracle Exadata otimizada e criada especificamente na nuvem pública e no Cloud@Customer. A automação da nuvem integrada, o dimensionamento elástico de recursos, a segurança e o desempenho rápido para todas as cargas de trabalho do Oracle Database ajudam a simplificar o gerenciamento e reduzir custos.

  • Oracle Database@Azure

    O Oracle Database@Azure integra tecnologias da Oracle, como Oracle Exadata Database Service, Oracle Autonomous Database Serverless, Oracle Real Application Clusters (Oracle RAC) e Oracle Data Guard na plataforma Microsoft Azure.

    O Oracle Database@Azure é o serviço do Oracle Database em execução no Oracle Cloud Infrastructure (OCI) e é colocado novamente nos data centers do Microsoft Azure. O serviço oferece paridade de recursos e preços com a OCI. Você pode comprar o serviço no Azure Marketplace. O Oracle Database@Azure oferece a mesma baixa latência que outros serviços nativos do Azure e atende aos requisitos essenciais de carga de trabalho e desenvolvimento nativo da nuvem. Você pode gerenciar o serviço na console do Azure e com ferramentas de automação do Azure. O serviço é implantado na Rede Virtual do Azure (VNet) e é integrado ao sistema de gerenciamento de identidade e acesso do Azure. As métricas e os logs de auditoria do OCI e do Oracle Database estão disponíveis nativamente no Azure. O serviço requer que os usuários tenham uma tenancy do Azure e uma tenancy do OCI.

Recomendações

Use as recomendações a seguir como ponto de partida ao executar a recuperação de desastre entre regiões para o Oracle Exadata Database Service no Oracle Database@Azure. Seus requisitos podem ser diferentes da arquitetura descrita aqui.
  • Implante a infraestrutura necessária do Exadata nas regiões principal e stand-by. Para cada instância do Exadata, implante um cluster de VMs do Exadata na sub-rede delegada de uma rede virtual do Microsoft Azure (VNet). O banco de dados do Oracle Real Application Clusters (RAC) pode então ser instanciado no cluster. No mesmo VNet, implante o Azure Kubernetes Service (AKS) em uma sub-rede separada. Configure o Oracle Data Guard para replicar dados de um Oracle Database para o outro, entre regiões.
  • Quando os clusters de VMs do Exadata são criados no site filho do Oracle Database@Azure, cada um é criado em sua própria rede virtual na nuvem (VCN) do Oracle Cloud Infrastructure. O Oracle Data Guard requer que os bancos de dados se comuniquem entre si para enviar dados de redo. As VCNs devem ser pareadas para permitir essa comunicação.

Considerações

Ao executar a recuperação de desastre entre regiões para o Oracle Exadata Database Service no Oracle Database@Azure, considere o seguinte.

  • A preparação para um cenário de desastre requer uma abordagem abrangente que considere diferentes requisitos de negócios e arquiteturas de disponibilidade e que englobe essas considerações em um plano acionável de alta disponibilidade (HA), recuperação de desastres (DR). O cenário descrito aqui fornece diretrizes para ajudar a selecionar a abordagem que melhor se adapta à implantação do seu aplicativo usando um failover simples, mas eficaz, para a configuração de recuperação de desastres em seus ambientes Oracle Cloud Infrastructure (OCI) e Microsoft Azure.
  • Use o Oracle Data Guard entre regiões para os bancos de dados provisionados no Cluster de VMs do Exadata no Oracle Database@Azure usando uma rede gerenciada pelo OCI.
  • O Oracle Cloud Infrastructure é a rede preferida para obter melhor desempenho, medido por latência e taxa de transferência, e para obter custo reduzido, pois os primeiros 10 TB/Mês são gratuitos.

Implante

Para configurar a comunicação de rede entre as regiões mostradas no diagrama de arquitetura acima, execute as etapas de alto nível a seguir.

Região Principal

  1. Crie uma rede virtual na nuvem (VCN), VCN HUB Principal, na região principal do Oracle Cloud Infrastructure (OCI).
  2. Implante dois LPGs (Local Peering Gateways), Primary-LPG e HUB-Primary-LPG, em VCN Principal e HUB VCN Principal, respectivamente.
  3. Estabeleça uma conexão LPG de mesmo nível entre os LPGs para VCN HUB Principal e VCN Principal.
  4. Na VCN Principal da VCN, atualize a tabela de roteamento padrão para rotear o tráfego do endereço IP associado à sub-rede do cliente Stand-by da VCN para usar o pareamento de LPG. Por exemplo: 
    10.6.0.0/24 to Primary-LPG

    Observação:

    Para atualizar a tabela de roteamento padrão, no momento você deve criar um ticket de suporte com o título Permissão Necessária de Atualização da Tabela de Roteamento da VCN e fornecer a região, o OCID da tenancy, o OCID da VCN e o OCID do DRG de Serviço.
  5. Crie um gateway de roteamento dinâmico (DRG), DRG Principal na VCN Principal da VCN do Hub.
  6. Na VCN HUB VCN Principal, crie a tabela de roteamento primary_hub_transit_drg e designe o destino da sub-rede do cliente VCN Principal, um tipo de destino LPG e o HUB-Primary-LPG de destino. Por exemplo: 
    10.5.0.0/24 target type: LPG, Target: Hub-Primary-LPG
  7. Na VCN HUB VCN Principal, crie uma segunda tabela de roteamento, primary_hub_transit_lpg, e designe o destino da sub-rede do cliente VCN Principal, um DRG do tipo de destino e um DRG Principal de destino. Por exemplo: 
    10.6.0.0/24 target type: DRG, Target: Primary-DRG
  8. Anexe a VCN Principal da VCN do Hub ao DRG. Edite os anexos da VCN do DRG e, em opções avançadas, edite a tabela de roteamento da VCN da guia para associá-la à tabela de roteamento primary_hub_transit_drg. Essa configuração permite o roteamento de trânsito.
  9. Associe a tabela de roteamento primary_hub_transit_lpg ao gateway Hub-Primary-LPG.
  10. Na tabela de roteamento padrão VCN Principal do Hub, adicione uma regra de roteamento para a faixa de Endereços IP de sub-rede do cliente VCN Principal para usar o LPG. Adicione outra regra de roteamento para a faixa de Endereços IP de sub-rede do cliente Stand-by da VCN para usar o DRG. Por exemplo:
    10.5.0.0/24 LPG Hub-Primary-LPG
10.6.0.0/24 DRG Primary-DRG
  11. Para DRG Principal, selecione a tabela de roteamento do DRG, a Tabela de Roteamento do DRG Gerada Automaticamente para anexos RPC, VC e IPSec. Adicione uma rota estática à faixa de Endereços IP do cliente de sub-rede VCN Principal que use a VCN Principal da VCN do Hub com um tipo de anexo de próximo salto de VCN e o nome do anexo de próximo salto de Anexo do Hub Principal. Por exemplo: 
    10.5.0.0/24 VCN Primary Hub attachment
  12. Use o menu de anexos de conexão de pareamento remoto do DRG Principal para criar uma conexão de pareamento remoto, o RPC.
  13. Na sub-rede do cliente VCN Principal, atualize o grupo de segurança de rede (NSG) para criar uma regra de segurança que permita entrada para a porta TCP 1521. Opcionalmente, você pode adicionar a porta SSH 22 para acesso SSH direto aos servidores de banco de dados.

    Observação:

    Para obter uma configuração mais precisa, desative a distribuição de rota de importação da tabela de roteamento Tabela de Roteamento do DRG Gerada Automaticamente para anexos RPC, VC e IPSec. Para Tabela de Roteamento do DRG Gerada Automaticamente para anexos de VCN, crie e designe uma nova distribuição de rota de importação, incluindo apenas o anexo RPC necessário.

Região Stand-by

  1. Crie a VCN, Stand-by da VCN HUB, na região stand-by do OCI.
  2. Implante dois LPGs, LPG Stand-by e LPG Stand-by do HUB, nas VCNs Stand-by da VCN e Stand-by da VCN do HUB, respectivamente.
  3. Estabeleça uma conexão LPG de mesmo nível entre LPGs para Stand-by da VCN e Stand-by da VCN HUB.
  4. Na VCN Stand-by da VCN, atualize a tabela de roteamento padrão para rotear o tráfego do endereço IP associado à sub-rede do cliente Principal da VCN para usar o pareamento de LPG. Por exemplo: 
    10.5.0.0/24 to Standby-LPG

    Observação:

    Para atualizar a tabela de roteamento padrão, no momento você deve criar um ticket de suporte com o título Permissão Necessária de Atualização da Tabela de Roteamento da VCN e fornecer a região, o OCID da tenancy, o OCID da VCN e o OCID do DRG de Serviço.
  5. Crie um DRG, DRG Stand-by na VCN Stand-by da VCN do Hub.
  6. Na VCN Stand-by da VCN HUB, crie uma tabela de roteamento standby_hub_transit_lpg e designe o destino da sub-rede do cliente Stand-by da VCN, um tipo de destino de LPG e um LPG de Stand-by do HUB de destino. Por exemplo: 
    10.6.0.0/24 target type: LPG, Target: Hub-Standby-LPG
  7. Na VCN Stand-by da VCN HUB, crie uma segunda tabela de roteamento standby_hub_transit_drg e designe o destino da sub-rede do cliente Stand-by da VCN, um DRG do tipo de destino e um DRG Stand-by de destino. Por exemplo: 
    10.5.0.0/24 target type: DRG, Target: Standby-DRG
  8. Anexe a VCN Stand-by da VCN do Hub ao DRG. Edite os anexos da VCN do DRG e, em opções avançadas, edite a tabela de roteamento da VCN para associá-la à tabela de roteamento standby_hub_transit_drg. Essa configuração permite o roteamento de trânsito.
  9. Na tabela de roteamento padrão Stand-by da VCN do Hub, adicione regras de roteamento para a faixa de Endereços IP de sub-rede do cliente Stand-by da VCN para usar o LPG e para a faixa de Endereços IP de sub-rede do cliente Principal da VCN para usar o DRG. Por exemplo: 
    10.6.0.0/24 LPG Hub-Standby-LPG
10.5.0.0/24 DRG Standby-DRG
  10. Associe a tabela de roteamento, standby_hub_transit_lpg, ao gateway Hub-Standby-LPG.
  11. Para DRG Stand-by, selecione a tabela de roteamento do DRG Tabela de Roteamento do Drg Gerada Automaticamente para anexos RPC, VC e IPSec. Adicione uma rota estática à faixa de Endereços IP do cliente de sub-rede Stand-by da VCN que use a VCN Stand-by da VCN do Hub com um tipo de anexo de próximo salto de VCN e o nome do anexo de próximo salto Anexo do Hub Stand-by. Por exemplo: 
    10.6.0.0/24 VCN Standby Hub attachment
  12. Use o menu de anexos de conexão de pareamento remoto Standby-DRG para criar uma conexão de pareamento remoto, RPC.
  13. Selecione a conexão de pareamento remoto, selecione Estabelecer Conexão e forneça o OCID do DRG Principal. O status de pareamento torna-se pareado. Ambas as regiões estão conectadas.
  14. Na sub-rede do cliente Stand-by da VCN, atualize o NSG para criar uma regra de segurança que permita entrada para a porta TCP 1521. Opcionalmente, você pode adicionar a porta SSH 22 para acesso SSH direto aos servidores de banco de dados.

Associação do Data Guard

  1. Para ativar o Oracle Data Guard ou o Oracle Active Data Guard para o Oracle Database, na página de detalhes do Oracle Database, clique em Associações do Data Guard e, em seguida, clique em Ativar Data Guard.
  2. Na página Ativar Data Guard:
    1. Selecione a região stand-by.
    2. Selecione o domínio de disponibilidade stand-by mapeado para o Azure AZ.
    3. Selecione o Exadata Infrastructure stand-by.
    4. Selecione o cluster de VMs stand-by desejado.
    5. Escolha Oracle Data Guard ou Oracle Active Data Guard. O MAA recomenda o Oracle Active Data Guard para reparo automático de blocos de corrupções de dados e a capacidade de descarregar relatórios.
    6. Para associações do Oracle Data Guard entre regiões, só há suporte para o modo de proteção máxima do desempenho.
    7. Selecione um home de banco de dados existente ou crie um. É recomendável usar a mesma imagem de software de banco de dados do banco de dados principal para o home do banco de dados stand-by, para que ambos tenham os mesmos patches disponíveis.
    8. Informe a senha do usuário SYS e ative o Oracle Data Guard.

    Depois que o Oracle Data Guard for ativado, o banco de dados stand-by será listado na seção Associações do Data Guard.

  3. (Opcional) Ative o failover automático (Failover de Inicialização Rápida) para reduzir o tempo de recuperação em caso de falhas instalando o Data Guard Observer em uma VM separada, de preferência em um local separado ou na rede do aplicativo.

Explorar Mais

Saiba mais sobre as características desta arquitetura e sobre arquiteturas relacionadas.

Reconhecimentos

  • Autores: Ricardo Anda, Srikanth Bolisetty, Julien Silverston, Andy Steinorth
  • Colaboradores: Tammy Bednar, Wei Han, Glen Hawkins, Gavin Parish, Sinan Petrus Toma, Lawrence To, Thomas Van Buggenhout, Robert Lies