Wysoka dostępność bazy danych dla Camunda BPM przy użyciu MySQL lub MariaDB Galera Cluster

Camunda BPM to platforma do automatyzacji procesów i decyzji typu open source. Camunda BPM jest dostarczany z narzędziami do tworzenia modeli przepływu pracy i decyzji, obsługi modeli wdrożonych w produkcji i umożliwiania użytkownikom wykonywania przypisanych im zadań przepływu pracy.

Domyślnie Camunda jest dostarczana z wbudowaną bazą danych o nazwie H2, która działa całkiem przyzwoicie w środowisku Java ze stosunkowo niewielkim zużyciem pamięci. Jednak jeśli chodzi o skalowanie i wysoką dostępność, istnieją inne backendy baz danych, które mogą być bardziej odpowiednie.

W tym wpisie na blogu zamierzamy wdrożyć Camunda BPM 7.10 Community Edition w systemie Linux, z naciskiem na osiągnięcie wysokiej dostępności bazy danych. Camunda obsługuje główne bazy danych poprzez sterowniki JDBC, a mianowicie Oracle, DB2, MySQL, MariaDB i PostgreSQL. Ten blog koncentruje się tylko na MySQL i MariaDB Galera Cluster, z różnymi implementacjami w każdym z nich – jedna z ProxySQL jako systemem równoważenia obciążenia bazy danych, a druga wykorzystująca sterownik JDBC do łączenia się z wieloma instancjami bazy danych. Zwróć uwagę, że ten artykuł nie obejmuje wysokiej dostępności samej aplikacji Camunda.

Warunek wstępny

Camunda BPM działa na Javie. W naszym pudełku CentOS 7 musimy zainstalować JDK, a najlepszą opcją jest użycie tego z Oracle i pominięcie korzystania z pakietów OpenJDK dostarczonych w repozytorium. Na serwerze aplikacji, na którym powinna działać Camunda, pobierz najnowszy zestaw Java SE Development Kit (JDK) firmy Oracle, wysyłając plik cookie akceptacji:

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

Zainstaluj go na hoście:

$ yum localinstall jdk-12_linux-x64_bin.rpm

Zweryfikuj za pomocą:

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

Utwórz nowy katalog i pobierz Camunda Community for Apache Tomcat z oficjalnej strony pobierania:

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

Wypakuj go:

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

Istnieje szereg zależności, które musimy skonfigurować przed uruchomieniem aplikacji internetowej Camunda. Zależy to od wybranej platformy bazy danych, takiej jak konfiguracja magazynu danych, łącznik bazy danych i środowisko CLASSPATH. Następne sekcje wyjaśniają wymagane kroki dla MySQL Galera (przy użyciu klastra Percona XtraDB) i MariaDB Galera Cluster.

Zauważ, że konfiguracje pokazane w tym blogu są oparte na środowisku Apache Tomcat. Jeśli używasz JBOSS lub Wildfly, konfiguracja datastore będzie nieco inna. Szczegółowe informacje można znaleźć w dokumentacji Camundy.

Klaster MySQL Galera (z ProxySQL i Keepalived)

Użyjemy ClusterControl do wdrożenia klastra Galera opartego na MySQL z klastrem Percona XtraDB. Istnieją pewne ograniczenia związane z Galerą wymienione w dokumentach Camunda dotyczących obsługi konfliktów z wieloma zapisami w Galera i poziomu izolacji InnoDB. W przypadku ich wystąpienia, najbezpieczniejszym sposobem jest użycie podejścia pojedynczego zapisu, które jest osiągalne przy konfiguracji grupy hostów ProxySQL. Aby zapewnić brak pojedynczego punktu awarii, wdrożymy dwie instancje ProxySQL i połączymy je z wirtualnym adresem IP przez Keepalived.

Poniższy diagram ilustruje naszą ostateczną architekturę:

Najpierw wdróż trzywęzłowy klaster Percona XtraDB Cluster 5.7. Zainstaluj ClusterControl, wygeneruj klucz SSH i skonfiguruj SSH bez hasła z hosta ClusterControl do wszystkich węzłów (w tym ProxySQL). W węźle ClusterControl wykonaj:

$ 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

Zanim wdrożymy nasz klaster, musimy zmodyfikować plik szablonu konfiguracji MySQL, którego ClusterControl będzie używał podczas instalowania serwerów MySQL. Nazwa pliku szablonu to my57.cnf.galera i znajduje się on w katalogu /usr/share/cmon/templates/ na hoście ClusterControl. Upewnij się, że w sekcji [mysqld] znajdują się następujące wiersze:

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

Zapisz plik i gotowe. Powyższe są wymaganiami określonymi w dokumentacji Camunda, zwłaszcza w przypadku obsługiwanej izolacji transakcji dla Galera. Zmienna wsrep_sync_wait jest ustawiona na 7, aby wykonać kontrole przyczynowości w całym klastrze dla instrukcji READ (w tym SELECT, SHOW i BEGIN lub START TRANSACTION), UPDATE, DELETE, INSERT i REPLACE, zapewniając, że instrukcja jest wykonywana w w pełni zsynchronizowanym węźle. Pamiętaj, że wartość inna niż 0 może skutkować zwiększonym opóźnieniem.

Przejdź do ClusterControl -> Wdróż -> MySQL Galera i określ następujące szczegóły (jeśli nie zostały wymienione, użyj wartości domyślnej):

• Użytkownik SSH:root
• Ścieżka klucza SSH:/root/.ssh/id_rsa
• Nazwa klastra:Percona XtraDB Cluster 5.7
• Dostawca:Percona
• Wersja:5.7
• Hasło administratora/root:{podaj hasło}
• Dodaj węzeł:192.168.0.21 (naciśnij Enter), 192.168.0.22 (naciśnij Enter), 192.168.0.23 (naciśnij Enter)

Upewnij się, że masz wszystkie zielone ptaszki, wskazujące, że ClusterControl może połączyć się z węzłem bez hasła. Kliknij „Wdróż”, aby rozpocząć wdrażanie.

Utwórz bazę danych, użytkownika MySQL i hasło na jednym z węzłów bazy danych:

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

Lub z interfejsu ClusterControl możesz użyć Zarządzaj -> Schemat i użytkownicy zamiast tego:

Po wdrożeniu klastra zainstaluj ProxySQL, przechodząc do ClusterControl -> Zarządzaj -> Load Balancer -> ProxySQL -> Wdróż ProxySQL i wprowadź następujące dane:

• Adres serwera:192.168.0.11
• Hasło administratora:
• Hasło monitora:
• Użytkownik bazy danych:camunda
• Hasło bazy danych:passw0rd
• Czy korzystasz z transakcji niejawnych?:Tak

Powtórz krok wdrażania ProxySQL dla drugiej instancji ProxySQL, zmieniając Adres serwera wartość do 192.168.0.12. Wirtualny adres IP dostarczony przez Keepalived wymaga co najmniej dwóch wdrożonych i uruchomionych instancji ProxySQL. Na koniec wdróż wirtualny adres IP, przechodząc do ClusterControl -> Zarządzaj -> Load Balancer -> Keepalved i wybierz oba węzły ProxySQL i określ wirtualny adres IP i interfejs sieciowy, aby VIP mógł nasłuchiwać:

Nasz backend bazy danych jest już gotowy. Następnie zaimportuj pliki SQL do klastra Galera jako utworzony użytkownik MySQL. Na serwerze aplikacji przejdź do katalogu "sql" i zaimportuj je do jednego z węzłów Galera (wybieramy 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 nie udostępnia łącznika MySQL dla Javy, ponieważ jego domyślną bazą danych jest H2. Na serwerze aplikacji pobierz MySQL Connector/J ze strony pobierania MySQL i skopiuj plik JAR do katalogu bin 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/

Następnie ustaw zmienną środowiskową CLASSPATH, aby zawierała łącznik bazy danych. Otwórz setenv.sh za pomocą edytora tekstu:

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

I dodaj następującą linię:

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

Otwórz ~/camunda/server/apache-tomcat-9.0.12/conf/server.xml i zmień linie związane z magazynem danych. Podaj wirtualny adres IP jako host MySQL w ciągu połączenia z portem 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"
              ...
/>

Na koniec możemy uruchomić usługę Camunda, wykonując start-camunda.sh skrypt:

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

Upewnij się, że CLASSPATH pokazana w danych wyjściowych zawiera ścieżkę do pliku MySQL Connector/J JAR. Po zakończeniu inicjalizacji możesz uzyskać dostęp do aplikacji internetowych Camunda na porcie 8080 pod adresem http://192.168.0.8:8080/camunda/ . Domyślna nazwa użytkownika to demo z hasłem „demo”:

Następnie możesz zobaczyć przetrawione zapytania przechwytywania z Węzły -> ProxySQL -> Najpopularniejsze zapytania , wskazując, że aplikacja poprawnie współpracuje z klastrem Galera:

Dla ProxySQL nie skonfigurowano podziału odczytu i zapisu. Camunda używa "SET autocommit=0" na każdej instrukcji SQL w celu zainicjowania transakcji i najlepszym sposobem, aby ProxySQL obsłużył to, wysyłając wszystkie zapytania do tych samych serwerów zaplecza docelowej grupy hostów. Jest to najbezpieczniejsza metoda obok lepszej dostępności. Jednak wszystkie połączenia mogą dotrzeć do jednego serwera, więc nie ma równoważenia obciążenia.

Galeria MariaDB

MariaDB Connector/J obsługuje różne tryby połączenia — przełączanie awaryjne, sekwencyjne, replikację i aurora — ale Camunda obsługuje tylko przełączanie awaryjne i sekwencyjne. Zaczerpnięte z dokumentacji MariaDB Connector/J:

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

Korzystanie z trybu „awaryjnego” stwarza większe potencjalne ryzyko zakleszczenia, ponieważ zapisy będą dystrybuowane do wszystkich serwerów zaplecza prawie równo. Podejście do jednego zapisu jest bezpiecznym sposobem uruchamiania, co oznacza, że ​​użycie trybu sekwencyjnego powinno całkiem dobrze wykonać zadanie. Możesz również pominąć warstwę równoważenia obciążenia w architekturze. Dlatego dzięki łącznikowi MariaDB Java możemy wdrożyć naszą architekturę tak prosto, jak poniżej:

Przed wdrożeniem naszego klastra zmodyfikuj plik szablonu konfiguracji MariaDB, którego ClusterControl będzie używać podczas instalowania serwerów MariaDB. Nazwa pliku szablonu to my.cnf.galera i znajduje się on w katalogu /usr/share/cmon/templates/ na hoście ClusterControl. Upewnij się, że w sekcji [mysqld] znajdują się następujące wiersze:

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

Zapisz plik i gotowe. Trochę wyjaśnienia, powyższa lista to wymagania określone w dokumentacji Camunda, szczególnie w przypadku obsługiwanej izolacji transakcji dla Galera. Zmienna wsrep_sync_wait jest ustawiona na 7, aby wykonać kontrole przyczynowości w całym klastrze dla instrukcji READ (w tym SELECT, SHOW i BEGIN lub START TRANSACTION), UPDATE, DELETE, INSERT i REPLACE, zapewniając, że instrukcja jest wykonywana w w pełni zsynchronizowanym węźle. Pamiętaj, że wartość inna niż 0 może skutkować zwiększonym opóźnieniem. Włączenie schematu wydajności jest opcjonalne dla funkcji monitorowania zapytań ClusterControl.

Teraz możemy rozpocząć proces wdrażania klastra. Zainstaluj ClusterControl, wygeneruj klucz SSH i skonfiguruj bezhasłowe SSH z hosta ClusterControl do wszystkich węzłów Galera. W węźle ClusterControl wykonaj:

$ 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

Przejdź do ClusterControl -> Wdróż -> MySQL Galera i określ następujące szczegóły (jeśli nie zostały wymienione, użyj wartości domyślnej):

• Użytkownik SSH:root
• Ścieżka klucza SSH:/root/.ssh/id_rsa
• Nazwa klastra:MariaDB Galera 10.3
• Dostawca:MariaDB
• Wersja:10.3
• Hasło administratora/root:{podaj hasło}
• Dodaj węzeł:192.168.0.41 (wciśnij Enter), 192.168.0.42 (wciśnij Enter), 192.168.0.43 (wciśnij Enter)

Upewnij się, że podczas dodawania węzłów masz wszystkie zielone ptaszki, co oznacza, że ​​ClusterControl może łączyć się z węzłem bez hasła. Kliknij „Wdróż”, aby rozpocząć wdrażanie.

Utwórz bazę danych, użytkownika MariaDB i hasło w jednym z węzłów Galera:

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

Dla użytkownika ClusterControl możesz użyć ClusterControl -> Zarządzaj -> Schemat i użytkownicy zamiast tego:

Wdrażanie naszego klastra bazy danych zostało zakończone. Następnie zaimportuj pliki SQL do klastra MariaDB. Na serwerze aplikacji przejdź do katalogu „sql” i zaimportuj je do jednego z węzłów MariaDB (wybraliśmy 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 nie udostępnia łącznika MariaDB dla Javy, ponieważ jego domyślną bazą danych jest H2. Na serwerze aplikacji pobierz MariaDB Connector/J ze strony pobierania MariaDB i skopiuj plik JAR do katalogu bin 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/

Następnie ustaw zmienną środowiskową CLASSPATH, aby zawierała łącznik bazy danych. Otwórz setenv.sh za pomocą edytora tekstu:

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

I dodaj następującą linię:

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

Otwórz ~/camunda/server/apache-tomcat-9.0.12/conf/server.xml i zmień linie związane z magazynem danych. Użyj protokołu połączenia sekwencyjnego i wypisz wszystkie węzły Galera oddzielone przecinkami w ciągu połączenia:

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

Na koniec możemy uruchomić usługę Camunda, wykonując start-camunda.sh skrypt:

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

Upewnij się, że CLASSPATH pokazana w danych wyjściowych zawiera ścieżkę do pliku JAR klienta Java MariaDB. Po zakończeniu inicjalizacji możesz uzyskać dostęp do aplikacji internetowych Camunda na porcie 8080 pod adresem http://192.168.0.8:8080/camunda/ . Domyślna nazwa użytkownika to demo z hasłem „demo”:

Możesz zobaczyć przetworzone zapytania przechwytywania z ClusterControl -> Monitor zapytań -> Najpopularniejsze zapytania , wskazując, że aplikacja poprawnie współpracuje z klastrem MariaDB:

Dzięki MariaDB Connector/J nie potrzebujemy warstwy równoważenia obciążenia, która upraszcza naszą ogólną architekturę. Tryb połączenia sekwencyjnego powinien załatwić sprawę, aby uniknąć zakleszczeń związanych z wieloma zapisami, które mogą się zdarzyć w Galerze. Ta konfiguracja zapewnia wysoką dostępność z każdą instancją Camunda skonfigurowaną z JDBC w celu uzyskania dostępu do klastra węzłów MySQL lub MariaDB. Galera zajmuje się synchronizacją danych między instancjami bazy danych w czasie rzeczywistym.