Nextcloud : des retours sur de grosses instances ?

neil · March 9, 2025, 4:32pm

Bonjour tout le monde,

Je suis intéressé par des retours d’expérience de CHATONS (ou pas CHATONS) ayant dû gérer un Nextcloud de grande taille.
Je ne parle pas de la gestion de nombreuses instances (comme c’est le cas pour Framaspace) mais bien d’une seule instance qui accueillerait plusieurs milliers de personnes.
Donc je recherche plutôt des retours sur des outils comme Framagenda ou Framadrive (ce dernier étant par ailleurs limité à 5000 utilisateur·ices), ou toute autre instance dont l’usage est mutualisé avec les autres utilisateur·ices, qui dépasse a minima les 100 personnes.

Combien d’utilisateur·ices hébergez vous sur votre instance ?
Pour cette instance, comment le serveur est-il dimensionné ? Vous avez combien en consommation moyenne disque / CPU / RAM ?
Utilisez-vous des configurations ou modules particuliers ? Par exemple : cache Redis, Cron système, réplication, load balancing, configuration de BDD spécifique…
Nextcloud gère-t-il bien la montée en charge, de manière générale ?
Une instance de cette taille nécessite-t-elle des précautions particulières par rapport à une instance classique ? Par exemple :
- Opérations de maintenance spécifiques ;
- Concernant le cloisonnement des utilisateur·ices sur l’instance ;
- Autre…
Parmi les applications suivantes, lesquelles sont les plus faciles à maintenir ? Lesquelles sont les plus difficiles ou coûteuses en consommation de ressources ? Pourquoi ? :
- Files
- Calendar
- Contacts
- Polls
- Forms
- Talk
- Activity
- Deck
- Autre (spécifiez)
Avez-vous déjà eu à modérer du contenu sur cette instance ? Souvent ? Comment ça se passe ?
Questions sur Collabora/Onlyoffice (si applicable) :
- Utilisez-vous une version « débridée » du logiciel pour passer outre les limites d’utilisation concurrente de l’éditeur sur la version gratuite ?
- Mutualisez-vous l’instance Office avec d’autres instances de Nextcloud ?
- Comment l’instance est-elle dimensionnée ? (conso CPU/RAM)
- Quels problèmes rencontrez-vous (ou avez-vous rencontré) avec ce logiciel ?

Je me permets un petit ping @Zaclys @infini @Framasoft @Libretic, si jamais vous avez un peu de temps pour partager vos expériences, ça nous sera utile
(et si vous avez de la documentation ou des confs qui présentent déjà tout cela en détail, je prends également volontiers.)

Merci !

bohwaz · March 9, 2025, 10:15pm

Je réponds pas pour NextCloud, mais pour Collabora : on paye Collabora 2000 € / an pour avoir le support et les paquets Debian débridés officiels.

En pratique on ne gère plus notre instance, c’est notre hébergeur Octopuce qui a une grosse instance Collabora qu’il partage entre tous ses clients. Tu peux peut-être les contacter car ils ont peut-être aussi des grosses instances NextCloud ?

On a eu des soucis de perte de données sur les documents, mais ça semble résolu maintenant. En général quand on a un bug, on remonte au support et dans les semaines qui suivent c’est corrigé. Généralement je remonte le bug à la fois sur Github pour que d’autres qui auraient le même souci puissent tomber dessus, et à la fois via le support commercial.

BOC47_Admin · March 10, 2025, 10:38pm

Bonsoir, les petits nouveaux de BOC47 vont essayer de vous donner un peu de matière par rapport à notre instance, si besoin de compléments, n’hésitez pas. Notre instance Nextcloud existe depuis un peu plus d’un an et demi et, à ce jour, nous comptons pas loin de 300 utilisateurs, j’avais déjà eu l’occasion d’installer plusieurs instances auto-hébergées à titre personnel mais rien qui me permettait d’avoir du recul sur ce projet quant aux thématiques que vous abordez. Ma prise de poste au sein du collectif depuis Février 2024 me permet désormais de mieux les évaluer avec une instance qui est clairement utilisée et évolue au fur et à mesure. Même dans le cadre d’une instance privée avec très peu d’utilisateurs, je trouvais que Nextcloud était un peu « usine à gaz », à la différence d’autres projets similaires (quoique moins complets) comme Seafile; aujourd’hui, je dois dire que ce n’est plus le cas et que, au vu de toutes les fonctions que ce logiciel remplit, il s’en sort particulièrement bien en termes de charge. J’ai beaucoup travaillé dessus mais ce n’est pas moi qui avait procédé à l’installation initiale, notre conteneur Proxmox abritant notre instance dispose de 2 To de stockage dédié aux données, de 8 coeurs et de 16 Go de RAM et, clairement, avec ce dimensionnement de ressources, on est loin de le saturer, globalement, on doit consommer 4 Go de RAM et à peine 10/15 % du CPU pendant les horaires de bureau + environ 650 Go de consommé en termes de stockage, j’avais envisagé de les réduire mais, ayant les mêmes craintes que vous concernant une montée en charge subite, je les ai conservées. Toutefois, malgré une nette augmentation de nos utilisateurs en 2024, les exigences matérielles de notre instance n’ont que peu évoluées voir quasiment pas du tout donc, oui, Nextcloud gère très bien la montée en charge. Pour la configuration, à aujourd’hui encore, rien de très spécifique de notre côté : pas (encore) d’équilibrage de charge, de réplication (même si c’est dans les cartons), pas de BDD séparée (ça aussi c’est en réflexion pour le futur), tâches cron et cache Redis, effectivement oui. Plutôt qu’Apache, c’est Nginx qui fait office de serveur web, là dessus il a fallu beaucoup travailler pour avoir une instance qui tourne bien : on a un reverse proxy nginx en frontal de tous nos conteneurs et Nextcloud ne passe pas parfaitement bien derrière un proxy qui fait de la décharge SSL, j’ai opté pour l’utilisation du module stream de Nginx pour certains cas particuliers dont Nextcloud, ainsi, on fait plutôt du TCP passthrough, le serveur nextcloud écoute sur le port 443, gère lui-même son certificat et sa sécurité et nous n’avons plus d’erreur de réécriture d’URL comme cela arrivait souvent au début (même si ma conf nginx suivait la doc officielle et les réécritures nécessaires + d’autres trouvées sur le forum officiel). Sa sécurisation via les conf proxy et serveur web + un WAF (Crowdsec en ce qui nous concerne) sont nécessaires car ce service héberge des données personnelles, hormis cela, pas vraiment de précaution particulière (ou alors je n’ai pas bien compris la question ). Des applications que vous citez, toutes sont faciles à maintenir car intégrées, Talk nécessitera de la configuration supplémentaire (un serveur coturn séparé, une bonne bande passante voire de la QOS pour prioriser le traffic => solution visio = latence la plus faible possible, je crois que nos soucis viennent plus de là que de la configuration, d’ailleurs). Pour la modération, en l’état actuel, ça n’est jamais encore arrivé et, en cherchant un peu, certaines nouvelles extensions permettent de le faire mais pas de manière générale, plutôt dans un contexte particulier comme le partage de liens publics, au préalable, les fichiers sont scannés par un antivirus mais cela s’arrête là dans le contrôle des données uploadées + le fait que notre instance doit permettre la collaboration et être plus respectueuse de la vie privée et des données personnelles que les services des GAFAM donc pas de surveillance/modération mais une incitation à la responsabilisation (également sur le volet consommation de l’espace de stockage). Pour Onlyoffice que nous utilisons pour la création/édition de documents, effectivement, nous utilisons une version débridée sinon ce ne serait pas viable, si besoin de liens, n’hésitez pas à demander et en termes de consommation des ressources, on est larges avec 2 coeurs/4 Go de RAM et un espace de stockage de 50 Go, c’est que de l’applicatif, je pourrais même réduire, les seuls problèmes rencontrés avec OnlyOffice concerne plus le couple Nextcloud/OnlyOffice via le connecteur officiel, attention aux versions, essayez d’être toujours au plus proche des dernières versions que ce soit Nextcloud, le connecteur OO ou le serveur Office, depuis quelques temps, plus de réel souci à ce niveau là car on est à jour et que de nouvelles fonctionnalités importantes n’ont pas été implémentées depuis deux trois versions mais on effectivement eu des périodes où on était à jour de quasiment tout sauf du serveur OO et ça créait des erreurs dans Nextcloud. Voilà, j’espère avoir répondu à au moins une partie de vos questions, si besoin de compléments et que je suis en capacité de répondre, pas de souci. Bonne soirée. Renaud.

Bschalck · March 11, 2025, 6:39am

Hello !

Merci pour ce retour
Une question : y a-t-il une raison particulière d’utiliser onlyoffice au lieu de Collabora ?

BOC47_Admin · March 11, 2025, 10:50am

Bonjour, avec plaisir, pas de souci, je pense que c’est plus pour permettre aux personnes désireuses de basculer vers nos services de pouvoir effectuer la transition en douceur, généralement utilisatrices des solutions Microsoft Office, elles peuvent ainsi garder leurs habitudes et leurs documents sous format natif.

tcit · March 11, 2025, 12:35pm

Je réponds pour Framagenda/Framadrive (et avec 2/3 détails sur Framaspace). Il est possible qu’un collègue vienne compléter.

Combien d’utilisateur·ices hébergez vous sur votre instance ?
138156 / 6647. Évidemment, le nombre d’utilisateurs actifs mensuellement est beaucoup plus faible - autour de 10%. Nous avons comme objectif de redévelopper une application pour purger les utilisateurs inactifs - je l’avais fait il y a 8 ans, mais ça fait très longtemps qu’elle ne fonctionne plus.

Pour cette instance, comment le serveur est-il dimensionné ? Vous avez combien en consommation moyenne disque / CPU / RAM ?

Pour les deux services, la base de données se trouve sur un autre serveur (grâce à pgbouncer). La consommation RAM n’a jamais été trop le point critique, on a énormément de mémoire cache.

Information	Framagenda	Framadrive
Modèle du serveur principal	AX51-NVMe (équivalent AX52)	EX42 (équivalent EX44)
Modèle du serveur de base de données	AX41-NVMe (équivalent AX42)	EX41-SSD (équivalent EX44)
Load average	Entre 2 et 14 (pics sur les jours de semaine) « ça passe »	Entre 0,5 et 1,5 « c’est très large »

Utilisez-vous des configurations ou modules particuliers ? Par exemple : cache Redis, Cron système, réplication, load balancing, configuration de BDD spécifique…

Redis utilisé partout où c’est possible comme cache Nextcloud. Il y a aussi la possibilité de mettre les sessions PHP dans Redis (on le fait parfois). Cron système évidemment (réglé à 5 minutes, avec un fichier de lock). Pas de réplication, ni de load balancing. Quelques tweaks de configuration pgbouncer (nombre de connexion). L’application notify_push évite énormément de requêtes de polling pour des changements de la part des clients bureau.
Nextcloud gère-t-il bien la montée en charge, de manière générale ?

À notre échelle, oui, mais notre nombre d’utilisateur·ices évolue lentement. C’est plus les mises à jour qui posent parfois des problèmes de performance.
Une instance de cette taille nécessite-t-elle des précautions particulières par rapport à une instance classique ?
- Évidemment, upgrade uniquement via CLI pour éviter un timeout si fait côté web (upgrade.disable-web pour forcer upgrade via CLI).
- Framagenda étant concentré sur les agendas, on a un job cron dédié pour ça dav:send-event-reminders (pour être sûr que le rappel de l’événement est envoyé à temps).
- Concernant le cloisonnement des utilisateur·ices sur l’instance, on désactive l’autocomplétion tant que l’identifiant ou l’email n’est pas entré en entier (il reste qu’on peut utiliser cette méthode pour vérifier si un utilisateur existe par exemple).
Parmi les applications suivantes, lesquelles sont les plus faciles à maintenir ? Lesquelles sont les plus difficiles ou coûteuses en consommation de ressources ?
- Polls n’est pas une application officielle et son développeur… a du mal à comprendre ce que sont des migrations de base de données, gérant les choses à sa sauce. Ainsi, la migration de cette application était souvent ce qui prenait le plus longtemps lors des mises à jour de Framagenda. L’application est assez pratique, mais codée un peu n’importe comment. C’est notamment la raison qui fait qu’on ne l’a pas installée jusqu’ici sur Framaspace.
- Talk, en l’absence du backend de haute performance, fait en permanence des long polling côté serveur pour récupérer les nouveaux messages, ce qui monopolise les threads php-fpm. L’application semble trop peu utilisée pour que ça soit gênant sur Framagenda ou Framadrive, mais on a patché pour Framaspace, en attendant d’avoir le temps de mettre en place le backend de haute performance.
- Cercles/Équipes a un niveau d’abstraction assez énorme, pas mal de bidouilles propres à l’auteur et du code de qualité discutable, ce qui mène souvent à des problèmes de régressions. Par exemple on a ce patch non mergé sur Framagenda (qui fait logiquement beaucoup d’appels pour lister les agendas et leurs permissions). Mais bon, pas trop le choix, c’est dans le core et ça reste utile.
On n’a pas de problèmes avec le reste, de ce que je me souvienne.
Avez-vous déjà eu à modérer du contenu sur cette instance ? Souvent ? Comment ça se passe ?
Jamais de modération du contenu, juste une fois ou deux une personne qui a partagé un contenu avec le mauvais compte, ce qui mène à incompréhension.
Questions sur Collabora/Onlyoffice
Non déployé sur Framagenda et Framadrive. Sur Framaspace on a principalement (97% des espaces) du Collabora débridé, dockerisés et répartis sur 2 VM dédiées « office » de 4-6 vCPU et 30GB de RAM chaque. On est pour le moment sur 50 espaces par Collabora dockerisé (mutualisé, donc), mais c’est pas sûr que le ratio soit le plus optimal. On observe parfois des processus zombies et des pics de mémoire avec les conteneurs Collabora, donc on a mis un restart nocturne des conteneurs faute de mieux, et il faut encore qu’on affine quelques trucs (utiliser les limites de ressources Docker).
On n’a pas (encore) d’OnlyOffice débridé, on en utilise un par espace (encore dockerisé).

De manière générale c’est clair que c’est difficile de provisionner de manière optimale, certains groupes d’utilisateur·ices ne vont jamais utiliser les offices quand d’autres vont se connecter tous au même moment.

On a quelques détails supplémentaires sur notre infra par ici :

rodinux · March 11, 2025, 12:48pm

Bonjour,
Je peux partager l’expérience de Numericloud, presque 900 utilisateur·ices actuellement ().sur une VM avec une stack Docker. Nous utilisons un build de l’image apache-full pour ajouter entre autres des configs adaptées pour opcache et php, quelques configurations aussi pour le cron (utilisation de preview-generator et de memories pour un club photo).
La VM utilise docker et Portainer avec pas mal de ressources (10CPU/16G de RAM), sachant qu’il a d’autres stacks aussi attachées à cette VM. Nextcloud va utilisé plutôt vers les 4G de ram
pour l’utilisation des CPU il reste plutôt en-dessous des 20%, mais peut avoir des pics.
Tout cela aussi sur un Promox, un volume pour /var/www/html sur du RAID ssd et les data un RAID sata. Il faut ajouter à cela un disque de cache, le risque est d’avoir beaucoup d’écritures disques I/O…
Sinon nextcloud semble bien gérer la charge, mais par exemple avec des grosses instances comme celle-ci, les mises à jour des modules demande de mettre le serveur en mode maintenance et sont un peu plus longues. Il y a parfois des bugs à corriger soit sur des applications, soit dans le core de Nextcloud. Il peut y avoir des choses à corriger, rarement dans
la BDD.
Pour les exemples d’application, Polls a déjà eu des versions avec des changement de tables qui cassait l’application, mais c’était possible de résoudre, il y a même une commande occ maintenant pour la migration des tables de polls…
Calendar et Contacts, ça va dépendre du nombres d’utilisateurs qui synchronisent avec le webdav, mais ça semble bien gérer.
Talk est clairement gourmand en ressources. Nous avons installer un serveur Hautes Performances (spreed-signaling) sur autre VM qui permet de faire des visios, qui gère aussi Coturn.
Activity, j’ai entendu autrefois que cette app consommait beaucoup de ressources, mais je pense que ce n’est plus le cas.
Deck, rien à dire, ça fonctionne bien.
Nous utilisons Collabora Office pour l’édition collaborative. Parfois le service Collabora est dans la stack pour l’instance Nextcloud dédiée seulement, ou sur un serveur Collabora code qui peut mutualiser des instances, ainsi qu’un serveur Collabora Online, car partenaires de Collabora. Collabora demande peut-être plus de ressources que OnlyOffice puisque les requêtes sont plus côté serveur. Le fichier de configuration coolwsd.xml pour collabora est touffu, mais assez explicite…
Petite parenthèse, Nextcloud aussi avec Yunohost a l’avantage d’être très bien maintenu et la future version de Yuno qui arrive bientôt va améliorer les performances du LDAP dans le cas où les utilisateurs sont nombreux. Le paquet Collabora et OnlyOffice aussi sont maintenus, il y a une app Coturn et une app Signaling pour Talk. Depuis peu on peu aussi ajouter Notify-push…

Ce qui est embêtant c’est le client de synchronisation qui suivant les OS fonctionne plus ou moins bien. Sans parler de modération, il y a souvent un besoin d’aider les utilisateurs avec leurs synchronisations…

neil · March 11, 2025, 3:33pm

Un grand merci pour vos incroyables retours. J’ai bien fait de demander ici

Je suis assez étonné pour la consommation en RAM, chez nous on a deux instances de Collabora pour 8 instances de Nextcloud, et chaque Collabora prend 2 Go en moyenne, et monte parfois à plus de 5 Go à cause de « sessions fantômes » (même problème que tcit a mentionné, je pense).
Je retiens l’astuce de tcit sur la cron nocturne pour Collabora.

Question bête, mais maintenant que ./occ user:lastseen --all a été introduit dans la version 29, est-ce que tu penses qu’il serait envisageable de scripter une routine avec notification:generate, user:disable et user:delete pour votre cas d’utilisation, ou cela ne prendrait pas en compte certaines problématiques ? (après, ce n’est peut-être juste pas votre priorité)

En tout cas, votre nombre de comptes est délirant sur Framagenda, je ne pensais pas que NC pouvait en supporter autant.

Il me semblait que dans votre conf aux JRES que vous utilisiez plutôt pgpool-II, est-ce que vous avez changé entre temps, ou alors pg_bouncer ne concerne que Framadrive/Framagenda et pas framaspace ? (ou alors, vous utilisez la combinaison des deux ?)

Ça, c’est super intéressant. Est-ce qu’une instance de notify_push peut être mutualisée sur plusieurs instances Nextcloud, par hasard ? (je vois qu’il faut lui donner le fichier de configuration NC, donc dans l’idée ça m’a l’air compliqué.)

Ah, oui, le développeur de Polls… Même retour pour ma part, et le retour de tcit vient corroborer. J’ai déjà eu à restaurer un backup sur ses tables à cause d’une migration de son app.
Je trouve aussi qu’il y a du mieux depuis un an.

tcit · March 11, 2025, 4:33pm

En fait, je me suis trompé, on a bien commencé à mettre ça en place, avec une limite à un petit peu plus de 2Go, et un autorestart du conteneur si jamais la mémoire est atteinte (ce qui arrive). On n’a pas encore eu de retours comme quoi c’était inutilisable . La plupart des conteneurs idle sont à 200/300Mo.

Je ne connaissais pas cette commande, merci. Ça pourrait marcher ainsi, mais il y aurait quand même besoin de bricoler un peu plus, notamment stocker la liste des comptes concernés quelque part avec un statut si on veut plusieurs emails d’avertissement (oui, car les notifications ne déclenchent pas forcément l’envoi d’un mail, et les mails de notification ne seraient pas explicites, donc je préfère un vrai mail). Vu qu’il ne semble pas avoir de pagination sur cette commande, ça pourrait être aussi un peu violent. De plus, une application dédiée permettrait également à n’importe qui de l’installer, donc ça serait quand même bénéfique pour nous.

Et encore, il y a aussi du monde qui supprime rapidement son compte après avoir testé et être insatisfait grâce à notre application.
Même sans le système Global Scale, il y a clairement encore de la place pour scale verticalement et horizontalement (ouais, y a enfin des transactions à peu près correctes dans Nextcloud), tant qu’on ne regarde pas à la dépense…
Mais dans le cas de Framagenda, rappel que le nombre d’utilisateurs actifs est bien plus faible… et qu’on ne s’occupe pas de fichiers ! Même avec 24M d’événements en BDD et 2.5M de contacts, la taille de la base de données (140GB) n’est pas forcément le point le plus gênant.

Oui, c’est bien cela, pgpool sur Framaspace et pg_bouncer sur Framadrive/Framagenda Je laisse @Framasky expliquer le choix (probablement le fait que pg_bouncer ne fait pas de load balancing ?).

Hélas non, ce qui fait aussi qu’on ne l’a pas non plus sur Framaspace. Et faut même plusieurs redis séparés à cause de prefix redis channels with redis db id by icewind1991 · Pull Request #202 · nextcloud/notify_push · GitHub qui n’est pas mergé.

b_b · March 11, 2025, 8:05pm

Salut, je réponds pour @infini :

Les infos sur notre instance sont dispos ici https://cloud.infini.fr/ocs/v2.php/apps/serverinfo/api/v1/info?format=json

Combien d’utilisateur·ices hébergez vous sur votre instance ?

244

Pour cette instance, comment le serveur est-il dimensionné ? Vous avez combien en consommation moyenne disque / CPU / RAM ?

Comme tous nos services (sauf etherpad qui ne le permet pas facilement), nextcloud est installé en mode HA sur deux vms dont voici les caractéristiques à l’instant :

Cpu ................: 6 x  QEMU Virtual CPU version 2.5+ @ 2397.222
Memory .............: 145.00 Mo (Free) / 7978.09 Mo (Total)
Load Averages ......: 0.32, 0.41, 0.43 (1, 5, 15 min)

Utilisez-vous des configurations ou modules particuliers ? Par exemple : cache Redis, Cron système, réplication, load balancing, configuration de BDD spécifique…

Cron système comme tout le monde
load balancing avec haproxy entre les deux vms qui portent l’instance
base de données posée sur notre cluster galera propulsé par mariadb sur 5 nodes
cache, le point le plus important pour ne pas se galérer cf Redirect loop login / Renewing session token failed · Issue #13431 · nextcloud/server · GitHub par exemple

Pour le cache donc, on applique ce que je citais ici Redirect loop login / Renewing session token failed · Issue #13431 · nextcloud/server · GitHub pour les sessions PHP gérées par memcached, sinon on est sur de la conf « classique » cf :

  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',

Puis du memcached_servers branché sur notre pool memcached de trois nodes.

Nextcloud gère-t-il bien la montée en charge, de manière générale ?

Aucun pb a signaler de notre côté, mais notre instance n’est pas très sollicitée par rapport à d’autres.

Parmi les applications suivantes, lesquelles sont les plus faciles à maintenir ?

Voici la liste des apps qu’on propose, aucune ne nous a jamais posé de pb.

  - activity: 2.21.1
  - calendar: 4.7.16
  - cloud_federation_api: 1.12.0
  - comments: 1.19.0
  - contacts: 6.0.3
  - dashboard: 7.9.0
  - dav: 1.30.1
  - deck: 1.13.4
  - drawio: 3.0.3
  - federatedfilesharing: 1.19.0
  - federation: 1.19.0
  - files: 2.1.1
  - files_downloadlimit: 2.0.0
  - files_pdfviewer: 2.10.0
  - files_reminders: 1.2.0
  - files_sharing: 1.21.0
  - files_trashbin: 1.19.0
  - files_versions: 1.22.0
  - firstrunwizard: 2.18.0
  - gpoddersync: 3.12.0
  - logreader: 2.14.0
  - lookup_server_connector: 1.17.0
  - news: 24.0.0
  - nextcloud_announcements: 1.18.0
  - notes: 4.11.0
  - notifications: 2.17.0
  - oauth2: 1.17.1
  - password_policy: 1.19.0
  - photos: 2.5.0
  - privacy: 1.13.0
  - provisioning_api: 1.19.0
  - recommendations: 2.1.0
  - related_resources: 1.4.0
  - serverinfo: 1.19.0
  - settings: 1.12.0
  - sharebymail: 1.19.0
  - support: 1.12.0
  - systemtags: 1.19.0
  - tables: 0.9.0
  - tasks: 0.16.1
  - text: 3.10.1
  - theming: 2.4.0
  - twofactor_backupcodes: 1.18.0
  - updatenotification: 1.19.1
  - user_status: 1.9.0
  - viewer: 2.3.0
  - weather_status: 1.9.0
  - workflowengine: 2.11.0

Avez-vous déjà eu à modérer du contenu sur cette instance ? Souvent ? Comment ça se passe ?

Jamais, on a lutim et lufi pour nous occuper sur le sujet

Questions sur Collabora/Onlyoffice (si applicable)

On ne les propose pas.

bohwaz · March 12, 2025, 3:49pm

Je suis étonné de voir l’idée de restart des conteneurs Collabora, car si vous faites ça et que des gens sont en train d’éditer des contenus, ils risquent de perdre leurs modifs (dans Collabora c’est le serveur qui édite le document, le client n’a qu’une vue de ce que le serveur fait, donc si on kill le serveur, le document en cours d’édition est perdu si non enregistré). Bon il y a normalement une sauvegarde auto, mais ça me semble risqué quand même.

D’autre part je ne suis pas sûr qu’utiliser beaucoup de conteneurs Collabora (par exemple un pour chaque instance NextCloud) soit le mieux niveau ressources, car ce qui prend de la RAM c’est l’instance Collabora (penser que c’est comme si on lance un LibreOffice, sans ouvrir de document), ensuite chaque document et chaque utilisateur prend un peu de RAM mais ça reste faible. Sur le paquet Collabora Debian voici ce que je mesure :

Collabora sans aucun document ouvert = 400 Mo de RAM
Document texte vide ouvert = 15 Mo
Document texte de 50 pages ouvert (taille du doc = 250 Ko) = 50 Mo
Document texte de 13 pages ouvert avec plein d’images (taille du doc = 13 Mo) = 50 Mo
Chaque utilisateur connecté à un document = ~2 Mo (quel que soit le type de document)

Collabora une console admin très utile pour suivre ça, qu’on peut activer via une directive de coolwsd.xml

tcit · March 12, 2025, 4:11pm

La logique c’était surtout de se dire que si le Collabora a besoin de 27GB de mémoire (on a déjà eu des OOM sur notre VM à 30GB de RAM) c’est probablement que les modifications sont déjà perdues. Mettre une limite permet d’éviter qu’un conteneur rende indisponible les X autres sur le même serveur en prenant toute cette mémoire. Maintenant, y a besoin qu’on affine un peu et qu’on étudie les éventuels retours. Potentiellement la fuite mémoire a été corrigée depuis.

C’est clairement pas ce qu’on fait hein, on est actuellement à 50 espaces sur chaque conteneur Collabora. Mais on est bien d’accord sur la logique que tu décris. Il me semble toutefois qu’on avait entendu parler et identifié des limites sur le nombre de connexions globales à un serveur Collabora, non pas sur la mémoire utilisée, mais sur les performances du rendu des tuiles et de la réactivité perçue du service.
Imaginons qu’à 18h30, 100 assos (5% de nos espaces totaux) avec en moyenne 1,5 personne se connectent en même temps, ça fait un sacré pic qui peut être bien mieux réparti par le fait qu’on utilise plusieurs conteneurs et plusieurs serveurs physiques.

Après, pareil, le nombre est un curseur qui peut bouger un peu (et Collabora produit souvent des améliorations satisfaisantes).

ljf · March 13, 2025, 8:16am

La plus grosse instance nextcloud que je gère à 800 utilisateurices (mais c’est un intranet et certaines personnes se connectent rarement). C’est un setup nextcloud_ynh (avec yunohost) standard avec un peu d’optimisation sur php fpm. Elle est dimensionnée avec 3Go de ram et 2vcpu. Seuls une trentaine de personnes sont censées pouvoir déployer le client de synchro…

J’ai aussi fait des nextcloud pendant le covid pour des écoles, environ 300 utilisateurices, 100+ connectés dans les 5 dernières minutes (4Go de ram et 4vcpu). J’avais écris un article dans le wiki chatons pour partager le paramétrage.

Je n’ai jamais déployé polls car je propose une installation de framadate.

Je suis en mesure de proposer de la visio (j’ai empaqueté nextcloud signaling pour yunohost) mais c’est peu utilisé pour l’instant.

Un document qui peut aider (je le retrouve plus que via archive.org…): Deployment Recommendations — Nextcloud 11 Server Administration Manual 11 alpha documentation

Après il prend de l’age et nextcloud a beaucoup évolué. Ceci dit on voit qu’il semble possible de faire des NC pour 100000 utilisateurices (en mode entreprise, donc salarié⋅es).

manu58 · March 30, 2025, 4:47pm

Bonjour

Au pic https://le-pic.org nous avons une seule instance nextcloud partagée par toutes les associations adhérentes qui le souhaitent. Pour rappel, au pic nous offrons des services aux associations, pas aux personnes individuelles. Les associations sont indépendantes entre elles, donc nous avons posé un cadre assez rigide:

Chaque association apparaît sur le cloud sous la forme d’un quadruplet: (compte, groupe, dossier, partage)
Le compte de l’association a un certain quota, par défaut de 1Go, pouvant être porté à 10Go
Les adhérent-es de l’asso ont des comptes personnels, intégrés au groupe de l’asso, leur quota est limité à 100Mo: pas question qu’ils utilisent le cloud pour leur besoin personnel.
Lorsqu’un utilisateur travaille dans le dossier de l’asso les documents appartiennent à l’asso, pas à l’utilisateur, et ils bénéficient du quota alloué à l’asso. S’ils travaillent dans leur home, le document leur appartient et ils sont limités à 100Mo
Une ou plusieurs adhérent-es de l’asso ont les droits de subadmin du groupe de l’asso, cela leur permet de créer/supprimer des comptes.
On peut créer d’autres groupes (ca, bureau etc), les subadmins de l’asso seront aussi subadmins de ces groupes ils pourront donc gérer la composition des groupes

Tout ça est décrit ici: NEXTCLOUD, la doc ! - Le Pic et nous avons écrit une application pour gérer le cloud via l’API, car créer une asso par exemple demande à faire plusieurs opérations, à la main on en oublierait. Cette appli est là: Emmanuel Courcelle / ncags · GitLab

Donc voici mon retour:

Nous avons plus de 800 comptes, pour 65 assos
Le serveur a un seul coeur, 4 Go de mémoire, 200 Go de disque (plein à 40%)
Nous avons les applis de base, plus deck, mindmap et onlyoffice (voir plus loin), mais pas contacts (pour éviter que tout le monde voit tout le monde).
ça marche plutôt très bien, avec quelques ralentissements de temps en temps, dans ce cas il faut redémarrer le cloud… ou ne rien faire car ça revient tout seul à la normale après quelques minutes. Je ne saurais pas dire précisément d’où cela vient.
Le système est réparti sur plusieurs conteneurs docker: nginx, php, postgresql, redis, comme proposé par oxytanet et intégré à notre système « houaibe », voir ici: images/cloud · master · Emmanuel Courcelle / houaibe · GitLab. Le proxy utilisé repose sur nginx (cf. images/proxy · master · Emmanuel Courcelle / houaibe · GitLab) sans configuration particulière. Nous utilisons le cron du système pour les tâches récurrentes du cloud.
Le cloud est sauvegardé toutes les nuits: passage en maintenance, dump de la BD postgresql, sauvegarde puis sortie du mode de maintenance.
Pour les mises à jour, on se borne à changer le numéro de version dans le Dockerfile du cloud, en utilisant les numéros complets (ex. 30.0.8) pour ne pas avoir de mauvaise surprise (exemple: mise à jour inattendue lors d’un redémarrage, ça peut arriver si on spécifie version 30.0). Ensuite on redémarre, la mise à jour se fait toute seule (mais ça dure bien 20mn) puis on appelle occ pour les dernières manips si nécessaire.
Pas de modération puisque les associations sont responsables de ce qu’elles font.
Concernant onlyoffice, il est installé sur une autre machine, elle aussi 1 cœur/4 Go. Nous le recompilons à chaque mise à jour afin de dépasser la limite des 20 connexions.

Concernant notre configuration « assos » il y a quelques limites:

Les subadmins ne peuvent pas donner des droits de subadmin à un de leurs adhérents, ils doivent nous demander
Par contre ils peuvent changer les quotas, ce qui me semble aberrant. Mais les gens sont raisonnables et nous n’avons pas de problème avec ça
Une personne ayant plusieurs casquettes appartient simplement à plusieurs groupes, mais les subadmins peuvent certes créer un utilisateurice, pas intégrer à leur groupe un utilisateurice existant. C’est nous (les « vrais » admins) qui devons le faire.
Nous ne pouvons pas activer l’appli contact sans casser l’isolation entre assos… et c’est pareil pour plusieurs applis (poll par exemple… encore que je n’ai pas essayé ces derniers temps ça a pu changer).
L’écran « Utilisateur et Comptes » est difficilement utilisable lorsqu’on a beaucoup d’utilisateurs… d’où l’intérêt d’utiliser une appli extérieur, même si elle est un peu « frustre » (et incomplète, le devt n’est pas terminé).

Ce qui est très utile par contre c’est de n’avoir qu’un seul cloud à administrer…

Emmanuel

Maxime · March 30, 2025, 5:45pm

Je vais répondre sur deux instances qui ont une petite centaine d’utilisateur⋅ices chacune, avec des usages très différents :

instance 1 (part): des comptes de particuliers
instance 2 (pro) : une PME - cabinet de conseil

Configuration

part : le NC est hébergé sur un dédié OVH sur lesquels on héberge ~89 autres Nextcloud, pour environ 2500 comptes. C’est la machine mutu2 dans notre architecture : 8 cœurs, 16 Go de RAM. Pour l’usage des 80 NC, c’est dimensionné assez juste, et on doit de temps en temps résoudre des soucis de performance. Ça représente ~450 Go. La BDD est une mariadb hébergée localement, on a toutes les tâches cron activées, notamment pour l’envoi de reminders d’agenda (important), une cron qui fait les optimisaitions de DB toutes les semaines, le service notify_push configuré. On sauvegarde (sauvegarde physique via mariabackup + borg des données) toutes les nuits chez @kepon via une API custom.
pro : le PHP+DB Nextcloud sont hébergés sur une machine OVH sur SSD (cornichon dans notre architecture). Les données (3.5To) sont sur deux machines (castoroil et castoroil2 dans notre architecture), dans S3/Garage. Ces machines sont hybrides SSD + HDD (indispensable pour utiliser garage dans notre cas). On a tâtonné un temps avec des machines avec des disques moins rapides et c’était clairement le goulot d’étranglement (machines qui plafonnent pendant des heures à 100% d’IO). On a aussi toutes les tâches cron activées, notify_push. On sauvegarde les données via btrfs send/receive sur une machine domestique. On a pas mal travaillé la configuration de nginx/php-fpm pour pouvoir traiter de gros fichiers, des soucis de performances, etc.

On a eu énormément de galères pour gérer la montée en charge : dans un contexte pro, 100 personnes se connectent à la même heure, ça crée des pics de charge très importants. Par ailleurs, iels utilisaient en priorité le client lourd NC, qui gère très mal les soucis (réseau, forte charge), et notre serveur a été extrêmement sollicité parce qu’il était trop lent (vous voyez le cercle vicieux). Globalement, opérer le client NC dans cette situation à été un enfer, avec des régressions majeures dans toutes les montées de version pendant un an (va expliquer à 90 personnes qu’il fallait pas faire la mise à jour du client Nextcloud parce que maintenant il leur affiche un message d’alerte comme quoi peut-être que tous les fichiers vont être supprimés). On a une section réservée aux bugs du client NC dans notre wiki.

Précautions particulières

part : pas grand chose de particulier. On réfléchit à distribuer un endpoint custom pour la liste des applications installables, en supprimant les apps « interdites » (voir plus bas).
pro : c’est pas simple de faire des backups/restaurations dans S3 (garage ne gère pas le versioning). Du coup aller chercher un fichier effacé par erreur est un peu galère (faut remonter un backup de la DB NC pour identifier le fichier → uid S3, puis remonter un cluster garage sur les données backupées, copier l’objet). Après sur cette instance on a eu l’enjeu de devoir gérer les soucis du client Nextcloud.

De manière générale, les montées de version sont toujours un moment où on croise les doigts, et franchement il y a souvent des régressions majeures lors des montées de version (noms de dossiers qui disparaissent, connecteur onlyoffice cassé, pdf qui s’ouvrent plus, etc).

Applications

RAS sur les applications citées.
Par contre :

Groupfolders semble être une réimplémentation de plein de concepts de Nextcloud (dossiers, ACLs, corbeille), et merdouille à quasi-chaque montée de version de Nextcloud (ça va de la perte d’affichage de nom des dossiers à la suppression de contenu)
Pour Onlyoffice, il y a un petit casse-tête pour garder les bonnes versions de NC + connecteur NC-OO + OO.

On a notre liste d’applications interdites :

talk (partie visio), car on n’héberge pas de serveur turn/stun, et les machines sont pas dimensionnées pour ça
collabora/richdocuments : mettent le serveur par terre

Modération

On n’y a pas été confronté⋅es.

Collabora/Onlyoffice

On mutualise une instance OO sur nos ~170 instance NC. C’est une instance débridée (merci IndieHosters), qui est hébergée dans un docker sur notre serveur mutu3 (donc sur une machine qui héberge aussi des NC). On a pu monter à près de 200 connexions simultanées sans aucun souci : dans cette gamme d’utilisation le service tient très bien la charge.

Soucis rencontrés :

le curseur fou, globalement avec les mises à jour il s’en va et il revient.
Occasionnellement l’impossibilité d’ouvrir certains docs (pb de conversion)
Extrêmement rarement (et de plus en plus rarement) et sans qu’on sache exactement quel composant incriminer : les données ne sont pas enregistrées.

bohwaz · March 30, 2025, 9:00pm

Données non enregistrées : activer les logs WOPI et remonter dedans quand on signale une perte de données.

Il faut voir aussi que comme Collabora, Onlyoffice n’envoie pas forcément le document au serveur WOPI (NextCloud) quand on clique sur le bouton enregistrer, mais seulement après la clôture de la dernière session d’édition, ou un certain délai. Donc si tu as une autre session d’édition en même temps que toi, même « fantôme », ça peut empêcher la sauvegarde rapide, et donc si tu reviens dans NextCloud, que tu télécharge le fichier sur ton ordi depuis NC, NC t’enverra une version « ancienne » du fichier car OO n’aura pas encore renvoyé la version mise à jour… Si OO crashe à ce moment-là, tu perdra les modifs aussi. Il existe des options pour forcer la sauvegarde sur le serveur WOPI : https://github.com/ONLYOFFICE/onlyoffice-nextcloud/issues/751

ljf · March 31, 2025, 8:02am

De notre côté, on a aussi remonté un problème de mauvaise gestion des conflits: Data loss : conflict between onlyoffice and nextcloud desktop client · Issue #1059 · ONLYOFFICE/onlyoffice-nextcloud · GitHub

J’ai d’ailleurs un client qui est passé récemment en full web (avant elles étaient en full synchro nextcloud client).

Le client nc desktop n’est pas fait pour synchroniser de grosses quantités de données. La version android se débrouille bien mieux.

Un de mes clients a utilisé un client propriétaire (licence payante) mountain duck (ou cyberduck je sais plus) pour résoudre ce point pendant un temps, mais là je crois qu’ils sont passé sur les dossiers virtuels windows…

bohwaz · March 31, 2025, 11:16am

Cyberduck = logiciel libre, explorateur, type FileZilla, avec WebDAV etc.
Mountain Duck = propriétaire (même développeur), pemet de monter comme disque réseau un endpoint WebDAV etc.

Microsoft a supprimé / est en train de supprimer le support WebDAV de Windows, donc les dossiers virtuels ça marchera plus à terme

Ton bug me semble dû justement au fait que le client WOPI (OnlyOffice) va écraser le fichier, même si celui-ci a été modifié via un autre moyen. C’est parce que la gestion des conflits se fait au niveau du client WebDAV, pas au niveau du serveur (NextCloud), le serveur quand on lui dit « enregistre à tel endroit », il enregistre c’est tout, car il n’y a pas de moyen de gérer un conflit car on ne sait pas à qui est liée la modification : on ne peut pas présenter d’UI pour permettre de choisir une version ou l’autre… C’est irrésolvable comme truc, à moins d’utiliser les locks : quand tu commence à éditer avec Onlyoffice, tu ne peux pas modifier le fichier avec WebDAV, mais dans ce cas les gens ne comprennent pas le truc… Et ça veut dire que si tu as un client qui édite le fichier en local avec WebDAV, tu ne peux plus utiliser OnlyOffice… Si ton utilisateur crashe et ne dé-lock pas le fichier, tu es coincé.

ljf · March 31, 2025, 11:05pm

Moui, enfin, « il suffirait » d’avoir le hash du dernier fichier enregistré et de regarder au moment de l’enregistrement si ce dernier n’a pas changé, et dans ce cas créer une copie…

kepon · April 1, 2025, 7:53am

C’est quoi une « grosse quantité » ? J’ai un client à 400Go avec ~15 client NC synchronisé ça semble bien se passer… pas plus de retour que pour les petits en tout cas…

Le client nextcloud embarque maintenant un mode virtuel ou les fichiers ne sont pas téléchargé, Ils sont là mais « vide », il te faut cliquer dessus pour les télécharger… je pense que c’était ça dont il est question… Pour moi c’est indépendant du support de WebDav par Windows. (Je crois que ce mode est proposé depuis quelques version sous Windows mais encore en béta sous linux… )