Arquiteturas para o banco de dados Oracle em Máquinas Virtuais do Azure
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
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.
Se a sua organização permitir a latência, considere configurar a instância de sincronização distante do Data Guard em uma zona de disponibilidade diferente do seu banco de dados primário do Oracle. Teste a configuração detalhadamente. Use um modo de disponibilidade máxima para configurar o transporte síncrono de seus arquivos refeitos para a instância de sincronização distante. Esses arquivos são transferidos de maneira assíncrona para o banco de dados em espera.
Seu aplicativo pode não permitir a perda de desempenho ao configurar a instância de Sincronização Distante em outra zona de disponibilidade no modo de Disponibilidade Máxima (síncrono). Caso contrário, você pode configurar uma instância de Sincronização Distante na mesma zona de disponibilidade que o banco de dados primário. Para obter disponibilidade adicional, configure várias instâncias de sincronização distantes próximas ao seu banco de dados primário e pelo menos uma instância próxima ao seu banco de dados em espera, se a função estiver em transição. Para obter mais informações, confira Sincronização Distante do Oracle Active Data Guard.
Ao usar bancos de dados Oracle Standard Edition, há soluções de ISV que permitem configurar alta disponibilidade e recuperação de desastre, como o DBVisit Standby.
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. 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á colocar qualquer banco de dados em espera na função principal, reduzindo o tempo de inatividade.
Ao usar o Oracle Data Guard, também é possível abrir seu banco de dados secundário somente para leitura. Essa configuração é chamada Active Data Guard. O Oracle Database 12c introduziu um recurso chamado instância de sincronização distante do Data Guard. Essa instância permite definir uma configuração sem perda de dados do seu Banco de dados da Oracle sem comprometer o desempenho.
Observação
O Active Data Guard requer uma licença adicional. Essa licença também é necessária para usar o recurso de sincronização distante. Entre em contato com o seu representante da Oracle sobre as implicações da licença.
Oracle Data Guard com failover de início rápido
O Oracle Data Guard com failover de Fast-Start (FSFO) pode oferecer mais resiliência com a configuração do agente em um computador separado. O agente do Data Guard e o banco de dados secundário executam o observador e observam o tempo de inatividade do banco de dados primário. Essa abordagem também permite a redundância na configuração do observador do Data Guard.
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. Essa configuração fornece disponibilidade adicional, caso um observador e o banco de dados secundário enfrentem tempo de inatividade. O agente do Data Guard é leve e pode ser hospedado em uma máquina virtual relativamente pequena. 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 é uma arquitetura recomendada para usar o Oracle Data Guard no Azure com zonas de disponibilidade. Essa arquitetura oferece um SLA de tempo de atividade de VM de 99,99%.
No diagrama anterior, o sistema cliente acessa um aplicativo personalizado com o back-end da Oracle usando a Web. O front-end da Web é configurado em um balanceador de carga. O front-end 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 primário Oracle. 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. São usados vários discos premium ou ultra (discos gerenciados) 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 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 FSFO são configurados em duas zonas de disponibilidade para iniciar e fazer failover do banco de dados para o secundário durante uma interrupção.
É possível configurar outros observadores ou bancos de dados em espera em uma zona de disponibilidade diferente, AZ 1, nesse caso, da zona mostrada na arquitetura anterior. Por fim, o Oracle Enterprise Manager (OEM) monitora o tempo de atividade e o desempenho de bancos de dados Oracle. O OEM também permite que você gere vários relatórios de desempenho e uso.
Em regiões em que não há suporte para zonas de disponibilidade, use conjuntos de disponibilidade para implantar seu Oracle Database de maneira altamente disponível. Os conjuntos de disponibilidade permitem alcançar um tempo de atividade de VM de 99,95%. O diagrama a seguir é uma arquitetura de referência desse uso:
Observação
- Como há apenas uma instância do OEM sendo implantada, você não precisa colocar a VM do Oracle Enterprise Manager em um conjunto de disponibilidade.
- No momento, os discos Ultra não são compatíveis com a configuração de conjunto de disponibilidade.
Sincronização distante do Oracle Data Guard
A sincronização distante do Oracle Data Guard tem uma funcionalidade de proteção contra perda de dados para bancos de dados Oracle. Essa funcionalidade permite a proteção contra a perda de dados caso o computador do banco de dados falhe. A sincronização distante do Oracle Data Guard precisa ser instalada em uma VM separada. A sincronização distante é uma instância leve do Oracle, com apenas um arquivo de controle, um arquivo de senha, spfile e logs em espera. Não há arquivos de dados, nem arquivos de log refazer.
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 sincronização distante falhar, o 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 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 de alta disponibilidade que usa a sincronização distante do Oracle Data Guard:
Na arquitetura anterior, há uma instância de sincronização distante implantada na mesma zona de disponibilidade que a instância do banco de dados, o que ajuda a reduzir a latência entre as duas. Nos casos em que o aplicativo é sensível à latência, considere implantar o banco de dados e a instância ou instâncias de sincronização distante em um grupo de posicionamento de proximidade.
O diagrama a seguir é uma arquitetura que usa o Oracle Data Guard FSFO e a sincronização distante para alcançar alta disponibilidade e recuperação de desastre:
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 definir uma configuração de vários mestres 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 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.
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.
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.
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.
- Use Azure Pipelines para gerenciar a aplicação de patches e atualizações no seu banco de dados sem nenhum 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 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.