- Configuração distribuída

A topologia do exige um serviço único para emular o controle de lock de registro ISAM. Para ser possível escalar a aplicação para atender a mais conexões simultâneas, o  pode ser configurado para trabalhar em uma configuração distribuída, onde um serviço do é configurado como Master, que terá a função de centralizar o controle de acessos mutuamente exclusivos (locks), e os demais serviços devem ser configurados como Slaves, e através deles serão realizadas as conexões e operações com o SGBD.

A configuração distribuída não é diretamente responsável por fazer distribuição da carga ou das conexões. Deste modo, cada serviço do  deve ser explicitamente configurado para realizar as conexões de dados em um  "Slave", onde o balanceamento efetivo das conexões já foi realizado pelo engine de balanceamento do , e cada  "Slave" é configurado para apontar para o "Master" para fazer as operações de lock.


Topologia sugerida

Partindo de um ambiente hipotético com 3 servidores, nomeados SRVDB, SRVAPP1 e SRVAPP2, onde o servidor de banco de dados possui um banco MSSQL Server e um e os servidores APP1 e APP2 possuam cada um 4 serviços do , configurados em modo de balanceamento de carga, neste cenário os serviços do  de todos os equipamentos apontam para um único , instalando na máquina de banco (SRVDB), onde têm um ODBC configurado para o . Nesse cenário, a seguinte topologia é sugerida:


Procedimento

Para implementar a configuração distribuída do , são necessários os seguintes passos:

  1. Instale um em cada máquina que contém o  (SRVAPP1 e SRVAPP2).
  2. Configure o ODBC para o banco de dados em cada uma das máquinas (SRVAPP1 e SRVAPP2).
  3. Configure cada , instalado nas máquinas Slave, para o modo de acesso Slave.
  4. Pare o serviço do da máquina de banco de dados (SRVDB).
  5. Configure o , da máquina de banco de dados, para o modo de acesso Master.
  6. Execute o da máquina de banco de dados (SRVDB).
  7. Execute o das máquinas que contém o  (SRVAPP1 e SRVAPP2).
  8. Teste as conexões, de cada um dos , usando o .
  9. Altere os arquivos de configuração (appserver.ini), dos serviços da máquina SRVAPP1, para acessar o da própria máquina.
  10. Altere os arquivos de configuração (appserver.ini), dos serviços da máquina SRVAPP2, para acessar o da própria máquina.


Para configurar o para modo de conexão Master, deve-se abrir o arquivo de configuração (dbaccess.ini), do , e na seção [General] inserir a chave Mode.

Mode=Master

Para configurar os para modo Slave, deve-se abrir o arquivo de configuração (dbaccess.ini) e configurar as seguintes chaves:

Mode=SlaveMasterServer=<IP>
MasterPort=<Port>

Onde <IP> e <Port> correspondem ao IP e Porta do Master que será utilizado como servidor de locks para os demais Slave.


Características operacionais da configuração distribuída

Um Slave somente consegue estabelecer conexão com o banco de dados, se conseguir conectar primeiro com o  Master. Caso o  Master não esteja no ar ou esteja configurado de forma incorreta, o retornará erro de conexão -43 (DBSERVER_INITERROR) ao .

Devido ao Master centralizar o serviço de controle de locks, o Master não realiza conexão com os SGBDs, que retorna erro -35 (NO_DB_CONNECTION) ao tentar conectar com o SGBD e mostra em console a mensagem: Invalid TopClient Connection on DBACCESS MASTER.

O Master é uma aplicação crítica e deve estar sempre no ar. Se o Master for derrubado durante a operação do sistema (ERP), as conexões dos Slaves serão derrubadas assim que qualquer recurso que dependa do Master (Lock de registro, controle de numeração de tabelas. virtual lock, table cache). Para o , será retornado o erro -2 (NO_CONNECTION), indicando que a conexão entre o  e o  foi perdida, e nos logs do  será registrado que a causa do fechamento da conexão foi falha de comunicação como Master.

Antes da build 19.2.1.0 do , a interface de monitoramento () somente têm acesso às informações e conexões processadas naquele serviço. Logo, para localizar uma conexão no ambiente mencioando, deve-se abrir um  para cada  Slave. Da mesma forma, os recursos de bloqueio de conexão e liberação de conexão ainda são individuais. Bloqueas novas conexões do Master não bloqueia novas conexões do Slave.

A partir da Build 19.2.1.0 do , foi implementado o mecanismo de monitoramento centralizado completo no Master, permitindo visualizar todas as conexões estabelecidas em todos os  Slave(s) do ambiente, bem como rasterar e encerrar conexões. Para maiores informações sobre essa implementação, conslute a nota de release no link Implementação - DBMonitor passa a suportar as funcionalidades de visualização de Locks, Rastrear e Encerrar quando conectado ao DBAccess Master

Além disso, outro ponto importante, é a respeito das configurações: As configurações devem ser replicadas, de modo que cada esteja configurado apontando para uma configuração ODBC que aponte para o mesmo banco de dados, ou ainda apontar para o mesmo banco de dados um ou mais  configurados como Slaves e apontar também para o mesmo banco de dados um configurado como StandAlone (Padrão sem distribuição). Discrepâncias desta natureza, não têm como serem detectadas pelo , e caso sejam realizadas, podem causar comportamentos inesperados e fatalmente prejudiciais a aplicação.


Flexibilidade de Configuração

O Master não precisa necessariamente ficar junto com a máquina de banco de dados. O pode ser um serviço instalado em um servidor de aplicação, em uma porta diferente da 7890, e como o seu controle será exclusivamente para bloqueio de registros, seu consumo de memória será bem inferior aos serviços Slaves. E, é possível configurar um Master em uma plataforma diferente dos demais Slaves, por exemplo um Master em uma máquina Linux e os demais Slaves em máquinas Windows. Além disso, podemos também colocar mais de um Slave no mesmo equipamento, desde que configurado em outra porta.

Embora seja possível, não é recomendável que sejam utilizados Slaves para o mesmo banco de dados/ambiente em plataformas distintas, por exemplo um Slave em Windows e outro em Linux.


Build do para uso do recurso distribuído

A utilização do em modo distribuído requer uma build com release igual ou superior a 20100510.