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 : Ubuntu 16.04 LTS.
- Serveur Web : Apache 2.4.
- Base de données : MySQL/MariaDB avec le moteur de stockage InnoDB (MyISAM n’est plus supporté, voir : MySQL / MariaDB storage engine)
- PHP 7.
Petits groupes de travail et départements¶
- Nombre d’utilisateurs
- Jusqu’à 150 utilisateurs.
- Haute disponibilité
- Pas de coupure de service avec des instantanés (snapshots) de système de fichiers, interruption de service si défaillance matérielle. Plan de sauvegarde alternatif : sauvegarde de nuit avec interruption de service.
Prérequis système¶
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 Ubuntu 16.04 LTS. D’autres distributions sont aussi supportées (par ex. : RedHat ou SuSE) mais elles peuvent ne pas fournir toutes les dépendances requises dans leurs dépôts officiels et il pourrait être nécessaire d’activer des dépôts tiers pour des modules comme APCu et Redis.
- 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
- Nous recommandons actuellement MySQL / MariaDB, car nos clients ont de bonnes expériences avec ceux-ci en passant sur une cluster Galera pour absorber la montée en charge de la base de données. (Moteur de stockage InnoDB, MyISAM n’est pas supporté, voir MySQL / MariaDB storage engine).
- 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
- Nous recommandons : - APC/APCu pour le cache local. - Redis pour le verrouillage de fichiers transactionnel et le cache distribué, sur un serveur dédié. 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.
Entreprises moyennes¶
- Nombre d’utilisateurs
- De 150 à 1 000 utilisateurs.
- Haute disponibilité
- Chaque composant est totalement redondé 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 ou un magasin d’objets compatible avec S3.
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 32 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 Ubuntu 16.04 LTS. D’autres distributions sont aussi supportées (par ex. : RedHat ou SuSE) mais elles peuvent ne pas fournir toutes les dépendances requises dans leurs dépôts officiels et il pourrait être nécessaire d’activer des dépôts tiers pour des modules comme APCu et Redis.
- 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 locale de session sur les serveurs applicatif.
- Base de données
Nous recommandons MySQL/MariaDB, avec un cluster Galera avec réplication maître-maître ou une configuration maître-esclave avec bascule automatique. (Moteur de stockage InnoDB, MyISAM n’est pas supporté, voir MySQL / MariaDB storage engine).
- 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
- APC/APCu pour le cache local.
- Redis pour le verrouillage de fichiers transactionnel et le cache distribué, sur un serveur dédié.
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.
Grandes entreprises et fournisseurs de services¶
- Nombre d’utilisateurs
- de 5 000 à plus de 100 000 utilisateurs.
- 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¶
Plus de 4 serveurs applicatifs/Web.
Un cluster de deux (ou plus) serveurs de base de données.
Stockage sur un serveur NFS ou un magasin d’objets 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
- plus de 4 serveurs applicatifs avec 4 sockets et 64 Go de RAM
- 4 serveurs de base de données avec 4 sockets et 64 Go de RAM
- 2 équilibreurs de charge, comme par exemple BIG IP de F5
- Stokage NFS
- Système d’exploitation
Distribution Linux entreprise avec support du vendeur. Nous recommandons Ubuntu 16.04 LTS. D’autres distributions sont aussi supportées (par ex. : RedHat ou SuSE) mais elles peuvent ne pas fournir toutes les dépendances requises dans leurs dépôts officiels et il pourrait être nécessaire d’activer des dépôts tiers pour des modules comme APCu et Redis.
- 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
Nous recommandons MySQL/MariaDB, avec un cluster Galera avec réplication maître-maître ou une configuration maître-esclave avec bascule automatique. (Moteur de stockage InnoDB, MyISAM n’est pas supporté, voir MySQL / MariaDB storage engine).
- 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
- APC/APCu pour le cache local.
- Redis pour le verrouillage de fichiers transactionnel et le cache distribué, sur un serveur dédié.
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
Une solution toute faite, comme IBM Elastic Storage ou RedHat Ceph doit être utilisée. Vous pouvez aussi utiliser un object store compatible S3.
Considérations sur le matériel¶
- Disques SSD obligatoires pour des performance d’entrées/sorties (I/O) optimales
- 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 :
- Pas d’option 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)
- Distribution du trafic sur plusieurs serveurs Web pour diminuer la charge (2-n)
- 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 réalisés plus facilement.
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 ?¶
Il peut être utilisé à la place de HAproxy pour l’équilibrage de charge.
Considérations sur les logiciels¶
Système d’exploitation¶
ownCloud est dépendant des distributions qui offrent un moyen facile d’installer les divers composants nécessaires à jour. d’expérience, nous recommandons vivevment Ubuntu 16.04 LTS, puisque toutes les dépendances requises sont contenues par défaut. Canonical, la maison mère de Ubuntu Linux, offre aussi des services et du support aux entreprises.
ownCloud a un partenariat avec RedHat et SUSE pour les clients ayant besoin d’un support commercial. 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 souvent, 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 bien que nous ayons encore à trouver un client qui utilise une configuration maître-esclave.
Et les autres SGBD ?
- PostgreSQL est une bonne alternative à MySQL/MariaDB (les modifications des tables ne verrouillent pas les tables, ce qui rend les migrations moins pénibles), cependant, les configuration maître-esclave ne sont pas très courantes.
- 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.
..note:: Une seule base de données maître est un point de défaillance unique car pas de montée en charge possible
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.
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 DRDB, 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).
