IP Storage Networking: Straight to the Core

Anyone even peripherally connected to information technology recognizes that the number of business continuance-level applications has dramatically increased in the last few years . However, the levels of availability required for each application vary dramatically. Assessing each application's availability requirements allows storage and networking administrators to target appropriate solutions.

While assessment of application criticality may be relatively simple for some businesses, in most cases the process can be complex and time-consuming . This is especially true of applications that have evolved over a period of time with nonuniform development processes. Dependency between applications contributes significantly to this complexity. For example, if application A relies on a feed from a database controlled by a separate application B to provide mission-critical information, having complete redundancy for A will be of no use if B is not available. An application itself could physically be running on several servers with their associated storage systems. For example, a client-server ERP application could consist of Web servers, front-end application servers, and a back-end database server. For complex, interdependent application systems, a single individual or group will not likely have complete information to assess the various components ' availability needs. In such cases, a cross-departmental internal task force or outsourced third-party business continuance specialist may undertake the assessment project.

Some of the steps to be taken in the assessment process include

• List all applications.

• Identify dependencies between applications.

• Create application groups based on dependencies.

• Prioritize application groups based on importance.

• Associate availability metrics for application groups and applications within groups.

Two key metrics that identify the level of availability required for applications and data, especially in a disaster recovery scenario, are recovery time objective (RTO) and recovery point objective (RPO).

6.1.1 Recovery Time Objective

RTO measures the acceptable time for recovery. It poses the question, How long can the application be down?

Cost and downtime implications determine RTO for a given application. There have been several studies on the cost of downtime for specific market segment applications in retail, telecommunications, manufacturing, e-commerce, energy, and financial services. These studies often take into account not just the short-term tangible loss in revenue, but also the intangible long- term effects. While these studies provide useful data, organizations can greatly benefit by performing a thorough assessment customized to their environment.

RTO for an application in turn helps determine the tools and technologies required to deploy the appropriate availability level. For example, if the RTO for a given application is seven days, then restoring from backup tapes may be adequate. If the RTO is a few minutes, wide-area replication and failover may be required in case of a disaster.

6.1.2 Recovery Point Objective

RPO measures the earliest point in time to which the application and data can be recovered. Simply put, how much data can be lost?

The nature of the particular application typically determines the RPO. In case of a major data center outage , it may be acceptable for certain applications to lose up to one week's worth of data. This could be from a human resources application in which data can be reentered from other document sources.

Once again, as in the case of RTO, RPO helps determine the tools and technologies for specific application availability requirements. If, for example, the RPO for our human resources application is indeed determined to be seven days, then restoring from backup tapes may be adequate. However, for a banking application that deals with electronic funds transfer, the RPO is likely to be secondsif that. In this case, in the event of a data center outage, nothing short of synchronous data replication may suffice.

Sample storage application placements against RTO and RPO are outlined in Figure 6-2.

6.1.3 Factors Affecting the Choice of Solution

Several factors must be considered when determining the criticality and design of business-continuance solutions for specific applications.

• Appropriate level of availability . In the absence of tight budget constraints, it still pays to curb the tendency of overengineering a solution. Even if cost is less of a concern, every level of increased availability invariably brings with it another level of increased complexity. Also, solutions designed to provide availability can themselves cause downtime. Consider the example of clustering a database server that really does not require clustering. Bugs in the clustering software and the associated patches could cause an application outage.

• Total cost of ownership (TCO) . Obviously, the TCO of the business-continuance solution should not exceed the potential losses incurred from not having one. Hence, it is important to take into account tangible and intangible costs of the business continuance solution.

• Complexity . When faced with multiple solutions, the least complex usually becomes the most desirable. This is especially true for disaster recovery, since in case of a disaster, personnel with expertise may not have access to systems and applications at the remote site. As such, the simpler solution has a better chance of success.

• Vendor viability in the long run . Viability of the vendor over the long haul should be considered when deploying business continuance solutions. This factor becomes more critical for disaster recovery solutions in which a true test of the solution may not come until a disaster occurs and which might require assistance from the vendor.

• Performance impact . Impact on performance of the application should be evaluated when deploying a business-continuity solution. While it is true that certain solutions can cause degraded application performance, other solutions can potentially enhance performance. Consider, for example, a database in which data is being replicated from a primary server to a secondary server. In several cases, replication will have a negative impact on application performance. Now let us assume that this database is being used for both online transaction processing (OLTP) and reporting. Migrating the reporting function to the secondary server could positively impact overall system performance.

• Security . Deploying technologies to address availability concerns potentially introduces security issues where none existed before. For example, if a business-continuance solution requires that sensitive data for an application be replicated over a WAN, measures have to be taken to provide network security using encryption or other technologies.

• Scalability . Given the realities of explosive data growth, any business continuance-solution considered must scale. Consider, for example, a database being replicated to a remote disaster recovery site using a storage array-based replication technology. Most array-based replication technologies guarantee data consistency on the remote site, as long as all the data being replicated resides within a single array on the primary side. While the database remains within the storage limits of the array, this may be the most optimal recovery solution for that particular database application. However, if data growth causes the database on the primary side to grow beyond the bounds of a single storage array, the solution stops working.