Comment Redundant Systems (Score 1) 575
We setup redundant systems and an airline training centers to make sure the pilot training side wouldn't fail (apparently the cost of having pilots come back was huge - go figure...). In the end the training center was actually more redundant and reliable than the actual reservation systems at the airline and we enjoyed 98.5% uptime (save for small things like the power company killin power to the entire builiding without notifying us). To make matters more interesting this system was spread over two locations that are 600 miles apart.
Essentially we had redundant routers put in place nin each center so that if one failed the traffic would kick over to the second. In addition we had developed a small application that resided on the classroom computers that would check the application servers holding the training material. If the primary server was down it simply switched to the secondary server (there were three application servers in one center and two in another).
Furthermore, our database servers (two in one location, one in another; the primary server was located in the larger center and all machines went there first) had a product called DoubleTake installed which would cause the backup server to assume the identity of the primary server in the event of a failure. DoubleTake also allowed us to mirror image the data on our servers fo consistency in the event of a failure. This was important because if we had a WAN failure the database server in the smaller facility would activate and act as the database server for that facility (this actually happened - we had our IT work farmed out to a large support company, which I shall not name, that actually once failed to notice a T1 line had failed for OVER A MONTH!!!).
There were a few glitches, such as the need to wait until afterhours to bring back the primary server in the event of a failure (if you didn't you would be bringing up another server with a duplicate IP address due to the DoubleTake software which caused all sorts of problems so both actually had to be brought down), but for the most part it works very well.
Heck, even if all that failed we had stand alone machines that could run off of a CD. I think that may be a little difficult for a hospital to do though.
Kris
Essentially we had redundant routers put in place nin each center so that if one failed the traffic would kick over to the second. In addition we had developed a small application that resided on the classroom computers that would check the application servers holding the training material. If the primary server was down it simply switched to the secondary server (there were three application servers in one center and two in another).
Furthermore, our database servers (two in one location, one in another; the primary server was located in the larger center and all machines went there first) had a product called DoubleTake installed which would cause the backup server to assume the identity of the primary server in the event of a failure. DoubleTake also allowed us to mirror image the data on our servers fo consistency in the event of a failure. This was important because if we had a WAN failure the database server in the smaller facility would activate and act as the database server for that facility (this actually happened - we had our IT work farmed out to a large support company, which I shall not name, that actually once failed to notice a T1 line had failed for OVER A MONTH!!!).
There were a few glitches, such as the need to wait until afterhours to bring back the primary server in the event of a failure (if you didn't you would be bringing up another server with a duplicate IP address due to the DoubleTake software which caused all sorts of problems so both actually had to be brought down), but for the most part it works very well.
Heck, even if all that failed we had stand alone machines that could run off of a CD. I think that may be a little difficult for a hospital to do though.
Kris
