MariaDB
 sql >> Base de données >  >> RDS >> MariaDB

Haute disponibilité de la base de données pour Camunda BPM avec MySQL ou MariaDB Galera Cluster

Camunda BPM est une plate-forme open source d'automatisation des workflows et des décisions. Camunda BPM est livré avec des outils pour créer des modèles de flux de travail et de décision, exploiter des modèles déployés en production et permettre aux utilisateurs d'exécuter les tâches de flux de travail qui leur sont assignées.

Par défaut, Camunda est livré avec une base de données intégrée appelée H2, qui fonctionne assez bien dans un environnement Java avec une empreinte mémoire relativement faible. Cependant, en ce qui concerne l'évolutivité et la haute disponibilité, il existe d'autres backends de base de données qui pourraient être plus appropriés.

Dans cet article de blog, nous allons déployer Camunda BPM 7.10 Community Edition sur Linux, en mettant l'accent sur la haute disponibilité de la base de données. Camunda prend en charge les principales bases de données via les pilotes JDBC, à savoir Oracle, DB2, MySQL, MariaDB et PostgreSQL. Ce blog se concentre uniquement sur MySQL et MariaDB Galera Cluster, avec une implémentation différente sur chacun - l'un avec ProxySQL comme équilibreur de charge de base de données, et l'autre utilisant le pilote JDBC pour se connecter à plusieurs instances de base de données. Notez que cet article ne couvre pas la haute disponibilité de l'application Camunda elle-même.

Prérequis

Camunda BPM fonctionne sur Java. Dans notre boîte CentOS 7, nous devons installer JDK et la meilleure option est d'utiliser celui d'Oracle, et d'ignorer les packages OpenJDK fournis dans le référentiel. Sur le serveur d'application où Camunda doit s'exécuter, téléchargez le dernier kit de développement Java SE (JDK) d'Oracle en envoyant le cookie d'acceptation :

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

Installez-le sur l'hôte :

$ yum localinstall jdk-12_linux-x64_bin.rpm

Vérifiez avec :

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

Créez un nouveau répertoire et téléchargez Camunda Community pour Apache Tomcat depuis la page de téléchargement officielle :

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

Extrayez-le :

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

Il y a un certain nombre de dépendances que nous devons configurer avant de démarrer l'application Web Camunda. Cela dépend de la plate-forme de base de données choisie, comme la configuration du magasin de données, le connecteur de base de données et l'environnement CLASSPATH. Les sections suivantes expliquent les étapes requises pour MySQL Galera (avec Percona XtraDB Cluster) et MariaDB Galera Cluster.

Notez que les configurations présentées dans ce blog sont basées sur l'environnement Apache Tomcat. Si vous utilisez JBOSS ou Wildfly, la configuration du magasin de données sera un peu différente. Reportez-vous à la documentation de Camunda pour plus de détails.

Cluster MySQL Galera (avec ProxySQL et Keepalived)

Nous utiliserons ClusterControl pour déployer un cluster Galera basé sur MySQL avec Percona XtraDB Cluster. Certaines limitations liées à Galera sont mentionnées dans les documents Camunda concernant la gestion des conflits multi-écrivains Galera et le niveau d'isolation InnoDB. Si vous êtes concerné par ceux-ci, le moyen le plus sûr consiste à utiliser l'approche à écrivain unique, qui est réalisable avec la configuration du groupe d'hôtes ProxySQL. Pour ne fournir aucun point de défaillance unique, nous déploierons deux instances ProxySQL et les lierons avec une adresse IP virtuelle par Keepalived.

Le schéma suivant illustre notre architecture finale :

Tout d'abord, déployez un cluster Percona XtraDB 5.7 à trois nœuds. Installez ClusterControl, générez une clé SSH et configurez SSH sans mot de passe depuis l'hôte ClusterControl vers tous les nœuds (y compris ProxySQL). Sur le nœud ClusterControl, faites :

$ 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

Avant de déployer notre cluster, nous devons modifier le fichier de modèle de configuration MySQL que ClusterControl utilisera lors de l'installation des serveurs MySQL. Le nom du fichier de modèle est my57.cnf.galera et se trouve sous /usr/share/cmon/templates/ sur l'hôte ClusterControl. Assurez-vous que les lignes suivantes existent dans la section [mysqld] :

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

Enregistrez le fichier et nous sommes prêts à partir. Ce qui précède sont les exigences indiquées dans les documents Camunda, en particulier sur l'isolation des transactions prises en charge pour Galera. La variable wsrep_sync_wait est définie sur 7 pour effectuer des contrôles de causalité à l'échelle du cluster pour les instructions READ (y compris SELECT, SHOW et BEGIN ou START TRANSACTION), UPDATE, DELETE, INSERT et REPLACE, en veillant à ce que l'instruction soit exécutée sur un nœud entièrement synchronisé. Gardez à l'esprit qu'une valeur autre que 0 peut entraîner une latence accrue.

Allez dans ClusterControl -> Déployer -> MySQL Galera et spécifiez les détails suivants (si non mentionnés, utilisez la valeur par défaut) :

  • Utilisateur SSH :root
  • Chemin de clé SSH :/root/.ssh/id_rsa
  • Nom du cluster :Percona XtraDB Cluster 5.7
  • Vendeur :Percona
  • Version : 5.7
  • Mot de passe administrateur/racine :{spécifiez un mot de passe}
  • Ajouter un nœud :192.168.0.21 (appuyez sur Entrée), 192.168.0.22 (appuyez sur Entrée), 192.168.0.23 (appuyez sur Entrée)

Assurez-vous que vous avez toutes les coches vertes, indiquant que ClusterControl est capable de se connecter au nœud sans mot de passe. Cliquez sur "Déployer" pour démarrer le déploiement.

Créez la base de données, l'utilisateur MySQL et le mot de passe sur l'un des nœuds de la base de données :

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

Ou depuis l'interface ClusterControl, vous pouvez utiliser Manage -> Schema and Users à la place :

Une fois le cluster déployé, installez ProxySQL en allant dans ClusterControl -> Manage -> Load Balancer -> ProxySQL -> Deploy ProxySQL et saisissez les informations suivantes :

  • Adresse du serveur :192.168.0.11
  • Mot de passe administrateur :
  • Mot de passe du moniteur :
  • Utilisateur de la base de données :camunda
  • Mot de passe de la base de données :passw0rd
  • Utilisez-vous des transactions implicites ? :Oui

Répétez l'étape de déploiement ProxySQL pour la deuxième instance ProxySQL, en modifiant l'adresse du serveur valeur à 192.168.0.12. L'adresse IP virtuelle fournie par Keepalived nécessite au moins deux instances ProxySQL déployées et en cours d'exécution. Enfin, déployez l'adresse IP virtuelle en allant dans ClusterControl -> Gérer -> Load Balancer -> Keepalived et choisissez les deux nœuds ProxySQL et spécifiez l'adresse IP virtuelle et l'interface réseau pour que le VIP écoute :

Notre backend de base de données est maintenant terminé. Ensuite, importez les fichiers SQL dans le cluster Galera en tant qu'utilisateur MySQL créé. Sur le serveur d'application, allez dans le répertoire "sql" et importez-les dans l'un des nœuds Galera (nous choisissons 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 ne fournit pas de connecteur MySQL pour Java car sa base de données par défaut est H2. Sur le serveur d'application, téléchargez MySQL Connector/J à partir de la page de téléchargement de MySQL et copiez le fichier JAR dans le répertoire bin d'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/

Ensuite, définissez la variable d'environnement CLASSPATH pour inclure le connecteur de base de données. Ouvrez setenv.sh à l'aide de l'éditeur de texte :

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

Et ajoutez la ligne suivante :

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

Ouvrez ~/camunda/server/apache-tomcat-9.0.12/conf/server.xml et modifiez les lignes relatives au datastore. Spécifiez l'adresse IP virtuelle en tant qu'hôte MySQL dans la chaîne de connexion, avec le port 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"
              ...
/>

Enfin, nous pouvons démarrer le service Camunda en exécutant start-camunda.sh script :

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

Assurez-vous que le CLASSPATH affiché dans la sortie inclut le chemin d'accès au fichier MySQL Connector/J JAR. Une fois l'initialisation terminée, vous pouvez accéder aux applications Web Camunda sur le port 8080 à http://192.168.0.8:8080/camunda/ . Le nom d'utilisateur par défaut est demo avec le mot de passe 'demo' :

Vous pouvez ensuite voir les requêtes de capture digérées depuis Nodes -> ProxySQL -> Top Requêtes , indiquant que l'application interagit correctement avec le cluster Galera :

Il n'y a pas de fractionnement lecture-écriture configuré pour ProxySQL. Camunda utilise "SET autocommit=0" sur chaque instruction SQL pour initialiser la transaction et la meilleure façon pour ProxySQL de gérer cela en envoyant toutes les requêtes aux mêmes serveurs principaux du groupe d'hôtes cible. C'est la méthode la plus sûre avec une meilleure disponibilité. Cependant, toutes les connexions peuvent finir par atteindre un seul serveur, il n'y a donc pas d'équilibrage de charge.

MariaDB Galera

MariaDB Connector/J est capable de gérer une variété de modes de connexion - basculement, séquentiel, réplication et aurore - mais Camunda ne prend en charge que le basculement et séquentiel. Extrait de la documentation MariaDB Connector/J :

Mode Description
séquentiel
(disponible depuis 1.3.0)		 Ce mode prend en charge le basculement de connexion dans un environnement multi-maître, tel que MariaDB Galera Cluster. Ce mode ne prend pas en charge les lectures d'équilibrage de charge sur les esclaves. Le connecteur essaiera de se connecter aux hôtes dans l'ordre dans lequel ils ont été déclarés dans l'URL de connexion, de sorte que le premier hôte disponible est utilisé pour toutes les requêtes. Par exemple, disons que l'URL de connexion est la suivante :
jdbc:mariadb:sequential:host1,host2,host3/testdb
Lorsque le connecteur essaie de se connecter, il essaie toujours host1 en premier. Si cet hôte n'est pas disponible, il essaiera host2. etc. Lorsqu'un hôte échoue, le connecteur essaie de se reconnecter aux hôtes dans le même ordre.
basculement
(disponible depuis 1.2.0)		 Ce mode prend en charge le basculement de connexion dans un environnement multi-maître, tel que MariaDB Galera Cluster. Ce mode ne prend pas en charge les lectures d'équilibrage de charge sur les esclaves. Le connecteur effectue l'équilibrage de charge pour toutes les requêtes en choisissant au hasard un hôte à partir de l'URL de connexion pour chaque connexion, de sorte que les requêtes seront équilibrées en raison de la distribution aléatoire des connexions sur tous les hôtes.

L'utilisation du mode « basculement » présente un risque potentiel plus élevé de blocage, car les écritures seront distribuées à tous les serveurs principaux de manière presque égale. L'approche à écrivain unique est un moyen sûr de s'exécuter, ce qui signifie que l'utilisation du mode séquentiel devrait très bien faire le travail. Vous pouvez également ignorer le niveau d'équilibrage de charge dans l'architecture. Ainsi, avec le connecteur Java MariaDB, nous pouvons déployer notre architecture aussi simplement que ci-dessous :

Avant de déployer notre cluster, modifiez le fichier de modèle de configuration MariaDB que ClusterControl utilisera lors de l'installation des serveurs MariaDB. Le nom du fichier de modèle est my.cnf.galera et se trouve sous /usr/share/cmon/templates/ sur l'hôte ClusterControl. Assurez-vous que les lignes suivantes existent dans la section [mysqld] :

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

Enregistrez le fichier et nous sommes prêts à partir. Un peu d'explication, la liste ci-dessus correspond aux exigences indiquées dans les documents Camunda, en particulier sur l'isolation des transactions prises en charge pour Galera. La variable wsrep_sync_wait est définie sur 7 pour effectuer des contrôles de causalité à l'échelle du cluster pour les instructions READ (y compris SELECT, SHOW et BEGIN ou START TRANSACTION), UPDATE, DELETE, INSERT et REPLACE, en veillant à ce que l'instruction soit exécutée sur un nœud entièrement synchronisé. Gardez à l'esprit qu'une valeur autre que 0 peut entraîner une latence accrue. L'activation du schéma de performances est facultative pour la fonctionnalité de surveillance des requêtes ClusterControl.

Nous pouvons maintenant démarrer le processus de déploiement du cluster. Installez ClusterControl, générez une clé SSH et configurez SSH sans mot de passe depuis l'hôte ClusterControl vers tous les nœuds Galera. Sur le nœud ClusterControl, faites :

$ 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

Allez dans ClusterControl -> Déployer -> MySQL Galera et spécifiez les détails suivants (si non mentionnés, utilisez la valeur par défaut) :

  • Utilisateur SSH :racine
  • Chemin de clé SSH :/root/.ssh/id_rsa
  • Nom du cluster :MariaDB Galera 10.3
  • Fournisseur :MariaDB
  • Version : 10.3
  • Mot de passe administrateur/racine :{spécifiez un mot de passe}
  • Ajouter un nœud :192.168.0.41 (appuyez sur Entrée), 192.168.0.42 (appuyez sur Entrée), 192.168.0.43 (appuyez sur Entrée)

Assurez-vous d'avoir toutes les coches vertes lors de l'ajout de nœuds, indiquant que ClusterControl est capable de se connecter au nœud sans mot de passe. Cliquez sur "Déployer" pour démarrer le déploiement.

Créez la base de données, l'utilisateur et le mot de passe MariaDB sur l'un des nœuds Galera :

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

Pour l'utilisateur ClusterControl, vous pouvez utiliser ClusterControl -> Gérer -> Schéma et utilisateurs à la place :

Le déploiement de notre cluster de bases de données est maintenant terminé. Ensuite, importez les fichiers SQL dans le cluster MariaDB. Sur le serveur d'application, allez dans le répertoire "sql" et importez-les dans l'un des nœuds MariaDB (nous avons choisi 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 ne fournit pas de connecteur MariaDB pour Java puisque sa base de données par défaut est H2. Sur le serveur d'application, téléchargez MariaDB Connector/J à partir de la page de téléchargement de MariaDB et copiez le fichier JAR dans le répertoire bin d'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/

Ensuite, définissez la variable d'environnement CLASSPATH pour inclure le connecteur de base de données. Ouvrez setenv.sh via l'éditeur de texte :

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

Et ajoutez la ligne suivante :

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

Ouvrez ~/camunda/server/apache-tomcat-9.0.12/conf/server.xml et modifiez les lignes relatives au datastore. Utilisez le protocole de connexion séquentielle et répertoriez tous les nœuds Galera séparés par une virgule dans la chaîne de connexion :

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

Enfin, nous pouvons démarrer le service Camunda en exécutant start-camunda.sh script :

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

Assurez-vous que le CLASSPATH affiché dans la sortie inclut le chemin d'accès au fichier JAR du client Java MariaDB. Une fois l'initialisation terminée, vous pouvez accéder aux applications Web Camunda sur le port 8080 à http://192.168.0.8:8080/camunda/ . Le nom d'utilisateur par défaut est demo avec le mot de passe 'demo' :

Vous pouvez voir les requêtes de capture digérées depuis ClusterControl -> Query Monitor -> Top Queries , indiquant que l'application interagit correctement avec le cluster MariaDB :

Avec MariaDB Connector/J, nous n'avons pas besoin de niveau d'équilibrage de charge, ce qui simplifie notre architecture globale. Le mode de connexion séquentielle devrait faire l'affaire pour éviter les blocages multi-écrivains - ce qui peut arriver dans Galera. Cette configuration offre une haute disponibilité avec chaque instance Camunda configurée avec JDBC pour accéder au cluster de nœuds MySQL ou MariaDB. Galera se charge de synchroniser les données entre les instances de la base de données en temps réel.