Un déploiement Nextcloud haute disponibilité avec Galera est un système coordonné, et non pas seulement trois serveurs de base de données. Il nécessite également des nœuds d'application Nextcloud redondants, une couche de données partagée et durable, une mise en cache et un verrouillage de fichiers distribués, un équilibrage de charge, une surveillance et des sauvegardes testées. Galera peut maintenir la disponibilité du service de base de données après la défaillance d'un nœud, tant que le quorum est maintenu, mais ne peut pas assurer la haute disponibilité des autres composants.
Ce guide utilise une architecture Linux indépendante des fournisseurs, avec MariaDB Galera et un proxy inverse ou un équilibreur de charge. Les noms des paquets, des services, les chemins d'accès au fournisseur Galera, les commandes d'amorçage et les intégrations de vérification de l'état du proxy varient selon la distribution et la version de MariaDB. Veuillez les vérifier dans la documentation de la version concernée avant le déploiement. Le manuel d'administration de la version stable actuelle de Nextcloud recommande PostgreSQL et MariaDB comme moteurs de base de données et précise que les versions prises en charge varient ; consultez la configuration système requise pour la version de Nextcloud que vous prévoyez d'utiliser. Cet article a été vérifié par rapport au manuel de la version stable de Nextcloud 35 le 6 octobre 2026.
Galera est une réplication synchrone multi-primaire pour les serveurs compatibles MySQL. Une transaction est certifiée au sein du cluster, ce qui garantit la cohérence des membres, mais engendre une surcharge de coordination. Les transactions conflictuelles peuvent être rejetées. L'ajout de nœuds de base de données n'augmente pas automatiquement le débit de Nextcloud. Les recommandations aux développeurs de Nextcloud indiquent que les clusters ont un impact sur les performances et que la base de données et le stockage demeurent des ressources partagées critiques.
| choix de conception | Bonne coupe | Compromis principal |
|---|---|---|
| Un serveur MariaDB ou PostgreSQL | Déploiements de petite taille nécessitant les opérations les plus simples | Une opération de maintenance ou une panne de la base de données peut interrompre le service. |
| MariaDB avec Galera | Les équipes qui ont besoin d'une redondance des nœuds de base de données et qui peuvent gérer les procédures de quorum, de réseau, de proxy et de récupération | Plus d'éléments à prendre en compte : coordination des écritures, gestion des conflits et complexité de la récupération |
| Deux nœuds de base de données plus un arbitre | Sites disposant de deux serveurs de base de données, mais d'un domaine de défaillance distinct pour le vote de quorum | L'arbitre facilite le quorum ; il ne stocke pas de données et ne remplace pas une copie de base de données tierce. |
| Galera derrière un proxy connaissant la base de données | Déploiements nécessitant un point de terminaison de connexion stable et un routage contrôlé | Les contrôles de santé des proxys et les règles de routage deviennent un autre service à exploiter |
Pour une nouvelle installation, un cluster Galera à trois nœuds de données répartis sur des hôtes indépendants constitue un point de départ courant lorsque l'équipe d'exploitation peut le prendre en charge. Le quorum Galera requiert une majorité : un cluster à deux nœuds ne peut pas basculer automatiquement et en toute sécurité en cas de perte d'un membre. Un cluster à trois nœuds peut tolérer l'indisponibilité d'un membre tant que les deux autres restent connectés. Dans la mesure du possible, répartissez les nœuds sur des domaines de défaillance, mais évitez d'étendre la réplication synchrone sur des liaisons à latence élevée sans tests préalables. Pour un environnement moins complexe, privilégiez une base de données unique prise en charge, associée à un plan de sauvegarde et de restauration éprouvé.
Identifiez les défaillances auxquelles vous souhaitez pouvoir résister : un processus web, un hébergeur web, un hébergeur de base de données, un équilibreur de charge, un point de terminaison de stockage, un chemin réseau ou un site web complet. Définissez des objectifs de reprise après incident pour chacune. Une architecture avec trois nœuds de base de données et un équilibreur de charge n'est pas totalement redondante. Il en va de même pour un cluster d'applications dont les fichiers utilisateur résident uniquement sur le disque local d'un serveur web.
Utilisez une version de Nextcloud, un environnement d'exécution PHP, un ensemble d'applications et une configuration identiques sur chaque nœud d'application. Choisissez des versions de MariaDB et Galera compatibles entre elles et prises en charge par la version de Nextcloud sélectionnée. La base de données Nextcloud doit impérativement utiliser InnoDB, l'isolation des transactions READ COMMITTED et désactiver la journalisation binaire ou le format ROW ; ne copiez pas les paramètres d'une version antérieure sans avoir vérifié la configuration requise.
Créez des noms DNS privés ou des adresses stables pour chaque membre de la base de données, chaque nœud web, le service de cache, le stockage partagé et le point d'accès web public. Réservez un point d'accès de base de données stable distinct pour les nœuds Nextcloud PHP. Séparez le trafic applicatif, de réplication et public sur des chemins réseau appropriés lorsque votre infrastructure le permet. Chaque nœud doit avoir un nom unique et chaque membre du cluster doit résoudre les noms des pairs Galera de manière cohérente.
Installez le serveur MariaDB et le fournisseur Galera à l'aide du dépôt recommandé pour votre système d'exploitation. Utilisez la même famille de serveurs et de fournisseurs sur tous les membres. N'utilisez pas de paquets communautaires non officiels avec une bibliothèque de fournisseur téléchargée séparément. Avant de poursuivre, vérifiez la procédure de mise à niveau, la méthode SST, l'unité de service et le répertoire d'inclusion de configuration compatibles avec cet ensemble de paquets.
Configurez le serveur pour utiliser InnoDB et le niveau d'isolation des transactions READ COMMITTED. Activez la journalisation binaire ROW si elle est activée. Vérifiez les valeurs effectives après le redémarrage au lieu de supposer qu'un fichier de configuration a été inclus. Nextcloud documente ces exigences dans son guide de configuration de base de données et sa configuration système requise .
Utilisez la documentation de configuration de votre fournisseur pour définir le nom du cluster, la liste des adresses des nœuds homologues, le nom et l'adresse uniques de chaque nœud, la bibliothèque du fournisseur et la méthode de transfert d'instantané d'état (SST). Le SST est le processus qui provisionne un nœud rejoignant le cluster avec l'état de la base de données. Une configuration de cluster MariaDB standard comprend des options de ce type :
[mariadb]
wsrep_on=ON
wsrep_cluster_name=nextcloud-cluster
wsrep_cluster_address=gcomm://db1.example.net,db2.example.net,db3.example.net
wsrep_node_name=db1
wsrep_node_address=db1.example.net
wsrep_sst_method=mariabackup
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
transaction_isolation=READ-COMMITTEDModifiez les valeurs spécifiques à chaque nœud sur chaque serveur. Les chemins d'accès aux fournisseurs et les méthodes SST prises en charge dépendent des paquets installés ; utilisez la méthode et les identifiants documentés pour votre version. Protégez les identifiants SST, les certificats et les mots de passe de la base de données comme des secrets. N'utilisez jamais une adresse de cluster vide comme paramètre permanent : MariaDB indique que cela peut entraîner la création d'un nouveau cluster au lieu de la réintégration du cluster existant.
Autorisez la couche web à accéder uniquement au point de terminaison du service de base de données et permettez aux membres de la base de données de communiquer entre eux via les ports de réplication et de transfert d'état Galera requis par votre fournisseur et la méthode SST choisie. Les déploiements Galera courants utilisent TCP et, selon les paramètres du fournisseur, UDP pour la communication de groupe ; les ports par défaut sont généralement 4567 pour la réplication, 4568 pour le transfert d'état incrémentiel et 4444 pour le transfert d'instantané d'état. Ces informations doivent être vérifiées en fonction de votre version et de votre configuration, et non pour justifier l'ouverture de tous les ports. Maintenez le port SQL privé et interdisez tout accès public.
Initialisez le cluster une seule fois en suivant la procédure d'amorçage documentée par le paquet MariaDB de votre distribution. Après avoir confirmé que le premier membre constitue le composant principal, démarrez les autres membres normalement afin qu'ils le rejoignent et reçoivent leur état via IST ou SST. IST transfère les ensembles d'écriture manquants lorsqu'ils sont disponibles ; SST effectue un transfert d'état complet. N'initialisez pas chaque hôte indépendamment et ne considérez pas un redémarrage comme une action d'amorçage.
Exécutez cette requête sur chaque membre de la base de données après son intégration :
SHOW GLOBAL STATUS WHERE Variable_name IN
('wsrep_cluster_status','wsrep_cluster_size','wsrep_ready',
'wsrep_connected','wsrep_local_state_comment');Vérifiez que chaque nœud est connecté et prêt, qu'il appartient au composant principal, qu'il indique la taille de cluster attendue et qu'il est synchronisé. MariaDB explique ces indicateurs dans son guide de surveillance Galera .
Créez la base de données avec le jeu de caractères et le classement requis par le guide d'installation Nextcloud. Créez un utilisateur de base de données dédié, limité au réseau de l'application, et accordez-lui uniquement les privilèges nécessaires à la configuration et au fonctionnement normal de Nextcloud. Utilisez TLS pour les connexions entre hôtes ou segments de réseau non fiables et validez les certificats lorsque votre déploiement le prend en charge. Ne saisissez pas les identifiants root dans le répertoire racine config.php.
Installez la même version de code Nextcloud, les mêmes extensions PHP, les mêmes applications activées et la même configuration serveur sur chaque nœud web. Configurez un seul point de terminaison de base de données partagé, et non des serveurs de base de données différents dans des fichiers par nœud. Tous les nœuds doivent utiliser le même ID d'instance, le même secret, les mêmes sels, la même politique de domaine de confiance et les mêmes paramètres d'instance. Stockez la configuration dans un processus de déploiement partagé contrôlé ou distribuez-la de manière sécurisée afin que les mises à jour restent identiques.
La couche de données des fichiers utilisateur doit être commune aux nœuds de l'application. Utilisez un système de fichiers partagé ou une architecture de stockage d'objets principale compatible avec votre version de Nextcloud et vos exigences opérationnelles. Le stockage des données utilisateur en local sur un seul serveur web compromet la reprise après incident : une requête acheminée vers un autre serveur ne permettrait pas d'accéder aux mêmes fichiers. Veillez à bien séparer le code de l'application et les chemins d'accès aux données accessibles en écriture, et validez le verrouillage des fichiers et la sémantique de stockage avant la mise en production.
Nextcloud configure généralement sa base de données lors de son installation. Une fois le point de terminaison de la base de données et le stockage partagé prêts, vérifiez que chaque nœud utilise les mêmes valeurs. Voici un exemple de configuration : conservez vos identifiants réels dans un système de gestion des secrets sécurisé et ne copiez pas cet extrait dans une configuration de production existante.
'dbtype' => 'mysql',
'dbname' => 'nextcloud',
'dbhost' => 'db-vip.internal:3306',
'dbuser' => 'nextcloud',
'dbpassword' => 'REPLACE_WITH_SECRET',
'datadirectory' => '/srv/nextcloud-data',
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
'host' => 'redis.internal',
'port' => 6379,
'password' => 'REPLACE_WITH_SECRET',
],Adaptez le système de cache et le répertoire de données aux options prises en charge par votre version de Nextcloud. Installez et configurez les extensions PHP requises, le cas échéant.
Utilisez APCu pour la mise en cache locale par hôte si nécessaire, et un service partagé compatible Redis tel que Redis ou Valkey pour la mise en cache distribuée et le verrouillage transactionnel des fichiers. Tous les nœuds web doivent utiliser le même service de cache ou un cluster de cache compatible, et non l'hôte local. Nextcloud documente la configuration des clusters Redis pour les architectures en cluster et précise que le verrouillage transactionnel des fichiers repose par défaut sur la base de données. Sécurisez le cache avec des restrictions réseau, une authentification et le protocole TLS lorsque cela est approprié ; la disponibilité du cache et le comportement en cas de basculement doivent être conçus spécifiquement.
Configurez Nextcloud pour qu'il utilise un point de terminaison stable fourni par un proxy de base de données ou une autre couche de routage compatible. Le proxy doit cesser d'envoyer de nouvelles connexions aux nœuds qui ne font pas partie du composant principal, qui ne sont pas synchronisés ou qui ne sont pas prêts. Une simple vérification de port TCP prouve uniquement qu'un socket accepte les connexions ; elle ne garantit pas que Galera puisse héberger l'application en toute sécurité. Examinez le comportement des contrôles d'intégrité et les modes de défaillance du proxy choisi. Si vous utilisez un simple équilibreur de charge TCP, associez-le à un contrôle de disponibilité Galera fiable et à des règles de routage robustes.
N'ajoutez pas le fractionnement lecture/écriture ni le routage round-robin à la légère. Le manuel développeur de Nextcloud décrit la prise en charge des connexions primaires/répliques et prévient que le routage des lectures à travers un cluster peut engendrer des problèmes de cohérence si les données n'ont pas été propagées ou si un proxy ne peut pas maintenir les lectures transactionnelles sur le nœud approprié. Commencez par un point de terminaison stable permettant l'écriture, effectuez des tests et n'introduisez un routage spécialisé que lorsque vous comprenez les implications en matière de cohérence et de prise en charge.
Placez au moins deux nœuds web derrière un équilibreur de charge et utilisez un mécanisme de disponibilité distinct pour ce dernier, tel qu'un service géré, une paire redondante ou une architecture d'adresses IP virtuelles éprouvée. Configurez la terminaison TLS, la taille des requêtes, le comportement du délai d'expiration et les exigences de persistance de session en fonction de votre déploiement. Consultez la documentation du proxy inverse de Nextcloud et configurez -le trusted_proxiesavec les adresses proxy réelles ; faire confiance à des plages d'adresses IP client arbitraires fragilise la gestion des adresses IP client.
Commencez par tester les mises à niveau sur une copie de test présentant la même topologie. Placez Nextcloud en mode maintenance lorsque la procédure de mise à niveau l'exige, appliquez la même version de l'application à chaque nœud et ne remettez les nœuds en service qu'après validation des tests d'intégrité. Pour la maintenance courante des hôtes, videz un nœud web à la fois et vérifiez que la capacité restante est suffisante. Appliquez les mises à niveau de la base de données en utilisant la procédure de mise à niveau progressive MariaDB/Galera recommandée pour les versions exactes concernées ; ne vous basez pas sur un tutoriel générique.
Sauvegardez la base de données et la couche de données des fichiers utilisateur en suivant une procédure documentée et cohérente avec l'application. Conservez la configuration, les éléments de chiffrement et les secrets à la disposition des opérateurs de récupération autorisés. Une réplique Galera n'est pas une sauvegarde : toute suppression accidentelle ou corruption logique peut se propager à chaque membre. Stockez les sauvegardes en dehors du domaine de défaillance du cluster et effectuez régulièrement des exercices de restauration. Galera documente les considérations relatives au transfert d'état et à la sauvegarde dans son guide de sauvegarde de cluster ; assurez-vous que toute procédure adoptée est compatible avec votre version de MariaDB.
Galera est un choix judicieux lorsque la redondance des nœuds de base de données est nécessaire, en présence de plusieurs domaines de défaillance, et que la surveillance du quorum et la mise en œuvre d'une reprise contrôlée sont possibles. En revanche, cette solution peut s'avérer inadaptée pour des opérations plus simples, lorsque la charge de travail de la base de données est principalement due à des conflits d'écriture, ou lorsque l'équipe ne peut pas réagir efficacement à une perte de quorum. Dans ces cas, un déploiement de base de données plus simple, bénéficiant d'un support technique et de sauvegardes robustes, ou un service de base de données managé, peut garantir une meilleure fiabilité opérationnelle.
Pour un service auto-hébergé de petite taille, commencez par rendre les nœuds d'application interchangeables, déplacez les fichiers utilisateur vers un stockage partagé durable, configurez le verrouillage Redis partagé et testez les sauvegardes. N'ajoutez Galera qu'après avoir constaté que la défaillance d'un seul nœud de la base de données ou la période de maintenance représente un risque inacceptable et que l'organisation est en mesure de gérer cette couche supplémentaire. Le véritable critère de réussite n'est pas le fonctionnement simultané des trois serveurs de base de données, mais plutôt la disponibilité de l'URL Nextcloud lors d'une panne planifiée d'un nœud, le bon fonctionnement des chargements et des téléchargements sur l'ensemble des nœuds web, le maintien du quorum de la base de données et la possibilité pour l'équipe de restaurer les données de la base de données et des fichiers à partir d'une sauvegarde.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
