Mise en place de la haute disponibilité autour de MariaDB : retour d’expérience

Introduction

Pour les besoins d’une étude réalisée pour un client, nous avons été amenés à comparer différentes approches à la haute disponibilité d’une base de données fonctionnant avec le moteur MariaDB. Le but de cette étude était de trouver un compromis entre simplicité d’utilisation, robustesse et sécurité des données.

Environnement

Dans le cadre de ce retour d’expérience, nous allons travailler sur une solution qui permettrait à l’utilisateur d’envoyer ses requêtes sur un service MariaDB, qui lui-même serait répliqué sur plusieurs serveurs.

• 

Pour cette étude nous allons utiliser :

• VMware (Virtual box pour la création des machines virtuelles)
• Debian 10 pour l’OS
• Docker pour la gestion des conteneurs
• MariaDB

Mode opératoire

Nous allons étudier 3 solutions différentes :

• 3 machines virtuelles sur lesquelles nous allons déployer le moteur MariaDB puis créer un cluster Galera,
• 3 machines virtuelles qui seront dans un cluster Swarm et sur lequel nous allons déployer notre solution Galera,
• 3 machines virtuelles avec un cluster Swarm et un simple container MariaDB.

Pour chacune de ces solutions, nous importerons un jeu de données et réaliserons quelques tests de résilience. Nous conclurons en indiquant les avantages et inconvénients de chaque solution.

#1 – Galera sur serveurs virtuels

Pour cette solution, nous déployons en respectant le cahier des charges suivant :

• Multi-master : chaque nœud de notre cluster Galera peut effectuer à la fois des opérations de lecture et d’écriture. Cela nous offre une meilleure scalabilité.
• Les nœuds peuvent joindre le cluster automatiquement et sont supprimés du cluster en cas de dysfonctionnement.
• La réplication Galera sera en mode synchrone. Cela signifie que les modifications apportées à un nœud seront répliquées en temps réel sur les autres. En théorie, cela permet une conservation des données dans le cas de la perte d’un nœud.

Ci-dessous, un schéma représentant la solution que nous allons implémenter.

• 

Prérequis

• Au moins 3 instances Debian 10,
• Un accès au compte root,
• La définition de la variable $EDITOR. Cette variable sera utilisée à plusieurs reprises pour la construction et la configuration. Définissez juste votre éditeur préféré. Dans notre cas, nous utiliserons vi.

EDITOR=vi

Installation de MariaDB

Cette partie est relativement simple puisque les lignes de commandes suivantes feront le travail pour nous. Chaque commande est à exécuter sur chaque nœud.

#> apt update
#> apt install -y mariadb-server mariadb-client galera-3 rsync
#> systemctl enable mariadb.service

Le script d’installation de MariaDB est ensuite utilisé pour avoir notre environnement initial.

#> mysql_secure_installation

Il suffit ensuite de répondre aux questions du script. Inutile de rappeler qu’un mot de passe robuste doit être choisi.

Enter current password for root (enter for none): Press <Enter>
Set root password? [Y/n] y
New password: your_password
Re-enter new password: your_password
Remove anonymous users? [Y/n] y
Disallow root login remotely? [Y/n] y
Remove test database and access to it? [Y/n] y
Reload privilege tables now? [Y/n] y
All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.

Configuration de MariaDB

Une fois encore, toutes les commandes sont à réaliser sur chaque nœud.
Nous commençons par arrêter notre service MariaDB.

#> systemctl stop mariadb.service

Par défaut, le démon Mariadb écoute les connexions entrantes uniquement sur localhost. Nous allons modifier sa configuration afin de permettre au service d’être disponible sur le réseau.

#> $EDITOR /etc/mysql/mariadb.conf.d/50-server.cnf

Nous cherchons la ligne suivante :

bind-address = 127.0.0.1

Et nous la remplaçons par celle-ci, qui permettra à notre service de répondre sur toutes les adresses ip de notre système.

bind-address = 0.0.0.0

Nous passons maintenant à la configuration du cluster.

#> $EDITOR /etc/mysql/mariadb.conf.d/99-cluster.cnf

Voici à quoi doit ressembler notre fichier de configuration. Attention à la ligne wsrep_cluster_address : pensez à mettre les adresses ip de vos serveurs.

[galera]

wsrep_on = on
wsrep_provider = /lib/galera/libgalera_smm.so
wsrep_cluster_address = gcomm://192.168.1.114,192.138.1.137,192.168.1.131
wsrep_cluster_name = galera_cluster_0

default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
innodb_doublewrite = 1

binlog_format = ROW

Les rôles des différentes options de ce fichier de configuration :

• wsrep_on : permet d’activer la réplication.
• wsrep_provider : permet de spécifier le chemin vers la bibliothèque. Ce chemin dépendra du package d’installation que vous avez utilisé (dépendant de votre distribution).
• wsrep_cluster_adress : va contenir l’adresse des différents membres du cluster. À minima, au moins une adresse d’un autre membre doit être renseignée.
• wsrep_cluster_name : il s’agit du nom de notre cluster, il doit être identique et commun à tous les membres du cluster.
• Les autres options sont nécessaires au bon fonctionnement de Galera et ne nécessitent pas d’être modifiées.

Démarrage du cluster

Avant de commencer, nous vérifions que notre service MariaDB est bien à l’arrêt sur chacun de nos nœuds.

#> systemctl status mariadb.service

Pour démarrer le cluster, nous devons lancer sa création depuis l’un des nœuds. Sur Debian 10, cette action peut être réalisée à l’aide de script galere_new_cluster. Vous ne devez exécuter ce script qu’une seule fois et sur un seul nœud.

#> galera_new_cluster

Ce script va démarrer MariaDB sur le nœud. Nous pourrons nous assurer de son bon fonctionnement à l’aide de la commande suivante :

#> systemctl status mariadb.service

Puis, nous démarrons MariaDB sur les autres nœuds.

#> systemctl start mariadb.service

À partir de ce point, notre cluster est opérationnel.

#2 – Galera sur cluster Swarm

Dans ce cas de figure, nous allons déployer avec le cahier de charge suivant :

• Plusieurs nœuds Docker (3 dans notre exemple) connectés entre eux à l’aide du cluster Swarm.
  • Notre manager sera swarmgalera1 et aura pour adresse 192.168.1.76.
  • Notre premier worker sera swarmgalera2 et aura pour adresse 192.168.1.114.
  • Et enfin, notre second worker sera swarmgalera3 et aura pour adresse 192.168.1.159.
• Un fichier compose qui va représenter notre cluster Galera.
• Une instance MariaDB par nœud.
• Chaque instance doit utiliser un stockage persistent, afin de ne pas perdre les données en cas de redémarrage.
• Le service sera joignable sur l’ip de notre cluster Swarm, sur le port TCP 3306

Ci-dessous, un schéma de ce que nous allons construire.

• 

Prérequis cluster Swarm et Galera

• Au moins 3 instances Debian 10, 
• Un accès au compte root, 
• La définition de la variable $EDITOR. Cette variable sera utilisée à plusieurs reprises pour la construction et la configuration. Définissez juste votre éditeur préféré. Dans notre cas, nous utiliserons vi.
• Un cluster ETCD pour la découverte des services MariaDB au démarrage de nos conteneurs.

EDITOR=vi

Nous allons déployer comme ci-dessous :

Role	hostname	ip
docker	swarmgalera1	192.168.1.76
docker	swarmgalera2	192.168.1.114
docker	swarmgalera3	192.168.1.159

Installation de Swarm

Cette partie est relativement simple puisque les lignes de commandes suivantes feront le travail pour nous. Chaque commande est à exécuter sur chaque nœud.

Nous commençons par l’installation de Docker :

#> apt update -y
#> apt upgrade -y
#> apt-get install -y apt-transport-https ca-certificates curl gnupg2 software-properties-common
#> curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
#> add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
#> apt-get update -y
#> apt-get install -y docker-ce docker-ce-cli containerd.io

Nous pouvons maintenant valider le fonctionnement de Docker sur chaque nœud à l’aide de la commande suivante :

#> docker info

Si tout s’est bien passé, vous devriez avoir un retour semblable à celui-ci :

Client:
 Debug Mode: false

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 19.03.9
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
etc...

Maintenant que nos 3 nœuds sont opérationnels, nous allons pouvoir déployer Swarm.

Sur le premier nœud, nous exécutons la commande suivante :

#> docker swarm init

Ceci va nous renvoyer la commande à exécuter sur les 2 autres nœuds.

Swarm initialized: current node (553z4mg5wdmg5ix0tvwkkcmsj) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-5mhr0hxq1ahyttqxqjlzfm36er9uzqk47i07e570xf42kelnf5-61bsig50wopdl3mt1vr5kgynd 192.168.1.76:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

Une fois les commandes exécutées, nous validons le bon fonctionnement en lançant cette commande sur le premier nœud,qui est maintenant notre manager Swarm. Pour la suite, toutes les commandes seront lancées depuis le manager.

#> docker node ls

Si tout s’est bien passé, vous aurez un retour comme celui-ci:

root@debian:~# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
553z4mg5wdmg5ix0tvwkkcmsj *   swarmgalera1        Ready               Active              Leader              19.03.9
mindcuuktfrhy2voauatr25yj     swarmgalera2        Ready               Active                                  19.03.9
k5sbg0vm5b8qtpbze7x0j45un     swarmgalera3        Ready               Active                                  19.03.9

Installation de ETCD

Nous commençons par installer ETCD sur chaque nœud. 

#> apt install etcd

Puis nous configurons chaque nœud avec les informations nécessaires, tout en éditant le fichier /etc/default/etcd. Sur notre premier nœud, nous aurons donc :

ETCD_NAME=swarmgalera1
ETCD_DATA_DIR="/var/lib/etcd/default"
ETCD_LISTEN_PEER_URLS="http://0.0.0.0:2380"
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://192.168.1.76:2380"
ETCD_INITIAL_CLUSTER="swarmgalera1=http://192.168.1.76:2380,swarmgalera2=http://192.168.1.114:2380,swarmgalera3=http://192.168.1.159:2380"
ETCD_INITIAL_CLUSTER_STATE="new"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster-1"
ETCD_ADVERTISE_CLIENT_URLS="http://0.0.0.0:2379"

Sur notre second noeud :

ETCD_NAME=swarmgalera2
ETCD_DATA_DIR="/var/lib/etcd/default"
ETCD_LISTEN_PEER_URLS="http://0.0.0.0:2380"
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://192.168.1.114:2380"
ETCD_INITIAL_CLUSTER="swarmgalera1=http://192.168.1.76:2380,swarmgalera2=http://192.168.1.114:2380,swarmgalera3=http://192.168.1.159:2380"
ETCD_INITIAL_CLUSTER_STATE="new"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster-1"
ETCD_ADVERTISE_CLIENT_URLS="http://0.0.0.0:2379"

Sur notre troisième nœud :

ETCD_NAME=swarmgalera3
ETCD_DATA_DIR="/var/lib/etcd/default"
ETCD_LISTEN_PEER_URLS="http://0.0.0.0:2380"
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://192.168.1.159:2380"
ETCD_INITIAL_CLUSTER="swarmgalera1=http://192.168.1.76:2380,swarmgalera2=http://192.168.1.114:2380,swarmgalera3=http://192.168.1.159:2380"
ETCD_INITIAL_CLUSTER_STATE="new"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster-1"
ETCD_ADVERTISE_CLIENT_URLS="http://0.0.0.0:2379"

Enfin, nous démarrons ETCD sur les 3 nœuds.

#> systemctl enable etcd
#> sytemctl stop etcd
#> rm -rf /var/lib/etcd/default/*
#> systemctl start etcd

Nous validons ensuite le bon fonctionnement du cluster à l’aide des commandes suivantes :

#> etcdctl cluster-health
member fd4ee767c2713ea is healthy: got healthy result from http://0.0.0.0:2379
member a7d00276d4bd4995 is healthy: got healthy result from http://0.0.0.0:2379
member f51c37d21088bc94 is healthy: got healthy result from http://0.0.0.0:2379
cluster is healthy

#> etcdctl member list
fd4ee767c2713ea: name=swarmgalera2 peerURLs=http://192.168.1.114:2380 clientURLs=http://0.0.0.0:2379 isLeader=false
a7d00276d4bd4995: name=swarmgalera1 peerURLs=http://192.168.1.76:2380 clientURLs=http://0.0.0.0:2379 isLeader=true
f51c37d21088bc94: name=swarmgalera3 peerURLs=http://192.168.1.159:2380 clientURLs=http://0.0.0.0:2379 isLeader=false

Déploiement de Galera dans notre cluster Swarm

Par souci de gain de temps, nous allons utiliser ce qui se trouve sur le docker hub, et plus précisément l’image chagridsada/galera-mariadb .

Nous créons le réseau dédié à notre cluster.

#> docker network create -d overlay --attachable galera-net

Puis nous démarrons notre service Swarm à l’aide de la chaîne de démarrage, fournie par le mainteneur du container, que nous adaptons à notre besoin. Attention cette commande n’est à exécuter qu’une seule fois sur le manager de notre Swarm:

#> docker service create --name mariadb-galera --replicas 3 -p 3306:3306 --network galera-net --mount type=volume,source=galera-vol,destination=/var/lib/mysql --env MYSQL_ROOT_PASSWORD=mypassword --env DISCOVERY_SERVICE=192.168.1.76:2379,192.168.1.114:2379,192.168.1.159:2379 --env XTRABACKUP_PASSWORD=mypassword --env CLUSTER_NAME=my_wsrep_cluster severalnines/mariadb

mt381gdyr6aiypf9o11sdiccr
overall progress: 0 out of 3 tasks
overall progress: 0 out of 3 tasks
overall progress: 3 out of 3 tasks
1/3: running   [==================================================>]
2/3: running   [==================================================>]
3/3: running   [==================================================>]
verify: Service converged

Nous vérifions que tout s’est bien déployé et que notre service est bien accessible.

docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                         PORTS
mt381gdyr6ai        mariadb-galera      replicated          3/3                 severalnines/mariadb:latest   *:3306->3306/tcp
root@swarmgalera1:~# docker service ps mariadb-galera
ID                  NAME                IMAGE                         NODE                DESIRED STATE       CURRENT STATE                ERROR               PORTS
wsq1yxb48ibe        mariadb-galera.1    severalnines/mariadb:latest   swarmgalera1        Running             Running 41 seconds ago
nmif84vuac1b        mariadb-galera.2    severalnines/mariadb:latest   swarmgalera3        Running             Running about a minute ago
mccd85ei4jdf        mariadb-galera.3    severalnines/mariadb:latest   swarmgalera2        Running             Running 28 seconds ago

#3 – Conteneur MariaDB simple sur cluster Swarm

Dans ce cas, nous allons simplement utiliser le conteneur MariaDB officiel que nous allons déployer sur notre cluster Swarm. Le principe est que les données de ce conteneur soient présentes sur tous les nœuds.

Dans le cas où notre conteneur serait défaillant, Swarm le redémarrera automatiquement sur un autre nœud. Les données étant synchronisées entre les nœuds, le service continuera d’être disponible sans interruption de service.

Ci-dessous, un schéma de ce que nous allons construire.

• 

Notre cahier des charges sera le suivant :

• Au moins 3 instances Debian 10.
• Un accès au compte root.
• La définition de la variable $EDITOR. Cette variable sera utilisée à plusieurs reprises pour la construction et la configuration. Définissez juste votre éditeur préféré. Dans notre cas, nous utiliserons vi.
• Un système de fichier répliqué entre nos 3 nœuds, afin que nos données soient identiques et présentes partout. Nous avons choisi d’utiliser GlusterFS simplement (i.e. pas d’ajout de disque dédié à cet usage).

EDITOR=vi

Prérequis cluster Swarm et simple conteneur

Nous allons déployer, comme plus tôt, un cluster Swarm sur 3 host debian 10. Nos hosts docker seront définis comme ci-dessous :

Role	hostname	ip
docker	swarmc1	192.168.1.83
docker	swarmc2	192.168.1.153
docker	swarmc3	192.168.1.117

Si tout s’est bien passé pour vous, vous devriez avoir un résultat semblable à celui-ci:

#> docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
7gueol0zvg8a1lgbgf6e8nz7p *   swarmc1             Ready               Active              Leader              19.03.9
vv5omrmy03eirlvrosqo85cis     swarmc2             Ready               Active                                  19.03.9
rdpfc2d21okthmqizmd1erk9n     swarmc3             Ready               Active                                  19.03.9

Installation de GlusterFS sur chaque nœud et mise en place de notre système de fichier répliqué

Nous exécutons le script suivant sur chaque nœud :

#!/bin/sh
apt install -y glusterfs-server
mkdir -p /glusterfs/distributed
systemctl enable glusterd
systemctl start glusterd

Puis sur un des trois nœuds (le manager Swarm par exemple), nous faisons la configuration de notre gluster.

Nous commençons par valider que les différents nœuds sont bien joignables.

#> gluster peer probe swarmc2
peer probe: success.
#> gluster peer probe swarmc3
peer probe: success.

Puis nous allons créer notre volume distribué.

Attention cependant, pour le besoin de l’exercice nous répliquons un dossier de / à l’aide de GlusterFS. Ceci est un usage non recommandé. Il faut privilégier soit la réplication d’un dossier d’un autre volume (ou partition), soit la réplication d’un disque ou d’un volume complet. C’est pourquoi nous utilisons la commande force pendant la création du volume.

#> gluster volume create glustervol1 replica 3 transport tcp swarmc1:/glusterfs/distributed swarmc2:/glusterfs/distributed swarmc3:/glusterfs/distributed force
volume create: glustervol1: success: please start the volume to access data
#> gluster volume start glustervol1
volume start: glustervol1: success
#> gluster volume info all

Volume Name: glustervol1
Type: Replicate
Volume ID: 24705f15-929b-421f-ad12-5fe0ba0b2b4e
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: swarmc1:/glusterfs/distributed
Brick2: swarmc2:/glusterfs/distributed
Brick3: swarmc3:/glusterfs/distributed
Options Reconfigured:
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

Enfin, il ne nous reste plus qu’à « monter » notre volume répliqué sur chaque nœud afin qu’il soit utilisable par notre container.

Sur chaque serveur, nous exécutons le script suivant :

#!/bin/sh
#creation du point de montage
mkdir /mnt/glusterfs
#ajout de notre point de montage à /etc/fstab afin qu'il soit actif au démarrage de notre serveur
cat << 'EOL' |  tee -a /etc/fstab
127.0.0.1:/glustervol1 /mnt/glusterfs glusterfs defaults,_netdev 0 0
EOL
#montage de notre système
mount /mnt/glusterfs
#creation de notre dossier pour le volume docker
mkdir -p /mnt/glusterfs/docker_volume/mariadb

Démarrage de notre instance MariaDB

Nous allons simplement utiliser le conteneur officiel de MariaDB. Étant donné que nous souhaitons profiter des avantages du cluster Swarm, nous allons écrire un fichier docker-compose.yml dont voici le contenu :

version: '3.4'
services:
 database:
  image: mariadb
  ports:
    - "3306:3306"
  environment:
    MYSQL_ROOT_PASSWORD: "mypassword"
  deploy:
    mode: replicated
    replicas: 1
    restart_policy:
      condition: any
      delay: 5s
  volumes:
  - /mnt/glusterfs/docker_volume/mariadb:/var/lib/mysql

Cette « stack » simple va nous permettre de déployer notre service et de le répliquer sur chaque nœud, en n’ayant pas plus d’une instance fonctionnelle à la fois. Attention, si vous passez réplicas à une valeur > 1, cela ne fonctionnera pas.

Pour démarrer notre stack, nous lançons la commande suivante sur le manager de notre cluster Swarm :

#> docker stack deploy maria -c docker-compose.yml

À partir de ce point, notre service est joignable sur n’importe quel nœud sur le port 3306.

Test de chaque solution

Comme indiqué en préambule, nous allons maintenant importer un jeu de données dans chacune de nos solutions et faire un test de continuité de service : Que se passe-t-il dans le cas de la perte d’un nœud ? Au bout de combien de temps notre service et nos données sont accessibles ?

Pour le jeu de données, nous allons utiliser l’archive test_db_master.zip du site dev.mysql.com (le lien direct vers la page github).

Pour l’installation nous procédons comme ci-dessous :

• Connexion aux instances et import des données :

#> mysql -H ip_de_notre_instance -u root -p < employees.sql

• Test de notre installation :

#> mysql -H ip_de_notre_instance -u root -p -t < test_employees_md5.sql

• Le protocole de test est simple. Sur chaque solution nous réalisons des requêtes de type select et insert. Pendant que ces requêtes sont réalisées, nous simulons la panne du service en arrêtant le service à la main (cas1), simulant une panne réseau (cas2), simulant une panne serveur (cas3). Nous regardons ensuite le nombre d’erreurs (err) et la durée d’interruption de service (ids). Chaque test est reproduit 5 fois. Les valeurs remontées sont une moyenne et les valeurs de temps sont en secondes.

Solution	cas1 err	cas1 ids	cas2 err	cas2 ids	cas3 err	cas3 ids
Galera Physique	0	0	0	0	0	0
Galera Swarm	0	0	0	0	0	0
MariaDB Swarm	0	3	0	2	0	2

Avantages et inconvénients de chaque solution

#1 – Cluster MariaDB et Galera sur serveurs virtuels

Cette solution est la plus éprouvée et maîtrisée aujourd’hui. Le seul inconvénient viendra du fait qu’elle nous oblige à dédier des serveurs (virtuels ou physiques) au simple fonctionnement de notre cluster. La scalabilité viendra au cours de l’ajout d’un nouveau serveur.

#2 – Cluster MariaDB et Galera sur un cluster Swarm

Cette solution est très prometteuse, car elle permet de s’affranchir de la notion de dédier un serveur à un service. Elle permet d’ajouter ou réduire les instances simplement à l’aide d’une simple commande.

Cependant, elle présente quelques limitations : il n’y aura pas d’automatic recovery en cas de split-brain (se produit si tous les nœuds sont en état non-primary). De plus, si le service MariaDB est toujours actif, mais ne répond plus aux requêtes des clients, docker sera incapable de le détecter et considèrera que le service est correctement rendu. Enfin le service d’auto découverte ne doit pas avoir le moindre souci au risque d’empêcher les conteneurs Galera de voir leur statut correctement.

#3 – Instance MariaDB simple sur cluster Swarm

Cette solution n’est pas une solution de haute disponibilité ou de scalabilité comme les solutions précédentes. Par contre, elle nous offre la possibilité de démarrer notre instance MariaDB très rapidement, sur n’importe quel nœud de notre cluster Swarm, la réplication des données étant assurée par la couche GlusterFS. Dans le cas où notre container MariaDB viendrait à cesser de fonctionner, le processus de réplication de Swarm nous assurera son redémarrage sur le nœud le plus disponible. Lors de nos tests, nous avons mesuré un temps d’interruption de service inférieur à 5 secondes.

Solution Retenue

Dans le cas de notre étude, nous avons choisi de retenir la solution de la simple instance sur le cluster Swarm. Cette solution nous a permis d’apporter une solution robuste et simple, tout en nous appuyant sur les briques déjà présentes de l’infrastructure du client.

Se concentrer sur son cœur de métier !

Avant de vous lancer dans un projet, pensez à faire réaliser un audit de votre infrastructure informatique. Nos experts vous conseillent et vous accompagnent pour vous proposer une solution adaptée à vos besoins et vous permettre de vous recentrer sur l’essentiel : votre cœur de métier. Pour en savoir plus, contactez l’un de nos experts.