Implementar Replicação de Camada Intermediária em uma Arquitetura de Recuperação de Desastres do OCI

Implemente a replicação contínua para sua camada de middleware em um sistema de DR (recuperação de desastres) simétrico na Oracle Cloud Infrastructure (OCI), replicando os servidores de aplicativos e suas configurações entre as regiões principal e secundária, garantindo o mínimo de tempo de inatividade e perda de dados durante um failover ou switchover.

Este manual de soluções fornece uma visão geral da replicação em camada intermediária durante todo o ciclo de vida do sistema. Apresenta várias tecnologias de replicação e fornece detalhes para implementá-las em um cenário real. Ele aplica cenários de recuperação de desastres ativo-passivo de camada intermediária em que os sistemas principal e stand-by estão na OCI.

O conteúdo é destinado a administradores de camada intermediária familiarizados com topologias de recuperação de desastres (DR) para middleware e com a OCI. Os exemplos e a terminologia se referem ao Oracle WebLogic Server e aos serviços PaaS que utilizam o WebLogic; no entanto, as tecnologias e implementações de replicação descritas se aplicam a qualquer sistema de camada intermediária.

Observação:

Este documento não descreve a configuração de recuperação de desastre.

Arquitetura

Esta arquitetura mostra uma visão geral de alto nível da topologia de recuperação de desastres ativo-passivo de middleware. Este manual pressupõe que os sistemas primário e secundário já foram criados.

Qualquer solução de recuperação de desastres ativo-passivo para um sistema de camada intermediária deve implementar os seguintes recursos essenciais:

• Separação geográfica

  Sistemas primários e secundários são geograficamente separados, longe o suficiente para que não possam ser afetados pelo mesmo evento de desastre.

• Simetria

  Os sistemas primário e secundário são simétricos. O sistema secundário tem o mesmo número de nós na camada intermediária e na camada de banco de dados, com CPU e capacidade de memória semelhantes.

• Nome de front-end exclusivo

  Nomes front-end exclusivos para o primário e secundário. O acesso de clientes ao sistema deve ser independente do site que está sendo usado como o principal. Para isso, os nomes de endereço front-end devem ser exclusivos e sempre mapeados para o IP do sistema que é o principal naquele momento. Esse nome geralmente é chamado de front-end virtual ou URL intuitivo.

• Endereços de listening

  Os endereços de listening dos processos de camada intermediária devem ser nomes de host resolvíveis em ambos os sistemas e mapeados para os IPs dos hosts do site local.

• Replicação de banco de dados

  Os dados do banco de dados principal devem ser replicados no banco de dados stand-by usando o Oracle Data Guard.

• Replicação de camada intermediária

  As camadas intermediárias primária e secundária devem estar sincronizadas. Eles devem ter a mesma configuração, a mesma versão do produto e o mesmo nível de patch. Existem diferentes abordagens para conseguir isso. Você pode manter os sistemas principal e secundário separadamente: se uma alteração for executada no principal, a mesma alteração será repetida no secundário, se um patch for instalado no principal, o mesmo patch será instalado no stand-by. No entanto, isso duplica o trabalho e é propenso a erros. O Oracle Maximum Availability Architecture (Oracle MAA) recomenda implementar uma replicação automática para copiar os artefatos do sistema de arquivos de camada intermediária. Isso garante que os sistemas principal e stand-by estejam sempre sincronizados.

• Gestão das informações específicas de cada site

  A configuração do secundário é uma cópia exata do primário, mas pode haver artefatos de arquivo que contenham informações específicas de cada site, que devem ser diferentes em primário e secundário. A topologia de DR deve suportar isso e permitir a personalização de informações específicas do local.

  Dica:

  Exemplo de Oracle WebLogic Server

  Em um sistema Oracle WebLogic, a camada intermediária principal se conecta ao banco de dados da região principal e a camada intermediária secundária se conecta ao banco de dados da região secundária. Os sistemas de camada intermediária primária e secundária têm a mesma configuração, portanto, deve haver um mecanismo para garantir que cada sistema use a string de conexão apropriada que aponta para seu banco de dados local. O Oracle Maximum Availability Architecture (Oracle MAA) recomenda o uso de aliases TNS para as origens de dados, com diferentes arquivos tnsnames.ora em cada site. Os métodos de replicação da camada intermediária devem levar isso em consideração, ignorando o arquivo que contém a string de conexão do banco de dados (tnsnames.ora) ou substituindo a string de conexão do banco de dados nos arquivos para apontar para o banco de dados local.

A imagem a seguir é um exemplo de uma solução de recuperação de desastres ativo-passivo para um sistema de camada intermediária.

Descrição da ilustraçãoActive-Passive-Dr-Mid-tier.png

active-passive-dr-mid-tier-oracle.zip

Terminologia

Você deve se familiarizar com os seguintes conceitos e terminologia:

• Camada intermediária (também de camada intermediária ou middleware)

  A camada intermediária refere-se à camada dentro de uma arquitetura de aplicativo de várias camadas que fica entre a interface do usuário (front-end) e o armazenamento de dados (back-end). Ele trata da lógica de negócios, do processamento de dados e da segurança, atuando como uma ponte entre o usuário e o banco de dados.

• Desastre

  Um evento catastrófico súbito e não planejado que causa danos ou perdas inaceitáveis em um local ou área geográfica. Um desastre é um evento que compromete a capacidade de uma organização de fornecer funções, processos ou serviços críticos por um período inaceitável e faz com que a organização invoque seus planos de recuperação.

• Recuperação de Desastres (DR)

  Capacidade de proteger contra interrupções naturais ou não planejadas em um site de produção, usando uma estratégia de recuperação para aplicativos e dados para um site secundário geograficamente separado

• Topologia de Recuperação de Desastres

  O site de produção e os componentes de hardware e software do site secundário que compõem uma solução do Oracle Fusion Middleware Disaster Recovery.

• Arquitetura de Disponibilidade Máxima Oracle

  O Oracle Maximum Availability Architecture (Oracle MAA) é o plano de melhores práticas para proteção de dados e disponibilidade de produtos Oracle (Database, Fusion Middleware, Applications). A implementação das melhores práticas do Oracle MAA é um dos principais requisitos para qualquer implantação da Oracle. Ele fornece recomendações para configurar e gerenciar um sistema Oracle. O Oracle MAA inclui as recomendações do Oracle Fusion Middleware Enterprise Deployment Guide e adiciona as melhores práticas de proteção contra desastres para minimizar o tempo de inatividade planejado e não planejado para interrupções que afetem todo um data center ou região.

• Sistema

  Um Sistema é um conjunto de destinos (hosts, bancos de dados, servidores de aplicativos, etc.) que trabalham juntos para hospedar seus aplicativos. Por exemplo, para monitorar um aplicativo no Oracle Enterprise Manager, primeiro você deve criar um Sistema, que consiste nos alvos do banco de dados, do listener, do servidor de aplicativos e dos hosts nos quais o aplicativo é executado.

• Site

  Um site é o conjunto de diferentes componentes em um data center necessário para executar um grupo de aplicativos. Por exemplo, um site pode consistir em instâncias, bancos de dados, armazenamento, etc. do Oracle Fusion Middleware.

• Local de produção ou principal

  O local que está carregando a carga de trabalho do sistema em um momento preciso. É um grupo de recursos de hardware, rede e armazenamento e processos que são usados ativamente para transportar lógica de negócios e solicitações de processos em um momento preciso.

• Site secundário (ou stand-by ou DR)

  Um site secundário é um local de backup que pode assumir a lógica de negócios e solicitações que um site principal estava processando. Normalmente, os sites secundários também são nomeados como "Standby" porque permanecem no "modo stand-by ou inativo". Isso significa que eles não estão processando a carga de trabalho de produção durante as operações normais. No entanto, isso não implica que o site secundário não possa ser usado para outros fins. Isso é especialmente verdadeiro em modelos mais modernos em que o site secundário é usado para operações de relatório e, mais importante, para validar as alterações antes de aplicá-las no site principal.

• RPO (Recovery Point Objective)

  O objetivo do ponto de recuperação é a quantidade de perda de dados que um sistema pode tolerar do ponto de vista de negócios. Por exemplo, a quantidade de perda de dados que é aceitável quando ocorre uma interrupção.

• RTO (Recovery Time Objective)

  O objetivo de tempo de recuperação é a quantidade de tempo de inatividade que um sistema pode tolerar ou a quantidade aceitável de tempo que um aplicativo ou serviço pode permanecer indisponível quando ocorre uma interrupção, do ponto de vista comercial.

• OCI (Oracle Cloud Infrastructure)

  A OCI é um conjunto de serviços complementares de nuvem que permite criar e executar uma variedade de aplicativos e serviços em um ambiente hospedado altamente disponível. O OCI oferece recursos de processamento de alto performance (como instâncias físicas de hardware) e capacidade de armazenamento em uma rede virtual flexível de sobreposição que fica acessível de forma segura na sua rede local.

• Região da OCI

  Uma região do OCI é uma área geográfica localizada, composta por um ou mais domínios e disponibilidade. As regiões são independentes de outras regiões e podem ser separadas por grandes distâncias — entre países ou até mesmo continentes. Uma região é um site em termos de Recuperação de Desastres.

• Volumes em Blocos do OCI

  O OCI Block Volumes fornece armazenamento em blocos confiável, de alto desempenho e de baixo custo que persiste além da vida útil de uma máquina virtual, com redundância integrada e capacidade de dimensionamento.

• OCI File Storage

  O OCI File Storage é um serviço de armazenamento de nível empresarial totalmente gerenciado e elástico que permite que servidores e aplicativos acessem dados por meio de sistemas de arquivos compartilhados.

• DBFS

  Um DBFS (Database File System) é uma interface de sistema de arquivos padrão no Oracle Database. DBFS é semelhante ao NFS, uma vez que fornece um sistema de arquivos de rede compartilhada que se parece com um sistema de arquivos local e tem um componente de servidor e um componente de cliente.

• Estrutura WLS-HYDR

  O "WLS-HYDR Framework" refere-se a um framework para criar e configurar um sistema de DR (Recuperação de Desastres) simétrico para ambientes Oracle WebLogic Server (WLS), especificamente no Oracle Cloud Infrastructure. Esse framework automatiza os processos manuais envolvidos na configuração de um ambiente de DR para domínios WLS ou Fusion Middleware (FMW).

• Pilha do Oracle WebLogic Server for Oracle Cloud Infrastructure

  A pilha do Oracle WebLogic Server para OCI refere-se a um ambiente pré-configurado criado usando o Oracle Resource Manager no OCI Marketplace, que provisiona e gerencia implantações do Oracle WebLogic Server na OCI. Ele automatiza a criação e a configuração de vários recursos da OCI, como instâncias de computação, rede, balanceadores de carga, juntamente com um domínio WebLogic.

• Pilha do Oracle SOA Suite on Marketplace

  A pilha do Oracle SOA Suite on Marketplace é um ambiente pré-configurado criado com o Oracle Resource Manager no OCI Marketplace para implantar e gerenciar os aplicativos do Oracle SOA Suite no OCI. Ele automatiza a criação e a configuração de vários recursos da OCI, como instâncias de computação, rede, balanceadores de carga, juntamente com um domínio SOA WebLogic.

• Apelido de TNS

  No Oracle, um alias TNS, também conhecido como Nome de Serviço de Rede, é um identificador amigável que simplifica as conexões de banco de dados. Ele atua como um atalho, mapeando um nome legível para os detalhes de conexão mais complexos necessários para acessar uma instância específica do banco de dados Oracle. Esses detalhes, incluindo protocolo, host, porta e nome do serviço, são armazenados em um arquivo de configuração, geralmente chamado tnsnames.ora.

• Pasta Admin TNS

  A pasta Admin do Oracle TNS, especificada pela variável de ambiente TNS_ADMIN, é o diretório no qual os arquivos de configuração do Oracle Net Services, como tnsnames.ora, estão localizados. Um sistema de camada intermediária pode usar uma pasta de administração TNS com o tnsnames.ora e outros artefatos necessários para estabelecer conexão com o banco de dados.

Sobre Procedimentos de Configuração de DR Ativo-Passivo de Middleware no OCI

Em uma topologia de recuperação de desastres ativo-passivo para middleware, o sistema secundário é um espelho do sistema primário. Quando os sistemas primário e secundário estão ambos na OCI, há diferentes maneiras de configurar o sistema secundário:

• Manual

  Crie cada recurso individualmente por meio da Console ou da CLI do OCI como um espelho do sistema principal.

• Framework WLS-HYDR

  Use a estrutura WLS-HYDR para seus sistemas de camada intermediária com base no Oracle WebLogic. Esse framework usa o OCI SDK para Python para criar todos os recursos no secundário como um espelho do sistema principal. Consulte a seção Explorar Mais neste playbook para obter um link para o framework wls-hydr em GitHub.

• Provisione usando a mesma pilha do Marketplace

  Se o sistema principal for uma pilha do Marketplace, como Oracle WebLogic Server para OCI ou SOA Marketplace, você poderá provisionar usando a mesma pilha do Marketplace usada no banco de dados principal, com o banco de dados stand-by no modo stand-by snapshot.

Este manual de soluções se aplica a todos esses casos desde que atendam aos recursos de uma topologia de recuperação de desastres ativa-passiva descrita no ponto anterior. Ele pressupõe que os sistemas primário e secundário já tenham sido criados.

Observação:

Este documento não descreve a configuração de recuperação de desastre.