Support

How can I achieve High Availability with my Shiny Server Pro instances?

Follow

We have a couple of features that will help you achieve high availability, depending on your needs:

1) balancing load within a single Shiny Server Pro server
2) load balancing to handle high volume
3) an extra license for a disaster recovery scenario

For the first, within a single Shiny Server Pro instance, you can tune the performance of the server using the Utilization Scheduler to balance connections across R processes.  There is detailed information on the scheduler in this section of the admin guide.

For the second, you could build a cluster of Shiny Servers and load balance traffic to them with a proxy like nginx. The key thing is to make sure to have sticky load balancing so that future requests for a given session go back to the same server.  Please see this article on running Shiny Server with a proxy for related information.

Note that that article is much more focused on nginx as a proxy than on nginx as a load balancer, but fortunately, configuring nginx as a load balancer is no different for Shiny Server than it is for any other web server.  There is an article on setting up nginx load balancing here.

To load balance Shiny Server, you can put the addresses to your two Shiny Servers in the "upstream" property in the nginx configuration file, using the ip-hash load balancing mechanism.  This mechanism is necessary to ensure "sticky" client sessions; otherwise, the applications will break in unexpected ways.  Finally, configure the "map" and "server" components of the nginx configuration file as described in the "Running Shiny Server with a Proxy" article and restart nginx.

Finally, for the third, you can contact your sales representative to get details on acquiring an extra license.  With the extra license, you can provision a Shiny Server in your separate disaster recovery cluster, as appropriate.

Note that a disaster recovery license is intended to be used for recovery in extreme cases of downtime. It is characterized at a minimum by being in a separate physical location from your main production servers, not load-balanced with active servers, inactive as long as the production environment it is intended to recover is active, and explicitly documented as part of a disaster recovery plan. Disaster recovery licenses cannot be load-balanced with production servers. High availability features for routine downtime occurrences require additional production licenses.

Comments