Red Hat Summit Red Hat SummitSuporteConsoleDesenvolvedoresComeçar um testeContato

Capítulo 6. Clusterizando

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 empresariais 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 BRMS e 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 Red Hat JBoss BPM Suite com Componentes de Sistemas Individuais

Figura 6.1. Esquema do Sistema 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.
Description

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 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 nos vários nós no cluster e deve ser sincronizada utilizando ferramentas externas como a rsync.
Uma alternativa ao uso de ferramentas de sincronização externas é 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
Copiar o link

Para instalar JBoss BPM Suite no modo cluster, recomendamos que utilize o instalador JAR, que fornece uma amostra de configuração que funciona por padrão. Porém, você também pode definir clusterização com um ZIP implantável para EAP.

6.1.1. Clusterização utilizando instalador JAR
Copiar o link

Nota

O instalador JAR fornece somente amostra de configuração, é necessário ajustar as configurações para que atenda às necessidades do seu projeto.
Utilizando o instalador JAR descrito no Seção 2.1, “Instalação do Instalador Red Hat JBoss BPM Suite”, você pode estabelecer uma configuração de clusterização básica de JBoss BPM Suite.
A configuração automática cria três instâncias ZooKeeper, uma cluster Helix que utiliza essas instâncias, e dois datastores Quartz (um gerenciado e outro não gerenciado). Esta configuração JBoss BPM Suite consiste em dois nós EAP que compartilham um repositório do Maven, utilize Quartz para coordenar tarefas cronometradas, e tenha implantados business-central.war, dashbuilder.war, e kie-server.war . Para personalizar a configuração para adaptar ao seu cenário, ou para utilizar clusterização com ZIP implantável, consulte o Seção 6.1.2, “Configuração Personalizada (ZIP Implantável)”. Você pode também obter mais informações no JBoss EAP documentation.
Siga o processo de instalação descrito em 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 avançar, 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 fornecedor JDBC

    Nesta tela, selecione o fornecedor JDBC da lista. Você precisa fornecer os JARs drivers JDBC correspondentes em uma destas formas:
    • Selecione um ou mais arquivos no sistema de arquivos
    • Forneça uma 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 JDBC Driver

  2. Configurar conexão Quartz

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

    Nota

    Durante a instalação, scripts do DDL Quartz serão executados no banco de dados selecionado nesta etapa. Estes 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 de nenhuma forma).
    Configure database connections

    Figura 6.4. Configuração de banco de dados Quartz

  3. Clique em next para iniciar a instalação.

    Importante

    Quando utilizar o instalador JAR, os arquivos war são automaticamente criados dos aplicativos que residem em $EAP_HOME/standalone/deployments/. Isto significa que é necessário espaço adicional conforme os aplicativos existam em ambos os estados compactado e descompactado no armazenamento durante a instalação.
    Três instâncias ZooKeeper são criadas automaticamente em $EAP_HOME/jboss-brms-bpmsuite-6.2-supplementary-tools/ (directory names zookeeper-one, zookeeper-two, e zookeeper-three).
    No diretório $EAP_HOME/jboss-brms-bpmsuite-6.2-supplementary-tools/helix-core, você pode encontrar configuração Helix padrão e scripts para iniciar o cluster—startCluster.sh para UNIX e startCluster.bat para Windows.
    Depois de finalizada 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.2-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 JBoss BPM Suite cluster em pleno funcionamento.

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

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. Configurar Zookeeper e Helix de acordo com Seção 6.2.1, “Configurando um Cluster”.
  2. Configurar Quartz de acordo com 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 uma 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. Configurar a fonte de dados para o servidor: abra para edição o arquivo host.xml ou standalone.xml, dependendo do PERFIL utilizado que está localizado no$EAP_HOME/PROFILE/, localize o perfil completo e siga as instruções a seguir:
    1. Adicione a definição da fonte de dados principal usada pelo JBoss BPM Suite.

      Exemplo 6.2. A fonte de dados PostgreSQL definida como a fonte de dados JBoss BPM Suite principal 

      <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. Adicionar a definição da fonte de dados para o serviço Quartz.

      Exemplo 6.3. A fonte de dados PostgreSQL definida como a fonte de dados 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. Definir 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 de servidores individuais no main-server-group element in the $EAP_HOME/domain/configuration/host.xml arquivo com propriedades definidas 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, é considerada a melhor prática ter a mesma contagem de nós tanto para o ZooKeeper quanto para o JBoss EAP.
    Expand
    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 Quartz
    org.uberfire.cluster.autostarttrue
    Este valor atrasa a clusterização VFS até que o aplicativo seja completamente inicializado, evitando conflitos quando todos os membros do cluster criam clones locais.
    org.uberfire.cluster.idbpms-cluster
    Nome do cluster do Helix
    org.uberfire.cluster.local.idnodeOne_12345
    ID exclusiva do nó do cluster do Helix.
    Observe que : é substituído por _.
    org.uberfire.cluster.vfs.lockvfs-repo
    Nome do recurso definido no cluster 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.cluster.autostart" value="true" boot-time="true"/>
	  
	  <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.cluster.autostart" value="true" boot-time="true"/>
	  
	  <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.cluster.autostart" value="true" boot-time="true"/>
	  
	  <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, conforme instruído no guia Administration and Configuration Guide do Red Hat JBoss EAP e os usuários do aplicativo, conforme 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. hibernar 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 de 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á implantada - deployed. Qualquer solicitação direcionando essa unidade de implantação enviada a um membro de cluster diferente falha com DeploymentNotFoundException.
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Legal Notice

Theme

© 2026 Red HatVoltar ao topo