Servers' architecture for multiple Mirth Connect clients

Question

Question: What is the best server architecture for multiple mirth connect installations for different clients?

Detailed Problem: We have a client that is sending HL7 msgs as well as other data with CSV files. we have used Mirth Connect to process these data into our systems (using around 7 channels in Mirth Connect). Mirth connect installation and its internal database are on the same server. However, in the near future we are adding many clients (around 10 this year), and we need to come up with a scalable solution that should be able to handle the load. We are planning of using a single central server (powerful) for the internal database of all the mirth connect installations (Postgresql db with a different schema for each mirth connect instance). and one mirth connect instance per client, each on a separate (smaller) server connected to the central database server.
Is this a good approach?

Thanks in advance.

Answer 1

Certainly what you've described is a viable solution. If all servers connect to the same internal DB, then all channels will be deployed on all server instances. But if you keep the schemata (always feel weird using that word) separate for each instance, then you sacrifice maintainability because now you have multiple MC instances to login to and manage.

It's still possible to do what you want on a single DB... for example channels A1..An should only be deployed on the instance for Client A, channels B1..Bn should only be deployed on the instance for Client B, and so on. One thing you could do is have a global deploy script that checks your current server ID and looks up what channels are "allowed" for that server in your own custom lookup table. Then if it's not allowed, throw an exception so the channel won't be deployed.

There's also a hybrid approach. Still have a separate instance/DB per client, but you can also have multiple instances for each client. You can do this for primary/backup failover purposes, or active/active load balancing purposes. That way you're also bring high availability at the MC application level. That's where the Advanced Clustering extension really shines... it's built specifically for horizontally scaling MC instances that share a single shared DB (that may also be horizontally scaled itself).

As a general note, whenever anyone has issues with performance/throughput, in the vast majority of cases the bottleneck is not MC per se, but instead the Disk I/O write times. So I'd definitely recommend using SSD for your database storage layer. Or at the very least an SSD fast-cache on top of spinning disks.