Créez un cluster Nextcloud résilient avec Galera

Commencez par créer le cluster de base de données, puis placez plusieurs nœuds d'application Nextcloud identiques derrière un équilibreur de charge dont l'état est vérifié. Pour une configuration stable, tous les nœuds d'application doivent utiliser le même système de stockage de fichiers persistant, la même configuration, le même service de verrouillage Redis ou Valkey, et un point de terminaison de base de données qui achemine les écritures uniquement vers un membre Galera opérationnel. Le manuel d'administration actuel de Nextcloud mentionne MariaDB comme base de données prise en charge, mais ne fournit pas de procédure de déploiement spécifique à Galera ; vérifiez vos versions exactes de Nextcloud, MariaDB, Galera et proxy auprès des fournisseurs avant la mise en production.

Au 9 octobre 2026, la page des exigences système de Nextcloud 35 mentionne MariaDB 10.11, 11.4, 11.8 et 12.3, la version 12.3 étant recommandée. Il s'agit d'une liste de versions de la base de données Nextcloud, et non d'une garantie de compatibilité avec toutes les combinaisons Galera ou proxy. Consultez la configuration système requise pour Nextcloud 35 et la matrice de compatibilité Galera de votre distribution MariaDB.

1. Définir les limites de défaillance

Un cluster à haute disponibilité ne se limite pas à une base de données répliquée. Galera protège la couche base de données ; il ne réplique pas les fichiers utilisateur, les sessions PHP, les verrous Redis ni le code applicatif de Nextcloud. Une base de données partagée unique ne peut pas non plus compenser une défaillance de montage de stockage ou un équilibreur de charge qui continue d'envoyer du trafic vers un nœud d'application défaillant.

Planifiez ces composants avant l'installation :

• Au moins deux serveurs d'applications exécutant la même version de Nextcloud, la même version de PHP, les mêmes applications activées et la même configuration web.
• Un équilibreur de charge ou un proxy inverse avec un nom d'hôte public stable, HTTPS et des contrôles d'intégrité pour les serveurs d'applications.
• Un espace de stockage de données Nextcloud partagé et durable, accessible au même emplacement et avec les autorisations appropriées sur chaque serveur d'applications. Le répertoire de données Nextcloud doit être défini lors de l'installation ; les instructions d'installation précisent qu'il est difficile de le déplacer ultérieurement.
• Un cluster Galera avec un nombre impair de nœuds de base de données de vote, généralement trois, placés de manière à ce qu'une panne d'hôte ne supprime pas la majorité.
• Un service Redis ou Valkey partagé pour la mise en cache distribuée et les verrous de fichiers transactionnels.

Choisissez des architectures de stockage et de réseau dotées de redondance et de procédures de récupération éprouvées. Un chemin partagé n'est pas automatiquement hautement disponible, même si plusieurs serveurs web peuvent y accéder.

2. Installez et validez d'abord MariaDB Galera.

Choisissez une version de MariaDB compatible avec les exigences actuelles de Nextcloud et un package Galera correspondant pris en charge par votre fournisseur MariaDB. Suivez la documentation de déploiement de MariaDB Galera pour la configuration des nœuds, les ports réseau, le transfert des instantanés d'état, TLS et l'initialisation. Ne démarrez pas chaque nœud vide comme un nouveau cluster ; initialisez un nœud, puis ajoutez les autres à ce cluster.

Nextcloud requiert InnoDB et le READ-COMMITTEDniveau d'isolation des transactions pour MySQL ou MariaDB. La page de configuration de Nextcloud recommande également la journalisation binaire au niveau des lignes. Vérifiez les valeurs sur chaque nœud de base de données, et pas seulement sur celui qui reçoit actuellement le trafic. Consultez la configuration requise pour Nextcloud concernant MariaDB .

Avant de connecter Nextcloud, vérifiez l'état du cluster sur chaque nœud. Par exemple, exécutez les commandes `npm install` SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status';et ` npm install` SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';. Le cluster devrait indiquer un Primarycomposant, la taille attendue du cluster et l' Syncedétat des nœuds. MariaDB explique que le quorum requiert plus de la moitié des derniers membres connus du cluster ; un cluster à trois nœuds peut donc tolérer la perte d'un nœud, mais pas de deux. Consultez la documentation relative au quorum et à la récupération .

3. Fournir à Nextcloud un point de terminaison de base de données sensible à l'état de santé

Configurez Nextcloud pour qu'il se connecte à une adresse proxy de base de données stable, et non à une liste d'adresses IP Galera réparties aléatoirement. Bien que Galera réplique les écritures sur l'ensemble du cluster, les applications nécessitent une gestion des transactions prévisible. Un proxy surveillant l'appartenance à Galera peut interrompre le routage vers les nœuds indisponibles ou non synchronisés et sélectionner un nœud d'écriture. Le moniteur Galera de MariaDB MaxScale est une option documentée ; son comportement exact et les modes de routage pris en charge dépendent de la version et de la configuration de MaxScale.

Utilisez le point de terminaison de connexion documenté du proxy comme celui de Nextcloud dbhost. Créez des comptes distincts, avec les privilèges minimaux, pour la surveillance et l'accès aux applications, protégez les identifiants et chiffrez le trafic de la base de données lorsqu'il traverse un réseau non sécurisé. Évitez d'activer la séparation lecture/écriture, même si cela semble être un gain de performance : la fonctionnalité de réplication de Nextcloud envoie les lectures vers les répliques tout en conservant les écritures et les lectures causales sur la connexion par défaut, mais Galera n'est pas une architecture de réplication asynchrone classique. Utilisez une architecture de routage testée spécifiquement pour votre infrastructure.

4. Faites en sorte que chaque nœud d'application voie la même instance Nextcloud.

Installez le même code et la même suite d'applications Nextcloud sur chaque serveur d'applications. Assurez-vous que chaque nœud config.phpde l'instance partagée possède une configuration cohérente, notamment son point de terminaison de base de données, ses clés secrètes, ses domaines de confiance et le chemin d'accès au répertoire de données. N'effectuez pas de mise à niveau indépendamment sur plusieurs nœuds. Sauvegardez d'abord les données, placez l'instance en mode maintenance, effectuez la mise à niveau via une méthode unique et contrôlée, et rétablissez le trafic uniquement lorsque tous les nœuds exécutent la même version.

Configurez tous les nœuds de l'application pour utiliser le même service Redis ou Valkey pour la mise en cache distribuée et le verrouillage. Un cache local tel qu'APCu peut rester local au nœud, mais memcache.distributeddoit memcache.lockingpointer vers un service commun, et non vers le service de chaque serveur localhost. Par exemple, la configuration Redis de Nextcloud peut utiliser 'memcache.locking' => '\OC\Memcache\Redis'un hôte Redis partagé redis. Suivez le guide de configuration du cache et le guide de verrouillage transactionnel des fichiers . Memcached n'est pas adapté aux verrous transactionnels de fichiers de Nextcloud.

Si vous centralisez également les sessions PHP dans Redis, considérez cela comme une tâche de configuration PHP distincte. La documentation de Nextcloud indique que le verrouillage de session n'est pas activé par défaut pour le gestionnaire de sessions Redis ; appliquez ses paramètres de verrouillage et testez le comportement des sessions avant de vous y fier. Ne confondez pas la réplication de la base de données ou le verrouillage des fichiers avec la continuité des sessions.

5. Tester le basculement avant de le qualifier de hautement disponible.

Commencez par vérifier le bon fonctionnement via le nom d'hôte public : connectez-vous, téléchargez et chargez un fichier de test, puis assurez-vous qu'il est visible après qu'une requête a atteint un autre nœud d'application. Ensuite, videz un nœud web et vérifiez que les requêtes continuent de transiter par l'autre. Enfin, restaurez-le et vérifiez qu'il se reconnecte sans servir de code ou de version de configuration obsolète.

Ensuite, profitez d'une fenêtre de maintenance pour simuler la défaillance d'un nœud de base de données, conformément au manuel d'exploitation de votre fournisseur. Vérifiez que le proxy supprime bien le membre défaillant ou non synchronisé, que Nextcloud peut toujours lire et écrire, et que le nœud de retour atteint sa destination Syncedavant d'accepter le trafic. Surveillez l'état du nœud principal Galera, la taille du cluster, la synchronisation des nœuds, l'état du proxy, les erreurs d'application et l'état des points de montage de stockage.

Une perte de quorum est une mesure de sécurité, et non la preuve que les données sont perdues. Ne forcez pas le démarrage de plusieurs nœuds et n'en choisissez pas un au hasard. Le guide de récupération de MariaDB recommande d'identifier le nœud le plus avancé, de le démarrer uniquement, puis de réintégrer les autres. Assurez-vous également d'avoir testé les sauvegardes de la base de données et du stockage de fichiers ; la réplication Galera réplique les modifications de la base de données et ne remplace pas les sauvegardes à un instant donné.

Vérifier le résultat

La configuration est prête pour la production uniquement lorsque la mise hors service d'un nœud d'application et d'un nœud de base de données n'interrompt pas les opérations de fichiers, que tous les nœuds Galera restants appartiennent à un composant principal et que le stockage de fichiers partagé ainsi que le service Redis ou Valkey restent accessibles. En cas d'échec d'un test, identifiez le niveau ayant cessé de traiter la requête avant de modifier les délais d'attente ou les paramètres de nouvelle tentative. Le manuel Nextcloud documente les configurations de base de données et d'application prises en charge, tandis que la matrice de compatibilité des fournisseurs et vos tests de basculement déterminent si ce déploiement Galera spécifique est compatible.