Arquitetura de microsserviços do Oracle GoldenGate

by Ravi Kant Sharma, Oracle Database Administrator, Rackspace Technology

Introdução

O Oracle® GoldenGate® suporta duas arquitecturas: a arquitetura clássica e a Oracle GoldenGate Microservices Architecture (OGG MA).

A arquitetura clássica possui as funções standard extract, replicat, pumpe receiver e é gerida pelo GoldenGate Software Command Interpreter (GGSCI).

O OGG MA é uma arquitetura baseada em microsserviços de interface de programa de aplicação (API) restful que lhe permite instalar, configurar, monitorizar e gerir os serviços Oracle GoldenGate através de uma interface de utilizador baseada na Web. O OGG MA foi introduzido na versão GoldenGate 12.3 e foi concebido na perspetiva das operações em nuvem.

Componentes de microsserviços do Oracle GoldenGate

É possível utilizar o OGG MA para configurar e gerir a replicação de dados através de uma interface de utilizador HTML. O OGG MA tem cinco componentes principais. O diagrama seguinte ilustra a forma como os processos de replicação funcionam num ambiente seguro de API Rest:

< entidade drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Fonte da imagem

As secções seguintes descrevem as funções e responsabilidades de cada componente do OGG MA, incluindo o cliente administrador.

Gestor de serviços

  • O gestor de serviços actua como um cão de guarda para os outros serviços disponíveis na arquitetura de microsserviços.
  • O gerenciador de serviços permite gerenciar uma ou mais implantações do GoldenGate em um host local.
  • O gerenciador de serviços é executado como um serviço do sistema, mantém informações de inventário e configuração sobre suas implantações e permite manter várias implantações locais.
  • Ao utilizar o gestor de serviços, pode iniciar e parar instâncias e consultar as implementações e os outros serviços.

Servidor de administração

  • O servidor de administração supervisiona, administra, gerencia e monitora os processos ativos e inativos que operam em uma implantação do GoldenGate.
  • O servidor de administração funciona como a entidade de controlo central para gerir os componentes de replicação nas suas implementações GoldenGate.
  • Utilizando o servidor de administração, pode criar e gerir os seus processos locais de extract replicat sem aceder ao servidor onde o GoldenGate está instalado.
  • A principal caraterística do servidor de administração é a interface de serviço da API Rest, que pode ser abordada por qualquer cliente HTTP ou HTTPS, como interfaces de serviço de arquitetura de microsserviços ou clientes Perl e Python.
  • Ao usar o servidor de administração, é possível adicionar, excluir ou alterar processos GoldenGate, editar arquivos de configuração, adicionar usuários e atribuir funções.

Servidor de distribuição

  • O servidor de distribuição funciona como um agente de distribuição de dados em rede que transmite e processa dados e comandos numa implementação distribuída em rede.
  • O servidor de distribuição é uma aplicação de elevado desempenho que pode tratar simultaneamente vários comandos e fluxos de dados de vários ficheiros de trilho de origem.
  • O servidor de distribuição substitui as clássicas bombas de dados múltiplas do lado da fonte por uma bomba de dados de lado único e por um serviço de instância única. Este servidor distribui um ou mais trails para um ou mais destinos e fornece apenas filtragem ligeira.

Servidor recetor

  • O servidor recetor é o serviço de controlo central que trata de todos os ficheiros de trajeto recebidos.
  • O servidor recetor interage com o servidor de distribuição e fornece compatibilidade com a bomba de arquitetura clássica para implementações clássicas remotas.
  • O servidor recetor substitui vários colectores discretos do lado do destino por um único serviço de instância.

Servidor de métricas de desempenho

  • O servidor de métricas de desempenho utiliza o serviço de métricas para recolher e armazenar os resultados do desempenho da implementação da instância.
  • A recolha e o repositório de métricas são separados da recolha de informações da camada de administração.
  • Todos os processos GoldenGate enviam métricas para o servidor de métricas de desempenho.
  • Pode utilizar o servidor de métricas de desempenho tanto na arquitetura de microsserviços como na arquitetura clássica.
  • Utilizando o servidor de métricas de desempenho, é possível consultar várias métricas, visualizar registos, estado do processo, monitorizar a utilização do sistema, etc.

Cliente administrador

  • O cliente admin é um utilitário de linha de comando (como o utilitário clássico GGSCI).
  • O cliente administrativo utiliza a API Rest publicada pelo servidor de arquitetura de microsserviços para realizar as suas tarefas.
  • O cliente de administração é utilizado para criar, configurar, modificar e remover processos.

O cliente administrativo tem mais funções e é mais utilizável em configurações distribuídas do que o GGSCI, como se pode ver na tabela seguinte:

< entidade drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Os principais diretórios e variáveis da arquitetura de microsserviços

A arquitetura de microsserviços foi concebida com uma estrutura de diretórios de instalação e implementação simplificada. O design é composto por um diretório home só de leitura, onde se instala o GoldenGate e se cria um diretório personalizado específico da implementação, como se mostra na imagem seguinte:

< entidade drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Fonte da imagem

Pode alterar as localizações predefinidas de todos estes diretórios para personalizar o local onde pretende armazenar os ficheiros.

Numa configuração em que OGG\_VAR\_HOME é um diretório local e OGG\_HOME é um diretório remoto só de leitura partilhado, muitas implementações com um OGG\_VAR\_HOME local podem partilhar o mesmo OGG_HOMEsó de leitura.

Conclusão

A arquitetura de microsserviços é uma nova arquitetura baseada em serviços que simplifica a configuração, a administração e a monitorização de implementações em nuvem de grande escala. Esta publicação apresentou o OGG MA e os seus componentes, que deverão mudar a forma como replica dados no local, na nuvem e em ambientes híbridos.

Saiba mais sobre nossos serviços AWS