Top 5 Low-Cost Tips for Preventing Exchange Downtime

Thanks again to everyone who joined us for last week’s webinar “Top 5 Low Cost Tips for Preventing Exchange Downtime” where Marathon’s availability experts reviewed their key tips for the prevention of downtime, including:

1. Reduce human error with process
2. Document your infrastructure
3. Remove single points of failure
4. Don’t forget to test
5. Understand your requirements

There’s a lot of great information in this 40-minute webinar, so be sure to check it out. We’ve summarized the Q&A portion for the webinar below.
 

Q: What type of storage does everRun support?
everRun supports any type of storage that you have. The most common storage configuration we see is local disk drives for the servers themselves. That would have the same amount of data protection as even a SAN would, and in some cases would be even better protection, because you have total redundancy from both servers and everRun is protecting that as if it’s a single storage device. You could also have iSCSI connected storage, or any kind of SAN storage that you wanted to have. Again, everRun supports any type of storage.

Q: Which versions of Exchange do you support?
The beauty of the everRun architecture is that is can support pretty much any Windows-based application. Exchange 2003, Exchange 2007 or Exchange 2010 – everRun supports them all. Some other high availability solutions require specialized scripting to support applications, but everRun does not require this. Also, with solutions like clusters, sometimes you have to buy the higher-end more expensive “enterprise” versions of the application software to support that configuration, but with everRun, we can provide complete protection for the standard versions of Windows and Exchange Server or any other application.

Q: What is the load on the systems when using everRun?
The good news here is that there is very little overhead associated with everRun – about 5% to make things run redundantly. That’s a very small performance price to pay to get such a high level of protection for Exchange.

Q: How does everRun handle the mirroring of data that’s loaded in memory?
There are a couple of ways that is done. Since the application is actually running both severs simultaneously, that means the memory is being replicated on both servers simultaneously as well. Keep in mind that as the applications execute, they are storing to storage, and because of the redundancy built into the everRun solution, that data is being written from memory down under the storage element redundantly as well.

Q: Is it possible to run servers in two different locations?
Absolutely. In the slide where I showed the everRun architecture with the two servers, you can take those two servers and separate them geographically. They could be in different rooms in the same building, different buildings on the same campus, or even separated further, by about 100 miles, depending on the bandwidth and latency of your connection. We call this our SplitSite configuration.

Q: How is this different from a cluster solution?
The major difference of everRun vs. a cluster solution is that we are doing operations on two servers simultaneously. The application is actually running in tandem on both of these servers. With a cluster solution, you’re running your application on one server, while the other server stands by and waits for a failure to occur. That means that with a cluster solution, when the first server fails, the cluster then has to do something to start up the application on the second server and then continue from that point. But that means downtime, data loss, and loss of connectivity. With everRun, that doesn’t happen. Because the other server is already doing the same thing, there is no downtime and no data loss, because there is no “recovery” – even when there is a failure.

Q: So are both servers “hot” in an everRun configuration?
Yes – that’s exactly right. Both servers are active and run simultaneously, unlike a cluster. So with everRun, you could have a failure of a component on one server and then another type of failure on the second server and still be operational. With a cluster, this scenario is not possible. If you have failures on both systems at the same time with a cluster, then you are down.

Q: Does everRun require dedicated servers just for Exchange?
No – everRun protected servers do not need to be dedicated to one specific application. You can run multiple applications on this pair of servers, and even chose which ones you do or don’t want to protect with everRun. This is good for small businesses, who want or need to consolidate several applications on to fewer servers.

For more information about protecting Exchange from downtime, be sure to check out our white paper "Six Secrets to 24x7 Exchange Availability."