Deployment Considerations

Hardware

  • Solid-state drives (SSDs) for I/O.

  • Separate hard disks for storage and database, SSDs for databases.

  • Multiple network interfaces to distribute server synchronisation and backend traffic across multiple subnets.

Single Machine / Scale-Up Deployment

The single-machine deployment is widely used in the community.

Pros:

  • Easy setup: no session storage daemon, use tmpfs and memory caching to enhance performance, local storage.

  • No network latency to consider.

  • To scale buy a bigger CPU, more memory, larger hard drive, or additional hard drives.

Cons:

  • Fewer high availability options.

  • The amount of data in ownCloud tends to continually grow. Eventually a single machine will not scale; I/O performance decreases and becomes a bottleneck with multiple up- and downloads, even with solid-state drives.

Scale-Out Deployment

Provider setup:

  • DNS round robin to HAProxy servers (2-n, SSL offloading, cache static resources)

  • Least load to Apache servers (2-n)

  • Memcached/Redis for shared session storage (2-n)

  • Database cluster with single primary, multiple replicas and proxy to split requests accordingly (2-n)

  • GPFS or Ceph via phprados (2-n, 3 to be safe, Ceph 10+ nodes to see speed benefits under load)

  • In case of clustering, your cluster nodes must have the same ownCloud configuration including an identical config.php to avoid any potential issues.

Pros:

  • Components can be scaled as needed.

  • High availability.

  • Test migrations easier.

Cons:

  • More complicated to setup.

  • Network becomes the bottleneck (10GB Ethernet recommended).

  • Currently DB filecache table will grow rapidly, making migrations painful in case the table is altered.

A Single primary DB is Single Point of Failure, Does Not Scale

When primary fails another replica can become primary. However, the increased complexity carries some risks: Multi-primary has the risk of split brain, and deadlocks. ownCloud tries to solve the problem of deadlocks with high-level file locking.

Software

Docker Host

ownCloud Server 11 runs exclusively in Docker containers. The host operating system only needs to provide Docker Engine and Docker Compose. A basic web server (Apache), the required PHP runtime, and the application dependencies are all encapsulated within the ownCloud Docker image.

Web Proxy

The Docker image does not handle SSL. Therefore, you must use a proxy in front of this image to add web security and other web-related settings. The embedded web server is pre-configured to serve ownCloud Server 11; further configuration is not possible.

Relational Database

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 primary-replica deployment with a MySQL proxy in front of them to send updates to primary, and selects to the replica(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 primary-replica setup.

What about the other DBMS?

  • Sqlite is adequate for simple testing, and for low-load single-user deployments. It is not adequate for production systems.

  • Microsoft SQL Server is not a supported option.

Storage

Docker Volume

When using bind mounts with the Docker volume, consider using a shared directory, such as NFS, as the mount point. This is important if you plan to implement Active-Passive failover scenarios, since the instance taking over must be able to access the configuration and app data..

File Storage

While many customers initially use NFS for file data, they eventually require scale-out storage. The current options are GPFS, GlusterFS or an object storage protocol such as S3. S3 also provides access to Ceph Storage.

Session Storage

  • Redis is required for transactional file locking Transactional File Locking, provides session persistence, and graphical inspection tools available.

  • If you need to scale out Shibboleth you must use Memcached, as Shibboleth does not provide an interface to Redis. Memcached can also be used to scale-out shibd session storage (see Memcache StorageService).