sql >> Base de Datos >  >> RDS >> MariaDB

Base de Datos de Alta Disponibilidad para Camunda BPM usando MySQL o MariaDB Galera Cluster

Camunda BPM es una plataforma de automatización de decisiones y flujo de trabajo de código abierto. Camunda BPM se envía con herramientas para crear flujos de trabajo y modelos de decisión, operar modelos implementados en producción y permitir a los usuarios ejecutar las tareas de flujo de trabajo que se les asignan.

De forma predeterminada, Camunda viene con una base de datos integrada llamada H2, que funciona bastante bien dentro de un entorno Java con una huella de memoria relativamente pequeña. Sin embargo, cuando se trata de escalabilidad y alta disponibilidad, existen otros backends de bases de datos que podrían ser más apropiados.

En esta publicación de blog, implementaremos Camunda BPM 7.10 Community Edition en Linux, con un enfoque en lograr una alta disponibilidad de la base de datos. Camunda admite las principales bases de datos a través de controladores JDBC, a saber, Oracle, DB2, MySQL, MariaDB y PostgreSQL. Este blog solo se enfoca en MySQL y MariaDB Galera Cluster, con una implementación diferente en cada uno:uno con ProxySQL como balanceador de carga de base de datos y el otro que usa el controlador JDBC para conectarse a múltiples instancias de base de datos. Tenga en cuenta que este artículo no cubre la alta disponibilidad de la propia aplicación Camunda.

Requisito previo

Camunda BPM se ejecuta en Java. En nuestra caja de CentOS 7, tenemos que instalar JDK y la mejor opción es usar el de Oracle, y omitir el uso de los paquetes de OpenJDK proporcionados en el repositorio. En el servidor de aplicaciones donde debe ejecutarse Camunda, descargue el último Java SE Development Kit (JDK) de Oracle enviando la cookie de aceptación:

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

Instálelo en el host:

$ yum localinstall jdk-12_linux-x64_bin.rpm

Verifique 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)

Cree un nuevo directorio y descargue Camunda Community para Apache Tomcat desde la página de descarga oficial:

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

Extraerlo:

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

Hay una serie de dependencias que debemos configurar antes de iniciar la aplicación web Camunda. Esto depende de la plataforma de base de datos elegida, como la configuración del almacén de datos, el conector de la base de datos y el entorno CLASSPATH. Las siguientes secciones explican los pasos necesarios para MySQL Galera (usando Percona XtraDB Cluster) y MariaDB Galera Cluster.

Tenga en cuenta que las configuraciones que se muestran en este blog se basan en el entorno Apache Tomcat. Si usa JBOSS o Wildfly, la configuración del almacén de datos será un poco diferente. Consulte la documentación de Camunda para obtener más detalles.

Clúster MySQL Galera (con ProxySQL y Keepalived)

Usaremos ClusterControl para implementar el clúster Galera basado en MySQL con Percona XtraDB Cluster. Hay algunas limitaciones relacionadas con Galera mencionadas en los documentos de Camunda que rodean el manejo de conflictos de múltiples escritores de Galera y el nivel de aislamiento de InnoDB. En caso de que se vea afectado por estos, la forma más segura es utilizar el enfoque de un solo escritor, que se puede lograr con la configuración del grupo de host ProxySQL. Para no proporcionar ningún punto único de falla, implementaremos dos instancias de ProxySQL y las vincularemos con una dirección IP virtual de Keepalived.

El siguiente diagrama ilustra nuestra arquitectura final:

Primero, implemente un Percona XtraDB Cluster 5.7 de tres nodos. Instale ClusterControl, genere una clave SSH y configure SSH sin contraseña desde el host de ClusterControl a todos los nodos (incluido ProxySQL). En el nodo ClusterControl, haga:

$ 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

Antes de implementar nuestro clúster, debemos modificar el archivo de plantilla de configuración de MySQL que utilizará ClusterControl al instalar servidores MySQL. El nombre del archivo de la plantilla es my57.cnf.galera y se encuentra en /usr/share/cmon/templates/ en el host de ClusterControl. Asegúrese de que existan las siguientes líneas en la sección [mysqld]:

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

Guarde el archivo y estamos listos para comenzar. Los anteriores son los requisitos establecidos en los documentos de Camunda, especialmente en el aislamiento de transacciones admitido para Galera. La variable wsrep_sync_wait se establece en 7 para realizar verificaciones de causalidad en todo el clúster para las declaraciones READ (incluido SELECT, SHOW y BEGIN o START TRANSACTION), UPDATE, DELETE, INSERT y REPLACE, lo que garantiza que la declaración se ejecute en un nodo completamente sincronizado. Tenga en cuenta que un valor distinto de 0 puede provocar un aumento de la latencia.

Vaya a ClusterControl -> Implementar -> MySQL Galera y especifique los siguientes detalles (si no se mencionan, use el valor predeterminado):

  • Usuario de SSH:root
  • Ruta de la clave SSH:/root/.ssh/id_rsa
  • Nombre del clúster:Percona XtraDB Cluster 5.7
  • Vendedor:Percona
  • Versión:5.7
  • Contraseña de administrador/raíz:{especifique una contraseña}
  • Agregar nodo:192.168.0.21 (presione Entrar), 192.168.0.22 (presione Entrar), 192.168.0.23 (presione Entrar)

Asegúrese de obtener todas las marcas verdes, lo que indica que ClusterControl puede conectarse al nodo sin contraseña. Haga clic en "Implementar" para iniciar la implementación.

Cree la base de datos, el usuario MySQL y la contraseña en uno de los nodos de la base de datos:

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

O desde la interfaz de ClusterControl, puede usar Administrar -> Esquema y usuarios en cambio:

Una vez que se implementa el clúster, instale ProxySQL yendo a ClusterControl -> Administrar -> Equilibrador de carga -> ProxySQL -> Implementar ProxySQL e ingrese los siguientes detalles:

  • Dirección del servidor:192.168.0.11
  • Contraseña de administración:
  • Contraseña del monitor:
  • Usuario de base de datos:camunda
  • Contraseña de base de datos:passw0rd
  • ¿Está utilizando transacciones implícitas?:Sí

Repita el paso de implementación de ProxySQL para la segunda instancia de ProxySQL, cambiando la Dirección del servidor valor a 192.168.0.12. La dirección IP virtual proporcionada por Keepalived requiere al menos dos instancias de ProxySQL implementadas y en ejecución. Finalmente, implemente la dirección IP virtual yendo a ClusterControl -> Manage -> Load Balancer -> Keepalived y seleccione ambos nodos ProxySQL y especifique la dirección IP virtual y la interfaz de red para que el VIP escuche:

Nuestro backend de base de datos ahora está completo. A continuación, importe los archivos SQL a Galera Cluster como el usuario de MySQL creado. En el servidor de aplicaciones, vaya al directorio "sql" e impórtelos a uno de los nodos de Galera (elegimos 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 no proporciona un conector MySQL para Java ya que su base de datos predeterminada es H2. En el servidor de aplicaciones, descargue MySQL Connector/J desde la página de descarga de MySQL y copie el archivo JAR en el directorio bin de 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/

Luego, configure la variable de entorno CLASSPATH para incluir el conector de la base de datos. Abra setenv.sh usando el editor de texto:

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

Y agregue la siguiente línea:

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

Abra ~/camunda/server/apache-tomcat-9.0.12/conf/server.xml y cambie las líneas relacionadas con el almacén de datos. Especifique la dirección IP virtual como host MySQL en la cadena de conexión, con el puerto 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"
              ...
/>

Finalmente, podemos iniciar el servicio Camunda ejecutando start-camunda.sh guión:

$ 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.

Asegúrese de que CLASSPATH que se muestra en el resultado incluya la ruta al archivo MySQL Connector/J JAR. Una vez completada la inicialización, puede acceder a las aplicaciones web de Camunda en el puerto 8080 en http://192.168.0.8:8080/camunda/ . El nombre de usuario predeterminado es demo con la contraseña 'demo':

A continuación, puede ver las consultas de captura digeridas de Nodos -> ProxySQL -> Consultas principales , lo que indica que la aplicación está interactuando correctamente con Galera Cluster:

No hay una división de lectura y escritura configurada para ProxySQL. Camunda usa "SET autocommit=0" en cada instrucción SQL para inicializar la transacción y la mejor manera de que ProxySQL maneje esto enviando todas las consultas a los mismos servidores backend del grupo de host de destino. Este es el método más seguro junto con una mejor disponibilidad. Sin embargo, todas las conexiones pueden llegar a un solo servidor, por lo que no hay equilibrio de carga.

Maria DB Galera

MariaDB Connector/J puede manejar una variedad de modos de conexión (conmutación por error, secuencial, replicación y aurora), pero Camunda solo admite conmutación por error y secuencial. Tomado de la documentación de MariaDB Connector/J:

Modo Descripción
secuencial
(disponible desde 1.3.0)		 Este modo admite la conmutación por error de la conexión en un entorno multimaestro, como MariaDB Galera Cluster. Este modo no admite lecturas de equilibrio de carga en esclavos. El conector intentará conectarse a los hosts en el orden en que se declararon en la URL de conexión, por lo que se utiliza el primer host disponible para todas las consultas. Por ejemplo, digamos que la URL de conexión es la siguiente:
jdbc:mariadb:sequential:host1,host2,host3/testdb
Cuando el conector intenta conectarse, siempre intentará host1 primero. Si ese host no está disponible, intentará host2. etc. Cuando falla un host, el conector intentará volver a conectarse a los hosts en el mismo orden.
conmutación por error
(disponible desde 1.2.0)		 Este modo admite la conmutación por error de la conexión en un entorno multimaestro, como MariaDB Galera Cluster. Este modo no admite lecturas de equilibrio de carga en esclavos. El conector realiza el equilibrio de carga para todas las consultas al elegir aleatoriamente un host de la URL de conexión para cada conexión, por lo que las consultas se equilibrarán como resultado de que las conexiones se distribuyan aleatoriamente entre todos los hosts.

El uso del modo de "conmutación por error" plantea un mayor riesgo potencial de interbloqueo, ya que las escrituras se distribuirán a todos los servidores back-end casi por igual. El enfoque de un solo escritor es una forma segura de ejecutar, lo que significa que usar el modo secuencial debería funcionar bastante bien. También puede omitir el nivel del equilibrador de carga en la arquitectura. Por lo tanto, con el conector MariaDB Java, podemos implementar nuestra arquitectura tan simple como a continuación:

Antes de implementar nuestro clúster, modifique el archivo de plantilla de configuración de MariaDB que utilizará ClusterControl al instalar los servidores de MariaDB. El nombre del archivo de la plantilla es my.cnf.galera y se encuentra en /usr/share/cmon/templates/ en el host de ClusterControl. Asegúrese de que existan las siguientes líneas en la sección [mysqld]:

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

Guarde el archivo y estamos listos para comenzar. Un poco de explicación, la lista anterior son los requisitos establecidos en los documentos de Camunda, especialmente en el aislamiento de transacciones admitido para Galera. La variable wsrep_sync_wait se establece en 7 para realizar verificaciones de causalidad en todo el clúster para las declaraciones READ (incluido SELECT, SHOW y BEGIN o START TRANSACTION), UPDATE, DELETE, INSERT y REPLACE, lo que garantiza que la declaración se ejecute en un nodo completamente sincronizado. Tenga en cuenta que un valor distinto de 0 puede provocar un aumento de la latencia. Habilitar el esquema de rendimiento es opcional para la función de supervisión de consultas de ClusterControl.

Ahora podemos comenzar el proceso de implementación del clúster. Instale ClusterControl, genere una clave SSH y configure SSH sin contraseña desde el host de ClusterControl a todos los nodos de Galera. En el nodo ClusterControl, haga:

$ 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

Vaya a ClusterControl -> Implementar -> MySQL Galera y especifique los siguientes detalles (si no se mencionan, use el valor predeterminado):

  • Usuario de SSH:root
  • Ruta de la clave SSH:/root/.ssh/id_rsa
  • Nombre del clúster:MariaDB Galera 10.3
  • Proveedor:MariaDB
  • Versión:10.3
  • Contraseña de administrador/raíz:{especifique una contraseña}
  • Agregar nodo:192.168.0.41 (presione Entrar), 192.168.0.42 (presione Entrar), 192.168.0.43 (presione Entrar)

Asegúrese de obtener todas las marcas verdes al agregar nodos, lo que indica que ClusterControl puede conectarse al nodo sin contraseña. Haga clic en "Implementar" para iniciar la implementación.

Cree la base de datos, el usuario y la contraseña de MariaDB en uno de los nodos de Galera:

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

Para el usuario de ClusterControl, puede usar ClusterControl -> Administrar -> Esquema y usuarios en cambio:

La implementación de nuestro clúster de base de datos ahora está completa. A continuación, importe los archivos SQL al clúster de MariaDB. En el servidor de aplicaciones, vaya al directorio "sql" e impórtelos en uno de los nodos de MariaDB (elegimos 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 no proporciona el conector MariaDB para Java ya que su base de datos predeterminada es H2. En el servidor de aplicaciones, descargue MariaDB Connector/J desde la página de descarga de MariaDB y copie el archivo JAR en el directorio bin de 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/

Luego, configure la variable de entorno CLASSPATH para incluir el conector de la base de datos. Abra setenv.sh a través del editor de texto:

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

Y agregue la siguiente línea:

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

Abra ~/camunda/server/apache-tomcat-9.0.12/conf/server.xml y cambie las líneas relacionadas con el almacén de datos. Utilice el protocolo de conexión secuencial y enumere todos los nodos de Galera separados por comas en la cadena de conexión:

<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"
              ...
/>

Finalmente, podemos iniciar el servicio Camunda ejecutando start-camunda.sh guión:

$ 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.

Asegúrese de que CLASSPATH que se muestra en el resultado incluya la ruta al archivo JAR del cliente Java de MariaDB. Una vez completada la inicialización, puede acceder a las aplicaciones web de Camunda en el puerto 8080 en http://192.168.0.8:8080/camunda/ . El nombre de usuario predeterminado es demo con la contraseña 'demo':

Puede ver las consultas de captura digeridas desde ClusterControl -> Query Monitor -> Top Queries , lo que indica que la aplicación interactúa correctamente con MariaDB Cluster:

Con MariaDB Connector/J, no necesitamos un nivel de equilibrador de carga, lo que simplifica nuestra arquitectura general. El modo de conexión secuencial debería hacer el truco para evitar interbloqueos de múltiples escritores, lo que puede ocurrir en Galera. Esta configuración proporciona alta disponibilidad con cada instancia de Camunda configurada con JDBC para acceder al clúster de nodos MySQL o MariaDB. Galera se encarga de sincronizar los datos entre las instancias de la base de datos en tiempo real.