Alta disponibilità del database per Camunda BPM utilizzando MySQL o MariaDB Galera Cluster

Camunda BPM è una piattaforma open source di automazione del flusso di lavoro e delle decisioni. Camunda BPM viene fornito con strumenti per la creazione di flussi di lavoro e modelli decisionali, per il funzionamento dei modelli distribuiti in produzione e per consentire agli utenti di eseguire le attività del flusso di lavoro loro assegnate.

Per impostazione predefinita, Camunda viene fornito con un database incorporato chiamato H2, che funziona abbastanza decentemente all'interno di un ambiente Java con un footprint di memoria relativamente piccolo. Tuttavia, quando si tratta di scalabilità e disponibilità elevata, esistono altri backend di database che potrebbero essere più appropriati.

In questo post del blog, implementeremo Camunda BPM 7.10 Community Edition su Linux, con l'obiettivo di ottenere un'elevata disponibilità del database. Camunda supporta i principali database tramite driver JDBC, ovvero Oracle, DB2, MySQL, MariaDB e PostgreSQL. Questo blog si concentra solo su MySQL e MariaDB Galera Cluster, con diverse implementazioni su ciascuno:uno con ProxySQL come servizio di bilanciamento del carico del database e l'altro che utilizza il driver JDBC per connettersi a più istanze di database. Tieni presente che questo articolo non copre l'alta disponibilità per l'applicazione Camunda stessa.

Prerequisito

Camunda BPM funziona su Java. Nella nostra scatola CentOS 7, dobbiamo installare JDK e l'opzione migliore è usare quella di Oracle e saltare usando i pacchetti OpenJDK forniti nel repository. Sul server delle applicazioni su cui deve essere eseguito Camunda, scarica l'ultimo Java SE Development Kit (JDK) da Oracle inviando il cookie di accettazione:

$ wget --header "Cookie: oraclelicense=accept-securebackup-cookie" https://download.oracle.com/otn-pub/java/jdk/12+33/312335d836a34c7c8bba9d963e26dc23/jdk-12_linux-x64_bin.rpm

Installalo sull'host:

$ yum localinstall jdk-12_linux-x64_bin.rpm

Verifica con:

$ java --version
java 12 2019-03-19
Java(TM) SE Runtime Environment (build 12+33)
Java HotSpot(TM) 64-Bit Server VM (build 12+33, mixed mode, sharing)

Crea una nuova directory e scarica Camunda Community per Apache Tomcat dalla pagina di download ufficiale:

$ mkdir ~/camunda
$ cd ~/camunda
$ wget --content-disposition 'https://camunda.org/release/camunda-bpm/tomcat/7.10/camunda-bpm-tomcat-7.10.0.tar.gz'

Estrailo:

$ tar -xzf camunda-bpm-tomcat-7.10.0.tar.gz

Ci sono un certo numero di dipendenze che dobbiamo configurare prima di avviare l'applicazione web Camunda. Ciò dipende dalla piattaforma di database scelta come la configurazione del datastore, il connettore del database e l'ambiente CLASSPATH. Le sezioni successive spiegano i passaggi necessari per MySQL Galera (usando Percona XtraDB Cluster) e MariaDB Galera Cluster.

Si noti che le configurazioni mostrate in questo blog sono basate sull'ambiente Apache Tomcat. Se stai usando JBOSS o Wildfly, la configurazione del datastore sarà leggermente diversa. Fare riferimento alla documentazione di Camunda per i dettagli.

MySQL Galera Cluster (con ProxySQL e Keepalived)

Utilizzeremo ClusterControl per distribuire il cluster Galera basato su MySQL con Percona XtraDB Cluster. Ci sono alcune limitazioni relative a Galera menzionate nei documenti Camunda che circondano la gestione dei conflitti multi-scrittore di Galera e il livello di isolamento di InnoDB. Nel caso in cui ne siate interessati, il modo più sicuro è utilizzare l'approccio a scrittore singolo, ottenibile con la configurazione del gruppo host ProxySQL. Per non fornire un singolo punto di errore, distribuiremo due istanze ProxySQL e le legheremo a un indirizzo IP virtuale tramite Keepalived.

Il diagramma seguente illustra la nostra architettura finale:

Innanzitutto, distribuire un Percona XtraDB Cluster 5.7 a tre nodi. Installare ClusterControl, generare una chiave SSH e configurare SSH senza password dall'host ClusterControl a tutti i nodi (incluso ProxySQL). Sul nodo ClusterControl, eseguire:

$ whoami
root
$ ssh-keygen -t rsa
$ for i in 192.168.0.21 192.168.0.22 192.168.0.23 192.168.0.11 192.168.0.12; do ssh-copy-id $i; done

Prima di distribuire il nostro cluster, dobbiamo modificare il file del modello di configurazione MySQL che ClusterControl utilizzerà durante l'installazione dei server MySQL. Il nome del file modello è my57.cnf.galera e si trova in /usr/share/cmon/templates/ sull'host ClusterControl. Assicurati che le seguenti righe siano presenti nella sezione [mysqld]:

[mysqld]
...
transaction-isolation=READ-COMMITTED
wsrep_sync_wait=7
...

Salva il file e siamo a posto. Quanto sopra sono i requisiti come indicato nei documenti di Camunda, in particolare sull'isolamento delle transazioni supportato per Galera. La variabile wsrep_sync_wait è impostata su 7 per eseguire controlli di causalità a livello di cluster per le istruzioni READ (inclusi SELECT, SHOW e BEGIN o START TRANSACTION), UPDATE, DELETE, INSERT e REPLACE, assicurando che l'istruzione venga eseguita su un nodo completamente sincronizzato. Tieni presente che un valore diverso da 0 può comportare un aumento della latenza.

Vai a ClusterControl -> Distribuisci -> MySQL Galera e specificare i seguenti dettagli (se non menzionati, utilizzare il valore predefinito):

• Utente SSH:root
• Percorso chiave SSH:/root/.ssh/id_rsa
• Nome cluster:Percona XtraDB Cluster 5.7
• Venditore:Percona
• Versione:5.7
• Password amministratore/root:{specificare una password}
• Aggiungi nodo:192.168.0.21 (premi Invio), 192.168.0.22 (premi Invio), 192.168.0.23 (premi Invio)

Assicurati di avere tutti i segni di spunta verdi, che indicano che ClusterControl è in grado di connettersi al nodo senza password. Fai clic su "Distribuisci" per avviare la distribuzione.

Crea il database, l'utente MySQL e la password su uno dei nodi del database:

mysql> CREATE DATABASE camunda;
mysql> CREATE USER [email protected]'%' IDENTIFIED BY 'passw0rd';
mysql> GRANT ALL PRIVILEGES ON camunda.* TO [email protected]'%';

Oppure dall'interfaccia ClusterControl, puoi usare Gestisci -> Schema e Utenti invece:

Una volta distribuito il cluster, installa ProxySQL andando su ClusterControl -> Gestisci -> Load Balancer -> ProxySQL -> Distribuisci ProxySQL e inserisci i seguenti dettagli:

• Indirizzo server:192.168.0.11
• Password di amministrazione:
• Password monitor:
• Utente DB:camunda
• Password DB:passw0rd
• Stai utilizzando transazioni implicite?:Sì

Ripetere il passaggio di distribuzione di ProxySQL per la seconda istanza di ProxySQL, modificando l'Indirizzo del server valore a 192.168.0.12. L'indirizzo IP virtuale fornito da Keepalived richiede almeno due istanze ProxySQL distribuite e in esecuzione. Infine, distribuisci l'indirizzo IP virtuale andando su ClusterControl -> Gestisci -> Load Balancer -> Keepalived e scegli entrambi i nodi ProxySQL e specifica l'indirizzo IP virtuale e l'interfaccia di rete per l'ascolto del VIP:

Il nostro database backend è ora completo. Quindi, importa i file SQL nel cluster Galera come utente MySQL creato. Sul server delle applicazioni, vai alla directory "sql" e importali in uno dei nodi Galera (scegliamo 192.168.0.21):

$ cd ~/camunda/sql/create
$ yum install mysql #install mysql client
$ mysql -ucamunda -p -h192.168.0.21 camunda < mysql_engine_7.10.0.sql
$ mysql -ucamunda -p -h192.168.0.21 camunda < mysql_identity_7.10.0.sql

Camunda non fornisce il connettore MySQL per Java poiché il suo database predefinito è H2. Sul server delle applicazioni, scarica MySQL Connector/J dalla pagina di download di MySQL e copia il file JAR nella directory bin di Apache Tomcat:

$ wget https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-8.0.15.tar.gz
$ tar -xzf mysql-connector-java-8.0.15.tar.gz
$ cd mysql-connector-java-8.0.15
$ cp mysql-connector-java-8.0.15.jar ~/camunda/server/apache-tomcat-9.0.12/bin/

Quindi, impostare la variabile di ambiente CLASSPATH per includere il connettore del database. Apri setenv.sh usando l'editor di testo:

$ vim ~/camunda/server/apache-tomcat-9.0.12/bin/setenv.sh

E aggiungi la seguente riga:

export CLASSPATH=$CLASSPATH:$CATALINA_HOME/bin/mysql-connector-java-8.0.15.jar

Apri ~/camunda/server/apache-tomcat-9.0.12/conf/server.xml e modifica le righe relative al datastore. Specificare l'indirizzo IP virtuale come host MySQL nella stringa di connessione, con la porta ProxySQL 6033:

<Resource name="jdbc/ProcessEngine"
              ...
              driverClassName="com.mysql.jdbc.Driver" 
              defaultTransactionIsolation="READ_COMMITTED"
              url="jdbc:mysql://192.168.0.10:6033/camunda"
              username="camunda"  
              password="passw0rd"
              ...
/>

Infine, possiamo avviare il servizio Camunda eseguendo start-camunda.sh sceneggiatura:

$ cd ~/camunda
$ ./start-camunda.sh
starting camunda BPM platform on Tomcat Application Server
Using CATALINA_BASE:   ./server/apache-tomcat-9.0.12
Using CATALINA_HOME:   ./server/apache-tomcat-9.0.12
Using CATALINA_TMPDIR: ./server/apache-tomcat-9.0.12/temp
Using JRE_HOME:        /
Using CLASSPATH:       :./server/apache-tomcat-9.0.12/bin/mysql-connector-java-8.0.15.jar:./server/apache-tomcat-9.0.12/bin/bootstrap.jar:./server/apache-tomcat-9.0.12/bin/tomcat-juli.jar
Tomcat started.

Assicurati che CLASSPATH mostrato nell'output includa il percorso del file JAR MySQL Connector/J. Al termine dell'inizializzazione, puoi accedere alle webapp di Camunda sulla porta 8080 all'indirizzo http://192.168.0.8:8080/camunda/ . Il nome utente predefinito è demo con password 'demo':

È quindi possibile visualizzare le query di acquisizione digerite da Nodi -> ProxySQL -> Query principali , indicando che l'applicazione sta interagendo correttamente con il Galera Cluster:

Non è stata configurata alcuna suddivisione in lettura/scrittura per ProxySQL. Camunda utilizza "SET autocommit=0" su ogni istruzione SQL per inizializzare la transazione e il modo migliore per ProxySQL di gestirlo inviando tutte le query agli stessi server back-end dell'hostgroup di destinazione. Questo è il metodo più sicuro insieme a una migliore disponibilità. Tuttavia, tutte le connessioni potrebbero finire per raggiungere un unico server, quindi non c'è bilanciamento del carico.

MariaDB Galera

MariaDB Connector/J è in grado di gestire una varietà di modalità di connessione - failover, sequenziale, replica e aurora - ma Camunda supporta solo failover e sequenziale. Tratto dalla documentazione di MariaDB Connector/J:

jdbc:mariadb:sequential:host1,host2,host3/testdb

L'uso della modalità "failover" comporta un rischio potenziale di deadlock più elevato, poiché le scritture verranno distribuite a tutti i server back-end in modo quasi uguale. L'approccio a scrittore singolo è un modo sicuro per l'esecuzione, il che significa che l'uso della modalità sequenziale dovrebbe fare il lavoro abbastanza bene. Puoi anche saltare il livello di bilanciamento del carico nell'architettura. Quindi, con il connettore Java MariaDB, possiamo distribuire la nostra architettura nel modo seguente:

Prima di distribuire il nostro cluster, modificare il file del modello di configurazione di MariaDB che ClusterControl utilizzerà durante l'installazione dei server MariaDB. Il nome del file del modello è my.cnf.galera e si trova in /usr/share/cmon/templates/ sull'host ClusterControl. Assicurati che le seguenti righe siano presenti nella sezione [mysqld]:

[mysqld]
...
transaction-isolation=READ-COMMITTED
wsrep_sync_wait=7
performance_schema = ON
...

Salva il file e siamo a posto. Un po' di spiegazione, l'elenco sopra sono i requisiti come indicato nei documenti di Camunda, in particolare sull'isolamento delle transazioni supportato per Galera. La variabile wsrep_sync_wait è impostata su 7 per eseguire controlli di causalità a livello di cluster per le istruzioni READ (inclusi SELECT, SHOW e BEGIN o START TRANSACTION), UPDATE, DELETE, INSERT e REPLACE, assicurando che l'istruzione venga eseguita su un nodo completamente sincronizzato. Tieni presente che un valore diverso da 0 può comportare una maggiore latenza. L'abilitazione dello schema delle prestazioni è facoltativa per la funzionalità di monitoraggio delle query di ClusterControl.

Ora possiamo avviare il processo di distribuzione del cluster. Installa ClusterControl, genera una chiave SSH e configura SSH senza password dall'host ClusterControl a tutti i nodi Galera. Sul nodo ClusterControl, eseguire:

$ whoami
root
$ ssh-keygen -t rsa
$ for i in 192.168.0.41 192.168.0.42 192.168.0.43; do ssh-copy-id $i; done

Vai a ClusterControl -> Distribuisci -> MySQL Galera e specificare i seguenti dettagli (se non menzionati, utilizzare il valore predefinito):

• Utente SSH:root
• Percorso chiave SSH:/root/.ssh/id_rsa
• Nome cluster:MariaDB Galera 10.3
• Fornitore:MariaDB
• Versione:10.3
• Password amministratore/root:{specificare una password}
• Aggiungi nodo:192.168.0.41 (premi Invio), 192.168.0.42 (premi Invio), 192.168.0.43 (premi Invio)

Assicurati di avere tutti i segni di spunta verdi quando aggiungi nodi, indicando che ClusterControl è in grado di connettersi al nodo senza password. Fai clic su "Distribuisci" per avviare la distribuzione.

Crea il database, l'utente MariaDB e la password su uno dei nodi Galera:

mysql> CREATE DATABASE camunda;
mysql> CREATE USER [email protected]'%' IDENTIFIED BY 'passw0rd';
mysql> GRANT ALL PRIVILEGES ON camunda.* TO [email protected]'%';

Per l'utente ClusterControl, è possibile utilizzare ClusterControl -> Gestisci -> Schema e utenti invece:

La nostra distribuzione del cluster di database è ora completa. Quindi, importa i file SQL nel cluster MariaDB. Sul server delle applicazioni, vai alla directory "sql" e importali in uno dei nodi MariaDB (abbiamo scelto 192.168.0.41):

$ cd ~/camunda/sql/create
$ yum install mysql #install mariadb client
$ mysql -ucamunda -p -h192.168.0.41 camunda < mariadb_engine_7.10.0.sql
$ mysql -ucamunda -p -h192.168.0.41 camunda < mariadb_identity_7.10.0.sql

Camunda non fornisce il connettore MariaDB per Java poiché il suo database predefinito è H2. Sul server delle applicazioni, scarica MariaDB Connector/J dalla pagina di download di MariaDB e copia il file JAR nella directory bin di Apache Tomcat:

$ wget https://downloads.mariadb.com/Connectors/java/connector-java-2.4.1/mariadb-java-client-2.4.1.jar
$ cp mariadb-java-client-2.4.1.jar ~/camunda/server/apache-tomcat-9.0.12/bin/

Quindi, impostare la variabile di ambiente CLASSPATH per includere il connettore del database. Apri setenv.sh tramite editor di testo:

$ vim ~/camunda/server/apache-tomcat-9.0.12/bin/setenv.sh

E aggiungi la seguente riga:

export CLASSPATH=$CLASSPATH:$CATALINA_HOME/bin/mariadb-java-client-2.4.1.jar

Apri ~/camunda/server/apache-tomcat-9.0.12/conf/server.xml e modifica le righe relative al datastore. Usa il protocollo di connessione sequenziale ed elenca tutti i nodi Galera separati da virgola nella stringa di connessione:

<Resource name="jdbc/ProcessEngine"
              ...
              driverClassName="org.mariadb.jdbc.Driver" 
              defaultTransactionIsolation="READ_COMMITTED"
              url="jdbc:mariadb:sequential://192.168.0.41:3306,192.168.0.42:3306,192.168.0.43:3306/camunda"
              username="camunda"  
              password="passw0rd"
              ...
/>

Infine, possiamo avviare il servizio Camunda eseguendo start-camunda.sh sceneggiatura:

$ cd ~/camunda
$ ./start-camunda.sh
starting camunda BPM platform on Tomcat Application Server
Using CATALINA_BASE:   ./server/apache-tomcat-9.0.12
Using CATALINA_HOME:   ./server/apache-tomcat-9.0.12
Using CATALINA_TMPDIR: ./server/apache-tomcat-9.0.12/temp
Using JRE_HOME:        /
Using CLASSPATH:       :./server/apache-tomcat-9.0.12/bin/mariadb-java-client-2.4.1.jar:./server/apache-tomcat-9.0.12/bin/bootstrap.jar:./server/apache-tomcat-9.0.12/bin/tomcat-juli.jar
Tomcat started.

Assicurati che CLASSPATH mostrato nell'output includa il percorso del file JAR del client Java MariaDB. Al termine dell'inizializzazione, puoi accedere alle webapp di Camunda sulla porta 8080 all'indirizzo http://192.168.0.8:8080/camunda/ . Il nome utente predefinito è demo con password 'demo':

Puoi vedere le query di acquisizione digerite da ClusterControl -> Query Monitor -> Query principali , indicando che l'applicazione sta interagendo correttamente con il cluster MariaDB:

Con MariaDB Connector/J, non abbiamo bisogno del livello di bilanciamento del carico che semplifica la nostra architettura generale. La modalità di connessione sequenziale dovrebbe fare il trucco per evitare deadlock multi-scrittore, che possono verificarsi in Galera. Questa configurazione fornisce un'elevata disponibilità con ogni istanza Camunda configurata con JDBC per accedere al cluster di nodi MySQL o MariaDB. Galera si occupa di sincronizzare i dati tra le istanze del database in tempo reale.