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.
Note
Whatever the size of your organization, always keep one thing in mind: the amount of data stored in ownCloud will only grow. Plan ahead.
Consider setting up a scale-out deployment, or using Federated Cloud Sharing to keep individual ownCloud instances to a manageable size.
Up to 150 users.
100 GB to 10TB.
Zero-downtime backups via Btrfs snapshots, component failure leads to interruption of service. Alternate backup scheme on other filesystems: nightly backups with service interruption.
One machine running the application server, Web server, database server and local storage.
Authentication via an existing LDAP or Active Directory server.
One server with at least 2 CPU cores, 16GB RAM, local storage as needed.
Enterprise-grade Linux distribution with full support from OS vendor. We recommend Red Hat Enterprise Linux or SUSE Linux Enterprise Server 12.
The SSL termination is done in Apache. A standard SSL certificate is needed, installed according to the Apache documentation.
None.
MySQL, MariaDB or PostgreSQL. We currently recommend MySQL / MariaDB, as our customers have had good experiences when moving to a Galera cluster to scale the DB.
Install owncloud, ownCloud data directory and database on Btrfs filesystem. Make regular snapshots at desired intervals for zero downtime backups. Mount DB partitions with the “nodatacow” option to prevent fragmentation.
Alternatively, make nightly backups with service interruption:
Then optionally rsync to a backup storage or tape backup. (See the Maintenance section of the Administration manual for tips on backups and restores.)
User authentication via one or several LDAP or Active Directory servers. (See User Authentication with LDAP for information on configuring ownCloud to use LDAP and AD.)
Local session management on the application server. PHP sessions are stored in a tmpfs mounted at the operating system-specific session storage location. You can find out where that is by running grep -R 'session.save_path` /etc/php5 and then add it to the /etc/fstab file, for example: echo "tmpfs /var/lib/php5/pool-www tmpfs defaults,noatime,mode=1777 0 0" >> /etc/fstab.
A memcache speeds up server performance, and ownCloud supports four memcaches; refer to Configuring Memory Caching for information on selecting and configuring a memcache.
Local storage.
Standard Edition. (See ownCloud Server or Enterprise Edition for comparisons of the ownCloud editions.)
150 to 1,000 users.
Up to 200TB.
Every component is fully redundant and can fail without service interruption. Backups without service interruption
2 to 4 application servers.
A cluster of two database servers.
Storage on an NFS server.
Authentication via an existing LDAP or Active Directory server.
Enterprise grade Linux distribution with full support from OS vendor. Red Hat Enterprise Linux or SUSE Linux Enterprise Server 12 are recommended.
The SSL termination is done in the HAProxy load balancer. A standard SSL certificate is needed, installed according to the HAProxy documentation.
HAProxy running on a dedicated server in front of the application servers. Sticky session needs to be used because of local session management on the application servers.
MySQL/MariaDB Galera cluster with master-master replication.
Minimum daily backup without downtime. All MySQL/MariaDB statements should be replicated to a backup MySQL/MariaDB slave instance.
- Create a snapshot on the NFS storage server.
- At the same time stop the MySQL replication.
- Create a MySQL dump of the backup slave.
- Push the NFS snapshot to the backup.
- Push the MySQL dump to the backup.
- Delete the NFS snapshot.
- Restart MySQL replication.
User authentication via one or several LDAP or Active Directory servers. (See User Authentication with LDAP for information on configuring ownCloud to use LDAP and AD.)
Read-only slaves should be deployed on every application server for optimal scalability
Session management on the application server. PHP sessions are stored in a tmpfs mounted at the operating system-specific session storage location. You can find out where that is by running grep -R 'session.save_path` /etc/php5 and then add it to the /etc/fstab file, for example: echo "tmpfs /var/lib/php5/pool-www tmpfs defaults,noatime,mode=1777 0 0" >> /etc/fstab.
A memcache speeds up server performance, and ownCloud supports four memcaches; refer to Configuring Memory Caching for information on selecting and configuring a memcache.
Use an off-the-shelf NFS solution, such as IBM Elastic Storage or RedHat Ceph.
Enterprise Edition. (See ownCloud Server or Enterprise Edition for comparisons of the ownCloud editions.)
5,000 to >100,000 users.
Up to 1 petabyte.
Every component is fully redundant and can fail without service interruption. Backups without service interruption
4 to 20 application/Web servers.
A cluster of two or more database servers.
Storage is an NFS server, or an object store that is S3 compatible.
Cloud federation for a distributed setup over several data centers.
Authentication via an existing LDAP or Active Directory server, or SAML.
RHEL 7 with latest service packs.
The SSL termination is done in the load balancer. A standard SSL certificate is needed, installed according to the load balancer documentation.
A redundant hardware load-balancer with heartbeat, for example F5 Big-IP. This runs two load balancers in front of the application servers.
MySQL/MariaDB Galera Cluster with 4x master – master replication.
Minimum daily backup without downtime. All MySQL/MariaDB statements should be replicated to a backup MySQL/MariaDB slave instance.
- Create a snapshot on the NFS storage server.
- At the same time stop the MySQL replication.
- Create a MySQL dump of the backup slave.
- Push the NFS snapshot to the backup.
- Push the MySQL dump to the backup.
- Delete the NFS snapshot.
- Restart MySQL replication.
User authentication via one or several LDAP or Active Directory servers, or SAML/Shibboleth. (See User Authentication with LDAP and Shibboleth Integration.)
Read-only slaves should be deployed on every application server for optimal scalability.
Redis should be used for the session management storage.
Redis for distributed in-memory caching (see Configuring Memory Caching).
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.
Enterprise Edition. (See ownCloud Server or Enterprise Edition for comparisons of the ownCloud editions.)
The single-machine deployment is widely used in the community.
Pros:
Cons:
Provider setup:
Pros:
Cons:
Could be used instead of HAproxy as the load balancer. But on uploads stores the whole file on disk before handing it over to PHP-FPM.
When master fails another slave can become master. However, the increased complexity carries some risks: Multi-master has the risk of split brain, and deadlocks. ownCloud tries to solve the problem of deadlocks with high-level file locking.
We are dependent on distributions that offer an easy way to install the various components in up-to-date versions. ownCloud has a partnership with RedHat and SUSE for customers who need commercial support. Canonical, the parent company of Ubuntu Linux, also offers enterprise service and support. Debian and Ubuntu are free of cost, and include newer software packages. CentOS is the community-supported free-of-cost Red Hat Enterprise Linux clone. openSUSE is community-supported, and includes many of the same system administration tools as SUSE Linux Enterprise Server.
Taking Apache and Nginx as the contenders, Apache with mod_php is currently the best option, as Nginx does not support all features necessary for enterprise deployments. Mod_php is recommended instead of PHP_FPM, because in scale-out deployments separate PHP pools are simply not necessary.
More often than not the customer already has an opinion on what database to use. In general, the recommendation is to use what their database administrator is most familiar with. Taking into account what we are seeing at customer deployments, we recommend MySQL/MariaDB in a master-slave deployment with a MySQL proxy in front of them to send updates to master, and selects to the slave(s).
The second best option is PostgreSQL (alter table does not lock table, which makes migration less painful) although we have yet to find a customer who uses a master-slave setup.
What about the other DBMS?
Our main use case is up- and download of files. Sooner or later, that requires scale-out storage. Currently, the options are GPFS or an object store like Ceph/s3 or Openstack/Swift. GPFS is expensive, and our s3 and Swift implementations use temp files which prevents them from scaling adequately.