Owncloud Deployment Recommendations
Total Page:16
File Type:pdf, Size:1020Kb
ownCloud Deployment Recommendations What is the best way to install and maintain ownCloud? The answer to that is “it depends” because every ownCloud customer has their own particular needs and IT infrastructure. ownCloud and the LAMP stack are highly-configurable, so we will present three typical scenarios and make best-practice recommendations for both software and hardware. General Recommendations Note: Whatever the size of your organiza- Recommended System Requirements Alternatively, make nightly backups with tion, always keep one thing in mind: service interruption: the amount of data stored in ownCloud One machine running the application ser- – Shut down Apache. will only grow. Plan ahead. ver, Webserver, database server and local – Create database dump. storage. Authentication via an existing – Push data directory to backup. Consider setting up a scale-out deploy- LDAP or Active Directory server. – Push database dump to backup. ment, or using Federated Cloud Sharing to – Start Apache. keep individual ownCloud instances to a • Components: One server with at least manageable size. 2 CPU cores, 16GB RAM, local storage Then optionally rsync to a backup storage as needed. or tape backup. (See the Maintenance sec- • Operating system: Linux. tion of the Administration manual for tips • Operating system: Enterprise-grade Linux • Webserver: Apache 2.4. on backups and restores.) distribution with full support from OS • Database: MySQL/MariaDB. vendor. We recommend Red Hat Enter- • Authentication: User authentication via • PHP 5.5+: PHP 5.4 is the minimum prise Linux or SUSE Linux Enterprise one or several LDAP or Active Directory supported version; note that it reached Server 12. servers. (See User Authentication with end-of-life in September 2015 and is no LDAP for information on configuring longer supported by the PHP team. Some • SSL Configuration: The SSL termination is ownCloud to use LDAP and AD.) Linux vendors, such as Red Hat, still done in Apache. A standard SSL certifi- support PHP 5.4. 5.6+ is recommended. cate is needed, installed according to the • Session Management: Local session mod_php is the recommended Apache Apache documentation. management on the application server. module because it provides the best PHP sessions are stored in a tmpfs • Load Balancer: None. performance. mounted at the operating system-specific • Database: MySQL, MariaDB or Post- session storage location. You can find out greSQL. We currently recommend MySQL where that is by running Small Workgroups or / MariaDB, as our customers have had grep -R ’session.save_path‘ / good experiences when moving to a etc/php5 Departments Galera cluster to scale the DB. and then add it to the • Number of users: Up to 150 users. • Backup: Install owncloud, ownCloud data • Storage size: 100 GB to 10TB. directory and database on Btrfs filesys- /etc/fstab file, for example: • High availability level: Zero-downtime tem. Make regular snapshots at desired echo "tmpfs /var/lib/php5/ backups via Btrfs snapshots, component intervals for zero downtime backups. pool-www tmpfs failure leads to interruption of service. Mount DB partitions with the “nodata- defaults,noatime,mode=1777 0 Alternate backup scheme on other cow” option to prevent fragmentation. 0" >> /etc/fstab. filesystems: nightly backups with service interruption. 2 • Memory Caching: A memcache speeds • Operating system: Enterprise grade Linux • LDAP: Read-only slaves should be up server performance, and ownCloud distribution with full support from OS deployed on every application server for supports four memcaches; refer to vendor. Red Hat Enterprise Linux or optimal scalability Configuring Memory Caching for SUSE Linux Enterprise Server 12 are • Session Management: Session manage- information on selecting and configuring recommended. ment on the application server. PHP a memcache. • SSL Configuration: The SSL termination is sessions are stored in a tmpfs mounted • Storage: Local storage. done in the HAProxy load balancer. A at the operating system-specific session standard SSL certificate is needed, storage location. You can find out where • ownCloud Edition: Standard Edition. (See installed according to the HAProxy that is by running ownCloud Server or Enterprise Edition for documentation. comparisons of the ownCloud editions.) grep -R ’session.save_path‘ / • Load Balancer: HAProxy running on a etc/php5 dedicated server in front of the applica- and then add it to the Small Workgroups or tion servers. Sticky session needs to be used because of local session manage- /etc/fstab file, for example: Departments ment on the application servers. echo "tmpfs /var/lib/php5/ • Number of users: 150 to 1,000 users. • Database: MySQL/MariaDB Galera cluster pool-www tmpfs • Storage size: Up to 200TB. with master-master replication. defaults,noatime,mode=1777 0 • High availability level: Every component 0" >> /etc/fstab. • Backup: Minimum daily backup without is fully redundant and can fail without downtime. All MySQL/MariaDB state- service interruption. Backups without • Memory Caching: A memcache speeds ments should be replicated to a backup service interruption up server performance, and ownCloud MySQL/MariaDB slave instance. supports four memcaches; refer to Recommended System Requirements Configuring Memory Caching for informa- – Create a snapshot on the NFS storage tion on selecting and configuring a server. 2 to 4 application servers. A cluster of two memcache. – At the same time stop the MySQL database servers. Storage on an NFS ser- replication. • Storage: Use an off-the-shelf NFS ver. Authentication via an existing LDAP or – Create a MySQL dump of the backup solution, such as IBM Elastic Storage or Active Directory server. slave. RedHat Ceph. – Push the NFS snapshot to the backup. • Components: • ownCloud Edition: Enterprise Edition. – Push the MySQL dump to the backup. – 2 to 4 application servers with (See ownCloud Server or Enterprise – Delete the NFS snapshot. 4 sockets and 32GB RAM. Edition for comparisons of the ownCloud – Restart MySQL replication. – 2 DB servers with 4 sockets and editions.) 64GB RAM. • Authentication: User authentication via – 1 HAproxy load balancer with one or several LDAP or Active Directory 2 sockets and 16GB RAM. servers. (See User Authentication with – NFS storage server as needed. LDAP for information on configuring ownCloud to use LDAP and AD.) 3 Large Enterprises and • Components: • Database: MySQL/MariaDB Galera – 4 to 20 application servers with Cluster with 4x master – master Service Providers 4 sockets and 64GB RAM. replication. – 4 DB servers with 4 sockets and • Backup: Minimum daily backup without • Number of users: 5,000 to >100,000 users. 128GB RAM downtime. All MySQL/MariaDB state- • Storage size: Up to 1 petabyte. – 2 Hardware load balancer, for ments should be replicated to a backup • High availability level: Every component example BIG IP from F5 MySQL/MariaDB slave instance. is fully redundant and can fail without – NFS storage server as needed. service interruption. Backups without • Operating system: RHEL 7 with latest – Create a snapshot on the NFS storage service interruption service packs. server. – At the same time stop the MySQL Recommended System Requirements • SSL Configuration: The SSL termination is replication. done in the load balancer. A standard – Create a MySQL dump of the backup 4 to 20 application/Webservers. A cluster SSL certificate is needed, installed slave. of two or more database servers. Storage is according to the load balancer documen- – Push the NFS snapshot to the backup. an NFS server, or an object store that is S3 tation. – Push the MySQL dump to the backup. compatible. Cloud federation for a distribu- • Load Balancer: A redundant hardware – Delete the NFS snapshot. ted setup over several data centers. load-balancer with heartbeat, for – Restart MySQL replication. Authentication via an existing LDAP or example F5 Big-IP. This runs two load Active Directory server, or SAML. balancers in front of the application • Authentication: User authentication via servers. one or several LDAP or Active Directory servers, or SAML/Shibboleth. (See User Authentication with LDAP and Shibboleth Integration.) • LDAP: Read-only slaves should be deployed on every application server for optimal scalability. • Session Management: Redis should be used for the session management storage. • Caching: Redis for distributed in-memory caching (see Configuring Memory Caching). • Storage: An off-the-shelf NFS solution should be used. Examples are IBM Elastic Storage or RedHAT Ceph. Optionally, an S3 compatible object store can also be used. • ownCloud Edition: Enterprise Edition. (See ownCloud Server or Enterprise Edition for comparisons of the ownCloud editions.) 4 Hardware Cons: and selects to the slave(s). The second best option is PostgreSQL (alter table does not • More complicated to setup. Considerations lock table, which makes migration less • Network becomes the bottleneck (10GB painful) although we have yet to find a Ethernet recommended). • Solid-state drives (SSDs) for I/O. customer who uses a master-slave setup. • Currently DB filecache table will grow • Separate hard disks for storage and rapidly, making migrations painful in database, SSDs for databases. What about the other DBMS? case the table is altered. • Multiple network interfaces to distribute server synchronisation and backend • Sqlite is adequate for simple testing, and What About Nginx / PHP-FPM? traffic across multiple subnets. for low-load single-user deployments. It is not adequate