Multiple instances sync/failover

Topics related to the setup and installation of NIM
Post Reply
ndroftheline
Posts: 4
Joined: February 19th, 2018, 9:53 pm

Multiple instances sync/failover

Post by ndroftheline »

Hey all, just wanted to try to get some input on how it might be smart to set up multiple instances that are synced for failover/load balancing purposes. We're in NZ and AU and the link between them is decent, but not great and sometimes may be unavailable for wahtever reason. We'd like to make sure that NIM keeps operating if one site goes down; how would you recommend, or do you maybe not recommend, setting up some sort of failover/synced setup between distributed sites?

Thanks!

User avatar
andrew
Site Admin
Posts: 337
Joined: June 24th, 2014, 8:10 am

Re: Multiple instances sync/failover

Post by andrew »

Hi,

NIM isn't currently configured to work with a distributed data, master/slave, or peer to peer configuration. This is something that we have been discussing but do not have on our roadmap as of yet. There are multiple ways we are looking to implement this, each with their own caveats. I'll share a few ideas here to see if you think any of these might meet your needs.

The first idea is to abstract the db from the frontend onto it's own VM. This way you could put the database VM somewhere, in the cloud for example, with high availability, and then run a local VM for the frontend. However when you say that the connection is unavailable at times, is that to the internet in general or just between offices? This solution would only suffice if the connection between offices was unstable but the connection to the internet had high availability. This does offer load balancing benefits as any media served/uploaded would be local to the location.

The other option is a master/slave situation where there are two VMs with the full database, one in each location. Each location would look at their local database for reads, however all write requests would need to be sent to the master. This works well for slow remote connections where the majority of requests are reads, but all writes would behave similar to the current implementation. So again, if the connection is down, then this fails for anything other than a read request.

The third option, which is quite a structural change, is to implement a global merging peer to peer system. Here the two VMs could operate independently and when a connection is reestablished it would sync the data based on a first come / first served method. Personally I'm not a huge fan of this as it could get dicey as people could be editing out of date information, however it's something we are looking at.

Would love to hear your thoughts on these options.

Cheers,
Andrew

Post Reply