Partilhar via

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

  • Artigo

Aplica-se a: ✔️ Linux VMs

Este artigo inclui informações sobre como implantar um banco de dados Oracle altamente disponível no Azure. Além disso, este guia mergulha em considerações sobre recuperação de desastres. Essas arquiteturas foram criadas com base nas implantações do cliente. Este guia aplica-se apenas ao Oracle Database Enterprise Edition.

Se você estiver interessado em saber mais sobre como maximizar o desempenho do seu banco de dados Oracle, consulte Projetar e implementar um banco de dados Oracle no Azure.

Pré-requisitos

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

Alta disponibilidade para bancos de dados Oracle

Alcançar alta disponibilidade na nuvem é uma parte importante do planejamento e design de todas as organizações. O Azure oferece zonas de disponibilidade e conjuntos de disponibilidade para serem usados em regiões onde as zonas de disponibilidade não estão disponíveis. Para obter mais informações sobre como projetar para a nuvem, consulte Opções de disponibilidade para máquinas virtuais do Azure.

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

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

Ao migrar ou criar aplicativos para a nuvem, recomendamos o uso de padrões nativos da nuvem, como padrão de repetição e padrão de disjuntor. Para obter outros padrões que podem ajudar a tornar seu aplicativo mais resiliente, consulte o guia Cloud Design Patterns.

Oracle RAC na nuvem

O Oracle Real Application Cluster (RAC) é uma solução da Oracle para ajudar os clientes a obter altas taxas de transferência ao ter muitas instâncias acessando um armazenamento de banco de dados. Esse padrão é uma arquitetura compartilhada. Embora o Oracle RAC possa ser usado para alta disponibilidade 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 do datacenter. Por esse motivo, a Oracle recomenda o uso do Oracle Data Guard com seu banco de dados, seja instância única ou RAC, para alta disponibilidade.

Os clientes geralmente exigem um SLA alto para executar aplicativos de missão crítica. Atualmente, a Oracle não certifica nem oferece 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 no nível da instância. Além dessas ofertas, você pode usar o Oracle Data Guard, o Oracle GoldenGate e o Oracle Sharding para obter 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 geopolíticas.

Ao executar 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 onde as zonas de disponibilidade ainda não estão presentes, você pode usar conjuntos de disponibilidade e obter um SLA de tempo de atividade de 99,95%.

Nota

Você pode ter uma meta de tempo de atividade muito maior do que o SLA de tempo de atividade fornecido pela Microsoft.

Recuperação de desastres para bancos de dados Oracle

Ao hospedar seus aplicativos de missão crítica na nuvem, é importante projetar para alta disponibilidade e recuperação de desastres.

Para o Oracle Database Enterprise Edition, o Oracle Data Guard é um recurso útil para recuperação de desastres. Você pode configurar uma instância de banco de dados em espera em uma região emparelhada do Azure e configurar o failover do Data Guard para recuperação de desastres. Para perda zero de dados, recomendamos que você implante uma instância do Oracle Data Guard Far Sync além do Ative Data Guard.

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

Nota

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

O Oracle Far Sync aborda 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 Far Sync. Este servidor recebe dados de refazer do banco de dados primário e, em seguida, encaminha-os para o banco de dados em espera. Assim, a instância Far Sync é colocada mais perto do principal para reduzir o tempo de comunicação. Em seguida, o servidor Far Sync transfere os dados de refazer de forma assíncrona para o banco de dados secundário.

Nota

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

Arquiteturas de referência

Proteção de Dados Oracle

O Oracle Data Guard garante alta disponibilidade, proteção de dados e recuperação de desastres para dados corporativos. O Data Guard mantém bancos de dados em espera como cópias transacionalmente consistentes do banco de dados primário. Dependendo da distância entre os bancos de dados primário e secundário e da tolerância do aplicativo para latência, você pode 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 o Fast Start Failover (FSFO). O Fast-Start-Failover é um recurso fornecido na Configuração do Data Guard Broker. Este 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 suas necessidades. Isso chamado OperationTimeout faz parte das propriedades do Data Guard que você define durante a implantação.

Como o Data Guard funciona com essa propriedade

A tarefa do Data Guards é monitorar continuamente a integridade e o status do banco de dados primário e secundário. Assim que você habilita o Fast-Start-Failover (FSFO), o processo do observador é acionado e revisa o status de integridade em um intervalo regular para garantir alta disponibilidade a qualquer momento.

Agora, se o banco de dados primário ficar indisponível, o observador e o Data Guard Broker detetarão essa interrupção. Assim, o parâmetro OperationTimeout de 30 segundos especifica quanto tempo o Broker deve aguardar por uma resposta do banco de dados primário antes de tomar qualquer ação adicional.

O que resulta em se o primário não responder dentro dessa janela de 30 segundos, o Observador assume que o primário está inacessível e inicia o processo de failover.

O Broker promove imediatamente o banco de dados em espera para o status principal, alternando as funções e garantindo que o aplicativo possa ser retomado rapidamente do modo de espera.

Durante esse tempo, o Corretor também garante que as transações estejam atualizadas no modo de espera. Com o modo configurado, que pode ser Disponibilidade Máxima ou Proteção Máxima, uma replicação síncrona forneceria perda de dados mínima a 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 centros de dados equipados com alimentação, arrefecimento e rede independentes. Para garantir a resiliência, um mínimo de três zonas separadas são configuradas em todas as regiões habilitadas. A separação física das zonas de disponibilidade dentro de uma região protege os dados contra falhas do data center. Além disso, dois observadores FSFO são configurados em duas zonas de disponibilidade para iniciar o failover para o banco de dados secundário em caso de falha. Depois que o failover aconteceu e seu banco de dados primário anterior estiver disponível novamente, ele poderá ser restabelecido. O Data Guard Broker facilita esse processo.

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

Esse recurso pode fornecer resiliência adicional configurando o observador em uma máquina virtual separada. Assim, você implanta o observador em uma VM leve. Esta abordagem permite alta disponibilidade e resiliência.

Com o Oracle Database versão 12.2 e superior, também é possível configurar vários observadores com uma única configuração de agente do Oracle Data Guard. Ele fornece disponibilidade extra, no caso de um observador e o banco de dados secundário experimentarem tempo de inatividade. Para obter mais informações sobre o Data Guard Broker e suas vantagens, consulte 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 que mostra 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 centros de dados equipados com alimentação, arrefecimento e rede independentes. Para garantir a resiliência, um mínimo de três zonas separadas são configuradas em todas as regiões habilitadas. A separação física das zonas de disponibilidade dentro de uma região protege os dados contra falhas do data center. Além disso, dois observadores FSFO são configurados em duas zonas de disponibilidade para iniciar o failover para o banco de dados secundário em caso de falha.

Nota

Ao planejar uma implantação simétrica do Data Guard, observe que você precisará de mais um observador 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. Recomenda-se que o Azure Monitor seja implantado com as seguintes métricas: Monitore os discos:

  • Percentagem de IOPS de disco do SO consumida
  • Porcentagem de IOPS de disco de dados consumida
  • Bytes de leitura de disco de dados/s
  • Disco de dados grava bytes/s
  • Profundidade da fila de disco
  • Largura de banda do disco em % por Lun

Além disso, é altamente recomendável habilitar os insights da VM também.

A Máquina Virtual é escolhida com base na sua avaliação AWR. Consulte o Oracle Capacity Planning para ler mais. É altamente recomendável fazer uso de vCPUs de núcleo restrito para economizar nos custos de licenciamento e maximizar o desempenho.

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

Como mencionado acima, o Far Sync é um recurso predominantemente usado em cenários em que você replica entre regiões que superam longas distâncias. Referindo-se a esse cenário, o Oracle Ative Data Guard Far Sync fornece capacidade de proteção contra perda de dados zero para bancos de dados Oracle. A instância do Oracle Far Sync precisa ser instalada em uma VM separada.

SSD Premium v2 não são suportados para arquivos referentes ao sistema operacional. Para obter mais informações, visite Implantar SSD Premium v2.

Como destino de backup, os Arquivos Premium do Azure são usados. Esta solução é a mais eficiente. Você também pode usar o Armazenamento de Blob do Azure como destino de backup. Certifique-se sempre de testar qual opção combina melhor com você. Visite também Oracle Database Backup Strategies.

Oracle Data Guard Far Sync

Como mencionado acima, o Far Sync é um recurso predominantemente usado em cenários em que você replica entre regiões que superam longas distâncias. Referindo-se a esse cenário, o Oracle Far Sync fornece nenhum recurso de proteção contra perda de dados para bancos de dados Oracle. A instância do Oracle Far Sync precisa ser instalada em uma VM separada.

Para proteção contra perda de dados zero, deve haver comunicação síncrona entre o banco de dados principal e a instância do Far Sync. A instância Far Sync recebe refazer do primário de forma síncrona e encaminha-o imediatamente para todos os bancos de dados em espera de forma assíncrona. Essa configuração também reduz a sobrecarga no banco de dados primário, porque ele só precisa enviar o refazer para a instância do Far Sync em vez de todos os bancos de dados em espera. Se uma instância do Far Sync falhar, o Ative Data Guard usará automaticamente o transporte assíncrono para o banco de dados secundário a partir do banco de dados primário para manter uma proteção contra perda de dados quase nula. Para maior resiliência, os clientes podem implantar várias instâncias do Far Sync por cada instância de banco de dados, incluindo primárias e secundárias.

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

Diagrama que mostra o Oracle Database usando o Far Sync em uma configuração do Ative Data Guard entre regiões.

Nota

Ao planejar uma implantação simétrica do Far Sync, observe que precisará de mais uma instância do Far Sync na segunda região.

Oracle GoldenGate

GoldenGate permite a troca e manipulação de dados no nível de transação entre múltiplas plataformas heterogêneas em toda a empresa. Ele move transações comprometidas com integridade de transação e sobrecarga mínima em sua infraestrutura existente. Sua arquitetura modular oferece a flexibilidade de extrair e replicar registros de dados selecionados, alterações transacionais e alterações na 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 multimestre ou ativa-ativa que requer reconhecimento 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 hyperthreaded com vCPUs de núcleo restrito para economizar 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 Data Guard Broker - FSFO.

Nota

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

O Oracle GoldenGate tem processos como Extract, Pump e Replicat que ajudam a replicar de forma assíncrona seus dados de um servidor de banco de dados Oracle para outro. Esses processos permitem configurar uma replicação bidirecional para garantir a alta disponibilidade do banco de dados se houver tempo de inatividade no nível da zona de disponibilidade.

No diagrama anterior, o processo Extract é executado no mesmo servidor que o banco de dados Oracle. Os processos Data Pump e Replicat são executados em um servidor separado na mesma zona de disponibilidade. O processo Replicat é usado para receber dados do banco de dados na outra zona de disponibilidade e confirmar os dados no banco de dados Oracle em sua zona de disponibilidade. Da mesma forma, o processo Data Pump envia dados que o processo Extract extrai para o processo Replicat na outra zona de disponibilidade.

Embora o diagrama de arquitetura anterior mostre os processos Data Pump e Replicat configurados em um servidor separado, você pode configurar todos os processos do Oracle GoldenGate no mesmo servidor, com base na capacidade e no uso do seu servidor. Consulte sempre o seu relatório AWR e as métricas no Azure para compreender o padrão de utilização 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 múltiplos fatores. Recomendamos que você configure testes de desempenho entre a camada de aplicativo e a 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, considere usar o Gateway de Aplicativo do Azure para balancear a carga do tráfego entre seus servidores de aplicativos. O Application Gateway é um balanceador de carga de tráfego da Web robusto. Ele fornece afinidade de sessão baseada em cookies que mantém uma sessão de usuário no mesmo servidor, minimizando os conflitos no banco de dados. As alternativas ao Application Gateway são o Azure Load Balancer e o Azure Traffic Manager.

Compartilhamento Oracle

O compartilhamento é um padrão de camada de dados que foi introduzido no Oracle 12.2. Ele permite que você particione horizontalmente e dimensione seus dados em bancos de dados independentes. É uma arquitetura de compartilhamento de nada onde cada banco de dados é 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 falhas e permite atualizações contínuas sem tempo de inatividade. O tempo de inatividade de um fragmento ou de uma falha no nível do data center não afeta o desempenho ou a disponibilidade dos outros fragmentos em outros data centers.

O compartilhamento é adequado para aplicativos OLTP de alto rendimento que não podem suportar nenhum tempo de inatividade. Todas as linhas com a mesma chave de fragmentação têm sempre a garantia de estar no mesmo fragmento. Este fato aumenta o desempenho, proporcionando 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 consistente, intervalo, lista ou composto. A estratégia acessa principalmente os dados usando uma chave de fragmentação, por exemplo, customerId ou accountNum. O compartilhamento também permite que você armazene conjuntos específicos de dados mais perto dos clientes finais, ajudando assim a atender aos seus requisitos de desempenho e conformidade.

Recomendamos que você replique seus fragmentos para alta disponibilidade e recuperação de desastres. 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 de espera podem ser colocados na mesma zona de disponibilidade onde os fragmentos primários são colocados. Para recuperação de desastres, os fragmentos de espera podem ser localizados em outra região. Você também pode implantar fragmentos em várias regiões para atender ao tráfego nessas regiões. Para saber mais sobre como configurar a alta disponibilidade e a replicação do banco de dados fragmentado, consulte Alta disponibilidade em nível de fragmento.

O Oracle Sharding consiste principalmente nos seguintes componentes. Para obter mais informações, consulte Visão geral do Oracle Sharding:

  • Catálogo de estilhaços. Banco de dados Oracle para fins especiais que é um armazenamento persistente para todos os dados de configuração do banco de dados Shard. Todas as alterações de configuração, como adicionar ou remover fragmentos, mapeamento dos dados e DDLs em um banco de dados de estilhaços, são iniciadas no catálogo de estilhaços. O catálogo de estilhaços também contém a cópia mestre de todas as tabelas duplicadas em um SDB.

    O catálogo de estilhaços 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 estilhaços também atua como um coordenador de consulta usado para processar consultas de vários estilhaços e consultas que não especificam uma chave de fragmentação.

    Recomendamos o uso do Oracle Data Guard com zonas de disponibilidade ou conjuntos de disponibilidade para alta disponibilidade do catálogo de estilhaços como prática recomendada. A disponibilidade do catálogo de estilhaços não tem efeito sobre a disponibilidade do banco de dados fragmentado. Um tempo de inatividade no catálogo de estilhaços afeta apenas as operações de manutenção e as consultas de vários estilhaços durante o breve período de conclusão do failover do Data Guard. O SDB continua a encaminhar e executar transações online. Uma interrupção de catálogo não os afeta.

  • Diretores de estilhaços. Serviços leves que precisam ser implantados em cada região/zona de disponibilidade em que seus fragmentos residem. Os Shard Directors são Gerentes de Serviços Globais implantados no contexto do Oracle Sharding. Para alta disponibilidade, recomendamos que você implante pelo menos um diretor de estilhaço em cada zona de disponibilidade em que seus fragmentos existem.

    Ao se conectar ao banco de dados inicialmente, o diretor de estilhaço configura as informações de roteamento e armazena em cache as informações para solicitações subsequentes, que ignoram o diretor de estilhaço. Uma vez que a sessão é estabelecida com um fragmento, todas as consultas SQL e DMLs são suportadas e executadas no escopo do fragmento fornecido. Esse roteamento é rápido e é usado para todas as cargas de trabalho OLTP que executam transações intra-estilhaço. Recomendamos que você use o roteamento direto para todas as cargas de trabalho OLTP que exigem o mais alto desempenho e disponibilidade. O cache de roteamento é atualizado automaticamente quando um fragmento fica indisponível ou ocorrem alterações na topologia de fragmentação.

    Para roteamento dependente de dados de alto desempenho, a Oracle recomenda o uso de um pool de conexões ao acessar dados no banco de dados fragmentado. Pools de conexões Oracle, bibliotecas específicas de idiomas e drivers oferecem suporte ao Oracle Sharding. Para obter mais informações, consulte Visão geral do compartilhamento do Oracle.

  • Serviço global. O serviço global é semelhante ao serviço de banco de dados regular. Além de todas as propriedades de um serviço de banco de dados, um serviço global tem propriedades para bancos de dados fragmentados. Essas propriedades incluem afinidade de região entre clientes e tolerância a atraso de fragmento e replicação. Apenas um serviço global precisa ser criado para ler/gravar dados de e para um banco de dados fragmentado. Ao usar o Ative Data Guard e configurar réplicas somente leitura dos fragmentos, você pode 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 estilhaços. Os bancos de dados Shard são seus bancos de dados Oracle. Cada banco de dados é replicado usando o Oracle Data Guard em uma configuração de Broker com FSFO habilitado. Não é necessário configurar o failover e a replicação do Data Guard em cada fragmento. Esse aspeto é configurado e implantado automaticamente quando o banco de dados compartilhado é criado. Se um fragmento específico falhar, o Oracle Sharing fará failover nas conexões de banco de dados do primário para o modo de espera.

Você pode implantar e gerenciar bancos de dados fragmentados Oracle com duas interfaces: Oracle Enterprise Manager Cloud Control GUI e o GDSCTL utilitário de linha de comando. Você pode até mesmo monitorar os diferentes fragmentos quanto à disponibilidade e desempenho usando o controle de nuvem. O GDSCTL DEPLOY comando cria automaticamente os fragmentos e seus respetivos ouvintes. Além disso, esse comando implanta automaticamente a configuração de replicação usada para alta disponibilidade de nível de fragmento especificada pelo administrador.

Há diferentes maneiras de fragmentar um banco de dados:

  • Fragmentação gerenciada pelo sistema: distribui automaticamente entre fragmentos usando 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 fragmentação
  • Subpartições de tabela: semelhante a uma tabela particionada regular

Para obter mais informações, consulte Métodos de compartilhamento.

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 tabelas fragmentadas são distribuídas em 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 dados fragmentado usando o catálogo de estilhaços como coordenador central ou executando o Data Pump em cada fragmento. Para obter mais informações, consulte Migrando dados para um banco de dados fragmentado.

Compartilhamento Oracle com Data Guard

O Oracle Data Guard pode ser usado para fragmentação com métodos de fragmentação compostos e gerenciados pelo sistema.

O diagrama a seguir é uma arquitetura de referência para Oracle Sharding com Oracle Data Guard usada para alta disponibilidade de cada fragmento. O diagrama de arquitetura mostra um método de fragmentação composta. O diagrama de arquitetura provavelmente difere para aplicativos com requisitos diferentes para localidade de dados, balanceamento de carga, alta disponibilidade e recuperação de desastres. Os aplicativos podem usar métodos diferentes para fragmentação. O Oracle Sharding permite que você atenda a esses requisitos e dimensione horizontalmente e de forma eficiente fornecendo essas opções. Uma arquitetura semelhante pode até ser implantada usando o Oracle GoldenGate.

Diagrama que mostra o Oracle Database Sharding usando zonas de disponibilidade com o Data Guard Broker - FSFO.

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

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

Cada shardspace contém vários shardgroups. Cada grupo de fragmentos tem vários fragmentos e é uma unidade de replicação. Cada shardgroup contém todos os dados no shardspace. Os grupos de fragmentos A1 e B1 são grupos de fragmentos primários, enquanto os grupos de fragmentos A2 e B2 são grupos de espera. Você pode optar por fazer com que fragmentos individuais sejam a unidade de replicação, em vez de um grupo de fragmentos.

Na arquitetura anterior, um Global Service Manager (GSM)/shard diretor é implantado em todas as zonas de disponibilidade para alta disponibilidade. Recomendamos que você implante pelo menos um diretor GSM/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 shardgroup. Essa configuração permite que o aplicativo mantenha a latência entre o servidor de aplicativos e o banco de dados/shardgroup 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 assim que a transição da função de banco de dados acontecer. O Gateway de Aplicativo do Azure e o diretor de estilhaços controlam a latência de solicitação e resposta e encaminham as solicitações de acordo.

Do ponto de vista do aplicativo, o sistema cliente faz uma solicitação ao Gateway de Aplicativo do Azure ou a outras tecnologias de balanceamento de carga no Azure, que redireciona a solicitação para a região mais próxima do cliente. O Gateway de Aplicativo do Azure também dá suporte a sessões adesivas, portanto, todas as solicitações provenientes do mesmo cliente são roteadas 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 chaves de fragmentação especificadas como parte da solicitação. O Oracle Universal Connection Pool (UCP) para clientes JDBC pode permitir que clientes de aplicativos não-Oracle, como Apache Tomcat e IIS, trabalhem com o Oracle Sharding. Para obter mais informações, consulte Visão geral do pool compartilhado UCP para compartilhamento de banco de dados.

Durante a solicitação inicial, o servidor de aplicativos se conecta ao diretor de fragmento em sua região para obter informações de roteamento para o fragmento para o qual a solicitação precisa ser roteada. Com base na chave de fragmentação passada, o diretor roteia o servidor de aplicativos para o respetivo fragmento. O servidor de aplicativos armazena essas informações em cache criando um mapa e, para solicitações subsequentes, ignora o diretor de estilhaços e encaminha as solicitações diretamente para o fragmento.

Oracle Sharding com GoldenGate

O diagrama a seguir é uma arquitetura de referência para Oracle Sharding com Oracle GoldenGate para alta disponibilidade na região de cada fragmento. Ao contrário 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 em várias regiões, semelhante ao exemplo anterior, usando o Oracle GoldenGate.

Diagrama que mostra o Oracle Database Sharding usando zonas de disponibilidade com 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 um nível de bloco, metade dos dados replicados para um fragmento pode ser replicada para outro fragmento. A outra metade pode ser replicada para um fragmento diferente.

A forma como os dados são replicados depende do fator de replicação. Com um fator de replicação de dois, você tem duas cópias de cada bloco de dados em seus três fragmentos no grupo de fragmentos. Da mesma forma, com um fator de replicação de três e três fragmentos em seu grupo de fragmentos, todos os dados em cada fragmento são replicados para todos os outros fragmentos no grupo de fragmentos. Cada fragmento no grupo de fragmentos pode ter um fator de replicação diferente. Essa configuração ajuda você a definir seu projeto de alta disponibilidade e recuperação de desastres de forma eficiente dentro de um shardgroup e em vários shardgroups.

Na arquitetura anterior, o shardgroup A e o shardgroup B contêm os mesmos dados, mas residem em zonas de disponibilidade diferentes. Se ambos os fragmentos A e B tiverem o mesmo fator de replicação de três, cada linha/pedaço da tabela fragmentada será replicado seis vezes nos dois grupos de fragmentos. Se o shardgroup A tiver um fator de replicação de três e o shardgroup B tiver um fator de replicação de dois, cada linha/pedaço será replicado cinco vezes nos dois shardgroups.

Essa configuração evita a perda de dados se ocorrer uma falha no nível da instância ou da zona de disponibilidade. A camada de aplicação é capaz de ler e gravar em cada fragmento. Para minimizar conflitos, o Oracle Sharding designa um bloco mestre para cada intervalo de valores de hash. Esse recurso garante que as solicitações de gravação para um bloco específico sejam direcionadas para o bloco correspondente. Além disso, o Oracle GoldenGate fornece deteção e resolução automática de conflitos para lidar com quaisquer conflitos que possam surgir. Para obter mais informações e limitações da implementação do GoldenGate com Oracle Sharding, consulte Usando o Oracle GoldenGate com um banco de dados fragmentado.

Na arquitetura anterior, um diretor GSM/shard é implantado em todas as zonas de disponibilidade para alta disponibilidade. Recomendamos que você implante pelo menos um diretor GSM/shard por data center ou região. Uma instância do servidor de aplicativos é implantada em cada zona de disponibilidade que contém um shardgroup. Essa configuração permite que o aplicativo mantenha a latência entre o servidor de aplicativos e o banco de dados/shardgroup 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 função de banco de dados for transferida. O Gateway de Aplicativo do Azure e o diretor de estilhaços controlam a latência de solicitação e resposta e encaminham as solicitações de acordo.

Do ponto de vista do aplicativo, o sistema cliente faz uma solicitação ao Gateway de Aplicativo do Azure ou a outras tecnologias de balanceamento de carga no Azure, que redireciona a solicitação para a região mais próxima do cliente. O Gateway de Aplicativo do Azure também dá suporte a sessões adesivas, portanto, todas as solicitações provenientes do mesmo cliente são roteadas 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 chaves de fragmentação especificadas como parte da solicitação. O Oracle Universal Connection Pool (UCP) para clientes JDBC pode permitir que clientes de aplicativos não-Oracle, como Apache Tomcat e IIS, trabalhem com o Oracle Sharding.

Durante a solicitação inicial, o servidor de aplicativos se conecta ao diretor de fragmento em sua região para obter informações de roteamento para o fragmento para o qual a solicitação precisa ser roteada. Com base na chave de fragmentação passada, o diretor roteia o servidor de aplicativos para o respetivo fragmento. O servidor de aplicativos armazena essas informações em cache criando um mapa e, para solicitações subsequentes, ignora o diretor de estilhaços e encaminha as solicitações diretamente para o fragmento.

Aplicação de patches e manutenção

Quando você implanta suas cargas de trabalho Oracle no Azure, a Microsoft cuida de todos os patches no nível do sistema operacional do host. A Microsoft comunica antecipadamente aos clientes qualquer manutenção planeada ao nível do sistema operativo. Dois servidores de duas zonas de disponibilidade diferentes nunca são corrigidos simultaneamente. Para obter mais informações sobre manutenção e aplicação de patches de VM, consulte 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 Azure Automation Update Management. A aplicação de patches e a manutenção do banco de dados Oracle podem ser automatizadas e agendadas usando o Azure Pipelines ou o Azure Automation Update Management para minimizar o tempo de inatividade. Para obter mais informações sobre entrega contínua e implantações azuis/verdes, consulte Técnicas de exposição progressiva.

Considerações sobre arquitetura e design

  • Considere o uso de máquina virtual otimizada para memória hyperthreaded com vCPUs de núcleo restrito para sua VM de banco de dados Oracle para economizar em 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 mudar na reinicialização. Recomendamos que você use o UUID do dispositivo em vez do nome para garantir que suas montagens persistam no sprite de reiniciar. Para obter mais informações, consulte Adicionar o novo sistema de arquivos ao /etc/fstab.
  • Use as zonas de disponibilidade para obter alta disponibilidade na região.
  • Considere o uso de discos ultra quando disponíveis ou discos premium para seu banco de dados Oracle.
  • Considere configurar um banco de dados Oracle em espera em outra região do Azure usando o Oracle Data Guard.
  • Considere o uso de grupos de posicionamento de proximidade para reduzir a latência entre seu aplicativo e a camada de banco de dados.
  • A largura de banda máxima de rede das VMs do Azure é (normalmente) maior do que a taxa de transferência máxima do disco na mesma SKU. Você pode obter uma taxa de transferência mais alta na mesma SKU de VM ou usar uma SKU de VM menor usando armazenamento em rede de alto desempenho e baixa latência, como Arquivos NetApp do Azure. para a base de dados.
  • Configure o Oracle Enterprise Manager para gerenciamento, monitoramento e registro.
  • Considere o uso do Oracle Automatic Storage Management para gerenciamento simplificado de armazenamento para 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 padrão de repetição, padrão de disjuntor e outros definidos no guia Padrões de design de nuvem.

Próximos passos

Analise os seguintes artigos de referência da Oracle que se aplicam ao seu cenário.