Hello Michael, Very good analysis.
We @ MSF are currently thinking along the same lines. Having one VM for each OpenMRS installation we will have, for the sake of data privacy and resilience. Thanks for sharing your thoughts. Best regards, Thang From: Michael Downey <[email protected]> To: [email protected] Date: 25/04/2012 18:43 Subject: Re: [OPENMRS-IMPLEMENTERS] Multiple Tomcat instances or multiple VMs to have many instances of OpenMRS Sent by: [email protected] Hi Joaquin, On Wed, Apr 25, 2012 at 11:47 AM, Joaquín Blaya <[email protected]> wrote: > Good question, I hadn't decided on that. My initial guess would be multiple > schemas on the same database instance, but I'd be happy to hear feedback on > the other option. The thing that first crossed my mind is security and privacy of data. Your clients might have requirements (or at least concerns) related to sharing a database with others. I imagine there probably not regulatory issues involved for where you're working, but it's still a consideration that some people might think of and understandably be concerned about. There are ways to mitigate this risk, of course, using security mechanisms within the single VM. > Yep, agreed. I see in Rackspace for example that having 2 2Gb machines or 1 > 4Gb machine is the same cost. Unfortunately, that's not the same here in > Chile (so we'll have to evaluate if we go with servers in the US). But the > question is in 2 2GB machines you'll be able to run 2 instances of OpenMRS, > while with 1 4Gb machine you could potentially run 3 OpenMRS instances (50% > more), and that commercially could be important. Of course keep in mind network latency for US vs. local servers. It might not be cost effective, but you may want to price out buying/leasing a large server that you could then divide into your own VM's using KVM or another such solution. Even if you did this, you'd still have a single poitn of failure at the hardware level that you might be able to avoid by leasing individual VM's from a provider. > Could you tell me or point me to a page which describes the disadvantages or > risks of multiple tomcat instances for example what you mean by limiting how > quickly you can respond to change, or how or if the tomcat instances could > interact with each other. As long as you kept each of the instances patched regularly, I don't see much of a problem from a technical perspective. It would be important to keep the configurations well-managed as each instance wouldn't quite be the same (you'd be running them on different ports and/or IP addresses) -- and that could be a bit confusing for management, but not too much. As I mentioned earlier there may be some privacy/security concerns around having data co-mingled on the same hardware, but that's a risk you can accept or mitigate through other means (e.g., different OS/DB users, separate Apache instances if you're putting a web server in front of Tomcat, etc.). There's also a disadvantage in terms of upgrading or flexibility. As you suggested earlier, should you need to patch the OS/kernel and reboot (happens occasionally) you'd have to arrange a common downtime for all your clients using a given VM. Additionally, a DDOS attack (unlikely but not unheard of) against one IP address (presuming you had a separate IP for each client's system) could consume all the VM's resources and affect other clients--at least until the cause and target were identified and traffic blocked. These are the first things that come to my mind--more from experience rather than any given resource, although I'm sure Google could turn up some. > For memory constraints, I don't know exactly what you mean. I think the RAM > used and the cost of each VM are the key cost factors that I'm trying to > balance. Here I just meant that you'll want to account for the memory footprint of MySQL or whatever database you use--and the more instances (or schemas) you have running simultaneously, the more memory usage that DBMS will have. Food for thought ... this work sounds interesting and I hope you'll keep asking questions when they come up and keep us updated as to how it goes! Michael _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l] _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l]
