Elipse Knowledgebase

1) Introdução

Muitas vezes se torna necessário ao integrador/programador disponibilizar aos usuários o estado atual de cada um dos servidores E3 envolvidos no Hot-Standby, sendo que atualmente só é possível verificar estes estados através de desenvolvimento na aplicação. A proposta deste artigo é demonstrar a utilização da biblioteca ServidoresE3 desenvolvida pela Elipse.


2) Implementação

Criou-se uma biblioteca capaz de verificar os estados dos dois servidores configurados como hot-standby, gerando informando se o servidor está ativo, reserva, em manutenção ou em falha. De maneira simplificada será demonstrada como adquirir cada um destes estados pela aplicação.

No caso do estado Ativo, foi adicionado um script no evento de OnStartRunning da biblioteca que verifica o nome da máquina que esta rodando o script. Este script foi baseado no objeto WScript, sendo utilizado da seguinte forma:

Para informação de Reserva, foi utilizado o driver Elipse Ping que envia comandos de ping para os dois servidores configurados. A falha de ping indica que o micro está desligado – ou que não foi capaz de responder a esta solicitação – indicando que o mesmo está em falha.

Para descobrir se o servidor está o estado de manutenção é utilizado um driver cliente OPC conectado a este micro, onde é monitorada a propriedade ServerStatus deste objeto, sendo que quando esta receber o valor 3–ServerStatus_NoConfig indica que o Cliente OPC está iniciado, porém sem configuração, situação que significa que o servidor esta configurado como Manutenção.

Por fim, quando o servidor não está em nenhum dos estados anteriores, ele é configurado como Reserva.


3) Aplicação

Algumas configurações são necessárias na aplicação para que a mesma possa trabalhar com esta biblioteca, podendo ser vistas a seguir:

1. Adicioná-la ao domínio
 a. Basta abrir o domínio desejado, e através do menu Arquivo, escolher a opção Abrir Projeto
 b. Escolha o arquivo chamado servidorese3.lib
 c. Após aberto o arquivo, uma mensagem informando que o arquivo não está inserido no domínio será mostrada, sendo perguntando também se deseja adicioná-lo ao domínio, deve-se escolher a opção Sim.

2. Deve-se configurar o caminho correto para o driver Ping. Este driver é utilizado para auxiliar na detecção do status de cada servidor.
 a. Para este passo, é necessário abrir a biblioteca e acessar o Xobject chamado ServidoresE3. Dentro deste existe uma pasta chamada Driver.
 b. Este driver possui uma propriedade chamada Driver Location, esta deve ser preenchida com a localização do driver.

3. Feito isto, o objeto pode ser inserido na aplicação. Escolha um objeto Servidor de Dados (DataServer, aquele no qual podem ser inseridos tags internos) para fazer esta inserção.

4. Será necessário configurar 4 propriedades deste objeto, sendo elas:
 a. Servidor1 e Servidor2: são os nomes das máquinas onde estão rodando os dois servidores Hot-Standby.
 b. IP1 e IP2: são os endereços IP dos servidores 1 e 2, respectivamente. Por exemplo: 192.168.0.68

5. Esta biblioteca gera como saída três propriedades tipo somente leitura, sendo elas:
 a. Ativo: informa o nome do servidor ativo
 b. StatusServer1 e StatusServer2: informa os status de cada um dos servidores. Esta propriedade pode receber os seguintes valores:
  1 – Indica que o referido servidor é ativo
  2 – Indica que o referido servidor é reserva
  3 – Indica que o referido servidor está em falha.
  4 – Indica que o referido servidor está em manutenção


4) Interação biblioteca-aplicação

A seguir é demonstrado como os objetos da aplicação interagem entre si e entre os servidores configurados como Hot-Standby.


Figura 1 – Descrição esquemática da interação biblioteca-aplicação


Imaginamos que o Server1 assumiu como servidor principal após passar pelo algoritmo de Hot-Standby, neste momento o objeto Servidores deste servidor será ativado e passará a verificar o estado de cada um dos servidores.

1. O servidor que assume como principal recebe o estado de Ativo automaticamente, porém ainda é necessário verificar o estado do segundo servidor.

2. Neste momento o objeto tenta fazer dois tipos de acesso ao segundo servidor.
 a. Primeiramente é enviado um comando de Ping para servidor, com isto pode-se verificar se ele esta respondendo corretamente a rede.
 b. Caso o comando de ping seja bem sucedido, é feito um acesso via cliente OPC esta máquina e dependendo do resultado desta conexão sabe-se o estado do servidor.

3. Além de rodar o algoritmo de Hot-Standby, esta segunda máquina tem a função de ajudar a informar alguns de seus estados. Caso ocorra alguma troca de servidores ativo, estes mesmos passos descritos anteriormente serão seguidos por este servidor.


5) Customização

Esta biblioteca possui alguns tempos pré-definidos para reconhecer a troca do estado do segundo servidor, principalmente para definir o estado de falha, isto porque este estado é baseado numa não confirmação de ping enviada para esta máquina. Desta forma, muitas vezes ocorre da máquina não responder a este comando devido a um tempo de latência de rede um pouco maior em determinado momento. A biblioteca foi desenvolvida visando esperar por um erro de ping antes de apontar a falha.

Caso o integrador/programador necessite alterar esta sensibilidade, existe um contador no evento de OnRead de cada um dos tags PLC do objeto Driver. Basicamente basta alterar o valor da comparação para o número de retentativas desejado.


6) Conclusão

Com o uso desta biblioteca, torna-se bastante simplificada a tarefa de disponibilizar os estados dos dois servidores na aplicação. Porém deve-se lembrar que, por se tratar de um desenvolvimento sobre o aplicativo, esta biblioteca necessita de uma configuração adequada para o seu funcionamento correto.

Nota: a partir da versão 3.0, o servidor OPC E3 necessita de um licenciamento na hardkey. Antes de utilizar a biblioteca, verifique esta configuração através do E3Admin\Licenças.