High Availability for NextCloud


i have the following scenario, i have three servers that are installed on Amazon EC2s (Ubuntu 16.04) that installed on them, NextCloud server 12.0.4, and my database is Amazon RDS for the three of them , and the primary storage is Amazon S3, and all three EC2s are behind Amazon Load Balancer.

what should i do to have these three Servers synced together so they will form High Availability NextCloud servers cluster?

is there anything wrong with the architecture ? what else is required to achieve this structure

There are some more pages in the documentation:

If you are not expert for such systems and you want to realize a larger deployment, you should check out the enterprise support, they have more experience and can help you: https://nextcloud.com/pricing/. On the forum are mostly private users with smaller setups (and a few larger ones), so there are comparable few people with multi-server setups and experience in running highly-available setups.

Apologies for the necropost but if Samir’s experience in High Availability is anything like mine, the question is still open.

I have found tflidd’s comments to be,unfortunately, accurate. I don’t understand how we can call something a “cloud” if it solely exists on a single machine–however, the community seems to disagree so tflidd is correct in warning you not to expect much in the way of knowledge/experience!

My setup is on my own system so I can’t tell you what will change with AWS… but it sounds like you’re on the right track. While the official answer is that nextcloud web service are stateless and that as long as you’re using a proxy (which your load balances has) then you’re fine (web proxy maintains connections & database maintains state). However, do keep in mind that any NextCloud store apps you install will write files to a folder files on the webserver and will be referenced in the database. I expect things will not play nice if you don’t have your apps synced so I would highly recommend that you map the apps folder to a shared location.

I would also make sure files like php.ini are shared too, as you don’t want different web services having different max file sizes for uploads.

Other considerations in a high-availability/multiple app server deployment:

  • Perform installation with only a single instance deployed, THEN make the configuration folder read-only (best to do it at mount time).
  • Ensure PHP session storage is using a shared resource like Redis instead of on-disk, or you will have problems with CSRF token validation. Otherwise, each app server has a different view of the user’s session.
  • Ensure that data volumes being shared between the instances are fast enough that there is not replication lag between them. For example, on Azure, use Azure Files/SMB instead of Azure Blob or you will be in for a world of pain since Blob isn’t expected to maintain consistency across instances when one instance is writing and others are reading.

We’ve published our own Docker-based, multi-instance deployment kit for Azure Kubernetes Service here, in case it’s useful as a reference:

1 Like

After doing some research on this subject for a home server solution.
I looked at possibly using https://telebit.cloud/ to broadcase from different raspberry pi’s
then use a mysql db from a shared webhost that is whitelisted for the raspberry pi public ip,
use an apache to load balance between different telebit urls https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html,
store files locally on raspberry pi’s using external usb storage options and mirror using something like resilio or btsync

Shared hosting databases are often limited, and because it’s on a different site you get an additional delay on your queries. If a single raspberry is not powerful enough, I’d try more powerful ARM boards or other computer system first, where everything is hosted (with good backup). Your complicated setup combined with single points of failures (load balancer, connection to db-hoster, …) could have lower availability than a single computer setup.