Implante Bancos de Dados Oracle Eliminados Linearmente Escaláveis Distribuídos pelo Oracle Cloud, Microsoft Azure e Amazon Web Services

Quando você precisar de um banco de dados que suporte escalonamento horizontal com isolamento completo de dados distribuídos em diferentes provedores de nuvem, implante instâncias fragmentadas do Oracle Database em uma topologia tolerante a falhas. Você pode implantar a topologia no Oracle Cloud, Microsoft Azure e Amazon Web Services.

O Oracle Sharding permite bancos de dados convergentes, distribuídos globalmente. Ele suporta aplicativos que exigem escalabilidade linear, elasticidade, isolamento de falhas e distribuição geográfica de dados para soberania de dados. Ele faz isso distribuindo partes de um conjunto de dados entre bancos de dados Oracle independentes (fragmentos). Você pode implementar shards na nuvem ou no local, sem precisar de hardware ou software especializado. Os shards não se comunicam entre si no tempo de execução nesta arquitetura de nada compartilhada, que permite implantar shards em uma nuvem enquanto outros shards estão em uma nuvem ou no local diferente.

Arquitetura

A arquitetura a seguir mostra uma topologia do Oracle Database 19c tolerante a falhas. Os principais shards são distribuídos entre regiões no Oracle Cloud, Microsoft Azure e Amazon Web Services. Para cada shard principal, um shard stand-by é provisionado dentro da mesma região.

A arquitetura tem recursos redundantes em cada camada (diretor de pátios, catálogo e shards) em cada provedor de nuvem, para garantir a disponibilidade máxima do banco de dados fragmentado.

O diagrama a seguir ilustra essa arquitetura de referência.

Veja a seguir a descrição da ilustração sharded-db-oci-azure-aws.png
Descrição da ilustração sharded-db-oci-azure-aws.png

A arquitetura tem os seguintes componentes:

  • Gateway de internet

    O gateway de internet permite tráfego entre as sub-redes públicas e a internet pública. Cada provedor de nuvem está conectado à internet pública.

  • Diretórios de shards

    O diretor de shard (também chamado de gerente de serviço global) é um listener de rede que permite o roteamento de conexão de alto desempenho para os shards de banco de dados apropriados com base nas chaves de fragmentação.

    Você pode especificar o número de diretores de fragmentos necessários. Os diretores de shard são implantados em instâncias de computação individuais em cada provedor de nuvem. Você pode escolher a forma das instâncias de computação a serem usadas para os diretores de shard.

  • Catálogos de shards principais e stand-by

    Um catálogo de shard é uma instância do Oracle Database de finalidade especial que suporta implantação automatizada de shard, gerenciamento centralizado de um banco de dados de shard e consultas de vários quintais.

    Essa arquitetura contém um par principal de bancos de dados de catálogo, cada um em um sistema de banco de dados de nó único. Você pode escolher a forma do banco de dados e a capacidade de armazenamento disponível para os bancos de dados do catálogo. Um par principal de bancos de dados de catálogo é implantado em cada provedor de nuvem.

  • Fragmentos do banco de dados

    Cada fragmento de banco de dados é um sistema de banco de dados de nó único. Os principais shards são distribuídos no Oracle Cloud, Microsoft Azure e Amazon Web Services. Cada fragmento primário tem um shard associado.

Recomendações

Use as recomendações a seguir como ponto de partida para implementar o Oracle Database shards no Oracle Cloud, Microsoft Azure e Amazon Web Services. Os requisitos podem diferir da arquitetura descrita aqui.
  • Tamanho e número de fragmentos
    Ao implantar a pilha, você pode especificar a forma do banco de dados a ser usada e o número de shards.
    • Escolha uma forma apropriada com base em seus requisitos de carga de trabalho. A forma especificada é usada para todos os fragmentos.

      Após a implantação, você pode alterar a forma dos shards individuais para se adaptar às alterações na carga de trabalho. O shard para o qual você altera a forma é interrompido e reiniciado usando a nova forma.

    • Em geral, um grande número de pequenas placas proporciona melhor tolerância geral a falhas do que um pequeno número de grandes placas. Para expandir a topologia ou melhorar a tolerância a falhas, você pode adicionar shards a qualquer momento sem afetar a disponibilidade dos shards existentes. Quando necessário, você pode dimensionar no banco de dados com shards; o último shard criado é removido primeiro depois de mover os dados para os outros shards.
  • Disponibilidade de fragmentos

    Para garantir a alta disponibilidade dos shards, provisione shards stand-by e use o Oracle Data Guard para sincronização primária para stand-by e para failover.

  • Disponibilidade do catálogo de shards

    Para alta disponibilidade do catálogo de shard, provisione um catálogo stand-by e use o Oracle Data Guard para sincronização e failover. Observe que a disponibilidade do catálogo de shard não tem impacto na disponibilidade do banco de dados fragmentado. Uma interrupção do catálogo de shard afeta somente a capacidade de executar operações de manutenção ou consultas de vários quintais durante a falha no catálogo stand-by. As transações OLTP continuam a ser encaminhadas para os shards.

  • Disponibilidade do diretor de shards

    Para alta disponibilidade da camada do diretor de shard, implante vários diretores de shard. Você pode implantar até cinco diretores de shard em uma região. A Oracle recomenda que você implante pelo menos dois diretores de shard. No Oracle Cloud, a Oracle recomenda isolar os diretores de fragmentos em domínios de disponibilidade separados ou domínios de falha.

  • Armazenamento

    Escolha uma capacidade de armazenamento apropriada à sua carga de trabalho. Por exemplo, o armazenamento local ou um volume em blocos de um tamanho especificado é anexado a cada shard do banco de dados.

    Você pode ampliar o armazenamento a qualquer momento sem afetar a disponibilidade do banco de dados com base no recurso de provedores de armazenamento em nuvem. Para shards localizados no Oracle Cloud, consulte a documentação do Oracle Cloud Infrastructure Database para obter mais informações sobre armazenamento no Oracle Cloud.

Considerações

  • Design do aplicativo

    Qualquer aplicativo que tenha uma estratégia de distribuição de dados bem definida e acessa dados principalmente usando uma chave de fragmentação (como ID do cliente, número da conta e assim por diante) é adequado para bancos de dados fragmentados.

  • Escalabilidade

    Após implantar o banco de dados com shards, você pode aumentar ou diminuir o número de shards editando a pilha e aplicando as alterações. Dependendo do fator de replicação especificado durante a implantação da pilha, os shards stand-by também serão escalados.

    Você também pode escalar o número de diretores de fragmentos.

  • Segurança

    Ao implantar o banco de dados fragmentado, especifique uma chave pública SSH para ativar conexões SSH seguras aos servidores de banco de dados.

    Use firewalls e proxies, conforme apropriado, com base em seus casos de uso e requisitos de segurança específicos.

  • Isolamento de rede

    Para garantir o isolamento da rede, a melhor prática é implantar o banco de dados fragmentado em uma sub-rede privada. As soluções de roteamento e firewall precisarão ser determinadas com base no projeto e nos requisitos do seu aplicativo.