High Availability Webinar Q&A

We had some great questions during last week's webinar High Availability Doesn't Have to be Expensive. A recap of the Q&A is below, including the questions that we weren't able to get to because of time constraints. Be sure to check out our library of on-demand webinars, for this webinar, as well as other topics including SQL availability, Windows Server availability, everRun product demos and more.

Q: How is everRun different from replication solutions?
To understand how everRun is different from replication solutions, you need to take a look at the key differences between disaster recovery and high availability. Availability is about preventing outages instead of just recovering from them; about maintaining the user state with minimal interruptions. With disaster recovery (DR) and replication methods, if there is a failure, you lose connectivity for a period of time and then you have to recover your data and system state. Conversely, availability is about reducing and preventing downtime and keeping users online, even through a failure.

everRun is used for availability, both locally and for short-distance geographic separation as well. We have a replication and recovery solution as well that can be used for disaster recovery for long distances. You should determine what your objectives are: do I have to keep my applications up and running or do I just need to recover it if something fails? What’s the recovery time objective for each application? It’s up to your individual applications and what level of protection you need for each. Oftentimes, availability is a priority as downtime is not desirable, with DR also a requirement on top of that to ensure recovery in the event of a major outage.

Q: What kind of bandwidth requirement is needed for a two-site solution?
As a general rule of thumb, an OC3 connection is required per application workload being protected. Latency is really more critical than bandwidth and this will vary based on the applications and environment.

Q: How does everRun software compare with EMC’s RepliStor and AutoStart applications?
everRun is different from these products because it provides high availability in an automated way with fault tolerant capabilities to prevent user interruptions when hardware fails. This goes back to prevention rather than recovery.

RepliStor is a DR/replication product. While it does provide a failover/restart capability, as do most DR solutions, it is really best used for failover in the event of a major disaster. There’s usually a substantial amount of downtime and a manual failover process to get the systems back online at the secondary site and to failback once the primary site is back online. For DR, you probably want to be able to specify when your systems fail over. But, you will lose some data because this is an asynchronous solution. For minor outages, you really don’t want this. For example, let’s say the power goes out in your primary location for an hour. It can take even longer than that with DR systems to failover to the secondary DR site. You would have been better off just waiting an hour for the power to come back on and restarting the primary systems. RepliStor is more suited for major disaster scenarios, rather than just minor local or regional failures.

Auto-Start is more of a clustering type of product designed for availability and application restarts. It’s not designed to prevent downtime due to failures, but rather to recover from them.

Q: Can everRun be used for planned downtime?
Planned downtime for patches, upgrades, etc. can sometimes cost as much or more to your company as unplanned downtime. The answer to this question will depend on the type of updates. Some OS upgrades do require that there be a restart for the changes to take effect. For some types of planned maintenance, everRun can eliminate the need for downtime. For the others, one of the main things everRun can do is to reduce the risk of updating a system and not having it come back online. For example, you’ve just overwritten your production system and it worked in a test environment, but now it won’t come up in production. We can reduce that risk greatly, by getting it back online quickly without the need to rebuild the server.

Q: What is the difference between everRun and vMotion and VMware HA?
These are two different products, so we'll start with VMware HA. The HA product is a failover/restart capability. If you lose a host, the system will try to restart the virtual machines on another host on the pool. There’s no real guarantee here though. It’s going to try to find resources when a failure happens, but they might not be there. There are some checks in place to warn when over using resources will impact the recovery plan but there is nothing to prevent this. When there’s a critical RTO though, it’s better to have something that is more assured like what everRun provides. everRun uses mirrored systems, so you always know that you have resources available in the event of a failure. everRun also protects the data – we don’t require a SAN. everRun can mirror data between to two systems or two buildings and it doesn’t have to be the same type of storage on both sides. It can be SAN on one side and NAS on the other. everRun can move the data between locations and keep it tied to the applications to keep your business running, even when there is a failure.

As far as vMotion, that is primarily used for planned downtime. Motion capabilities in general allow virtual machines to be moved or “motioned” while they are running from one host to another host. everRun can provide that capability as well. We call it online migration. If you want to take host offline for planned downtime for upgrades for example, we can do that. Motioning is really for planned downtime. If something fails unexpectedly, vMotion can’t help you there. everRun provides capabilities for both planned and unplanned downtime.

Q: What versions of Windows does everRun support?
everRun supports Windows Server 2003 SP2 Standard and Enterprise Editions, 32-bit and 64-bit, as well as Windows Server 2008 Standard and Enterprise Editions, 64-bit.

Q: In considering using everRun across two sites, is everRun doing real-time synchronization between the sites?
Yes it is. It’s writing the data on both systems in a synchronous manner, so that data is always complete—system data and applications are secure and exactly mirrored on the secondary server. It protects the entire environment—the operating system, registry, every setting, etc. is completely cloned. You can turn on that system on the other site and not have to rebuild the server. We maintain exact mirror copies of both servers. That goes back to our message about prevention and computing through failures, rather than downtime and recovery.

Q: Does everRun work with SQL 2008 and SharePoint 2010?
everRun sits below Windows. It’s not in the operating environment. We protect the entire environment, so anything in that environment is automatically protected, whether it’s SQL or Exchange or anything else, even custom applications. There is no customization needed for everRun to protect any Windows applications.

Q: What are the storage requirements for everRun?
everRun offers two storage configuration options: mirrored storage and a shared storage model. When using mirrored storage, everRun will synchronously mirror all storage between paired hosts; this includes the OS, the application, data, etc. This does not require similar storage vendors or types. One host can have SAN-attached storage while the other has local SCSI storage.

In a shared-storage configuration, the everRun paired hosts must be connected to the same storage device with access to the shared LUN’s. In this configuration, everRun does not mirror the data or protect against failures within the storage subsystem. Because of this, it is critical that you ensure proper configuration of the storage devices to protect against failures.

Q: Should everRun be set up on a seperate server?
everRun is typically deployed on two new servers, however an existing server can be utilized, requiring only one additional server.

Q: How is everRun different from the NeverFail product?
Neverfail is an asynchronous DR solution with failover/restart capabilities.