Q&A with Forrester Analyst Stephanie Balaouras

Last Thursday’s webinar “Application Availability for Remote & Branch Locations” with Forrester analyst Stephanie Balaouras was packed with useful tips and best practices for protecting remote and branch offices from application service disruption. Stephanie has conducted extensive research in this area and shared her Top 5 Best Practices during the webinar. A recording of the webinar is now available in case you missed the live event.

The summary of the webinar Q&A with Stephanie and Michael Bilancieri, Sr. Director of Products for Marathon, is below.

Q: I like the idea of integrating HA and DR plans. How often should those plans be updated?
A: Stephanie Balaouras, Forrester: The ideal scenario is to update your high availability and disaster recovery plans continuously as part of your change management and configuration management. That’s the ideal scenario. They should be integrated into day-to-day operations and your plans should be updated as a part of that. If that’s not feasible, then at least quarterly updates should be made to the plans. One of the hardest parts of DR is that if you don’t keep the plans updated and you’re not testing regularly you’ll have major configuration drift between your sites. When you have a failure or disaster and have to invoke your DR plan is not the time you want to find out just how far your configurations have drifted and that you can’t recover. One solution for this is the combination of virtualization and replication, which can reduce complexity because in most cases you’re actually replicating the configuration changes as they happen.

Q: On your disaster recovery continuum slide (slide #14), can I think of that as a disaster recovery maturity model?
A: Stephanie Balaouras, Forrester: Not really. When I evaluate a company for disaster recovery maturity, I look at two dimensions – process and technology.

On the process side, I look at things such as: Have you run a business impact analysis? What about a risk assessment? Are preventative measures in place? Do you have documented plans, and are they up to date? How often do you test them?

On the technology side, I look at things like the RTO and RPO that you have defined: Are they matched up with the appropriate technology solution? If RTO is less than 2 hours and RPO is zero then I would expect that you are replicating data and doing rapid system restart with virtualization. If I find that you are using tape in that situation, then that’s a problem. I think when it comes to maturity you have to look at process and technology together. Not only should you match up with the right technology, but you might actually leverage more than one technology depending on your needs.

Q: Traditionally, HA & DR at remote locations has not been a priority. Do you see that attitude changing with clients that you talk to?
A: Stephanie Balaouras, Forrester: I do see things changing. I run an annual survey with the Disaster Recovery Journal. One of the questions we ask is: How critical is it to upgrade disaster recovery at your sites? The answer is always either “high” to “extremely critical”. It doesn’t always get addressed the way we want it to, but the recognition is there.

I see three main drivers for this trend. First, availability and disaster recovery are now considered a fiduciary responsibility. It’s no longer an optional practice. It’s essential. It’s something you owe to your employees, your customers, your partners and your investors. Second is the cost of downtime. Companies are much savvier at calculating this cost and aware of the problems they can avoid by not having downtime. When you understand those costs, you can make the right technology investment choices. The final driver I see is the changing business environment. A lot of companies are operating globally on a near 24x7 basis. Like an online retailer for example. We’re operating close to 24x7 and there is no tolerance for downtime anymore. All three of these – fiduciary responsibility, cost of downtime and a 24x7 business environment are moving the needle quite a bit.

Q: In my environment, our IT staff says they have no way to measure if an application is up or not. They can tell us if a server is up, or if a database is up, but not the application. What solutions have you seen that can tackle that issue?
A: Stephanie Balaouras, Forrester: There’s a couple of ways to address that. There are third party application monitoring tools from the large system vendors. They are great for basic monitoring and telling you if your application is up or down, but they don’t tell you about degradation of performance. The other option is that different HA solutions will be able to detect whether the applications is up or down.

 

Michael Bilancieri, Sr. Director of Products for Marathon, answered your questions about everRun software.

Q: Does everRun have any kind of alerting capabilities for system problems?
A: Yes, everRun has alerts. You can send notifications back to any location. It will tell you that something has failed – it’s not a downed system because everRun kept it going through redundancy, but it alerts you that it needs attention.

Q: Does everRun require that the two servers to be identical?
A: The servers don’t have to be exactly the same; however, the CPUs should be identical as a best practice. For what we call our Level 2 protection (for component level protection of the network and disk), you can use different RAM and spindle speeds on storage. Level 3 protected workloads require the servers to be alike. You can view a complete list of supported processors on our website.

Q: How much of CPU and IO payload will we have by running the everRun software?
A: It varies depending on the applications and systems and where the load may be. The general range is from 5-10%. We have specific application performance documentation for Exchange 2007 and XenApp that you can download from our website.

Q: I understand from your presentation that everRun doesn’t require a SAN, but does it work with SAN?
A: everRun can support a SAN in multiple ways. everRun can support a SAN where you have a single copy of the data. And both servers will connect to the single copy of the data. everRun also supports a SAN where one of the servers is connected to that SAN and the other server has its own storage and we can mirror between that. A lot of our customers are using that option to provide data protection and fault tolerance at the data level. We can use different types of storage on either side.
A great benefit of everRun is that is has an agnostic approach to storage. Pretty much any type of storage will work. iSCSI, fiber, direct attached, etc.

Q: Does Marathon have a strategy for SAP environments?
A: Applications are transparent to everRun. We protect many types of SQL, Oracle and SAP applications. There are some best practices around that and we can offer you assistance with those. everRun is invisible to the application, so there are no configuration and design issues. You design your application the way you need to for your business and then everRun protects it without needing changes.

Q: What versions of Windows Server does everRun support?
A: 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: The requirement for redundant systems is obvious, one local and one remote, but I am concerned with the return of the repaired server back to the primary server role. Has that issue been also automated in your application?

A: Replacing one of the servers in an everRun configuration is quite simple as well. It is required that the everRun software be installed and the server be physically connected to the remaining everRun system. Once connected and configured to see each other as a pair, there is a ‘re-pairing’ process that is initiated via command which starts the process of creating the redundant OS environment on the new system and mirroring all of the storage to the new system. Once the mirroring is complete, the system is once again fully protected.