Michael, Agreed with Thang that this has been great. I had a last question. If you had multiple Tomcat instances versus multiple VMs should you be able to use less RAM?
For example, if I want 4 instances of OpenMRS, I could do 4 VMs each with 2 Gb RAM each (that's what my experience has shown me is best to run a simple instance of OpenMRS) or if I understand correctly I could have a single 5 Gb RAM VM with 4 tomcat instances each with 1 Gb each, which should be approximately the same, no? (This is assuming similar processor between the machines and also that the single VM has 4x the hard disk space) I know that we're going to have to test this setup up out (and I'll report the findings), but at least on a theoretical level they should be the same? (Aside from the JVM garbage collector which is probably going to spike more for the larger machine) Thanks, Joaquín ___________________________________________________________________ Gerente de Desarrollo, eHealth Systems <http://www.ehs.cl/> Research Fellow, Escuela de Medicina de Harvard <http://hms.harvard.edu/> Moderador, GHDOnline.org <http://www.ghdonline.org/> On Thu, Apr 26, 2012 at 4:42 AM, Thang Dao <[email protected]> wrote: > 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] > _________________________________________ 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]
