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

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. As arquiteturas descritas neste artigo foram criadas com base em implantações de clientes. 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

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:

• Oracle Data Guard
• Data Guard com FSFO
• Fragmentação
• Portão Dourado

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

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.

Se seu aplicativo permitir a latência, considere configurar a instância do Data Guard Far Sync em uma zona de disponibilidade diferente do banco de dados principal do Oracle. Teste a configuração minuciosamente. Use um modo de Disponibilidade Máxima para configurar o transporte síncrono de seus arquivos de refazer para a instância do Far Sync. Esses arquivos são então transferidos de forma assíncrona para o banco de dados em espera.

Seu aplicativo pode não permitir a perda de desempenho ao configurar a instância do Far Sync em outra zona de disponibilidade no modo de Disponibilidade Máxima (síncrono). Caso contrário, você pode configurar uma instância do Far Sync na mesma zona de disponibilidade do banco de dados principal. Para maior disponibilidade, considere configurar várias instâncias do Far Sync perto do banco de dados principal e pelo menos uma instância perto do banco de dados em espera, se a função for transferida.

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.

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. 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 poderá alternar qualquer banco de dados em espera para a função principal, minimizando o tempo de inatividade.

Ao usar o Oracle Data Guard, você também pode abrir seu banco de dados secundário para fins somente leitura. Essa configuração é chamada de Ative Data Guard. O Oracle Database 12c introduziu um recurso chamado Data Guard Far Sync Instance. Essa instância permite que você configure uma configuração de perda de dados zero do seu banco de dados Oracle sem ter que comprometer o desempenho.

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

O Oracle Data Guard com Fast-Start Failover (FSFO) pode fornecer mais resiliência configurando o broker em uma máquina separada. O agente do Data Guard e o banco de dados secundário executam o observador e observam o banco de dados primário quanto ao tempo de inatividade. Essa abordagem também permite redundância na configuração do observador do Data Guard.

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. Essa configuração fornece disponibilidade extra, caso um observador e o banco de dados secundário enfrentem tempo de inatividade. O Data Guard Broker é leve e pode ser hospedado em uma máquina virtual relativamente pequena. Para obter mais informações sobre o Data Guard Broker e suas vantagens, consulte Conceitos do Oracle Data Guard Broker.

O diagrama a seguir é uma arquitetura recomendada para usar o Oracle Data Guard no Azure com zonas de disponibilidade. Essa arquitetura permite que você obtenha um SLA de tempo de atividade da VM de 99,99%.

No diagrama anterior, o sistema cliente acessa um aplicativo personalizado com back-end Oracle usando a Web. O frontend da Web é configurado em um balanceador de carga. O frontend da Web faz uma chamada para o servidor de aplicativos apropriado para lidar com o trabalho. O servidor de aplicativos consulta o banco de dados Oracle primário. O banco de dados Oracle é 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. Vários discos premium ou ultra (Managed Disks) são usados para desempenho e alta disponibilidade.

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 e fazer failover do banco de dados para o secundário quando ocorre uma interrupção.

Você pode configurar outros observadores ou bancos de dados em espera em uma zona de disponibilidade diferente, AZ 1, neste caso, da zona mostrada na arquitetura anterior. Por fim, o Oracle Enterprise Manager (OEM) monitora os bancos de dados Oracle quanto ao tempo de atividade e ao desempenho. O OEM também permite gerar vários relatórios de desempenho e utilização.

Em regiões onde as zonas de disponibilidade não são suportadas, você pode usar conjuntos de disponibilidade para implantar seu banco de dados Oracle de uma maneira altamente disponível. Os conjuntos de disponibilidade permitem que você obtenha um tempo de atividade da VM de 99,95%. O diagrama a seguir é uma arquitetura de referência desse uso:

Oracle Data Guard Far Sync

O Oracle Data Guard Far Sync fornece proteção contra perda de dados zero para bancos de dados Oracle. Esse recurso permite que você se proteja contra perda de dados se sua máquina de banco de dados falhar. O Oracle Data Guard Far Sync precisa ser instalado em uma VM separada. O Far Sync é uma instância Oracle leve que tem apenas um arquivo de controle, arquivo de senha, spfile e logs em espera. Não há arquivos de dados ou arquivos de log de refazer.

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 Data Guard usará automaticamente o transporte assíncrono do banco de dados primário para o banco de dados secundá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 de alta disponibilidade usando o Oracle Data Guard Far Sync:

Na arquitetura anterior, há uma instância do Far Sync implantada em uma zona de disponibilidade diferente como a instância do banco de dados para garantir perda zero de dados e failover automático se houver uma falha na zona de disponibilidade. Nos casos em que o aplicativo é sensível à latência, considere implantar seu banco de dados e a instância ou instâncias do Far Sync na mesma zona de disponibilidade em um grupo de posicionamento de proximidade.

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

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. 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 é configurado usando uma máquina virtual otimizada para memória hyperthreaded com vCPUs de núcleo restrito 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.

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 primária 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.

  Quando você se conecta 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.

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 estão em 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.

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.
• Use o Azure Pipelines para gerenciar patches e atualizações em seu banco de dados sem qualquer tempo de inatividade.
• 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.

• Introdução ao Oracle Data Guard
• Conceitos do Oracle Data Guard Broker
• Configurando o Oracle GoldenGate para Alta Disponibilidade Ativo-Ativo
• Visão geral do Oracle Sharding