Compartilhar via

Arquiteturas para o banco de dados Oracle em Máquinas Virtuais do Azure

  • Artigo

Aplica-se a: ✔️ VMs do Linux

Este artigo inclui informações sobre como implantar um banco de dados Oracle altamente disponível no Azure. Ele também se aprofunda em considerações sobre recuperação de desastres. Essas arquiteturas foram criadas com base nas implantações do cliente. O guia só se aplica ao Oracle Database Enterprise Edition.

Se quiser saber mais sobre a maximização do desempenho do seu banco de dados Oracle, confira Projetar e implementar um banco de dados Oracle no Azure.

Pré-requisitos

  • Compreensão sobre os diferentes conceitos do Azure, como zonas de disponibilidade
  • Oracle Database Enterprise Edition 12c ou posterior
  • Conscientização das implicações de licenciamento ao usar as soluções neste artigo
  • Requisitos definidos de RPO e RTO

Alta disponibilidade para Bancos de dados Oracle

A obtenção de alta disponibilidade na nuvem é uma parte importante do planejamento e da concepção de todas as organizações. O Azure oferece zonas de disponibilidade e conjuntos de disponibilidade para serem usados em regiões em que as zonas de disponibilidade estão indisponíveis. Para obter mais informações sobre como projetar para a nuvem, confira Opções de disponibilidade para Máquinas Virtuais do Microsoft Azure.

Além das ferramentas e ofertas nativas da nuvem, o Oracle fornece soluções para alta disponibilidade que podem ser configuradas no Azure:

Este guia inclui as arquiteturas de referência para cada uma dessas soluções.

Ao migrar ou criar aplicativos para a nuvem, recomendamos usar padrões nativos de nuvem, como o padrão de repetição e padrão de disjuntor. Para outros padrões que podem ajudar a tornar seu aplicativo mais resiliente, confira Padrões de Design de Nuvem.

Oracle RAC na nuvem

O Oracle Real Application Cluster (RAC) é uma solução da Oracle que ajuda os clientes a alcançar altas taxas de transferência, com muitas instâncias acessando um armazenamento de banco de dados. Esse padrão é uma arquitetura de tudo compartilhado. Embora o Oracle RAC possa ser usado para alta disponibilidade no local, o Oracle RAC sozinho não pode ser usado para alta disponibilidade na nuvem. O Oracle RAC protege apenas contra falhas no nível da instância e não contra falhas no nível do rack ou no nível do datacenter. Por esse motivo, a Oracle recomenda o uso do Oracle Data Guard com o seu banco de dados, seja instância única ou RAC, para alta disponibilidade.

Geralmente, os clientes exigem um SLA elevado para executar seus principais aplicativos. Atualmente, o Oracle não certifica nem dá suporte ao Oracle RAC no Azure. No entanto, o Azure oferece recursos como zonas de disponibilidade e janelas de manutenção planejada para ajudar a proteger contra falhas nas instâncias. Além dessas ofertas, você pode usar o Oracle Data Guard, o Oracle GoldenGate e o Oracle Sharding para alto desempenho e resiliência. Essas tecnologias podem ajudar a proteger seus bancos de dados contra falhas no nível do rack, no nível do datacenter e na política geográfica.

Quando você executa bancos de dados Oracle em várias zonas de disponibilidade com o Oracle Data Guard ou GoldenGate, você pode obter um SLA de tempo de atividade de 99,99%. Em regiões do Azure em que as zonas de disponibilidade ainda não estão presentes, os clientes podem usar conjuntos de disponibilidade e obter um SLA de tempo de atividade de 99,95%.

Observação

É possível ter um destino de tempo de atividade muito maior do que o SLA de tempo de atividade fornecido pela Microsoft.

Recuperação de desastre para Bancos de dados Oracle

Ao hospedar seus principais aplicativos na nuvem, é importante se preparar para alta disponibilidade e recuperação de desastres.

O Oracle Data Guard é um recurso útil para o Oracle Database Enterprise Edition com relação à recuperação de desastre. É possível configurar uma instância de banco de dados em espera em uma região combinada do Azure e configurar o failover do Data Guard para recuperação de desastre. Para não haver perda de dados, recomendamos implantar uma instância de sincronização distante do Oracle Data Guard, além do Active Data Guard.

Para replicação de dados de longa distância, é recomendável tirar proveito do Far Sync. Far Sync é um recurso do Oracle Active Data Guard.

Observação

Se você habilitar o Far Sync, uma licença do Active Data Guard será necessária. Entre em contato com seu representante da Oracle para conversar sobre as implicações da licença.

O Far Sync do Oracle soluciona a questão de uma longa distância entre o banco de dados primário e o banco de dados secundário introduzindo um servidor intermediário conhecido como Instância do Far Sync. Esse servidor recebe dados de recuperação do banco de dados primário e, em seguida, os encaminha para o banco de dados em espera. Desta forma, a instância do Far Sync é posicionada mais perto do banco de dados primário para reduzir o tempo da comunicação. Em seguida, o servidor Far Sync transfere os dados de recuperação para o banco de dados secundário de forma assíncrona.

Observação

Ao usar bancos de dados Oracle Standard Edition, você terá soluções de ISV que permitem configurar a alta disponibilidade e a recuperação de desastres, como o DBVisit Standby ou o Tessell.

Arquiteturas de referência

Oracle Data Guard

O Oracle Data Guard garante alta disponibilidade, proteção de dados e recuperação de desastre para dados corporativos. O Data Guard mantém os bancos de dados em espera como cópias de transação consistente do banco de dados primário. Dependendo da distância entre os bancos de dados principal e secundário e da tolerância do aplicativo para a latência, é possível configurar a replicação síncrona ou assíncrona.

Oracle Data Guard com failover de início rápido

O Data Guard pode ser implantado usando Fast Start Failover (FSFO). Fast-Start-Failover é um recurso fornecido na Configuração do Agente do Data Guard. Esse recurso permite que você faça failover automaticamente em caso de falha. O tempo padrão que os clientes usam é de 30 segundos, mas pode ser ajustado de acordo com seus requisitos. Essa assim chamada OperationTimeout faz parte das propriedades do Data Guard que você define durante sua implantação.

Como o Data Guard funciona com essa propriedade

A tarefa Do Data Guards é monitorar continuamente a integridade e o status dos bancos de dados primário e secundário. Assim que você habilita o Fast-Start-Failover (FSFO), o processo do observador é disparado e revisa o status de integridade a intervalos regulares para garantir alta disponibilidade a qualquer momento.

A partir de agora, se o banco de dados primário ficar indisponível, o observador e o Agente do Data Guard irão detectar essa interrupção. Desta forma, o parâmetro OperationTimeout de 30 segundos especifica por quanto tempo o Agente deve aguardar uma resposta do banco de dados primário antes de tomar qualquer providência adicional.

O resultado, a seguir, será o seguinte: se o primário não responder dentro dessa janela de 30 segundos o Observador irá presumir que o primário está inacessível e iniciar o processo de failover.

O Agente imediatamente promoverá o banco de dados em espera para o status de banco de dados primário, alternando as funções e garantindo que o aplicativo possa ser retomado rapidamente a partir do modo de espera.

Durante esse tempo, o Agente também garante que as transações se mantenham atualizadas no status em espera. Com o modo que você configurar, que pode ser Disponibilidade Máxima ou Proteção Máxima, uma replicação síncrona proporcionaria uma perda de dados entre mínima e zero. Os bancos de dados Oracle são colocados em várias zonas de disponibilidade para alta disponibilidade. Cada zona é composta por um ou mais data centers equipados com energia, resfriamento e rede independentes. Para garantir a resiliência, são configuradas no mínimo três zonas separadas em todas as regiões habilitadas. A separação física das zonas de disponibilidade dentro de uma região protege os aplicativos e os dados contra falhas do data center. Além disso, dois observadores de FSFO são configurados em duas zonas de disponibilidade para iniciar o failover para o banco de dados secundário em caso de falha. Após o failover ocorrer e assim que estiver disponível novamente, seu banco de dados primário anterior poderá ser restabelecido. O Agente do Data Guard Broker facilita esse processo.

Em última análise, se o banco de dados primário estiver indisponível devido a uma interrupção, planejada ou não, o Data Guard irá alternar ou fazer failover para o seu banco de dados em espera.

Esse recurso poderá fornecer uma resiliência adicional ao configurar o observador em uma máquina virtual separada. Desta forma, você implanta o observador em uma VM leve. Essa abordagem permite alta disponibilidade e resiliência.

O Oracle Database versão 12.2 e posteriores também permite configurar vários observadores com uma única configuração de agente do Oracle Data Guard. Fornece uma disponibilidade extra no caso de um observador e do banco de dados secundário experimentarem um tempo de inatividade. Para obter mais informações sobre o Agente do Data Guard e suas vantagens, confira Conceitos do Oracle Data Guard Broker.

O diagrama a seguir mostra uma instalação do Oracle Data Guard sem Far Sync com um tempo de recuperação inferior a 5 minutos.

Diagrama mostrando uma Arquitetura do Oracle Data Guard.

Os bancos de dados Oracle são colocados em várias zonas de disponibilidade para alta disponibilidade. Cada zona é composta por um ou mais data centers equipados com energia, resfriamento e rede independentes. Para garantir a resiliência, são configuradas no mínimo três zonas separadas em todas as regiões habilitadas. A separação física das zonas de disponibilidade dentro de uma região protege os aplicativos e os dados contra falhas do data center. Além disso, dois observadores de FSFO são configurados em duas zonas de disponibilidade para iniciar o failover para o banco de dados secundário em caso de falha.

Observação

Observe que, ao planejar uma implantação simétrica do Data Guard, você vai precisar de um observador a mais na zona de disponibilidade três.

Além disso, é altamente recomendável implantar o Oracle Enterprise Manager para continuar tendo uma visão geral da camada de banco de dados. É recomendado implantar o Azure Monitor com as seguintes métricas: Monitorar os discos:

  • Percentual Consumido de IOPS do Disco do SO
  • Percentual Consumido de IOPS do Disco de Dados
  • Bytes de Leitura do Disco de Dados/s
  • Bytes de Gravação do Disco de Dados/s
  • Profundidade da fila de disco
  • Largura de Banda de Disco em % por Lun

Além do indicado acima, recomendamos fortemente habilitar os insights de VM.

A Máquina Virtual é escolhida com base na sua avaliação da AWR. Certifique-se de ler o Planejamento de Capacidade da Oracle para ir além. Recomendamos fortemente que você use vCPUs de núcleo restrito para economizar nos custos de licenciamento e maximizar o desempenho.

A escolha do tipo de disco depende do resultado da sua avaliação da AWR.

Conforme mencionado acima, o Far Sync é uma funcionalidade predominantemente usada em cenários nos quais você replica entre regiões que cobrem longas distâncias. No que se refere a esse cenário, o Far Sync do Oracle Active Data Guard fornece uma funcionalidade de proteção com perda de dados zero para o Oracle Database. Uma instância do Far Sync do Oracle precisa ser instalada em uma VM separada.

Os discos SSD Premium v2 não têm suporte para arquivos referentes ao sistema operacional. Para obter mais informações, acesse Implantar o disco SSD Premium v2.

Os Arquivos Premium do Azure são usados como destino de Backup. Essa solução é a que apresenta melhor desempenho. Você também pode usar o Armazenamento de Blobs do Azure como destino de Backup. Certifique-se sempre de testar qual opção é a mais conveniente para você. Acesse também Estratégias de Backup do Oracle Database.

Sincronização distante do Oracle Data Guard

Conforme mencionado acima, o Far Sync é uma funcionalidade predominantemente usada em cenários nos quais você replica entre regiões que cobrem longas distâncias. No que se refere a esse cenário, o Far Sync do Oracle fornece uma funcionalidade de proteção com perda de dados zero para Oracle Databases. A instância do Far Sync do Oracle precisa ser instalada em uma VM separada.

Para proteção sem perda de dados, deve haver comunicação síncrona entre o banco de dado principal e a instância de sincronização distante. A instância de sincronização distante recebe a instrução de Refazer do banco de dados primário de maneira síncrona e a encaminha imediatamente para todos os bancos de dados em espera de maneira assíncrona. Essa configuração também reduz a sobrecarga no banco de dados primário, pois ele só precisa enviar a instrução de Refazer para a instância de sincronização distante, em vez de todos os bancos de dados em espera. Se uma instância de Far Sync falhar, o Active Data Guard usará automaticamente o transporte assíncrono do banco de dados primário para o banco de dados secundário para manter a proteção contra perda de dados próxima de zero. Para resiliência adicional, os clientes podem implantar várias instâncias de sincronização distante por cada instância de banco de dados, incluindo primária e secundária.

O diagrama a seguir é uma arquitetura que usa o Oracle Data Guard FSFO e o Far Sync para obter alta disponibilidade e recuperação de desastres:

Diagrama mostrando o Oracle Database usando o Far Sync em uma configuração multirregião do Active Data Guard.

Observação

Observe que, ao planejar uma implantação simétrica do Far Sync, você vai precisar de uma instância do Far Sync a mais na segunda região.

Oracle GoldenGate

O GoldenGate permite a troca e a manipulação de dados no nível de transação entre várias plataformas heterogêneas em toda a empresa. Ele move transações confirmadas com integridade de transação e sobrecarga mínima em sua infraestrutura existente. Sua arquitetura modular oferece a flexibilidade para extrair e replicar registros de dados selecionados, alterações transacionais e alterações em linguagem de definição de dados (DDL) em várias topologias.

O Oracle GoldenGate permite que você configure seu banco de dados para alta disponibilidade, fornecendo replicação bidirecional. Essa abordagem permite que você configure uma configuração de vários mestres ou ativa-ativa, que requer conscientização no nível do aplicativo. O diagrama a seguir é uma arquitetura recomendada para a configuração ativa-ativa do Oracle GoldenGate no Azure. Na arquitetura a seguir, o banco de dados Oracle foi configurado usando uma máquina virtual otimizada para memória de hiperthread com vCPUs básica restritas para economizar nos custos de licenciamento e maximizar o desempenho. A arquitetura usa vários discos premium ou ultra (discos gerenciados) para desempenho e disponibilidade.

Diagrama que mostra o Oracle Database usando zonas de disponibilidade com o agente do Data Guard – FSFO.

Observação

Uma arquitetura semelhante pode ser configurada usando conjuntos de disponibilidade em regiões em que as zonas de disponibilidade não estão disponíveis no momento.

O Oracle GoldenGate tem processos como Extrair, Bombear e Replicar, que ajudam a replicar seus dados de forma assíncrona, de um servidor de banco de dados Oracle para outro. Esses processos permitem configurar uma replicação bidirecional, para garantir a alta disponibilidade do seu banco de dados se houver tempo de inatividade na zona de disponibilidade.

No diagrama anterior, o processo de Extração é executado no mesmo servidor que o seu banco de dados do Oracle. A Bomba de Dados e os processos Replicat são executados em um servidor separado na mesma zona de disponibilidade. O processo de replicação é usado para receber dados do banco de dados em outra zona de disponibilidade e para confirmar os dados para o banco de dados Oracle em sua zona de disponibilidade. Da mesma forma, o processo de bombeamento de dados envia dados extraídos pelo processo de extração para o processo de Replicação na outra zona de disponibilidade.

Embora o diagrama de arquitetura anterior mostre os processos de Bombeamento de Dados e Replicação configurados em um servidor separado, é possível configurar todos os processos do Oracle GoldenGate no mesmo servidor, com base na capacidade e no uso do servidor. Sempre consulte seu relatório AWR e as métricas no Azure para entender o padrão de uso do seu servidor.

Ao configurar a replicação bidirecional do Oracle GoldenGate em diferentes zonas de disponibilidade ou regiões diferentes, é importante garantir que a latência entre os diferentes componentes seja aceitável para seu aplicativo. A latência entre zonas de disponibilidade e regiões pode variar. A latência depende de vários fatores. Recomendamos que você configure os testes de desempenho entre o seu nível de aplicativo e sua camada de banco de dados em diferentes zonas ou regiões de disponibilidade. Os testes podem confirmar se a configuração atende aos requisitos de desempenho do aplicativo.

A camada de aplicativo pode ser configurada em sua própria sub-rede e a camada de banco de dados pode ser separada em sua própria sub-rede. Quando possível, use o Gateway de Aplicativo do Azure para balancear a carga de tráfego entre os servidores de aplicativos. O Gateway de Aplicativo é um balanceador de carga robusto do tráfego da Web. Ele fornece afinidade de sessão baseada em cookie, que mantém uma sessão de usuário no mesmo servidor, minimizando os conflitos no banco de dados. As alternativas para o gateway de aplicativo são o Azure Load Balancer e o Gerenciador de Tráfego do Microsoft Azure.

Oracle Sharding

Fragmentação é um padrão de camada de dados introduzido no Oracle 12.2. Ele permite particionar horizontalmente e dimensionar os dados em bancos de dados independentes. É uma arquitetura de não compartilhar nada em que cada banco de dados está hospedado em uma máquina virtual dedicada. Esse padrão permite alta taxa de transferência de leitura e gravação, além de resiliência e maior disponibilidade.

Esse padrão elimina pontos únicos de falha, fornece isolamento de falha e habilita as atualizações sem tempo de inatividade. O tempo de inatividade de um fragmento ou uma falha no data center não afetam o desempenho ou a disponibilidade de outros fragmentos em outros datacenters.

A fragmentação é adequada para aplicativos OLTP com alta taxa de transferência, que não podem apresentar tempo de inatividade. Todas as linhas com a mesma chave de fragmentação sempre estão garantidamente no mesmo fragmento. Esse fato aumenta o desempenho, fornecendo alta consistência. Os aplicativos que usam fragmentação devem ter um modelo de dados bem definido e uma estratégia de distribuição de dados, como hash, intervalo, lista ou composição consistentes. A estratégia acessa principalmente dados usando uma chave de fragmentação, por exemplo, customerId ou accountNum. A fragmentação também permite armazenar conjuntos específicos de dados mais próximos dos clientes finais, ajudando você a atender aos requisitos de desempenho e conformidade.

Recomendamos replicar seus fragmentos para alta disponibilidade e recuperação de desastre. Essa configuração pode ser feita usando tecnologias Oracle, como Oracle Data Guard ou Oracle GoldenGate. Uma unidade de replicação pode ser um fragmento, uma parte de um fragmento ou um grupo de fragmentos. Uma interrupção ou lentidão de um ou mais fragmentos não afeta a disponibilidade de um banco de dados fragmentado.

Para alta disponibilidade, os fragmentos em espera podem ser colocados na mesma zona de disponibilidade dos fragmentos primários. Para a recuperação de desastre, os fragmentos em espera podem estar localizados em outra região. Também é possível implantar fragmentos em várias regiões para atender ao tráfego no local. Para saber mais sobre como configurar a alta disponibilidade e a replicação do banco de dados fragmentado, confira Alta disponibilidade de nível de fragmento.

O Oracle Sharding oferece principalmente os componentes a seguir. Para obter mais informações, confira Visão geral do Oracle Sharding:

  • Catálogo de fragmentos. Banco de dados Oracle com finalidade especial, que é um repositório persistente para todos os dados de configuração do banco de dados de fragmento. Todas as alterações de configuração, como adicionar ou remover fragmentos, mapeamento dos dados e DDLs em um banco de dados de fragmento, são iniciadas no catálogo de fragmentos. O catálogo de fragmentação também contém a cópia mestra de todas as tabelas duplicadas em um SDB.

    O catálogo de fragmentos usa exibições materializadas para replicar automaticamente as alterações em tabelas duplicadas em todos os fragmentos. O banco de dados do catálogo de fragmentos também atua como um coordenador de consultas usado para processar consultas de vários fragmentos e consultas que não especificam uma chave de fragmentação.

    Recomendamos usar o Oracle Data Guard com as zonas ou conjuntos de disponibilidade para alta disponibilidade do catálogo de fragmentos. A disponibilidade do catálogo de fragmentos não tem impacto sobre a disponibilidade do banco de dados fragmentado. Um tempo de inatividade no catálogo de fragmentos afeta apenas as operações de manutenção e as consultas em diferentes fragmentos durante o breve período em que o failover do Data Guard é concluído. O SDB continua a rotear e executar transações online. Uma interrupção do catálogo não os afeta.

  • Diretores de fragmentos. Serviços leves que precisam ser implantados em cada região/zona de disponibilidade em que seus fragmentos residem. Os diretores de fragmentos são gerentes de serviço globais implantados no contexto do Oracle Sharding. Para alta disponibilidade, recomendamos implantar pelo menos um diretor de fragmentos em cada zona de disponibilidade em que os fragmentos se encontram.

    Ao se conectar ao banco de dados inicialmente, o diretor do fragmento configura as informações de roteamento e armazena em cache as informações para solicitações subsequentes, que ignoram o diretor do fragmento. Depois que a sessão é estabelecida com um fragmento, todas as consultas SQL e DMLs têm suporte e são executadas no escopo do fragmento fornecido. Esse roteamento é rápido e usado para todas as cargas de trabalho OLTP que executam transações de fragmento internas. Recomendamos usar o roteamento direto para todas as cargas de trabalho OLTP que exigem o melhor desempenho e disponibilidade. O cache de roteamento é atualizado automaticamente quando um fragmento se torna indisponível ou ocorrem alterações na topologia de fragmentação.

    Para um roteamento dependente de dados de alto desempenho, a Oracle recomenda usar um pool de conexões ao acessar dados no banco de dado fragmentado. O Oracle Sharding é compatível com pools de conexão, bibliotecas de idioma específicos e drivers. Para obter mais informações, confira Visão geral do Oracle Sharding.

  • Serviço global. O serviço global é semelhante ao serviço de banco de dados comum. Além de todas as propriedades de um serviço de banco de dados, um serviço global possui propriedades para bancos de dados fragmentados. Essas propriedades incluem afinidade de região entre clientes e tolerância de atraso de fragmentos e replicação. É preciso criar somente um serviço global para realizar a leitura e a gravação dos dados de e para um banco de dado fragmentado. Ao usar o Active Data Guard e configurar réplicas somente leitura dos fragmentos, é possível criar outro serviço global para cargas de trabalho somente leitura. O cliente pode usar esses serviços globais para se conectar ao banco de dados.

  • Bancos de dados de fragmentos. Os bancos de dados de fragmentos são seus bancos de dados Oracle. Cada banco de dados é replicado usando o Oracle Data Guard em uma configuração de agente com FSFO habilitado. Não é preciso configurar o failover do Data Guard e a replicação em cada fragmento. Esse aspecto é automaticamente configurado e implantado quando o banco de dados compartilhado é criado. Se um fragmento específico falhar, o Oracle Sharding fará failover das conexões de banco de dados do primário para o que está em espera.

É possível implantar e gerenciar bancos de dados fragmentados da Oracle com duas interfaces: GUI do controle de nuvem do Oracle Enterprise Manager e o utilitário de linha de comando GDSCTL. É possível até monitorar a disponibilidade e o desempenho dos diferentes fragmentos usando o controle de nuvem. O comando GDSCTL DEPLOY cria automaticamente os fragmentos e seus respectivos ouvintes. Além disso, esse comando implanta automaticamente a configuração de replicação usada para alta disponibilidade no fragmento especificado pelo administrador.

Há diferentes maneiras de fragmentar um banco de dados:

  • Fragmentação gerenciada pelo sistema: distribui automaticamente entre fragmentos usando o particionamento
  • Fragmentação definida pelo usuário: permite especificar o mapeamento dos dados para os fragmentos, o que funciona bem quando há requisitos regulatórios ou de localização de dados
  • Fragmentação composta: uma combinação de fragmentação gerenciada pelo sistema e definida pelo usuário para diferentes espaços de fragmentos
  • Subpartições de tabela: semelhante a uma tabela particionada regular

Para obter mais informações, confira Métodos de fragmentação.

Um banco de dados fragmentado se parece com um único banco de dados para aplicativos e desenvolvedores. Ao migrar para um banco de dados fragmentado, planeje cuidadosamente para entender quais tabelas são duplicadas versus fragmentadas.

As tabelas duplicadas são armazenadas em todos os fragmentos, enquanto as fragmentadas são distribuídas entre diferentes fragmentos. Recomendamos que você duplique tabelas pequenas e dimensionais e distribua/fragmente as tabelas de fatos. Os dados podem ser carregados em seu banco de dado fragmentado usando o catálogo de fragmentos como o coordenador central ou executando o bombeamento de dados em cada fragmento. Para obter mais informações, confira Migração de dados para um banco de dados fragmentado.

Oracle Sharding com Data Guard

O Oracle Data Guard pode ser usado para fragmentação com métodos gerenciados pelo sistema, definidos pelo usuário e de fragmentação composta.

O diagrama a seguir é uma arquitetura de referência para o Oracle Sharding com o Oracle GoldenGate para alta disponibilidade de cada fragmento. O diagrama de arquitetura mostra um método de fragmentação composto. O diagrama de arquitetura provavelmente difere para aplicações com diferentes requisitos para localidade de dados, balanceamento de carga, alta disponibilidade e recuperação de desastres. Os aplicativos podem usar um método diferente para fragmentação. Com essas opções, o Oracle Sharding permite atender a esses requisitos e dimensionar horizontalmente com eficiência. Uma arquitetura semelhante pode até mesmo ser implantada usando o Oracle GoldenGate.

Diagrama que mostra a fragmentação do Oracle Database usando zonas de disponibilidade com o agente do Data Guard – FSFO.

A fragmentação gerenciada pelo sistema é a mais fácil de configurar e gerenciar. A fragmentação definida pelo usuário ou a composta são adequadas para cenários em que seus dados e aplicativos são distribuídos geograficamente ou quando é preciso ter controle sobre a replicação de cada fragmento.

Na arquitetura anterior, a fragmentação composta é usada para distribuir geograficamente os dados e expandir horizontalmente suas camadas de aplicativo. A fragmentação composta é uma combinação de fragmentação gerenciada pelo sistema e pelo usuário e, portanto, fornece o benefício de ambos os métodos. No cenário anterior, primeiramente os dados são fragmentados em vários espaços separados por região. Em seguida, os dados são particionados novamente usando hash consistente em vários fragmentos no espaço de fragmentos.

Cada espaço de fragmentos contém vários grupos de fragmentos. Cada grupo de fragmentos tem vários fragmentos e é uma unidade de replicação. Cada um deles contém todos os dados do espaço de fragmentos. Os grupos de fragmentos A1 e B1 são os grupos primários, enquanto os grupos A2 e B2 estão em espera. É possível optar por fragmentos individuais como a unidade de replicação, em vez de um grupo de fragmentos.

Na arquitetura anterior, um Service Manager Global (GSM)/diretor de fragmentos é implantado em cada zona de disponibilidade para alta disponibilidade. Recomendamos que você implante pelo menos um GSM/diretor de fragmento por data center/região. Além disso, uma instância do servidor de aplicativos é implantada em cada zona de disponibilidade que contém um grupo de fragmentos. Essa configuração permite que o aplicativo mantenha a latência entre o servidor de aplicativos e o banco de dados/grupo de fragmentos baixa. Se um banco de dados falhar, o servidor de aplicativos na mesma zona que o banco de dados em espera poderá lidar com solicitações depois que a transição da função de banco de dados ocorrer. O Gateway de Aplicativo do Azure e o diretor de fragmentos controlam a latência da solicitação e da resposta e encaminham as solicitações adequadamente.

Do ponto de vista de um aplicativo, o sistema cliente faz uma solicitação para o Gateway de Aplicativo do Azure ou outras tecnologias de balanceamento de carga no Azure, o que redireciona a solicitação para a região mais próxima do cliente. O Gateway de Aplicativo do Azure também é compatível com sessões temporárias. Portanto, todas as solicitações provenientes do mesmo cliente são encaminhadas para o mesmo servidor de aplicativos. O servidor de aplicativos usa o pool de conexões em drivers de acesso a dados. Esse recurso está disponível em drivers como JDBC, ODP.NET e OCI. Os drivers podem reconhecer as chaves de fragmentação especificadas como parte da solicitação. O UCP (ponto de controle do utilitário) da Oracle para clientes JDBC pode permitir que clientes de aplicativos que não sejam da Oracle, como o Apache Tomcat e o IIS, trabalhem com o Oracle Sharding. Para obter mais informações, confira Visão geral do pool compartilhado UCP para fragmentação de banco de dados.

Durante a solicitação inicial, o servidor de aplicativos se conecta ao diretor de fragmentos em sua região para obter informações de encaminhamento para o fragmento ao qual a solicitação precisa ser encaminhada. Com base na chave de fragmentação enviada, o diretor encaminha o servidor de aplicativos para o respectivo fragmento. O servidor de aplicativos armazena essas informações em cache criando um mapa e, para solicitações subsequentes, ignora o diretor de fragmentos e encaminha as solicitações diretamente para o fragmento.

Oracle Sharding com GoldenGate

O diagrama a seguir é uma arquitetura de referência para o Oracle Sharding com o Oracle GoldenGate para alta disponibilidade na região de cada fragmento. Diferentemente da arquitetura anterior, essa arquitetura retrata apenas a alta disponibilidade em uma única região do Azure, com várias zonas de disponibilidade. Você pode implantar um banco de dados fragmentado de alta disponibilidade de várias regiões, semelhante ao exemplo anterior, usando o Oracle GoldenGate.

Diagrama que mostra o Oracle Database Sharding usando zonas de disponibilidade com o GoldenGate.

A arquitetura de referência anterior usa o método de fragmentação gerenciado pelo sistema para fragmentar os dados. Como a replicação do Oracle GoldenGate é feita em uma parte, metade os dados replicados para um fragmento podem ser replicados para outro fragmento. A outra metade pode ser replicada para um fragmento diferente.

A maneira como os dados são replicados depende do fator de replicação. Com um fator de replicação 2, você tem duas cópias de cada parte dos dados nos três fragmentos do grupo. Da mesma forma, com um fator de replicação 3 e três fragmentos em seu grupo, todos os dados de cada fragmento são replicados para todos os outros fragmentos do grupo. Cada fragmento no grupo de fragmentos pode ter um fator de replicação diferente. Essa configuração ajuda a definir seu design de alta disponibilidade e a recuperação de desastre com eficiência em um grupo de fragmentos e em diferentes grupos de fragmentos.

Na arquitetura anterior, os grupos de fragmentos A e B contêm os mesmos dados, mas residem em diferentes zonas de disponibilidade. Se os grupos de fragmentos A e B tiverem o mesmo fator de replicação 3, cada linha/parte da tabela fragmentada será replicada seis vezes nos dois grupos. Se o grupo de fragmentos A tiver um fator de replicação 3 e o grupo de fragmentos B tiver um fator de replicação 2, cada linha/parte será replicada cinco vezes entre os dois.

Essa configuração impede a perda de dados se ocorrer uma falha na instância ou na zona de disponibilidade. A camada de aplicativo consegue fazer a leitura e gravação em cada fragmento. Para reduzir os conflitos, o Oracle Sharding designa uma parte mestra para cada intervalo de valores de hash. Esse recurso garante que as solicitações de gravação para determinada parte sejam direcionadas para a parte correspondente. Além disso, o Oracle GoldenGate fornece detecção e resolução automáticas de conflitos para lidar com os conflitos que possam surgir. Para obter mais informações e limitações de implementação do GoldenGate com o Oracle Sharding, confira Usar o Oracle GoldenGate com um banco de dados fragmentado.

Na arquitetura anterior, um diretor de GSM/fragmento é implantado em cada zona de disponibilidade para alta disponibilidade. Recomendamos que você implante pelo menos um GSM/diretor de fragmento por data center ou região. Uma instância do servidor de aplicativos é implantada em cada zona de disponibilidade que contém um grupo de fragmentos. Essa configuração permite que o aplicativo mantenha a latência entre o servidor de aplicativos e o banco de dados/grupo de fragmentos baixa. Se um banco de dados falhar, o servidor de aplicativos na mesma zona que o banco de dados em espera poderá lidar com solicitações depois que a transição da função de banco de dados fizer a transição. O Gateway de Aplicativo do Azure e o diretor de fragmentos controlam a latência da solicitação e da resposta e encaminham as solicitações adequadamente.

Do ponto de vista de um aplicativo, o sistema cliente faz uma solicitação para o Gateway de Aplicativo do Azure ou outras tecnologias de balanceamento de carga no Azure, o que redireciona a solicitação para a região mais próxima do cliente. O Gateway de Aplicativo do Azure também é compatível com sessões temporárias. Portanto, todas as solicitações provenientes do mesmo cliente são encaminhadas para o mesmo servidor de aplicativos. O servidor de aplicativos usa o pool de conexões em drivers de acesso a dados. Esse recurso está disponível em drivers como JDBC, ODP.NET e OCI. Os drivers podem reconhecer as chaves de fragmentação especificadas como parte da solicitação. O UCP (ponto de controle do utilitário) da Oracle para clientes JDBC pode permitir que clientes de aplicativos que não sejam da Oracle, como o Apache Tomcat e o IIS, trabalhem com o Oracle Sharding.

Durante a solicitação inicial, o servidor de aplicativos se conecta ao diretor de fragmentos em sua região para obter informações de encaminhamento para o fragmento ao qual a solicitação precisa ser encaminhada. Com base na chave de fragmentação enviada, o diretor encaminha o servidor de aplicativos para o respectivo fragmento. O servidor de aplicativos armazena essas informações em cache criando um mapa e, para solicitações subsequentes, ignora o diretor de fragmentos e encaminha as solicitações diretamente para o fragmento.

Aplicação de patches e manutenção

Quando você implanta suas cargas de trabalho do Oracle no Azure, a Microsoft cuida de todos os patches do nível de sistema operacional do host. A Microsoft comunica qualquer manutenção planejada no nível do sistema operacional aos clientes com antecedência. Dois servidores de duas zonas de disponibilidade diferentes nunca são corrigidos simultaneamente. Para obter mais informações sobre manutenção e remendos da VM, confira as Opções de disponibilidade para máquinas virtuais do Azure.

A aplicação de patches no sistema operacional da máquina virtual pode ser automatizada usando o Gerenciamento de Atualizações de Automação do Azure. É possível automatizar e agendar a aplicação de patches e a manutenção do seu banco de dados Oracle usando Azure Pipelines ou o Gerenciamento de Atualizações de Automação do Azure para reduzir o tempo de inatividade. Para obter mais informações sobre entrega contínua e implantações azuis/verdes, confira Técnicas de exposição progressiva.

Considerações de design e arquitetura

  • Use uma máquina virtual otimizada para memória de hiperthread com vCPUs restritas de núcleo para a máquina virtual do Oracle Database para economizar nos custos de licenciamento e maximizar o desempenho. Use vários discos premium ou ultra (discos gerenciados) para desempenho e disponibilidade.
  • Quando você usa discos gerenciados, o nome do disco/dispositivo pode ser alterado na reinicialização. Recomendamos que você use o UUID do dispositivo em vez do nome para garantir que suas montagens persistam no sprite de reinicialização. Para obter mais informações, confira Adicionar o novo sistema de arquivos a /etc/fstab.
  • Use zonas de disponibilidade para obter alta disponibilidade na região.
  • Considere o uso de discos ultra quando disponíveis ou discos premium para o seu banco de dados Oracle.
  • Configure um banco de dados Oracle em espera em outra região do Azure usando o Oracle Data Guard.
  • Use grupos de posicionamento por proximidade para reduzir a latência entre o aplicativo e a camada de banco de dados.
  • A largura de banda máxima de rede das VMs do Azure é (normalmente) maior que a taxa de transferência máxima de disco no mesmo SKU. Você pode obter maior taxa de transferência na mesma SKU de VM ou usar uma SKU de VM menor usando armazenamento em rede de alto desempenho e baixa latência, como o Azure NetApp Files. para o banco de dados.
  • Configure o Oracle Enterprise Manager para gerenciamento, monitoramento e registro em log.
  • Considere o uso do Gerenciamento Automático de Armazenamento Oracle para um gerenciamento de armazenamento simplificado do seu banco de dados.
  • Introdução ao Oracle Data Guard
  • Ajuste o código do seu aplicativo para adicionar padrões nativos da nuvem que podem ajudar seu aplicativo a ser mais resiliente. Considere padrões como o padrão de repetição, padrão de disjuntor e outros definidos no guia Padrões de Design de Nuvem.

Próximas etapas

Consulte os artigos de referência do Oracle a seguir que se aplicam ao seu cenário.