Série Ferramentas Gráficas – Oracle GoldenGate Microservices Architecture (OGG MA) – PARTE I

 

Embora essa seja uma nova arquitetura, veja que alguns componentes da Arquitetura Clássica ainda estão presentes, como o processo Extract, Replicat e os TrailFiles, porém, eles não são mais gerenciados diretamente, ou seja, fazemos tudo isso através do Microserviço que gerencia ele. Outro detalhe interessante é que os processos Manager, Data Pump, Server Collector não existem nesta arquitetura.

A imagem a seguir ilustra com mais detalhes todos os componentes da Arquitetura de Microserviços:

Uma das principais novidades do OGG MA é que a interface para administração e configuração é totalmente web. Outro ponto em destaque que podemos observar na imagem é que existe apenas um único local como interface para configurar, monitorar e administrar os componentes, e essa interface é baseada em chamadas REST (GET / POST / PUT / DELETE), que permite fazer remotamente configurações, administração e monitoração utilizando páginas web, linha de comandos e APIs. Desta forma, não é necessário estar logado no servidor onde está rodando a instância do GoldenGate para realizar as tarefas, como é feito na Arquitetura Clássica usando o GGSCI.

Existem várias ferramentas que podem ser utilizados para administrar o OGG MA utilizando REST. A imagem abaixo mostra uma variedade de ferramentas (produtos Oracle, linha de comando, navegadores e interfaces de REST API programáticas) que pode ser usada para administrar as implementações usando as interfaces de serviço.

Agora vamos conhecer um pouco mais de cada um desses Microserviços, e veremos que eles realmente são independentes e possui interfaces de interação diferentes.

Service Manager

O microserviço “Service Manager” é a interface principal do OGG MA, através dela é possível ter uma visão geral de todos os outros microserviços que estão executando naquela instância do OGG MA. Além disso caso algum dos serviços falhar, ele pode ser reiniciado através do Service Manager. A seguir está a tela de login do Service Manager.

A seguir está a interface do Service Manager, ela possui um painel com todos os serviços e seus status. Um conceito importante de saber sobre o OGG MA é que para cada implementação/instalação do OGG MA, chamamos de deploy, e o local de instalação dos deploys também são diferentes do Arquitetura Clássica.

Admin Server

O microserviço “Administration Server” é utilizado para realizar as seguintes atividades:

• Criar os processos EXTRACT e REPLICAT.
• Configurar as credentials.
• Realizar manutenções e configurações de tarefas (auto-start/restart, purges).
• Criação da masterkey e criptografia.
• Criação e manipulação dos arquivos de parâmetros.
• Visualizar o status e diagnóstico do que está ocorrendo no Admin Server.

A seguir está interface do Admin Server, ela possui um painel onde podemos observar os processos Extract e Replicat. Essa forma de visualização é interessante, pois, podemos além de visualizar, também monitorar a replicação tanto no lado da extração (origem), quanto no lado da replicação (destino). E logo mais abaixo, também existe um painel com eventos e mensagens sobre os principais eventos ocorridos.

Metrics Server

O microserviço “Performance Metrics Server” é responsável por coletar e disponibilizar as métricas de performance de todos os componentes do OGG MA. Embora seja possível realizar normalmente o acesso via browser para monitorar e realizar os ajustes e tuning necessários, é necessário ter licença adicional do OGG Management Pack Plug-in para acessar qualquer API REST.

A seguir está interface do Performance Metrics Server, ela possui um painel onde podemos observar todos os componentes da Arquitetura do OGG MA, tanto os microserviços como os processos Extract e Replicat. Com este microserviço podemos realizar as seguintes atividades:

• Consultar várias métricas e receber resultados no formato JSON de serviços ou no formato XML
• Integrar ferramentas de métricas de terceiros
• Ver logs de erros
• Ver o status dos processos ativos
• Monitorar a utilização de recursos do sistema

Distribution Server

O microserviço “Distribution Server” funciona como um agente de distribuição de dados em rede, para dar suporte à transmissão, processamento de dados e comandos em uma implantação distribuída. Possui alto desempenho capaz de lidar com vários comandos e fluxos de dados de vários arquivos da trilha de origem, simultaneamente.

A seguir está interface do “Distribution Server”, ele substitui o processo “Data Pumps” que executa no lado da origem onde os dados são extraídos, com um serviço centralizado de uma instância única. Este microserviço distribui um ou mais trail files para um ou mais destinos, e um detalhe muito importante é que só é possível fazer alguns filtros simples e nenhuma transformação de dados.

Neste serviço é onde fica criado o fluxo de replicação (Distribution Path), ou seja, você terá a visibilidade de qual é a origem e qual é o destino, além de outros detalhes como: os bancos de dados, extract, trails de origem e destino.

Receiver Server

O microserviço “Receiver Server” é responsável por gerenciar todos os Trail Files que são enviados para algum destino. Ele trabalha junto com o “Distribution Server” e fornece compatibilidade com o processo Data Pump da Arquitetura Clássica para deploys remotos.

O Receiver Server substitui vários processos Collectors, que rodam no destino na Arquitetura Clássica, por um microserviço de instância única. E como vimos no Distribution Server, na Arquitetura OGG MA chamados o fluxo de replicação de “Distribution Path” ou apenas“Path”, que são configurações de replicação de origem para destino.

Com este microserviço podemos realizar as seguintes atividades:

• Monitorar eventos do Path
• Consultar o status dos Paths de entrada
• Ver as estatísticas dos Paths de entrada
• Diagnosticar problemas no Path

AdminClient

Mas e a linha de comando, morreu? Nããããoooo… ufa!

Para quem gosta e ainda prefere gerenciar os recursos por linha de comando, ainda existe uma alternativa. O AdminClient é um utilitário de linha de comando (semelhante ao GGSCI da Arquitetura Clássica). Com ele é possível executar comandos para realizar configuração, administração e monitoração dos componentes do Oracle GoldenGate.

A imagem a seguir, mostra alguns comandos possíveis, não mudou muita coisa do que já conhecemos com o GGSCI.

A arquitetura de Microserviços suporta apenas banco de dados Oracle, mas é possível utilizar um setup onde a origem seja a arquitetura clássica heterogênea e replicar para o destino com uma arquitetura OGGMA com Oracle ou o inverso, que seria uma origem com OGGMA e o destino OGG Clássico com banco de dados heterogêneo.

Mas não acaba por aqui, como este post ficou bem longo, dividi em duas etapas, porque ainda precisamos falar um pouco sobre a comparação das duas arquiteturas. Então se você quer saber mais sobre isso, fica ligado na PARTE II clicando aqui!

Documentação:

https://docs.oracle.com/en/middleware/goldengate/core/19.1/index.html

A GoldenGateBR é a primeira empresa a lançar um Treinamento de OGG MA aqui no Brasil, e claro em português! Quer saber mais? Clique aqui.

Gostou do Post? Acesse nossos outros posts clicando aqui ou acesse e se inscreva em nosso canal!

Obrigado Pessoal e até a próxima!

Abs,

Gilson Martins.