> I don't want to drag this into a long thread, but note the original says > "the system should survive just about anything short of an act of God", > and suddenly you are talking about a reliable server and a few switches. > These are quite different things. I have yet to see a 5 x 9's server > room. Fire, mechanical damage and other factors will normally keep the > location itself well below 5 x 9's. Think "system" instead of "server > equipment", and the picture looks very different. Even for a single PC > type server, downtime due to telecoms lines, power problems, fire, > flood, typhoon damage, theft and a mass of other stuff mught well exceed > the server unavailablility itself. I've seen many servers not fail in 5 > years. I have yet to see the best location go that long without causing > at least one substantial period of downtime. 5 x 9's allows about 6 > minutes downtime a year. That means 100% of all failures must have > automated failover, as manuals repair could never be achieved so fast. > Physical diversity if essential for that.
The five-9's thread has been discussed under several different subjects in the last few months, and its not difficult to detect from the postings the subject has lots of very different levels of technical understandings. It's also obvious that many have not worked in a business or institution where disaster recovery or business continuity plans mean something much different then redundant power supplies, raid, motherboard on the shelf, a Sun multiprocessor system, a database server, redundent layer-2 switches, or lots of toys in one's basement. Whether one refers to application/system availability as five-9's, maximum uptime, or some other set of words is mostly irrelevant; the objective is still to provide the highest level of functionality possible given a set of business parameters that might include cost, time to repair, commercial power stability, regional susceptibility to tornados or floods, etc, etc. Low-end ISP's tend to believe a UPS would address their needs, small companies tend towards hot/cold spares, while larger organizations frequent towards other approaches that minimize the need for human involvement to recovery from any form of failure. Gus may have a strong conviction that clustering addresses his needs (given his set of business drivers), while Joe's needs are to recover from "any" event (including loss of building"s") within X hours that may be driven by outside requirements such as government regulations, etc. It is a given the recovery plan and supported investments will be dramatically different for many business cases. Neither one should be ragged on since none of us on the list are exposed to their business drivers. Regardless of how one chooses to address application availability (for the purposes of this list anyway), sharing configuration and operational data between multiple asterisk boxes on a more real-time basis is/will be important to those involved with systems in the small business category and above. Therefore, the list would benefit from discussions and implementations that help support the task of dynamically sharing asterisk data across multiple systems to improve uptime (whatever that happens to mean to each reader). Excluding the low-end ISP approach and from a 5,000-foot level, it would appear that an underlying/common design data-point might be "what are the asterisk design changes that need to occur to support two (or more) asterisk systems in seperate physical locations?" (Note that if someone's business drivers suggest the systems remain within the same building/room, that's fine. If they are separated by 10 feet or 100 miles, that's fine. If someone wants to include UPS, power supplies, raid, dual-this-or-that, layer two/three boxes, load balancers, Sun systems, database servers, etc, that's fine. If an external T1 switch is required, that's fine. If clustering add's some value for someone's deployment, that's fine. If a hot spare meets the business needs, that's fine. If lots of people have issues with a particular sip phone vendor's method of fail over, I'll bet some vendors would be more then willing to improve code "if" they understood it gives them a competitive advantage over another vendor, etc, etc.) Thoughts? Rich _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
