Funcionalidades de Redundância
Action.NET possui recursos internos para implantar sistemas redundantes, tanto no nível do servidor quanto no nível de aquisição de dados, permitindo a implantação, de modo fácil e confiável, de sistemas tolerantes a falhas. A sincronização das alterações em projetos é uma preocupação ao usar redundância, mas o Action.NET possui ferramentas para simplificá-la, possibilitando engenharia colaborativa eficaz.
Action.NET - Visão geral da redundância
Tipos de redundância de servidor
Existem dois tipos básicos de abordagens de redundância de servidor, "Hot-Hot" e "Hot-Standby".
Na maioria dos casos, o "Hot-Standby" é a maneira preferida para implementar sistemas tolerantes a falhas.
Redundância Hot-Hot
Para este cenário, dois servidores e todos os módulos dos servidores estão em execução em todos os momentos. Um aplicativo personalizado (normalmente, o driver TRemoteClient) faz a sincronização das entradas do operador entre os servidores. Quando o aplicativo está alimentando bancos de dados SQL remotos ou trocando dados com sistemas de terceiros, um código personalizado no aplicativo deve garantir que os dados não sejam gravados duplamente.
A configuração Hot-Hot é usada quando o processo não permite nenhum tempo de alternância do primário para o secundário. Portanto, não existe o conceito de "servidor ativo". Ambos os servidores estão totalmente ativos em todos os momentos. Os Monitores do cliente remoto podem acessar o projeto de qualquer servidor. Para criar cenários Hot-Hot com Action.NET, você precisa ter dois servidores em execução. Você precisa usar o TRemoteClient para sincronizar todos os dados necessários entre os servidores e usar Scripts para habilitar ou desabilitar partes do aplicativo em execução, conforme exigido pela operação duplicada.
A desvantagem das implementações Hot-Hot é que elas exigem engenharia de projeto personalizada. Especialmente quando você tem integração com outros aplicativos e quando a aquisição de dados dos dispositivos de campo é duplicada, o que causa uma carga extra na rede de dispositivos e potencialmente causa uma diferença de carimbos de data/hora (timestamps) entre cada estação.
Como gerenciar dois operadores em cada estação tentando dar comandos ao mesmo tempo, bem como a integração de SQL remoto e sistema de arquivos, a fim de evitar a duplicação de dados, deve ser decidido no nível do aplicativo.
Por esses motivos, a configuração Hot-Standby é a opção preferida ao implementar servidores tolerantes a falhas. O cenário Hot-Hot é aplicado principalmente quando o tempo de ativação do servidor do hot-standby, geralmente de alguns segundos, não é aceitável para o processo. Caso contrário, o Hot-Standby tem configuração mais simples, nenhuma engenharia personalizada, e garante automaticamente a consistência dos dados entre os servidores.
Redundância Hot Standby
Nesse cenário, há dois servidores com o projeto carregado, mas apenas um servidor (o ATIVO) está executando todos os módulos. O servidor STANDBY tem os módulos em um estado PAUSED e está recebendo a sincronização de dados do computador ACTIVE para atualizar sua memória local, mas não está executando as tarefas.
A redundância é implementada automaticamente pelo Action.NET, usando uma caixa de diálogo de configuração simples. Não há necessidade de programação personalizada ou de aplicativos personalizados. Qualquer projeto criado como um projeto autônomo pode ser implantado como um par tolerante a falhas sem necessidade de engenharia, mesmo quando conectado a sistemas de terceiros.
A comunicação entre os servidores é executada em TCP/IP MS-WCF, que pode ser criptografada e usa normalmente os recursos do MS-WCF. A troca de dados usa algoritmos desenvolvidos por anos de experiência de campo, que sincroniza os dados usando um modelo publicador-subescritor baseado no envio de dados apenas por exceção (eventos e alterações de dados) de maneira eficiente e confiável.
Mais importante ainda, a redundância não é um módulo externo. É "redundância para o núcleo". O Action.NET foi projetado a partir de entidades para ter suporte interno, no nível do kernel, para aplicativos tolerantes a falhas.
Quando o servidor STANDBY detecta que o computador ACTIVE está inativo, ele altera os Módulos do estado PAUSED para o estado ACTIVE; partindo a execução com os estados e valores atuais do banco de dados em tempo real recebidos recentemente da continua sincronização de dados.
A detecção do Active Server é feita normalmente usando uma mensagem de watch-dog no mesmo canal TCP/IP que está sendo usado para trocar os dados de sincronização. Também comandos de chaveamento personalizados podem ser adicionados, se necessário. Os parâmetros "Tempo limite de conexão" (Connection Timeout) na configuração de redundância é o tempo inativo do computador ativo que faz com que o computador em espera entre em operação; o valor típico para esse número é de um a dez segundos, dependendo da rede e dos servidores.
Configuração de redundância Action.NET
A redundância Hot-Standby é configurada na ficha Info-Projeto-Redundância do aplicativo TManager.
A configuração está na guia INFO (não na guia EDIT) porque não há alterações no próprio projeto. Configurar a redundância é apenas iniciar exatamente o mesmo projeto com os parâmetros de redundância opcionais.
Configuração de redundância do servidor
Os principais parâmetros a serem configurados são:
Timeout de conexão: Tempo do watch-dog em segundos. Este é o tempo que o computador em espera usa para monitorar periodicamente a atividade do computador ativo para fazer a troca automática. Fazer a troca entre o servidor ativo e o que está em espera também pode ser iniciada por comando. Nesse caso, a opção é imediata. Somente é necessário o tempo para alterar os módulos de PUSED para ACTIVE no computador em espera. O tempo normalmente varia de um a cinco segundos, mas depende muito da configuração específica do projeto, dos computadores servidores e da rede.
Endereços IP/computador primários e secundários: O endereço IP do computador ou os nomes DNS dos computadores que trabalharão juntos como um par tolerante a falhas. Eles executarão exatamente a mesma configuração do projeto, e qualquer um deles pode ser ATIVO ou EM ESPERA a qualquer momento. As únicas diferenças entre o definido como o Primário e o definidoo como o Secundário são:
Precedência primária: Se você iniciar dois servidores ao mesmo tempo e surgir um conflito, o computador Primario terá a função de ATIVO. Se ambos estiverem ativados, a função irá para o computador principal.
Na inicialização principal: Quando o Secundário é o servidor ATIVO e o computador Principal está inativo, o computador Principal é iniciado. Você pode especificar se o Secundário permanecerá como o servidor ATIVO ou se o servidor Primário assumirá o estado ATIVO depois de concluir sua inicialização, o que alterará automaticamente o computador Secundário para a função STANDBY. A configuração está usando a opção "Na inicialização principal".
Com base nessas configurações, uma linha de comando personalizada para o TStartup.exe é criada e apresentada na linha de configuração. Ao implantar a configuração redundante, você precisará usar a linha de comando no Windows AutoStart ou na configuração do Serviço do Windows se estiver executando Action.NET como um Serviço do Windows.
Configuração de redundância de dados
Ao executar aplicativos tolerantes a falhas, o servidor de Arquivamento de Alarmes e o servidor de arquivamento Historian podem estar localizados no mesmo computador que os servidores Action.NET ou em um terceiro computador dedicado ao arquivamento, como um servidor Microsoft SQL Server ou Oracle. A configuração "Replicação do historiador" fornece suporte aos muitos cenários.
Quando o Historiador está em um banco de dados em uma maquina remota, não há necessidade de fazer a Replicação em Action.NET. Como apenas um computador está ATIVO, o Primário ou o Secundário gravarão no banco de dados externo. Nesse caso, você define "sem replicação" para a configuração dos bancos de dados.
Observe que o banco de dados externo ainda pode ser um cluster tolerante a falhas que usa as ferramentas de redundância de banco de dados, mas o cluster é exibido pelo projeto Action.NET como apenas uma conexão externa.
Se você estiver executando o banco de dados de alarme ou o banco de dados de histórico no mesmo computador que os servidores de Action.NET, será necessário habilitar a respectiva opção de replicação.
Parâmetros do servidor
Ao usar a redundância, há um conjunto de parâmetros que podem ser atribuídos a TStartup.exe e TServer.exe para especificar o seu comportamento. A linha de comando é criada automaticamente em Info-Projeto-Redundância, mas você pode personalizar as linhas de comando diretamente conforme necessário. Estes são os parâmetros utilizados:
/ip1: <Nome do Servidor Principal ou IP>
/ip2: <Nome do Servidor Secundário ou IP>
/Port1: <Número da porta principal, o padrão é 3101>
/Port2: < porta para secundário, o padrão é 3101>
/project: <caminho completo do arquivo de projeto>
/connectionTimeout: <watch-dog timeout em segundos, aceita pontos decimais>
/username: <usuário de inicialização>
/redundância (não tem parâmetros, só precisa ser incluído para habilitar a redundância)
/autoswitch (não tem parâmetros. se incluído, o Primário assume como o nó Ativo se o secundário estava agindo como Ativo)
/TimeAutoSwitch: <número de segundos que o Primário aguarda antes de se tornar ativo se a opção de comutação automática estiver ativada. Normalmente definido como 60 segundos.
/ProjectIPPath: <IP>;<Caminho do projeto no servidor remoto>
O ProjectIPPath é usado pelo sistema para permitir que uma estação atualize automaticamente o projeto no par redundante ao fazer alterações de projeto online e comandos HotStart.
Exemplo: /ProjectIPPath:192.168.0.1; C:\Action.NET\Projetos\test.tproj
O tempo TimeAutoSwitch é considerado quando você está usando a opção /autoswitch. Nesse cenário, quando o computador definido como o primário é iniciado, ele irá "alternar automaticamente" de modo de espera para ativo depois de iniciado. É importante que a troca aconteça somente após o processo ter tido tempo de obter toda a sincronização do computador ativo. Normalmente, 60 segundos devem ser suficientes para isso, mas você deve aumentar este tempo para projetos grandes ou redes lentas.
Engenharia Colaborativa
A configuração de projeto centralizada do Action.NET facilita a manutenção de um projeto sincronizado em ambos os servidores. Todas as configurações do projeto estão apenas em um dos dois arquivos, o arquivo tproj ou trun. Você só precisa certificar-se de que o arquivo é o mesmo em ambos os computadores ao implantar seu projeto.
Observe que a opção depende de muitos fatores: se houver operações pendentes, o tamanho do projeto, os computadores e a rede. O tempo total de switch normalmente é medido em segundos, mas é necessário realizar um teste em seu cenário específico para especificar os parâmetros corretos para os parâmetros de tempo limite de conexão e repetir novamente.
Você pode configurar seu próprio procedimento para sincronizar os dois arquivos ou usar os métodos automatizados do Action.NET para configuração de espera ativa.
Alterações online
Opção 1: IPC local atuando como o servidor primário
MS Command Line for TFS Eng App e Runtime Debugging Tool:
"C:\Arquivos de Programas (x86)\Spin\Action.NET\an-9.2\TManagerExe.exe" /project:"C:\Action.NET\Projects\ExampleProject1.tproj"
Ferramentas
"C:\Arquivos de Programas (x86)\Spin\Action.NET\an-9.2\PropertyWatch.exe" /ip1:nome do computador /nome de usuário: Administrador
Quando você abre o aplicativo de Engenharia do Action.NET, TManager.exe, usa as ferramentas de configuração e se conecta a um Servidor que executa um projeto com a caixa de seleção Configuração online habilitada, o Servidor pode estar no mesmo computador com as ferramentas de configuração ou em um computador remoto.
Nesse caso, cada alteração feita no projeto é aplicada imediatamente ao aplicativo em execução.
A propriedade runtime @Server.UpdateProjectOnInactiveServer propagará as alterações online no servidor ativo para o servidor de backup.
Opção 2: Para alterações online, você deve usar o arquivo TPROJ, em vez de TRUN, e executar as seguintes etapas:
Conecte as ferramentas de engenharia no computador STANDBY.
Faça as modificações online ou pressione o botão HotStart para aplicar as alterações feitas anteriormente.
No aplicativo (em uma tela de administrador), execute o comando Server.SwitchToStandby(), para que o computador com o novo projeto esteja ativo.
Finalmente, execute um gatilho na propriedade Server.UpdateProjectOnInactiveServer que aplicará as alterações ao outro computador.
Se você quiser retornar o estado ativo para o computador original, basta executar o método Server.SwitchToStandby() novamente
Alterações offline
A opção de parâmetro de linha de comando /ProjectIPPath permite definir um caminho de verificação. Quando o aplicativo é iniciado, ele verifica a configuração do projeto local comparando-o com o projeto que está no computador remoto referido nesta opção.
Para alterações off-line:
Faça as alterações do projeto em outro computador e crie o arquivo TPROJ ou TRUN a ser instalado para uso em produção.
PARE a execução do Servidor runtime no computador em Standby, copie o arquivo TPROJ e inicie o Servidor runtime novamente.
Execute a troca na execução, tornando ATIVO o Servidor runtime que já foi atualizado e PARE o servidor runtime no outro sistema.
Use o parâmetro /ProjectIPPath ao partir o Servidor não atualizado para habilita-lo a obter a configuração do outro Servidor automaticamente ao iniciar ou copie o arquivo para o segundo computador
Inicie este servidor runtime.
Início a quente
Você pode fazer alterações em um projeto quando ele estiver em execução, mesmo que você não esteja conectado a ele. Quando você faz alterações em um projeto e aplica todas as novas alterações de uma só vez sem parar o aplicativo, isso é chamado de "hot-swapping". Para fazer isso: Depois de fazer as alterações no projeto, conecte-se ao servidor e pressione o botão Hot Start na ficha Executar-inicialização.
Alterações em tempo de execução (Runtime Changes)
É possível atualizar projetos sem o uso de ferramentas de engenharia. Há um método @Server.LoadProjectVersion(<project>), que permite o carregamento dinâmico de uma nova configuração de projeto. Esse comando pode ser incluído com o próprio aplicativo ou dentro de um aplicativo .NET externo conectado ao servidor.
Configuração do cliente com base no cenário de Redundância
Os clientes Action.NET são fáceis de configurar em qualquer cenário de redundância. Não há necessidade de programação ou configuração avançada. Você só precisa iniciar a estação do cliente com o parâmetro certo, como mostrado em Info-Projeto-Redundância, exemplos:
TRichClient.exe /ip1:192.168.1.1 /ip2:192.168.1.2 /connectiontimeout:5
http://192.168.1.1/an-9.2/TSmartClient.application?connectiontimeout=5;ip2=192.168.1.2
Os clientes nem precisam instalar nenhum arquivo de projeto em suas máquinas. Os computadores cliente obterão todas as informações do projeto do servidor. O RichClient só precisa do Action.NET no computador cliente. Ao usar o SmartClient, a única coisa necessária é o Internet Explorer instalado no computador cliente.
Esta conexão funciona da seguinte forma quando o cliente é iniciado (o RichClient ou o SmartClient), ele procura o computador ip1 para se conectar. Se não for encontrado, ele alterna para o computador ip2. Se o cliente perder a conexão com o computador servidor, ele tentará alternar automaticamente para o par redundante sem interromper as operações do operador.
Interação de redundância sobre o cliente
Os clientes podem visualizar informações críticas de redundância e até mesmo fazer uma troca de servidor usando propriedades e métodos de tempo de execução do Action.NET.
Alternando o servidor ativo
Há um método incluído no Action.NET: @Server.SwitchToStandby()
Esse método forçará o servidor ativo a manipular o controle do servidor em espera; se o servidor em espera não estiver em execução, o comando falhará e a execução será mantida no mesmo computador. Se você quiser usar esse recurso, precisará criar uma tela ou botão protegido em uma tela de aplicativo.
Visualizando o status de redundância
A seguir estão as propriedades mais usadas:
@Server.IsPrimary // True, se o servidor ativo for o Primary
@Server.IsSecondary //True, se o servidor ativo for o Secundário
@Server.IsStandByActive //True, se o computador em espera estiver instalado e funcionando
@Server.IsSwitchToPrimaryEnabled //True, quando a configuração é para o primário está sempre ativo
@Server.RedundancyPendingObjects //Número de objetos pendentes de sincronização
@Server.UpdateProjectOnInactiveServer //Permitir alterações online/HotStart para replicar para o computador em espera
@Server.SwitchToStandby() // Solicitar ao servidor ativo para alternar para o modo de espera
Executando o aplicativo como serviço do Windows
Ao executar o aplicativo como um Windows Services, você precisa executar 4 ações:
Configurar a inicialização em tempo de execução: Usando as ferramentas de configuração do Action.NET ou editando diretamente o sistema de Serviço do Windows, você define um projeto do Action.NET para iniciar como um Serviço do Windows que executará os componentes de "servidor" do projeto. A interface gráfica do usuário sempre é executada em um Modo de Usuário do Windows no mesmo computador ou iniciada em um computador remoto.
Configure um servidor Web: Se você quiser acesso remoto a este projeto (para configuração de projeto ou para acessar os monitores em tempo de execução), você precisará configurar um servidor Web. Isso é feito com o software TWebServer interno ou com o Microsoft IIS (Serviços de Informações da Internet).
Verificar as configurações de segurança: Verifique as configurações de segurança do Serviço do Windows e as configurações de segurança do projeto Action.NET.
Definir a inicialização do cliente: Quando um projeto do Action.NET está sendo iniciado como um Serviço do Windows, os Monitores não serão executados, apesar da configuração do projeto, devido às restrições de sua execução como um serviço. Portanto, você precisa configurar as exibições do cliente, em um atalho de inicialização no mesmo computador ou em um computador remoto.
Configurando o Action.NET para o AutoStart de Tempo de Execução como um Serviço
O Action.NET pode ser configurado para iniciar como um serviço que reduz o tempo de inatividade. Isso pode ser feito em sua janela de boas-vindas. Na guia Servidor, clique em Configurações... botão.
Em "Selecionar modo de inicialização automática em tempo de execução", escolha a opção Serviço para executar o projeto como um serviço quando o computador for iniciado e selecione qual projeto você deseja. Por fim, clique no botão Aplicar configurações.
1. Configurar o TWebserver como Serviço
Se o projeto usa SmartClients para visualização, é recomendável configurar o TWebServer para ser executado como um serviço também.
Você deve desinstalar o TWebServer atual com o prompt de comando (por exemplo: C:\Arquivos de Programas (x86)\Spin\Action.NET) e executando:
InstallTWebServer /uninstall /port:80
Para executar o TWebServer como um serviço, você pode executar o InstallTWebServer usando o parâmetro /windowsservice.
E para escolher uma porta específica, você pode usar o parâmetro /port:<portnumber>.
InstallTWebServer /windowsservice /porta:1234
Para configurar o Microsoft IIS, consulte a documentação do projeto.
2. Verifique as configurações de segurança
Verifique as configurações de Segurança do Windows para Logon
Quando você configura o projeto para ser executado como um Serviço do Windows, ele será executado por padrão sob as credenciais internas da janela "Sistema Local". Para alguns projetos, especialmente se você acessar bancos de dados ou pastas externas, talvez seja necessário executar com as credenciais de logon de segurança do Windows de um usuário específico. A configuração é executada diretamente na Configuração do Serviço do Windows. Para a maioria dos cenários, a configuração padrão será suficiente.
Opcionalmente, você pode atrasar o início do serviço
Se o aplicativo estiver usando recursos, serviços ou aplicativos externos, convém atrasar o início do projeto para permitir que os outros serviços sejam iniciados primeiro. Isso também é executado na configuração do Serviço do Windows.
Configurar a segurança no projeto Action.NET
Quando o aplicativo estiver sendo executado como um serviço, os componentes do servidor serão executados sob as credenciais do "usuário do projeto" definido em Executar-Inicialização. Por padrão, o usuário é um "convidado". Para a maioria dos projetos, esse usuário será alterado para Administrador, o que permitirá que o usuário faça alterações no projeto com configuração online ou tenha acesso a todos os objetos de aplicativo.
3. Defina a inicialização do cliente
A última etapa é configurar a inicialização ou as exibições do cliente. O procedimento que descreveremos é o mesmo se os monitores do cliente estiverem sendo executados no mesmo computador ou em um computador remoto.
Para que o cliente seja iniciado automaticamente, você precisa criar um atalho no qual o operador clicará ou você pode colocar o atalho na Pasta de Inicialização do Windows.
O atalho será para o RichClient ou SmartClient. O RichClient inicia mais rápido, mas precisa ter o Action.NET instalado no computador cliente. O SmartClient não precisa de nenhuma instalação do Action.NET no computador cliente, mas precisa ter um servidor Web em execução no computador servidor.
Os atalhos podem ser criados usando a ferramenta de edição em Info-Projeto-Redundância
O parâmetro /IP1 é o endereço do computador servidor. O valor 127.0.0.1, o computador local, é o valor padrão para esse parâmetro. Talvez seja necessário definir outros parâmetros, como /port1, se não estiver usando a porta 3101, ou Ip2 e Port2 se estiver em um cenário de espera.
Para acessar as exibições de um projeto em um computador servidor remoto, o parâmetro /ip1 deve ter o endereço IP do servidor ou o nome do computador remoto. Mesmo que o parâmetro seja chamado de "Ip1", ele aceita o nome do computador na rede, desde que sua rede tenha um serviço DNS habilitado.
Para criar o atalho do Windows, você pode seguir as etapas em:
Quando você vê o espaço reservado em <IP_address> linhas de comando ou URLs, ele sempre pode ser substituído pelo Nome do Computador em uma rede, desde que os serviços DNS estejam habilitados.
Iniciando as interfaces do Monitor de Módulo
Quando você inicia o aplicativo no modo de usuário, você tem o aplicativo TStartup.exe, que mostra uma página de diálogo com todos os módulos em execução, e você pode iniciar e parar os módulos individualmente usando essa interface. O aplicativo não fica visível quando o servidor de projeto (o aplicativo TServer) é iniciado como um Windows Server.
Se você quiser acessar a mesma interface ao executar como um serviço, será necessário iniciar o PropertyWatch.exe localizado na pasta de instalação do Action.NET (normalmente c:\Arquivos de Programas (x86)\Spin\Action.NET\an-9.2\PropertyWatch.exe).
Ao executar como um serviço, você precisa definir os parâmetros /ip1 e /port1 com o nome do computador ou com o IP do computador. A configuração padrão não permitirá uma conexão nesse caso. Você pode definir os outros parâmetros opcionais, como /username. Ex.: "C:\Arquivos de Programas (x86)\Spin\Action.Net\an-9.2\PropertyWatch.exe" /ip1:W10-VS /nome de usuário: Administrador
Outra maneira de iniciar essas ferramentas é abrir a configuração do projeto, Executar inicialização e pressionar o botão de conexão. Isso habilitará um botão nessa caixa de diálogo que abrirá as Ferramentas de monitoramento.
Nesta página: