I’ve visited both FOSDEM and SCALE over the last weeks, where spoke with dozens of people and gave talks about ownCloud 8. We’ve been getting a lot of positive feedback on the work we’re doing in ownCloud (thanks!) and that has been very motivating.
Does it scale?
A question which comes up frequently is: “What hardware should I run ownCloud on?” This sounds like a simple questions but if you give it a second thought, it is actually not so easy to answer. I had a small cubox on the booth as a demonstration that this is a way to run ownCloud. But development boards like the Raspberry Pi and the cubox might give the impression ownCloud is only suitable for very small installations – while in reality, worlds’ largest on-premise sync and share deployment has brought ownCloud to 500,000 students! So, ownCloud scales, and that introduces the subject of this blog.
If you look up the term scalability on wikipedia you get the explanation that software scales well if you get double the performance gain out of it if you throw twice the hardware at the problem. This is called linear scalability, and rarely if ever achieved.
The secret to scalability
ownCloud runs on small Raspberry Pi’s for your friends and family at home but also on huge clusters of web servers where it can serve over hundreds of thousands of users and petabytes of data. The current Raspberry Pi doesn’t deliver blazing fast performance but it works and the new raspberry pi 2 announced last month should be great hardware for small ownCloud deployments. Big deployments like the one in Germany or at CERN are usually ‘spread out’ over multiple servers, which brings us to the secret sauce that makes scalable software possible.
This secret to building great scalable software is to avoid central components that can be bottlenecks and use components that can easily be clustered by just adding just more server nodes.
How ownCloud scales
The core ownCloud Server is written in PHP which usually runs together with a web server like Apache or ISS on an application server like Linux or Windows. There is zero communication needed between the application nodes and the load can be distributed between different application servers by standard HTTP load balancers. This scales completely linear so if you want to handle double the load because you have double the users, you can just double the number of application servers making ownCloud perfectly scalable software.
Unfortunately an ownCloud deployment still depends on a few centralized components that have the potential to become bottlenecks to scalability. These components are typically the file system, database, load balancer and sometimes session management. Let’s talk about each of those and what can be done to address potential performance issues in scaling them.
File system scalability
The file system is where ownCloud has its data stored, and it is thus very important for performance. The good news is that file systems are usually fast enough to not slow down ownCloud. A modern SSD, RAID setup, NFS server or Object Store can deliver data rates that are a lot faster than the typical internet network uplinks so you rarely bump into limits with data storage. And if you do, there are solutions like GlusterFS which help you scale performance quite easily. On the App server, a properly setup and configured Temp directory is important to achieve good performance as data has to flow via the ownCloud installation to the user (sync clients or web interface).
Sometimes, this isn’t enough. If you have to handle petabytes of data, ownCloud 8 offers a solution developed together with CERN. This solution lets ownCloud act as a storage broker to direct read and write requests directly to the storage node where the data resides. The result is that that no actual payload flows through the ownCloud servers anymore and the storage performance is entirely dependent upon the data storage itself. Thanks to this solution, the file system storage should never be the bottle neck for ownCloud.
Database scalability
ownCloud uses a database to store all kind of metadata so it depends on a database which is very fast and scalable to keep performance up. ownCloud can use enterprise databases like MSSQL and Oracle DB which offer all kinds of fancy clustering options. Unfortunately they are proprietary and not necessarily cheap. Luckily there are Open Source alternatives like PostgreSQL and MySQL/MariaDB which also offer impressive clustering and scalability options. Especially MySQL combined with a Galera cluster is a very nice and fast option that is used by a lot of the larger ownCloud installations.
Note that scalability doesn’t always mean big! Scalability also means that ownCloud should run fine on very tiny systems. Some embedded systems like the first Raspberry Pi had very limited RAM. In such situations it is nice to use SQLite which is embedded in the PHP runtime and has a very tiny memory footprint, saving precious system resources. This is is all about choice for the right system size!
load balancer scalability
If you have more than one application server than you need a way to distribute the incoming requests to the different servers. ownCloud uses a standard protocol like HTTP so that off the shelf solutions can be used for load balancing. There are standard and enterprise grade appliances from companies like F5 that are very fast and reliable if used for redundancy with a heat beat. Nowadays there are also very good and affordable options like the Open Source HAProxy on top of a standard Linux system available. This also works very well and is very fast. If you really have a lot of traffic and don’t want to buy hardware appliances you can combine several redundant HAProxy servers with DNS round robin. This has to be done very carefully so that you don’t compromise your high availability. There are several blogs and articles out there describing how to set up a system like this.
Session management scalability
There are two fundamentally different ways to do session management which are both supported by ownCloud. One is local session management on the application servers. The other is a centralized session management. I don’t want to discuss the pros and cons of both solutions here because they are a lot of aspects to consider. But with regards to scalability I want to mention that the simpler solution to have local session management together with sticky connections has the benefit that it does not need a central component. This means that it provides linear scalability. If a centralized session management is used then something like memcached is recommended and supported by ownCloud because it can also scale easily internally.
summary
ownCloud has been designed to scale from tiny embedded systems like a Raspberry Pi for a few users to a standard Linux server for a small workgroup to a big cluster for several hundred thousands of users. A wide variety of solutions and technologies can be used to make this possible and if you are interested in ways how to do this than have a look at the owncloud documentation for more information and look at the third party resources and white papers available for this on owncloud.com