> Right now, we would mean 50 virtual machines (each perhaps 2 GB memory) > with the usage still wouldn't swamp a single IFL. And, these are coded > queries. No dynamic "queries from hell". We just "can't" have that many > users. Currently we have 204 PC type database servers and we only have a > few thousand PCs. I figure it comes down to 20-30 possible users per > database with the very fast majority of them, occasional users.
First, the 2G size is *way* too big to start. Also, with that few users, the server images are likely to go idle fairly often, and Linux has become much better behaved about releasing resources when not needed. > So, I have been planning for about 5-7 production servers such as: > 1. First shift server (most City functions end at 5 PM) > 2. 6 AM to midnight server > 3. Near high availability > 4. Convention Center (their usage and uptime requirements based on the > current conventions) > 5. Courts system > perhaps a couple other "weird" ones > Plus their test systems, development systems. Think about it in terms of time spent tracking down problems. 1 app per server means you know exactly where the problem is if someone calls in a ticket. Your time - and time out of service - is much, much more expensive than more hardware. Also think about what it would take to reconstruct test servers, etc. Having separate servers for each purpose allows you to easily create/destroy instances, clone from dev to test, etc in a controlled way. That's a lot harder to do if you're sharing guests with multiple apps. > 1. Very high utilization along with performance requirements > 2. Political > 3. Some idiot designed things that every user needs DBA authority, hence > would have access to all other applications tables. #2 and #3 are the dominant force in most distributed applications. It's the "toddler" view of the world -- I have it, therefore it's mine. Mine, mine, mine. 8-) But, seriously, think about the time you'd need to diagnose stuff, or sort out how to combine applications into smaller #s of servers. Is it really worth the amount of administrative overhead you'll undertake to get a fairly small savings in resources? It's a lot harder over time to maintain shared images, especially if you don't have ways to coerce programmers to write maintainable systems. People are also a lot more expensive than hardware, and in the combined scenario you need more skilled people, which are even harder to find. > In large mainframe shops (not that we are one of them), I've only seen a > few database servers running to support all their applications (outside of > the PC servers). Most of those large mainframe environments also have the benefit of control over the applications development or deployment that you're not likely to have if you're using apps brought over from the distributed environment. You might, but it's a rare occurrence, and that's a LOT harder battle to fight than just giving them separate instances and showing an immediate ROI improvement on license count. Rich's comment on XIP is a good one -- that's a winner, and you can still give them what they want w/o wasting resources, but the other parts are kind of penny-wise/pound-foolish. This is a battle you don't have to fight; think of it as a quicker way to get machine upgrades...8-). -- db ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
