Recommandations de déploiement d’ownCloud¶
Quel est le meilleur moyen pour installer et maintenir ownCloud ? La réponse à cette question est : « Ça dépend » car chaque client ownCloud a ses propres besoins et infrastructure. ownCloud et l’ensemble LAMP sont hautement configurables, nous présenterons donc trois scénarios typiques et ferons des recommandations pour le matériel et les logiciels.
Recommandations générales¶
Note
Quelle que soit la taille de votre organisation, gardez toujours ceci à l’esprit : la quantité de données stockées dans ownCloud ne fera qu’augmenter. Planifiez en conséquence.
Vous pouvez envisager de définir une infrastructure pour gérer la montée en charge ou utiliser la fédération de serveurs ownCloud pour conserver des instances ownCloud de taille gérable.
- Système d’exploitation : Linux.
- Serveur Web : Apache 2.4.
- Base de données : MySQL/MariaDB.
- PHP 5.5+. PHP 5.4 est la version minimale gérée. Veuillez noter qu’il est arrivé en fin de vie en septembre 2015 et qu’il n’est plus supporté par l’équipe PHP. Certains vendeurs Linux comme Red Hat, supportent encore PHP 5.4. Les versions 5.6 et suivantes sont recommandées. mod_php est le module Apache recommandé car il fournit les meilleurs perforemances.
Petits groupes de travail et départements¶
- Nombre d’utilisateurs
- Jusqu’à 150 utilisateurs.
- Taille du stockage
- De 100 Go à 10 To.
- Haute disponibilité
- Pas de coupure de service avec des instantanés Btrfs, interruption de service si défaillance matérielle. Plan de sauvegarde alternatif : sauvegarde de nuit avec interruption de service.
Prérequis système recommandés¶
Une seule machine exécutant le serveur applicatif, le serveur Web, la base de données et le stockage local.
Authentification à l’aide d’un serveur LDAP existant ou Active Directory.
- Composants
Un seul serveur avec au moins deux cœurs, 16 Go de RAM, stockage local.
- Système d’exploitation
Distribution Linux entreprise avec support du vendeur. Nous recommandons Red Hat Enterprise Linux ou SUSE Linux Enterprise Server 12.
- Configuration SSL
La terminaison SSL est réalisée dans Apache. Un certificat SSL standard est nécessaire, installé selon les recommandation de la documentation Apache.
- Équilibrage de charge
Aucun.
- Base de données
MySQL, MariaDB ou PostgreSQL. Nous recommandons MySQL ou MariaDB, car nos clients ont une bonne expérience lors d’une migration vers un cluster Galera pour gérer la montée en charge.
- Sauvegarde
Installation d’owncloud, du répertoire data d’ownCloud et de la base de données sur un système de fichiers Btrfs. Faire des instantanés à intervalles réguliers pour un service 24/7. Monter les partitions de base de données avec l’option « nodatacow » pour empêcher la fragmentation.
Vous pouvez aussi faire des sauvegardes de nuit avec interruption de service :
- arrêter Apache ;
- faire un export de la base de données ;
- pousser le répertoire data sur le support de sauvegarde ;
- pousser l’export de la base de données sur le support de sauvegarde ;
- redémarrer Apache.
Vous pouvez aussi utiliser rsync. Voir la section Maintenance du manuel d’administration pour des conseils sur les sauvegardes et restaurations.
- Authentification
Authentification à l’aide d’un ou plusieurs serveurs LDAP ou Active Directory. Voir Authentification utilisateur avec LDAP pour des informations sur la configuration d’ownCloud pour utiliser LDAP et Active Directory.
- Gestion de session
Gestion de session locale sur le serveur applicatif. Les sessions PHP sont stockées sur une partition tmpfs montée sur un emplacement spécifique du système d’exploitation. Vous pouvez trouver cet emplacement en exécutant la commande grep -R 'session.save_path' /etc/php5 et ajoutez-le au fichier /etc/fstab. Par exemple : echo "tmpfs /var/lib/php5/pool-www tmpfs defaults,noatime,mode=1777 0 0" >> /etc/fstab.
- Mémoire cache
Un système de mémoire cache améliore les performances du serveur. ownCloud sait gérer 4 systèmes de mémoire cache. Veuillez consulter Configuration de la mémoire cache pour des informations sur le choix et la configuration d’un système de mémoire cache.
- Stockage
Stockage local.
- Édition ownCloud
Édition standard. Voir Serveur ownCloud ou Édition Entreprise pour une comparaison des différentes éditions.
Entreprises moyennes¶
- Nombre d’utilisateurs
- De 150 à 1 000 utilisateurs.
- Stockage
- Jusqu’à 200 To.
- Haute disponibilité
- Chaque composant est totalement redondant et peut s’arrêter sans interruption de service. Sauvegardes sans interruption de service.
Prérequis serveurs recommandés¶
De 2 à 4 serveurs applicatifs.
Un cluster de deux serveurs de bases de données.
Stockage sur un serveur NFS.
Authentification à laide d’un serveur LDAP ou Active Directory existant.
- Composants
- de 2 à 4 serveurs applicatifs avec 4 sockets et 32 Go de RAM.
- 2 serveurs de base de données avec 4 sockets et 64 Go de RAM.
- Un équilibreur de charge HAproxy avec 2 sockets et 16 Go de RAM.
- Un serveur de stockage NFS.
- Système d’exploitation
- Distribution Linux entreprise avec support du vendeur. Nous recommandons Red Hat Enterprise Linux ou SUSE Linux Enterprise Server 12.
- Configuration SSL
- La terminaison SSL est réalisée sur l’équilibreur de charge HAProxy. Un certificat standard SSL est nécessaire, installé selon la documentation HAProxy.
- Équilibrage de charge
- HAProxy s’exécutant sur un serveur dédié en frontal des serveurs applicatifs. L’affinité de session doit être utilisée à cause de la gestion lcoale de session sur les serveurs applicatif.
- Base de données
Cluster Galera MySQL ou MariaDB avec une réplication master-master.
- Sauvegarde
Une sauvegarde quotidiennesans coupure. Toutes les instructions MySQL/MariaDB doivent être répliquées sur une instance esclave MySQL/MariaDB.
- créer un instantanésur le serveur de stockage NFS ;
- au même moment, arrêter la réplication MySQL ;
- créer un export de l’instance MySQL esclave ;
- pousser l’instantané NFS sur le support de sauvegarde ;
- pousser l’export MySQL sur le support de sauvegarde ;
- supprimer l’instantané NFS ;
- redémarrer la réplication MySQL.
- Authentification
Authentification à l’aide d’un ou plusieurs serveurs LDAP ou Active Directory. Voir Authentification utilisateur avec LDAP pour des informations sur la configuration d’ownCloud pour utiliser LDAP ou Active Directory.
- LDAP
Des serveurs esclaves en lecture seule doivent être déployés pour chaque serveur applicatif pour une montée en charge optimale.
- Gestion de session
Gestion de session locale sur le serveur applicatif. Les sessions PHP sont stockées sur une partition tmpfs montée sur un emplacement spécifique du système d’exploitation. Vous pouvez trouver cet emplacement en exécutant la commande grep -R 'session.save_path' /etc/php5 et ajoutez-le au fichier /etc/fstab. Par exemple : echo "tmpfs /var/lib/php5/pool-www tmpfs defaults,noatime,mode=1777 0 0" >> /etc/fstab.
- Mémoire cache
Un système de mémoire cache améliore les performances du serveur. ownCloud sait gérer 4 systèmes de mémoire cache. Veuillez consulter Configuration de la mémoire cache pour des informations sur le choix et la configuration d’un système de mémoire cache.
- Stockage
Utiliser une solution NFS toute faite comme IBM Elastic Storage ou RedHat Ceph.
- Édition ownCloud
Édition standard. Voir Serveur ownCloud ou Édition Entreprise pour une comparaison des différentes éditions.
Grandes entreprises et fournisseurs de services¶
- Nombre d’utilisateurs
- de 5 000 à plus de 100 000 utilisateurs.
- Stokage
- Jusqu’à 1 Po.
- Haute disponiblité
- Chaque composant est totalement redondant et peut s’arrêter sans interruption de service. Sauvegardes sans interruption de service.
Prérequis système recommandés¶
de 4 à 20 serveurs applicatifs/Web.
Un cluster de deux (ou plus) serveurs de base de données.
Stockage sur un serveur NFS ou un object store compatible S3.
Fédération de serveurs pour une configuration distribuée sur plusieurs centres de données.
Authentification à l’aide de serveurs LDAP ou Active Directory existants ou SAML.
- Composants
- de 4 à 20 serveurs applicatifs avec 4 sockets et 64 Go de RAM
- 4 serveurs de base de données avec 4 sockets et 128 Go de RAM
- 2 équilibreurs de charge, comme par exemple BIG IP de F5
- Stokage NFS
- Système d’exploitation
RHEL 7 avec les derniers service packs.
- Configuration SSL
La terminaison SSL est réalisée dans l’équilibreur de charge. Un certificat standard SSL est nécessaire installé selon la documentation de l’équilibreur de charge.
- Équilibrage de charge
Des équipements redondants avec pulsation (heartbeat), par exemple F5 Big-IP. Deux équilibreurs de charge en frontal des serveurs applicatifs.
- Base de données
Cluster Galera MySQL/MariaDB avec 4 réplications master-master.
- Sauvegarde
Une sauvegarde quotidiennesans coupure. Toutes les instructions MySQL/MariaDB doivent être répliquées sur une instance esclave MySQL/MariaDB.
- créer un instantanésur le serveur de stockage NFS ;
- au même moment, arrêter la réplication MySQL ;
- créer un export de l’instance MySQL esclave ;
- pousser l’instantané NFS sur le support de sauvegarde ;
- pousser l’export MySQL sur le support de sauvegarde ;
- supprimer l’instantané NFS ;
- redémarrer la réplication MySQL.
- Authentification
Authentification à l’aide d’un ou plusieurs serveurs LDAP ou Active Directory, ou SAML/Shibboleth. Voir Authentification utilisateur avec LDAP et Intégration Shibboleth.)
- LDAP
Des serveurs esclaves en lecture seule doivent être déployés pour chaque serveur applicatif pour une montée en charge optimale.
- Gestion de session
Redis should be used for the session management storage.
- Cache
Redis pour du cache mémoire distribué. Voir Configuration de la mémoire cache).
- Stockage
Une solution toute faite, comme IBM Elastic Storage ou RedHAT Ceph doit être utilisée. Vous pouvez aussi utiliser un object store compatible S3.
- Édition ownCloud
Édition Entreprise. Voir Serveur ownCloud ou Édition Entreprise pour une comparaison des différentes éditions.
Considérations sur le matériel¶
- Disques SSD pour les entrées/sorties
- Partitions séparées pour le stockage et la base de données, disques SSD pour les base de données
- Plusieurs interfaces réseau pour distribuer le trafic sur plusieurs sous-réseaux
Machine unique / montée en charge¶
Le déploiement machine unique est largement utilisé dans la communauté.
Avantages :
- Configuration facile : pas de démon de stockage de session, utilisation de tmpfs et de mémoire cache pour améliorer les performances, stockage local.
- Pas d’inquiétude sur la latence réseau.
- Pour la montée en charge, augmenter les processeurs, la mémoire et l’espace disque.
Inconvénients :
- Moins d’options pour la haute disponiblité.
- La quantité de données tend à augmenter continuellement. Au bout du compte, une seule machine ne pourra pas absorber la montée en charge : les performances d’entrées/sorties diminuent et deviennent un goulet d’étranglement pour les téléchargements et les téléversements, même avec des disques SSD.
Déploiement pour une montée en charge¶
Configuration pour les fournisseurs de service :
- Round Robin DNS sur serveurs HAProxy (2-n, déchargement SSL, cache des ressources statiques)
- Charge moindre sur serveurs Apache (2-n)
- Memcached/Redis pour le stockage de session partagé (2-n)
- Cluster de base de données avec un seul maître et plusieurs esclaves, plus un proxy pour répartir les requêtes (2-n)
- GPFS ou Ceph via phprados (2-n, 3 pour être sûr, plus de 10 nœuds Ceph pour bénéficier de la rapidité sous la charge)
Avantages :
- Les composants peuvent être multipliés si besoin.
- Haute disponibilité.
- Tests de migration plus faciles.
Inconvénients :
- Configuration plus compliquée.
- Le réseau devient le goulet d’étranglements (10 Go Ethernet recommandé).
- Actuellement, la table de fichiers de cache de la base de données grossit rapidement, rendant les migrations pénibles si la table est altérée.
Et Nginx / PHP-FPM ?¶
Ils peuvent être utilisés à la place de HAproxy pour l’équilibrage de charge. Mais pour les téléversements, le fichier complet est stocké sur disque avant d’être traité par PHP-FPM.
Une seule base de données maître, point de défaillance unique, pas de montée en charge¶
Quand la base maître est défaillante, un esclave peut devenir maître. Cependant, cette complexité accrue comporte des risques : un système multi-maître comporte le risque de cerveau partagé (split brain) et de verrous. ownCloud essai de résoudre le problème des verrous avec un système de verrouillage de fichiers de haut niveau.
Considérations sur les logiciels¶
Système d’exploitation¶
Nous sommes dépendants des distributions qui offrent un moyen facile d’installer les divers composants nécessaires à jour. ownCloud a un partenariat avec RedHat et SUSE pour les clients ayant besoin d’un support commercial. Canonical, la maison mère de Ubuntu Linux, offre aussi des services et du support aux entreprises. Debian et Ubuntu sont gratuits et contiennent les dernières versions de paquets. CentOS est le clone gratuit de Red Hat Enterprise Linux, soutenu par la communauté. openSUSE est soutenu par la communauté et contient beaucoup des outils d’administration de SUSE Linux Enterprise Server.
Serveur Web¶
Si l’on compare Apache et Nginx, Apache avec mod_php est actuellement la mailleure option, car Nginx ne gère pas toutes les fonctionnalités nécessaires pour des déploiements en entreprise. mod_php est recommandé par rapport à PHP_FPM, car pour de la montée en charge, des pools PHP séparés ne sont tout simplement pas nécessaires.
Base de données relationnelles¶
Le plus suivent, le client a déjà une opinion sur la base de données à utiliser. Il est en général recommandé d’utiliser celle avec laquelle l’administrateur de bases de données est le plus familier. En prenant en compte ce que nous pouvons voir dans les déploiements chez nos clients, nous recommandons MySQL/MariaDB en mode maître esclave, avec un proxy MySQL en frontal pour envoyer les mises à jour au serveur maître et sélectionner les serveurs esclaves.
La deuxième meilleure option est d’utiliser PostgreSQL (les modifications des tables ne verrouillent pas les tables, ce qui rend les migrations moins pénibles) bien que nous ayons encore à trouver un client qui utilise une configuration maître-esclave.
Et les autres SGBD ?
- Sqlite est adapté pour les tests ou pour un utilisateur unique. Il n’est pas approprié pour les systèmes en production.
- Microsoft SQL Server n’est pas une option supportée.
- Oracle est le standard de facto des grandes entreprises et est totalement supporté pour l’Édition Entreprise seulement.
Stockage de fichiers¶
Bien que beaucoup de clients commencent avec NFS, ils ont besoin tôt ou tard d’un stockage supportant la montée en charge. Actuellement, les options sont GPFS ou GlusterFS, ou un protocole de stockage d’objet comme S3 (supporté pour l’Édition Entreprise seulement) ou Swift. S3 permet aussi l’accès à Ceph Storage.
Stockage de session¶
- Redis : fournit la persistance, des outils d’inspection graphique et gère le verrouillage de fichiers de haut niveau d’ownCloud.
- Si Shibboleth est un prérequis, vous devez utiliser Memcached, et il peut être aussi utilisé pour la montée en charge pour le stockage de session shibd (voir Memcache StorageService).
