On 3/24/2011 2:07 PM, m.roth at 5-cent.us wrote: > >> Having said that, I have this troubling thought for last decade: What >> exactly is high availability: is it 24/7 power on time? or is ti "when >> needed". Please not it am not talking about the maybe arrogant "on >> demand" attitude of a human. > > Ok, h/a is not "fault tolerance", which is for 99.+% uptime (and you *pay* > a lot for additional decimals there). Most of the computation in percentages is like computing rates for insurance - balancing the penalty for missing your SLA against the cost of providing it. But on the operations side you can only work in integer numbers of instances. You know everything will break and if you can't be down long enough to replace it, you need a complete duplicate copy, and then you may need to duplicate that pair in another location. If you aren't already working with grid/cluster systems you almost always more than double your cost to get even the slightest increase in expected availability. >> What exactly is "production" use? (I know DEV, UAT, blah, bla, tla >> etc been there done that and I don't have the T shirt - nobody gave me >> one) > > All services expected from a server at a given IP should be available up > to or over 99% of the time, with no lost transactions, or transactions in > an undefined state - that's h/a and production. Not everything deals in transactions, though. The recently popular distributed database versions that scale up are more about doing something reasonable in scenarios where you can't guarantee a transaction state (where 'reasonable' is defined by the application). -- Les Mikesell lesmikesell at gmail.com