Peter put forth on 11/1/2010 6:51 PM: > Hi Stan, > >> 1. What are your specific failure concerns with your >> primary site? >> Network failure? Host failure? Storage hardware >> failure? > > You have a great suggestion assuming the data center functions well. > > the data center primary site failure means that the data center > itself failed, meaning the host machine/storage/network are all > in-accessible.
You seem to be looking at this from a macro point of view. For an entire datacenter to "fail" you're looking at something like a natural disaster (hurricane, earthquake, tornado, flood, lightning) destroying the facility, or all power and comm lines into it. The probability of these things is very low, assuming the datacenter was located, designed, and constructed properly. I suggest you need to look at disaster avoidance and recovery from a micro point of view. Failures at the micro level are far more common, and less expensive to architect around and recover from. >> Maybe a good question for you to ask of the members of this >> list at this >> point is: >> >> How many OPs here run with a multi site IMAP cluster setup >> with a >> physically distributed mail store, either via replication >> or a cluster >> filesystem over a wide area network? >> > > That is a good question. It is something I am looking for. Then simply start a new thread and ask the question of the members of this list. The answers you get should be very instructive. My guess is that very very few OPs here are doing what you're attempting to do, and yet they have great reliability. I may be all wrong. Ask the list and get consensus on how others approach disaster avoidance and recover of their IMAP stores. > however, if not going for expensive cluster filesystem over a wide area > network, > one simple way is to rsync every 5 minutes to copy over a backup serer in > another data center and a quick > dns change if the primary data center failed. The TTL in DNS settings can be > 5 minutes. This is not automatic fail over. If you're going to bother with a remote hot site, you should have automatic fail over of the mailbox server. Again, I ask you, is your primary site so prone to failure that you _need_ a remote site? Let me guess: You have already sold your superiors on the idea of a remote hot site, and now you're trying to figure out how to implement it? If this is the case I'm wasting my breath and you are wasting the lists' time. A technical engineer identifies a problem and then finds and implements the proper solution. He doesn't pick a solution from a magazine article or blog that sounds neat, to a problem that may or may not exist at his organization, and then drive to implement it due to personal desires instead of operational needs. A hot backup site is actually relatively rare. Few organizations implement this strategy. In the vast majority of cases the cost of such an architecture (hardware, comms links, testing, admin time, etc) outweighs the benefit due to reliability of the primary site and thus the fact the hot site is rarely if ever used. Ask the members of this list how many do IMAP store replication/fail over to a remote site. -- Stan
