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- • : . 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 Cachingfor 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 / PHP-FPM? traffic across multiple subnets. for low-load single-user deployments. It is not adequate for production systems. Could be used instead of HAproxy as the Single Machine / Scale-Up Deployment • MSSQL is not automatically tested. load balancer. But on uploads stores the • Oracle is expensive, but is the de facto whole file on disk before handing it The single-machine deployment is widely standard at large enterprises. Developers over to PHP-FPM. used in the community. need to be aware of the 30 char identifier limit, empty string equals null and A Single Master DB is Single Point of Pros: varchar2 can only be made 4000 chars Failure, Does Not Scale wide. • Easy setup: no session storage daemon, use tmpfs and memory caching to When master fails another slave can enhance performance, local storage. become master. However, the increased File Storage • No network latency to consider. complexity carries some risks: Multimaster • To scale buy a bigger CPU, more memory, has the risk of split brain, and deadlocks. Our main use case is up- and download of larger hard drive, or additional hard ownCloud tries to solve the problem of files. Sooner or later, that requires scale-out drives. deadlocks with high-level file locking. storage. Currently, the options are GPFS or Cons: an object store like Ceph/s3 or Openstack/ Swift. GPFS is expensive, and our s3 and • Fewer high availability options. Software Considerations Swift implementations use temp files which • The amount of data in ownCloud tends to prevents them from scaling adequately. continually grow. Eventually a single Operating System machine will not scale; I/O performance decreases and becomes a bottleneck We are dependent on distributions that Session Storage with multiple up- and downloads, even offer an easy way to install the various com- with solid-state drives. ponents in up-to-date versions. ownCloud • Redis: provides persistence, nice has a partnership with RedHat and SUSE for graphical inspection tools available, Scale-Out Deployment customers who need commercial support. supports ownCloud high-level file Canonical, the parent company of Ubuntu locking. Provider setup: Linux, also offers enterprise service and support. Debian and Ubuntu are free of • If Shibboleth is a requirement you must • DNS round robin to HAProxy servers (2-n, cost, and include newer software packages. use Memcached, and it can also be used SSL offloading, cache static resources) CentOS is the community-supported free-of- to scale-out shibd session storage (see • Least load to Apache servers (2-n) cost Red Hat Enterprise Linux clone. open- Memcache StorageService). • Memcached/Redis for shared session SUSE is community-supported, and inclu- storage (2-n) des many of the same system administra- • Database cluster with single Master, tion tools as SUSE Linux Enterprise Server. Storage multiple slaves and proxy to split requests accordingly (2-n) Relational Database • Database High Availability • GPFS or Ceph via phprados (2-n, 3 to be • Performance enhancements for Apache safe, Ceph 10+ nodes to see speed More often than not the customer already and PHP benefits under load) has an opinion on what database to use. In • How to Set Up a Redis Server as a Pros: general, the recommendation is to use what Session Handler for PHP on Ubuntu 14.04 their database administrator is most fami- • Components can be scaled as needed. liar with. Taking into account what we are • High availability. seeing at customer deployments, we • Test migrations easier. recommend MySQL/MariaDB in a master- slave deployment with a MySQL proxy in front of them to send updates to master, 5

Copyright 2016 ownCloud All Rights Reserved. ownCloud and the ownCloud Logo are registe- red trademarks of ownCloud, Inc.in the United States and/or other countries.

ownCloud, Inc. 57 Bedford Street Suite 102 Lexington, MA 02420 United States

www.owncloud.com/contact phone: +1 (877) 394-2030

ownCloud GmbH Schloßäckerstr. 26a 90443 Nürnberg Germany

www.owncloud.com/de/kontakt phone: +49 911 14888690

www.owncloud.com

@ownCloud facebook.com/owncloud gplus.is/owncloud linkedin.com/company/owncloud