[Asterisk-Users] Hardware to build an Enterprise AsteriskUniversal Gateway

[Rich Adamson]

> 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