Capítulo 6. Clusterização

Quando clusterizando o Red Hat JBoss BPM Suite, considere quais componentes precisam ser clusterizados. Segue uma lista do que pode ser clusterizado:
  • O Repositório GIT: repositório do sistema de arquivos virtual (em inglês, virtual-file-system - VFS) que retém os ativos de negócios para que todos os nós do cluster utilizem o mesmo repositório.
  • O Servidor de Execução e os Aplicativos Web: servidor de tempo de execução que reside no contêiner (como o Red Hat JBoss EAP) junto com os aplicativos web do Red Hat JBoss BRMS e Red Hat JBoss BPM Suite para que os nós compartilhem os mesmos dados de tempo de execução.
    Para instruções sobre como clusterizar o aplicativo, consulte a documentação de clusterização de contêineres.
  • O Banco de Dados Back-end: banco de dados com dados de estados, tais como, instâncias de processos, sessões KIE, log do histórico, etc., com finalidade de failover.
Esquema do Sistema do Red Hat JBoss BPM Suite com Componentes de Sistemas Individuais

Figura 6.1. Esquema do Sistema do Red Hat JBoss BPM Suite com Componentes de Sistemas Individuais

Mecanismo de Clusterização do Repositório GIT

Para clusterizar o repositório GIT, usa-se o seguinte:
  • Apache Zookeeper, que reúne todas as partes.
  • Apache Helix, componente de gerenciamento do cluster que registra todos os detalhes do cluster (o cluster em si, os nós e os recursos).
O ambiente de tempo de execução, que é o Servidor de Execução, utiliza o seguinte para fornecer as capacidades de clusterização:
  • uberfire framework, que fornece o suporte principal dos aplicativos web.
Esquema de clusterização com Helix e Zookeeper

Figura 6.2. Esquema de clusterização com Helix e Zookeeper

Uma configuração típica de clusterização envolve o seguinte:
  • Configurar o próprio cluster, usando Zookeeper e Helix
  • Configurar o banco de dados back-end com configuração e tabelas do Quartz
  • Configurar a clusterização no seu contêiner (essa documentação fornece instruções de clusterização apenas para o Red Hat JBoss EAP 6)

Clusterizando os Repositórios do Maven

Várias operações dentro do Business Central publicam JARs no repositório do Maven interno no Business Central.
Esse repositório existe no sistema de arquivos do servidor do aplicativo como arquivos comuns e não oferece suporte a clusters. Esta pasta não é sincronizada através dos vários nós no cluster e deve ser sincronizada utilizando ferramentas externas como a rsync.
Uma alternativa ao uso de ferramentas externas de sincronização é definir a propriedade do sistema org.guvnor.m2repo.dir em cada nó do cluster, apontando para um SAN ou NAS. Nesse caso, a clusterização da pasta do repositório do Maven não é necessária.

6.1. Clusterização no JBoss EAP

Para instalar o Red Hat JBoss BPM Suite no modo clusterizado, recomendamos que utilize o instalador JAR, que fornece uma configuração padrão de amostra. Porém, você também pode configurar a clusterização com o ZIP implantável para EAP.

6.1.1. Clusterização Utilizando o Instalador JAR

Nota

O instalador JAR fornece somente uma amostra de configuração, é necessário ajustar as configurações para que atenda às necessidades do seu projeto.
Ao usar o instalador JAR descrito na Seção 2.1, “Instalação do Red Hat JBoss BPM Suite através do Instalador”, você pode definir uma configuração de clusterização básica do Red Hat JBoss BPM Suite.
A configuração automática cria três instâncias ZooKeeper, um cluster Helix que utiliza essas instâncias e dois datastores do Quartz (um gerenciado e outro não gerenciado). Esta configuração do Red Hat JBoss BPM Suite consiste em dois nós EAP que compartilham um repositório do Maven, utilizam o Quartz para coordenar tarefas cronometradas e têm business-central.war, dashbuilder.war e kie-server.war implantados. Para personalizar a configuração para adaptar ao seu cenário, ou para utilizar a clusterização com o ZIP implantável, consulte a Seção 6.1.2, “Configuração Personalizada (ZIP Implantável)”. Você também pode obter mais informações através da documentação do JBoss EAP.
Siga o processo de instalação descrito na Seção 2.1.1, “Instalando Red Had JBoss BPM Suite Usando o Instalador” e selecione Instalar configurações clusterizadas em Configuração de Tempo de Execução Avançada. Depois de clicar em próximo, você irá percorrer as seguintes etapas. :

Nota

As etapas listadas aqui descrevem a instalação com GUI. As etapas para a instalação do console são análogas.
  1. Selecione o fornecedor do JDBC

    Nesta tela, selecione o fornecedor do JDBC através da lista. Você precisa fornecer o(s) JAR(s) correspondente(s) ao driver JDBC em uma destas formas:
    • Selecione um ou mais arquivos no sistema de arquivos
    • Forneça um ou mais URLs. O instalador baixa os arquivos automaticamente.
    Em seguida, o instalador copia o(s) JAR(s) em uma localização apropriada abaixo do diretório $EAP_HOME/modules, onde um arquivo module.xml correspondente também foi criado automaticamente.
    Configure JDBC provider and drivers

    Figura 6.3. Configuração do Driver JDBC

  2. Configure a conexão do Quartz

    Na próxima tela, forneça os dados ao banco de dados para o Quartz. O instalador automaticamente cria o arquivo de definição do Quartz ($EAP_HOME/domain/configuration/quartz-definition.properties) e duas fontes de dados do Quartz no arquivo de configuração de domínio $EAP_HOME/domain/domain.xml. Você pode editar os arquivos após concluir a instalação.

    Nota

    Durante a instalação, os scripts DDL do Quartz serão executados no banco de dados selecionado nesta etapa. Esses scripts fazem mudanças necessárias para que o Quartz opere (adicionando tabelas, etc.) e podem ser encontrados em $EAP_HOME/jboss-brms-bpmsuite-6.2-supplementary-tools/ddl-scripts para referência (Você não precisa modificá-los).
    Configure database connections

    Figura 6.4. Configuração do Banco de Dados do Quartz

  3. Clique em próximo para iniciar a instalação.

    Importante

    Ao utilizar o instalador JAR, os arquivos war serão criados automaticamente a partir dos aplicativos que residem em $EAP_HOME/standalone/deployments/. Isto significa que é necessário um espaço adicional, já que os aplicativos existem tanto em estado compactado quanto descompactado no armazenamento durante a instalação.
    Três instâncias ZooKeeper são criadas automaticamente em $EAP_HOME/jboss-brms-bpmsuite-6.3-supplementary-tools/ (nomes de diretório zookeeper-one, zookeeper-two e zookeeper-three).
    No diretório $EAP_HOME/jboss-brms-bpmsuite-6.3-supplementary-tools/helix-core, você pode encontrar a configuração Helix padrão e os scripts para iniciar o cluster—startCluster.sh para UNIX e startCluster.bat para Windows.
    Após concluir a instalação, NÃO selecione executar o servidor imediatamente. Primeiro, você precisa iniciar o cluster mudando para o diretório $EAP_HOME/jboss-brms-bpmsuite-6.3-supplementary-tools/helix-core e executando o script de inicialização mencionado:
    Nos sistemas UNIX:
    ./startCluster.sh
    No Windows:
    ./startCluster.bat
    Este script inicializa o cluster Helix e as intâncias ZooKeeper. Somente depois disto, inicie o servidor EAP no modo de domínio, movendo para o diretório $EAP_HOME/bin e executando:
    Nos sistemas UNIX:
    ./domain.sh
    No Windows:
    ./domain.bat
Você tem agora um cluster do Red Hat JBoss BPM Suite em pleno funcionamento.

6.1.2. Configuração Personalizada (ZIP Implantável)

Quando utilizar a clusterização JBoss EAP, existe um único controlador de domínio do JBoss EAP com os outros subordinados do JBoss EAP conectando-se a ele como usuários de gerenciamento. A implantação do Business Central e do Dashbuilder pode ser feita como um usuário de gerenciamento em um controlador de domínio e as implantações WAR serão distribuídas a outros membros do cluster do JBoss EAP.
Para configurar a clusterização no Red Hat JBoss EAP 6, siga as instruções a seguir:
  1. Configure o Zookeeper e Helix de acordo com a Seção 6.2.1, “Configurando um Cluster”.
  2. Configure o Quartz de acordo com a Seção 6.2.2, “Configurando o Quartz”.
  3. Instale o seu driver JDBC como um módulo principal: copie o driver jar em $EAP_HOME/modules/system/layers/base/ e crie um arquivo module.xml no diretório.
  4. Edite o arquivo module.xml a partir do respectivo módulo XSD.

    Exemplo 6.1. Conteúdo do Arquivo module.xml para a Fonte de Dados PostgreSQL

    <module xmlns="urn:jboss:module:1.0" name="org.postgresql">
    	  <resources>
    		<resource-root path="postgresql-jdbc.jar"/>
    	  </resources>
    
    	  <dependencies>
    		<module name="javax.api"/>
    		<module name="javax.transaction.api"/>
    	  </dependencies>
    	</module>
    
  5. Configure a fonte de dados para o servidor: abra para edição o arquivo host.xml ou standalone.xml, dependendo do PERFIL utilizado localizado no $EAP_HOME/PROFILE/, localize o perfil full e siga as instruções a seguir:
    1. Adicione a definição da fonte de dados principal usada pelo Red Hat JBoss BPM Suite.

      Exemplo 6.2. Fonte de Dados PostgreSQL Definida como a Fonte de Dados Principal do Red Hat JBoss BPM Suite

      <datasource jndi-name="java:jboss/datasources/psbpmsDS"
      					pool-name="postgresDS" enabled="true" use-java-context="true">
      	  <connection-url>jdbc:postgresql://localhost:5432/jbpm</connection-url>
      	  <driver>postgres</driver>
      	  <security>
      		<user-name>bpms</user-name>
      		<password>bpms</password>
      		</security>
      	</datasource>
    2. Adicione a definição da fonte de dados para o serviço Quartz.

      Exemplo 6.3. Fonte de Dados PostgreSQL Definida como a Fonte de Dados do Quartz

      <datasource jta="false" jndi-name="java:jboss/datasources/quartzNotManagedDS"
      			   pool-name="quartzNotManagedDS" enabled="true" use-java-context="true">
      		<connection-url>jdbc:postgresql://localhost:5432/jbpm</connection-url>
      	  <driver>postgres</driver>
      	  <security>
      		<user-name>bpms</user-name>
      		<password>bpms</password>
      	  </security>
      	</datasource>
    3. Defina o driver da fonte de dados.

      Exemplo 6.4. Definição do Driver PostgreSQL

       <driver name="postgres" module="org.postgresql">
      	  <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
      	</driver>
  6. Configure os nós individuais do servidor no elemento main-server-group no arquivo $EAP_HOME/domain/configuration/host.xml com propriedades definidas na Tabela 6.1, “Propriedades dos Nós de Cluster ”:
    Observe que, ao configurar um cluster do JBoss EAP com o ZooKeeper, é possível haver uma diferença entre o número de nós do JBoss EAP e do ZooKeeper (lembrando que o ZooKeeper deve ter um número ímpar de nós). No entanto, é preferível ter o mesmo número de nós tanto no ZooKeeper quanto no JBoss EAP.

    Tabela 6.1. Propriedades dos Nós de Cluster

    Nome das propriedadesValorDescrição
    jboss.node.namenodeOne
    Nome de nó exclusivo dentro do cluster
    org.quartz.properties/bpms/quartz-definition.properties
    Caminho absoluto para o arquivo de configuração do Quartz
    org.uberfire.cluster.idbpms-cluster
    Nome do cluster do Helix
    org.uberfire.cluster.local.idnodeOne_12345
    ID exclusiva de nó do cluster do Helix.
    Observe que : é substituído por _.
    org.uberfire.cluster.vfs.lockvfs-repo
    Nome do recurso definido no cluster do Helix
    org.uberfire.cluster.zkserver1:2181
    Localização do ZooKeeper
    org.uberfire.metadata.index.dir/home/jbpm/node[N]/index
    Local onde o index para pesquisa será criado (mantido pelo Apache Lucene)
    org.uberfire.nio.git.daemon.hostnodeOneNome da máquina hospedeira daemon em um cluster físico.
    org.uberfire.nio.git.daemon.port9418
    Porta usada pelo repositório VFS para aceitar as conexões do cliente
    A porta precisa ser exclusiva para cada membro do cluster.
    org.uberfire.nio.git.dir/home/jbpm/node[N]/repo
    Localização do repositório (VFS) GIT no nó[N]
    org.uberfire.nio.git.ssh.hostnodeOneNome da máquinha hospedeira SSH em um cluster físico.
    org.uberfire.nio.git.ssh.port8003Número de porta exclusivo para acesso ssh ao repo GIT para um cluster em execução nas máquinas físicas.
    org.uberfire.nio.git.ssh.hostport and org.uberfire.nio.git.daemon.hostport8003 and 9418Porta externa a ser usada em um ambiente virtualizado.

    Exemplo 6.5. Configuração do Cluster de Nó 1 (nodeOne)

    <system-properties>
    
    	  <property name="org.uberfire.nio.git.dir" value="/tmp/bpms/nodeone" boot-time="false"/>
    	  <property name="jboss.node.name" value="nodeOne" boot-time="false"/>
    
    	  <property name="org.uberfire.cluster.id" value="bpms-cluster" boot-time="false"/>
    	  <property name="org.uberfire.cluster.zk" value="server1:2181,server2:2181,server3:2181" boot-time="false"/>
    	  <property name="org.uberfire.cluster.local.id" value="nodeOne_12345" boot-time="false"/>
    	  <property name="org.uberfire.cluster.vfs.lock" value="vfs-repo" boot-time="false"/>
    
    
    	  <property name="org.uberfire.nio.git.daemon.host" value="nodeOne" />
    	  <property name="org.uberfire.nio.git.daemon.port" value="9418" boot-time="false"/>
    	  <property name="org.uberfire.nio.git.daemon.hostport" value="9418" boot-time="false"/>
    
    	  <property name="org.uberfire.nio.git.ssh.port" value="8003" boot-time="false"/>
    	  <property name="org.uberfire.nio.git.ssh.hostport" value="8003" boot-time="false"/>
    	  <property name="org.uberfire.nio.git.ssh.host" value="nodeOne" />
    
    	  <property name="org.uberfire.metadata.index.dir" value="/tmp/jbpm/nodeone" boot-time="false"/>
    	  <property name="org.uberfire.nio.git.ssh.cert.dir" value="/tmp/jbpm/nodeone" boot-time="false"/>
    
    	  <property name="org.quartz.properties" value="/tmp/jbpm/quartz/quartz-db-postgres.properties" boot-time="false"/>
    
    	</system-properties>

    Exemplo 6.6. Configuração do Cluster de Nó 2 (nodeTwo)

    <system-properties>
    
    	  <property name="org.uberfire.nio.git.dir" value="/tmp/bpms/nodetwo" boot-time="false"/>
    	  <property name="jboss.node.name" value="nodeTwo" boot-time="false"/>
    
    	  <property name="org.uberfire.cluster.id" value="bpms-cluster" boot-time="false"/>
    	  <property name="org.uberfire.cluster.zk" value="server1:2181,server2:2181,server3:2181" boot-time="false"/>
    	  <property name="org.uberfire.cluster.local.id" value="nodeTwo_12346" boot-time="false"/>
    	  <property name="org.uberfire.cluster.vfs.lock" value="vfs-repo" boot-time="false"/>
    
    
    	  <property name="org.uberfire.nio.git.daemon.host" value="nodeTwo" />
    	  <property name="org.uberfire.nio.git.daemon.port" value="9418" boot-time="false"/>
    	  <property name="org.uberfire.nio.git.daemon.hostport" value="9418" boot-time="false"/>
    
    	  <property name="org.uberfire.nio.git.ssh.port" value="8003" boot-time="false"/>
    	  <property name="org.uberfire.nio.git.ssh.hostport" value="8003" boot-time="false"/>
    	  <property name="org.uberfire.nio.git.ssh.host" value="nodeTwo" />
    
    	  <property name="org.uberfire.metadata.index.dir" value="/tmp/jbpm/nodetwo" boot-time="false"/>
    	  <property name="org.uberfire.nio.git.ssh.cert.dir" value="/tmp/jbpm/nodetwo" boot-time="false"/>
    
    	  <property name="org.quartz.properties" value="/tmp/jbpm/quartz/quartz-db-postgres.properties" boot-time="false"/>
    
    
    	</system-properties>

    Exemplo 6.7. Configuração do Cluster de Nó 3 (nodeThree)

    <system-properties>
    
    	  <property name="org.uberfire.nio.git.dir" value="/tmp/bpms/nodethree" boot-time="false"/>
    	  <property name="jboss.node.name" value="nodeThree" boot-time="false"/>
    
    	  <property name="org.uberfire.cluster.id" value="bpms-cluster" boot-time="false"/>
    	  <property name="org.uberfire.cluster.zk" value="server1:2181,server2:2181,server3:2181" boot-time="false"/>
    	  <property name="org.uberfire.cluster.local.id" value="nodeThree_12347" boot-time="false"/>
    	  <property name="org.uberfire.cluster.vfs.lock" value="vfs-repo" boot-time="false"/>
    
    
    	  <property name="org.uberfire.nio.git.daemon.host" value="nodeThree" />
    	  <property name="org.uberfire.nio.git.daemon.port" value="9418" boot-time="false"/>
    	  <property name="org.uberfire.nio.git.daemon.hostport" value="9418" boot-time="false"/>
    
    	  <property name="org.uberfire.nio.git.ssh.port" value="8003" boot-time="false"/>
    	  <property name="org.uberfire.nio.git.ssh.hostport" value="8003" boot-time="false"/>
    	  <property name="org.uberfire.nio.git.ssh.host" value="nodeThree" />
    
    	  <property name="org.uberfire.metadata.index.dir" value="/tmp/jbpm/nodethree" boot-time="false"/>
    	  <property name="org.uberfire.nio.git.ssh.cert.dir" value="/tmp/jbpm/nodethree" boot-time="false"/>
    
    	  <property name="org.quartz.properties" value="/tmp/jbpm/quartz/quartz-db-postgres.properties" boot-time="false"/>
    
    
    	</system-properties>
  7. Adicione os usuários de gerenciamento, como instruído no guia Administration and Configuration Guide do Red Hat JBoss EAP, e os usuários do aplicativo, como instruído no guia Red Hat JBoss BPM Suite Administration and Configuration Guide.
  8. Mova para o diretório $EAP_HOME/bin e inicie o servidor do aplicativo no modo de domínio:
    Nos sistemas UNIX:
    ./domain.sh
    No Windows:
    ./domain.bat
  9. Verifique se os nós estão disponíveis.
Implante o aplicativo Business Central nos seus servidores:
  1. Mude a persistência predefinida do aplicativo para o banco de dados solicitado (PostgreSQL): em persistence.xml, mude o seguinte:
    1. O nome da fonte de dados jta para a fonte definida no servidor do aplicativo (java:jboss/datasources/psbpmsDS)
    2. Hiberne o dialeto para corresponder ao dialeto da fonte de dados (org.hibernate.dialect.PostgreSQLDialect)
  2. Faça o logon como o usuário de gerenciamento no console de administração do servidor do seu domínio e adicione as novas implantações utilizando o modo de exibição Runtime do console. Depois que a implantação for adicionada ao domínio, atribua-a ao grupo de servidores correto (main-server-group).

Nota

É importante que os usuários verifiquem explicitamente a prontidão da unidade de implantação em cada membro do cluster.
Quando uma unidade de implantação é criada em um nó de cluster, leva-se algum tempo até que ela seja distribuída entre todos os membros do cluster. O status da implantação pode ser verificado via IU e REST, no entanto, caso a consulta chegue ao nó onde a implantação foi emitida originalmente, a resposta será - deployed (implantada). Qualquer solicitação com foco nessa unidade de implantação enviada a um membro de cluster diferente obterá falhas com DeploymentNotFoundException.