Cluster and cloud support for OpenMRS

We are evaluating providing documentation and tooling for deployment of OpenMRS to Kubernetes.

Kubernetes is open-source and supported by all big cloud vendors such as AWS, Azure, Google Cloud, smaller vendors and can be deployed on premise.

We will not be providing guidance on deployment and management of Kubernetes itself.

The proposed solution for Kubernetes will include Helm charts for production grade deployments of OpenMRS 3. They will be cloud vendor agnostic i.e. they will include minimal setup for deploying OpenMRS application, database and http gateway. The database and gateway will be optionally replaceable by services hosted by vendors.

A single Kubernetes cluster should be able to handle multiple deployments of OpenMRS with shared pool of VMs to support multi-tenancy in a scenario with one OpenMRS application container per tenant and a possibility to share database engine, but each tenant using a separate schema.

Container cluster such as Kubernetes provides us heavy lifting for high availability, better resource utilization than dedicated machines or VMs, logs aggregation and monitoring, upgrades, cloud compatibility.

Initial features will include:

  1. DB and DB read replica configured out of the box with automated backups.
  2. HTTP gateway for serving frontend and backend requests
  3. Health checks and automated restarts in case of failures
  4. Aggregated logs and metrics for OpenMRS service and DB.
  5. Rolling upgrades of containers

Prospectively we envision providing:

  1. Support for deployments with DB engine shared between OpenMRS deployments, but separate schemas (to support multi-tenancy for smaller facilities at lower cost)
  2. Support for OpenSearch indexes for patient and concept search for improved speed and HA.
  3. Support for OpenMRS service replicas with load-balancer in front for high availability and performance.
  4. Maintenance pages for upgrades
  5. Error logs notifications

Proposed vendors checklist for running a single deployment of OpenMRS:

  1. Kubernetes version 1.29
  2. Min. 2 VMs with 1.5+ GHz CPU, 2+ GB of RAM, 50+ GB of SSD (DB, DB replica, OpenMRS instance, http gateway)
  3. Optionally (recommended) vendor hosted MySQL 8.x with automated backups.
  4. Optionally (recommended) vendor hosted gateway with load balancing e.g. ELB (AWS), Gateway Load Balancer / Front Door (Azure)

We are sill in the evaluation phase and are open to go with any cluster technology and architecture so your feedback, experience and usage scenarios is invaluable. If there’s anything that you would like to accomplish in not so distant future, but are not sure how to go about it e.g. multi-tenancy, specific reporting needs, synchronization, geo-distribution, other concerns, please throw these on us and we can continue to refine the proposed architecture.

3 Likes

@burke, @cintiadr, @ibacher, @scott does jetstream provide any container cluster to use for testing purposes? Would we be able to get Kubernetes on AWS for testing (maybe using some of the AWS grant)?

Hi @raff I think jetstream supports containers and kubernetes. I just looked up the docs and found this Kubernetes - Jetstream2 Documentation

With enough AWS credits from the grant, EKS is ideal, only downside would be cost.

1 Like

@raff Do you have an account in our secondary AWS site? If not, I can probably set you up with one.

As @scott said, it’s possible to run a Kubernetes cluster on Jetstream (it’s just OpenStack), but there’s no managed option for a Kubernetes cluster, i.e., we’d have to build our own.

Thanks @ibacher. I’ve just e-mailed you regarding the account.

I should have mentioned in my initial post that the cluster route is only for some implementations and shall not replace the simple setup with docker for all smaller implementations running on-premise that we will continue to support.

@mseaton, @mogoodrich do you see the need for Kubernetes in any of PIH deployments? I recall you did have to deal with some huge DBs in your deployments. Have you ended up introducing DB clustering and replication in any scenario? Do you run any deployments serving many facilities from one datacenter?