Multiple presentation nodes?

[TheRealKingS]

Since we want to slowly decommission Wowza for HLS streams and the HLS streams are to be provided via the presentation node, the question arises as to whether this is even possible with Opencast.
My idea: I set up an HAProxy or an NGINX proxy that listens to the URL of the presentation node. This then distributes the load to the other presentation nodes. The presentation nodes then each use the same configuration, as well as the same CephFS storage. Has anyone already used this or are there still pitfalls? The aim is to replace the single engage node with 3 engage nodes and a load balancer.

[KatrinIhler]

Off the top of my head it should definitely be possible to run multiple presentation nodes at once. But I've personally never done it. :D

[rute-santos]

Which version of Opencast are you running? Versions <= 15 were problematic because of the SOLR search index. We haven't tried it either.

[gregorydlogan]

To clarify what Rute's saying here, it was possible <= 15, but required tracking down and running a very old version of Solr. Old enough that actually finding the relevant files has become challenging.

[TheRealKingS]

Yeha we are @ Opencast 16.x

[reiferschris]

Do you mean decommission wowza for livestreams or vod streams?
Either way I would argue that it's not the presentation node you would have to worry about. You can configure where the stream files/playlists are located in opencast and even define a different URL (e.g. download.opencast.your-institution.edu). Then all you really need is a (bunch of) webservers that handle the traffic and can access the files on the file system layer. Opencasts presentation node would then only be involved for delivering the player assets and the episode.json if I'm not mistaken.
While I don't want to argue against a clustered proxy setup I can tell you from our experience that even one small vm handles almost all of our traffic, including livestreams and vod without a sweat.
Since this is an interesting topic I would suggest you pop by the sys admin meeting next time so we can discuss this? Coincidentally I think next time (26.03. 3pm CET) @snoesberger will present their setup and they happen to have livestreaming and vod playback without wowza via HLS.

[TheRealKingS]

We only want to get rid of the VOD - live streams will continue to run via Wowza, as they do the downscaling for us.
Your description sounds good - the presentation node in this setup is then, as now, only the supplier for the opencast player (Paella) and gets the streams from Wowza. So if I can point this URL (the one from Wowza to the HLS streams) to another proxy where HAProxy and three other servers are only responsible for “downloading” the HLS streams, that would be great. Saves me some problems with multiple presentation nodes. So it remains one. As I can't currently estimate 100% whether one VM is enough for our streams, I just want to protect myself with three.

[mtneug]

Delivering static assets can be done in multiple ways with Opencast. Personally, I would recommend what @reiferschris is suggesting. In general, adding redundancy is good for availability. So, I would say go for multiple VMs, even if one is enough.

[snoesberger]

I agree with @reiferschris.
On our end, we serve all the VoD video files, preview pictures, HLS live streams (playlists, video chunks), etc. with a pair of nginx webservers behind a load balancer. The presentation node only provides the Paella player and information about the event and series and has therefore not much load. The media download URL is configured using the org.opencastproject.download.url=' parameter in the Storage section of the custom.properties' config file.

[TheRealKingS]

To have it complete now: A HAProxy is sufficient, whose URL is then entered in Opencast as org.opencastproject.download.url. This can then distribute to three other servers, all of which have mounted the shared storage (CephFS in our case) and they then provide the videos. An NGINX/Apache can then run on the three servers. Correct so far?

[mtneug]

Not quite. Changing org.opencastproject.download.url will only be relevant for newly published events. All old events will still point to the old URLs. There is this guide to change stuff without republishing everything, but maybe you can also simply redirect / proxy for the path prefix /static/....