Two node on instance

Hi
what errors are expected during implementation

  1. DNS balancing . example.com - 2 diferent IP
  2. Two peertube node (with diferent public IP)
  3. folder ~/storage as nfs, connect 2 instance
  4. central Postgres Database server

It won’t work. Many things are not compatible (notifications, tasks scheduling, plugin installation, …).

There are other ways to do load balancing with peertube (redundancy system, proxy caching, …).

« There are other ways to do load balancing with peertube (redundancy system, proxy caching, …). »

This way not good for high availability service

Static files/bandwidth are almost certainly going to be your first bottleneck, and for that multiples nodes are less useful than reverse-proxy caching and redundant instances.

1 Like

performance and avability are different things … sooner or later the server will need to be stopped for maintenance … and the service will not be available and some of the users will no longer use it, considering it unstable (((

I see, I hadn’t grasped the nuance. Thanks!

Making the server able to run accross multiple nodes is a costly development though, and the availability loss currently isn’t as dire as you make it sound, even for a version update or a server migration.

1 Like

Thanks for the answer !

I hope that in the future you will plan the implementation of this functionality.

P.S. As it seems to me personally, without this, the platform will not be used for large installations, but will continue to be used by enthusiasts IT

While I fail to see anything tying technical scale to high availability (you would rather use performance metrics as a measure of technical scale), I could also point out that large installations might not be desired – big installations tend to hold power within federated networks.

1 Like

High availability is always tricky but to give you an order of magnitude assuming your setup is correct PeerTube documentation takes seconds, a minute at most. If your configuration is off you can pin a version and rollback. If you need close to perfect availability you could consider mirroring and have a floating IP.

We’ve achieved some « high availability » with a kubernetes setup described in the documentation PeerTube documentation with the media files stored on S3 (in our case OVH S3 which relies on openstack swift, s3 has many self-hosting options) and the data in a postgresql cloudb (which has high availability - but you can probably do a high availability setup of postgresql self-hosted) .

One size doesn’t fit all, but know that using kubernetes (which for some use cases is way too complex) enables to have the « application » runners, and you can upgrade / maintenance your kubernetes nodes without having to shut down the service.

Hope you find a scenario that fits your needs. As far as our experience goes, peertube has no technical limitations that can’t make it into a high available solution.

1 Like