EVALUATING DIFFERENT CLUSTERING ARCHITECTURES FOR DISASTER RECOVERY

Transcription

1 EVALUATING DIFFERENT CLUSTERING ARCHITECTURES FOR DISASTER RECOVERY Michelle M. Mol and Jim Senicka December 23, 2003 VERITAS ARCHITECT NETWORK

2 TABLE OF CONTENTS Introduction... 3 Understanding Basic Disaster Recovery Terms... 3 Recovery Point Objective (RPO)... 3 Recovery Time Objective (RTO)... 4 Planned Downtime... 4 Unplanned Downtime... 4 DR Architectures for VERITAS Cluster Server...4 What Solution Is Best for My Environment?... 5 Solution Offerings... 6 Local Clustering... 6 Customer Scenario... 8 Stretch Clustering (Metro DR / Campus Clustering)... 9 Customer Scenario Option to Metropolitan Clustering: Replicated Data Cluster (RDC) Customer Scenario Wide Area Disaster Recovery Customer Scenario Conclusion VERITAS ARCHITECT NETWORK 2

3 Introduction Information systems and infrastructure have become critical for business enterprises to offer services and conduct day-to-day business. Even a small amount of planned or unplanned downtime can have adverse measurable and material impact on the business in terms of loss of revenue or loss of reputation. Traditional approaches to disaster recovery have focused on backing up data and then restarting the services from recovered data. Although backing up data is the foundation to any disaster recovery plan, the time required for restoring data from tape or disk can cause long, unnecessary delays in uptime of critical applications and databases. Clustering is one of the methods to make applications highly available and to ensure that services continue even when one component fails. Simply defined, upon an application or server fault, clustering ensures that the services running are failed over to another server in the cluster to ensure high availability and minimized downtime. This protection can be offered at a local data center level; but in the event the entire data center is affected, clustering can fail over applications and databases to other data centers either within a metropolitan area over Fibre Channel or over a wide area over IP. This paper presents the different clustering options available and highlights the salient benefits and drawbacks of those options. Within this paper, the user can explore clustering options outside the local data center and provide disaster recovery utilizing other locations within a metropolitan area or over long geographic distances. Understanding Basic Disaster Recovery Terms Two key concepts to understand are your recovery point objective (RPO) and your recovery time objective (RTO). In the event of a fault or disaster, it is important to have a clear understanding of the time required to come back online, as well as how current the data will be after recovery. It may be that not all applications and databases require the same levels of availability. The sections below include brief descriptions of RPO and RTO. Figure 1. Recovery Point Objective and Recovery Time Objective Recovery Point Objective (RPO) How much data loss can you afford after a fault or disaster? What amount of data loss is acceptable? Recovery point objective is the point at which data must be restored. Organizations should have a recovery point objective (per application) and a recovery time objective that must be satisfied. Most people tend to focus on the RTO or how much downtime is acceptable. However, it is just as important to consider how much data loss an organization can tolerate. Data is important, and data loss (even just a few minutes, hours, or days) can have far-reaching negative business impacts. Most companies today rely primarily on tape backup and restore as the centerpiece of their DR plan. Although tape backup is important and the foundation to any comprehensive disaster VERITAS ARCHITECT NETWORK 3

4 recovery plan, this usually means at least a day of lost data and a few days of downtime after a disaster due to the amount of time required to recover from tape. This may meet some business needs, but if not, technologies must be implemented to reduce the time it takes to recover data. Recovery Time Objective (RTO) The recovery time objective is the time in which data accessibility must be restored in other words, the maximum acceptable outage duration. Even in a local failure, there s some time needed to actually detect the fault, and this eats into recovery time. The mandatory decision point is the maximum amount of time that can elapse before taking action to restore accessibility. For example, if a customer states that it takes 45 minutes to bring applications online, and the RTO is 1 hour, then the mandatory decision point is within 15 minutes of the actual disaster. Planned Downtime If an application, database or server requires upgrades or maintenance, clustering is essential to maintain high availability to the users during these periods. Unplanned Downtime In the event of an application, database or server fault, the services running on the server are failed over to another server to avoid long periods of downtime and maintain a quick recovery time objective. DR Architectures for VERITAS Cluster Server VERITAS recognizes that not all data centers are alike. Building an infrastructure for high availability at a local site may not meet the management or availability requirements of every business. However, by using VERITAS Cluster Server as a stand-alone solution or in combination with other VERITAS products, availability can be achieved in almost any open system environment. VERITAS can meet data center architecture requirements for most companies by providing and supporting several clustering architectures: Local high availability with shared data Metropolitan area clustering Wide area clustering (global clustering) for disaster recovery VERITAS can provide high availability (HA) and disaster recovery (DR) for any enterprise requirement, be it single-site local HA, to DR scenarios including short-haul metropolitan area network (MAN) and full wide area network (WAN) support. Regardless of data center infrastructure and availability of SAN and network connections, VERITAS has a proven HA and DR architecture, all built around its high availability and storage management products (see Figure 2). VERITAS ARCHITECT NETWORK 4

5 Figure 2. VERITAS Solutions that Support Clustering Architectures What Solution Is Best for My Environment? The differences between local clustering and wide area disaster recovery is relatively clear: local clustering protects against hardware and software failures within the data center, and wide area disaster recovery using replication protects against far reaching disasters covering large regions. It is the intermediate distance between high availability/disaster recovery solutions that combine clustering with either mirroring or replication into a single cluster that raise the most interest when protecting mission critical applications and databases with minimal cost. Can a high availability cluster also provide disaster recovery capability? One of the primary shifts that drive questions such as this is the concept of how far away is far enough? Traditional thinking has been that a disaster recovery center must be hundreds or even thousands of miles away to provide complete protection. The bottom line is that more organizations need online data protection, with an RPO and a RTO of nearly zero. This means customers are looking to provide disaster recovery capabilities similar to a simply deployed local high availability clustering solution, but spanning multiple sites, without enormous cost. Customers are now realizing that shorter distances, in the range of kilometers can provide disaster recovery protection against most credible threats, such as fire, flood, and power outages. For those threats that affect more than an entire metropolitan area, either traditional tape backup and offsite vaulting will suffice, or to meet an RPO and RTO, the organization will deploy wide area clustering that spans beyond a metropolitan area. This paper details the VERITAS offerings in high availability clustering from a local data center to metropolitan area and finally, to a wide area. The objective of this paper is to demonstrate that VERITAS can provide a seamless high availability and disaster recovery solution, based on current infrastructure, to meet an organization s RPO and RTO requirements. VERITAS ARCHITECT NETWORK 5

6 Solution Offerings 1 Local Clustering Definition Local clustering is the first step toward achieving high availability and disaster recovery. Architecting a local clustering solution sets the framework for future expansion. Local clustering is defined as a single cluster consisting of multiple systems connected in various combinations to shared storage devices. Clustering monitors and controls applications and databases, and can failover or restart applications and databases in response to a variety of hardware or software faults. A cluster is defined as sets of systems connected with a redundant network interconnect. This solution provides local recovery of UNIX and Windows servers in the event of application, OS, or hardware failure at a single site. It also minimizes planned and unplanned application downtime. Local clustering, also called shared-storage clusters, is the most prevalent for providing HA through application and database failover. Environment Figure 3. Diagram of a Local Clustering Environment A redundant network and storage architecture for application and data availability through the linking of multiple servers with shared storage. Systems are linked with a private network interconnect, usually Ethernet, which they use to communicate the status of systems and software and hardware. Each system in the cluster can access application data as necessary on shared storage. There is no replication or mirroring of data to other data centers, as opposed to a stretch cluster (mirroring/raid inside a single array is used to provide disk protection) A SAN facilitates larger clusters (> 2 nodes), and is typically present in all clusters, i.e., switches or hubs are used VERITAS ARCHITECT NETWORK 6

7 All cluster components servers, SAN infrastructure, storage are co-located on a single site All servers in the cluster are in a single location (single data center) Advantages Applications recover using data on shared storage (zero data loss) Minimal downtime for applications and databases (automated failover) Optimal for server consolidation (N+1 failover scenarios) Quick recovery time objective to meet stringent service level agreements and high availability Ideal for minimizing planned downtime other servers in cluster can host the application or database while the server is receiving maintenance or the application and database is upgraded Disadvantages Data center or site can be a single point of failure in a disaster. In the event of a fire or flood within the data center, the critical services will not have the opportunity to failover to another location. This is where the other clustering architectures can provide a higher level of availability: disaster recovery. Failover Behavior In the event of an application, database, or server fault, clustering will bring down the faulted application or database in dependency order and bring up those services on another server in the cluster in dependency order. All servers are local (within the same data center) and are sharing storage. Since the servers are accessing the same storage, the data that the faulted server was accessing is available to the server that restored the services. RPO/RTO Facts Recovery Point Objective: At what point can the data be restored? In this configuration, the cluster is using shared storage and therefore, upon a failure, the other servers in the cluster will always have access to the identical data. Recovery Time Objective: Clustering reduces the recovery time objective because it takes the human intervention of first detecting a fault, and then taking the appropriate action of bringing the application down and bringing it up on another server. Automating this process ensures that the failover of an application or database to another server is quick and accurate. Cost Comparison The cost of implementing a local HA solution involving any clustering technology can increase in that the IT Administrator will have to learn a new technology and an additional server is required as a failover target. However, the reduction in downtime will, over time, outweigh the cost of implementing this new technology. Rather than the traditional thinking of 1 server + 1 spare server, which is required for first-generation HA software, VERITAS Cluster Server can provide much lower cost through the use of N+1 clustering. For example, in a 1-to-1 cluster (one active and one passive), cost of redundancy is 100% at the server level. If an 8+1 cluster is deployed, cost of redundancy is reduced to 12.5%. Local Clustering Solution VERITAS Foundation Suite High Availability is the local clustering solution that combines three products VERITAS Cluster Server, VERITAS File System, and VERITAS Volume Manager. VERITAS Cluster Server monitors and controls applications and databases, and can failover or restart applications and databases in response to a variety of hardware or software faults. VERITAS File VERITAS ARCHITECT NETWORK 7

8 System, and VERITAS Volume Manager manages the data in logical volumes and enables data redundancy within the array. Customer Scenario ICON Clinical ICON Clinical is the leader in providing the pharmaceutical and biotechnology industries with exceptional clinical research and biometric services worldwide. These services include: Clinical Trial support for all phases of drug delivery. The documentation of all patent/doctor/drug information for the trial with their custom application system. Patients involved in the trial disclose information such as symptoms and daily health, either through the ICON Clinical phone system or Web interface. This information is a critical component for passing Phase 3 clinical trials. Data Center Information The data center supports 23 offices in 14 countries on five continents, with over 1,500 employees. Revenue Information Net revenues increased 36% on a year-to-date basis, with $67 million of net new business awarded to ICON during Q2FY03. Problem Statement Need to achieve 99.9% system availability for Microsoft SQL 2000 database and custom application. Deliver 24x7 service to doctors and patients involved in the clinical trials. Required a solution that would provide high availability and disaster recovery for hardware and software already in place. Description of Local HA Environment Operating System: Windows 2000 Server Servers: Compaq and Sun Storage: Hitachi Applications: Microsoft Exchange 2000, SQL 7, SQL 2000, Citrix, Custom Applications Total Storage: 300 GB VERITAS Products NetBackup Volume Manager Cluster Server Volume Replicator Global Cluster Manager Success Clustering exceeded their expectations: Required a local high availability and disaster recovery solution in the event of an application or server outage. Met their 99.9% system availability requirements both at their local and disaster recovery site. Needed a solution that could use their current hardware and software investment Standard Edition of the application and low-end Windows servers. Easy to deploy and manage with GUI interface. VERITAS ARCHITECT NETWORK 8

9 2 Stretch Clustering (Metro DR / Campus Clustering) Definition Stretch clustering (also known as campus clustering over a metropolitan area) is a single cluster that stretches over two sites using fiber connectivity for data mirroring and cluster communication. Simply put, stretch clustering is local clustering over a metropolitan area (within about 80 kilometers). This architecture is deployed when organizations want disaster recovery and have a SAN infrastructure in place but don t have a secondary site many miles away. Rather, these organizations have a secondary site either several meters apart or on the other side of town. For example, some businesses located in the Wall Street area (Manhattan, New York) have set up campus clusters mirroring their data centers over several miles (Manhattan to New Jersey), thus providing disaster recovery for local site failures such as fires, floods, or local power outages. Additionally, campus clustering provides continuous availability for expanding data centers faced with limited space for growth. Note: A separate white paper on the VERITAS Web site details campus cluster configurations. Figure 4. Diagram of a Campus Cluster (Stretch Cluster) Environment Single cluster stretched over multiple buildings, data centers, or sites connected via a single subnet and Fibre Channel SAN. Up to 32 nodes distributed freely among buildings, data centers, or sites. Local storage is mirrored between cluster nodes at each location. With new data switches using CWDM or DWDM, support for up to 80-kilometer distances has been achieved. Distance between sites depends on storage networking infrastructure. VERITAS ARCHITECT NETWORK 9

10 Advantages Campus clustering provides local high availability within each site as well as protection against site failure. This is a cost-effective, simple solution. There is no need for replication (zero data loss due to remote mirroring, which is the synchronous copying of data to both sides). Minimal downtime for applications and databases (automatic or manual failover) is needed. Enables you to leverage existing SAN infrastructure. Looks and acts like a locally deployed cluster environment no specialized configuration is necessary. Protects against weather related outages and local power grid failure as a single point of failure. Allows for data center expansion creates a single, logical grouping of servers, storage, and applications across sites. Allows failover across multiple networks (provides DNS updates). Disadvantages Higher cost requires Fiber Channel SAN infrastructure. Distance limitations because of the inability to mirror storage over great distances with adequate performance. Provides no protection against regional power outages. Failover Behavior Example: If 3 servers are located in Building A and another 2 servers are located in Building B, upon a failover of one server in Building A, VERITAS Cluster Server will attempt to failover the application to another server in Building A. If Building A is down, all services will be failed over to Building B. The data is already at Building B since VERITAS Volume Manager is using remote mirroring to get the data to another site. RTO/RPO Facts Recovery Point Objective: At what point can the data be restored in a campus-clustering configuration? The data is synchronously mirrored between the two sites using VERITAS Volume Manager; therefore, upon a site failure at the primary location, the exact copy of the data can be found at the secondary site. VERITAS recommends the secondary site should be no more than 80 kilometers away due to application performance considerations. Recovery Time Objective: At what point can the application or database be back online? This architecture is appealing because of the quick recovery times and the level of protection against local disasters that it provides. In the event of a local disaster (building fire, flood, etc.), all of the services such as the applications, databases, and data are failed over from that site to the other building that is not affected by the disaster. If a customer deploys local clustering and experiences a building disaster, the recovery time objective could be from seconds/minutes when deploying a campus cluster, to days/weeks when only deploying a local cluster. Consider the time necessary to deploy new servers, upload the services and mount the data coupled with the expense of idle users and lost productivity. Clearly there is an advantage to deploying campus clusters if the infrastructure is in place. Cost Comparison Implementing this solution can maximize the investment made toward the networking infrastructure while providing a level of disaster recovery. Recovering from a local disaster can be financially disastrous, even resulting in lost business due to the amount of time it would take to set up the configuration at another site. Since this architecture involves deploying VERITAS Cluster Server and VERITAS ARCHITECT NETWORK 10

11 VERITAS Volume Manager, it is a relatively inexpensive, lightweight disaster recovery solution that meets most disaster recovery needs. Stretch Clustering Solution The same VERITAS products used for local clustering are used for campus clustering. This includes VERITAS Foundation Suite High Availability (VERITAS File System, VERITAS Volume Manager, and VERITAS Cluster Server). VERITAS FlashSnap is also recommended. Customer Scenario The Wellcome Trust The Wellcome Trust is an independent research-funding charity, established under the will of Sir Henry Wellcome in It is funded from a private endowment, which is managed with long-term stability and growth in mind. Its mission is to foster and promote research with the aim of improving human and animal health. To this end, it supports ' blue skies research and applied clinical research. It also encourages the exploitation of research findings for medical benefit. Problem Statement The Wellcome Trust manages 4bn in funds, so the company needed continuous business, even in the event of a building failure. The company wanted to maximize infrastructure investment and deploy a level of disaster recovery utilizing their current network investment and company properties. Customer could not afford another hot site 100+ miles away. Description of Campus Clustering Environment Number of servers in the cluster: 6 nodes. Data centers contains of 50+ servers (2 data centers; one at each site) Servers: Compaq 100 Storage: Compaq MSA1000 Applications: Microsoft SQL, Microsoft Exchange, Custom Application Distance ~500 meters VERITAS Products Volume Manager Cluster Server Cluster Server agent for Microsoft SQL Cluster Server agent for Microsoft Exchange Success Utilizing Cluster Server and the remote mirroring features bundled in VERITAS Volume Manager; the customer was able to achieve local high availability as well as a level of disaster recovery without added costs. The customer had already invested in a Fiber Channel infrastructure for other reasons outside the scope of the data center needs and maximized that networking investment by deploying a level of disaster recovery. VERITAS ARCHITECT NETWORK 11

12 3 Option to Metropolitan Clustering: Replicated Data Cluster (RDC) Definition Replicated Data Cluster (RDC) is a single cluster that resembles stretch clustering architecture but rather than require a SAN between two sites, this architecture requires IP. This is different than the final clustering architecture described in this paper wide area disaster recovery in that this is still one cluster, one subnet, so distance is still a limiting factor. The replication within an RDC configuration must be synchronous for automatic failover. A question associated with RDC is when to consider this solution over the campus cluster solution. The general rule is this: if a you do not have a SAN nor want to invest in a SAN, but you can run private Ethernet networks for cluster heartbeating, then an RDC architecture may be applicable. In most cases, if a SAN is present, a campus cluster is by far the better choice, as there is no cost for replication software beyond volume mirroring. Additionally, in all cases performance is better for mirroring than data replication over IP. Environment Figure 5. Diagram of a Replicated Data Cluster Minimum of 2 servers one server at each location per replicated storage. Cluster stretches between multiple buildings, data centers, or sites connected via Ethernet (IP). Local storage is replicated between cluster nodes at each location synchronously. One cluster servers located in multiple sites are part of the same cluster. Advantages IP over standard Ethernet can be used. No SAN infrastructure is required. Cost doesn t require SAN infrastructure. VERITAS ARCHITECT NETWORK 12

13 Similar protection as stretch clustering protection against disasters local to a building, data center, or site. Leverage existing Ethernet infrastructure. Replicate synchronously and avoid data loss upon a site failure. Disadvantages More complex solution than local clustering or stretch clustering (direction of replication and currency of data must be considered in all failure scenarios). Potential application performance hit if using synchronous replication over a large distance. Limited to 2 sites. Synchronous replication only. Failover Behavior Example: If 1 server is located in Building A and another server is located in Building B, upon a failover of one server in Building A, clustering will failover the application to the other server in Building B. Data is being replicated over IP, or hardware replication using its native protocol. In all cases, the replication is expected to be synchronous. RTO/RPO Facts Recovery Point Objective: At what point can the data be restored in a replicated data cluster configuration? The data is synchronously replicated between the two sites using VERITAS Volume Replicator or EMC SRDF; therefore, upon a site failure at the primary location, the data at the secondary site is an exact duplicate. Recovery Time Objective: At what point can the application or database be back online? This architecture is appealing because of the quick recovery times and the level of protection against local disasters that it provides. In the event of a local disaster (one building fire, flood, etc.), all of the services such as the applications, databases, and data are failed over from that site to the other building that is not experiencing the disaster. If a customer deploys local clustering and experiences a building disaster, the recovery time objective could be from seconds/minutes when deploying a campus cluster, to days/weeks when only deploying a local cluster. Consider the time necessary to deploy new servers, upload the services and mount the data coupled with the expense of idle users and loss productivity. Clearly there is an advantage to deploying campus clusters if the infrastructure is in place. Cost Comparison Either an organization will have Fibre Channel SAN or IP (Ethernet). The cost of implementing Fibre Channel SAN to achieve a campus cluster architecture far outweighs an immediate cost and return of investment of purchasing a replication technology that can replicate data over IP. The bottom line is that metropolitan area disaster recovery can still be permitted if Ethernet is the only connection between two sites. Replicated Data Cluster Solution As with the stretch clustering solution, VERITAS Foundation Suite High Availability is used for an RDC solution. A replication solution, such as VERITAS Volume Replicator, is required to facilitate replication of data. VERITAS FlashSnap is also recommended. VERITAS ARCHITECT NETWORK 13

14 Customer Scenario A Large Manufacturing Company This company manufactures specialized equipment for the oil industry. Their manufacturing plant is located in Arizona and runs 24/7. Both the manufacturing data and applications cannot afford long periods of planned and unplanned downtime. Two sites: Phoenix, Arizona, and Scottsdale, Arizona Problem Statement The company manages a large amount of data that not only provides specifications to manufacture specialized equipment for large oil companies. The company wanted to minimize the risk of having downtime due to data loss a manufacturing specification management system is required to be up and running throughout the day. The facility runs continuously. The company wanted to minimize risk of having downtime to their application that accesses inventory data. Description of Replicated Data Cluster Environment Number of servers in the cluster: 2 nodes; Data centers have 20+ servers (2 data centers; one data center at each site) o 2 Replicated Data Clusters deployed o 2 servers (one at each site) Servers: Compaq 100 Storage: EMC Symmetrix Applications: Microsoft SQL, Custom Application Distance ~10 Km VERITAS Products Cluster Server Cluster Server agent for Microsoft SQL 3rd Party Products EMC Symmetrix array for replicating data between Phoenix and Scottsdale Success Company was able to achieve a level of disaster recovery over their IP infrastructure for a specific application. Since the two sites were relatively close together, this architecture enabled the customer to utilize their current infrastructure and employee resources within the area. VERITAS ARCHITECT NETWORK 14

15 4 Wide Area Disaster Recovery Definition Wide area disaster recovery provides the most protection for data and applications in the event of a disaster. If the disaster affects a local or metropolitan area, protection of data and critical services are failed over to a site thousands of miles away. The architecture requires deployment of two or more data centers with two or more subnets. In the event of a site outage, all services and data are moved to the secondary hot site, which then becomes available to users. This architecture involves precision when determining secondary sites. For instance, the location of the secondary site shouldn t be on the same fault line as the primary site, it shouldn t be near airports or on same power grids, and it should be far enough away to avoid weather patterns that could affect both locations. There are several companies, including VERITAS, that provide consulting services for deploying disaster recovery best practices. Wide area disaster recovery will typically be deployed based on government regulations or service level agreements that the company is forced to comply with. However, there are several companies that have office locations in other parts of the world that they could take advantage of for deploying such architecture. By definition, wide area disaster recovery is typically deployed when IP is available and the customer has a need for distance greater than 100 kilometers. The secondary site is a hot site, which has servers and storage available in the case of the primary site failing over. Connection between the sites is typically over IP. Figure 6. Diagram of a Wide Area Disaster Recovery Architecture VERITAS ARCHITECT NETWORK 15

16 Environment A local cluster deployed at primary site and another local cluster deployed at secondary site(s) two clusters minimum: o Two or more subnets o Two or more clusters Data is replicated between clusters at each location. VERITAS allows up to 32 nodes per cluster and up to 64 clusters per site. Advantages All advantages of local clustering. Unlimited data replication distance in asynchronous mode. Protection against disasters local to a building, data center, or geographic area. Supports any distance using IP for cluster-to-cluster communication. Application failover is automatic locally, with a manual one click recovery to a remote site. Support for VERITAS and third-party replication solutions. Disadvantages Cost of network infrastructure, servers, and storage at remote site(s). Potential data loss if failure occurs while running in asynchronous mode. Failover Behavior Example: If a server or application fails locally, VERITAS Cluster Server will attempt to fail over the services to another server in the same cluster. Upon receiving no response from the clusters within the local site, VERITAS Global Cluster Manager will then fail over all services from the local site to the secondary/remote site. VERITAS Global Cluster Manager Disaster Recovery option manages the failover between sites and all replication commands needed to view replication status, and switches replication roles between the primary and secondary site. RTO/RPO Facts Recovery Point Objective: Data can be replicated periodically, asynchronously, or synchronously between the two sites using VERITAS Volume Replicator, EMC SRDF, or Hitachi TrueCopy; therefore, upon a site failure at the primary location, the data is usable at the secondary site. How current the data is, or how much data will be lost during a true disaster, is dependent on the mode of replication used. If the replication is synchronous, then there will be zero data loss. With periodic or asynchronous replication, there will be some amount of data lost. The amount of data depends on the replication configuration. VERITAS Volume Replicator ensures consistency with no distance limitations/requirements between the primary and secondary site. Other technologies may have limitations that need to be investigated by the customer to decide whether those limitations are acceptable. Recovery Time Objective: At what point can the application or database be back online? In the event of a site disaster, all of the services such as the applications, databases, and data are failed over from that site to the other site that is not experiencing the disaster. If a customer deploys a wide area disaster recovery architecture, recovery time can be as little as seconds or minutes, to hours depending on, among other things, the processes in place, the readiness of the IT staff to act on those processes, and the amount of data that needs to be mounted at the secondary site. Without wide area cluster technology, the downtime cost is considerable given the time necessary to deploy new servers, upload the services, and mount the data as well as the expense of idle users and lost productivity. Clearly there is an advantage to deploying wide area disaster recovery. VERITAS ARCHITECT NETWORK 16

17 Cost Comparison The cost of deploying wide area disaster recovery architecture is expensive and usually is deployed due to a government mandate or to meet regulatory requirements. Providing hardware, software, and networking infrastructure at a remote site is a daunting task for most companies. Therefore, it is important to provide professional services to help with deployment. Wide Area Disaster Recovery Solution VERITAS Foundation Suite High Availability (VERITAS File System, VERITAS Volume Manager, and VERITAS Cluster Server). Recommended: VERITAS FlashSnap VERITAS Volume Replicator VERITAS Global Cluster Manager VERITAS Global Cluster Manager Disaster Recovery Option VERITAS Global Cluster Manager provides centralized, Web-based management of distributed VERITAS Cluster Server clusters, running on a variety of UNIX and Windows platforms. When integrated with data replication, VERITAS Global Cluster Manager allows you to migrate applications, clusters, or entire sites throughout your global infrastructure. Customer Scenario BlueStar BlueStar Solutions is a leading provider of hosted enterprise-class applications such as ERP, financials, taxware, human resources, sales distribution, and other data-intensive and business-critical programs. Its customers demand guaranteed service levels for availability, performance, scalability, and support. With over 500 servers handling over 127 terabytes for multiple customers and varying applications, the management of data and storage has always been a challenge for BlueStar s technical staff. Customers don t buy equipment from us; they buy a service. And the service is what we get paid on. So it s in our best interest to evaluate and select the best technology out there to provide the best service back to the customer, says Bill Augustadt, Chief Architect and Technologist for BlueStar Solutions. Every time we sell a service that includes hosting and servers and applications, VERITAS is automatically plugged into the equation. The customer wants to know how we are going to provide the service levels that we guarantee in their contract, and by mentioning VERITAS they understand how we will provide availability, scalability, and recoverability. Customer Profile Summary Leading provider of enterprise application outsourcing for SAP environments. o Hosts more than 50 customers and 35,000 users in 20 countries. o Support more than 215 instances of SAP, completed 75 migrations/30 upgrades. Headquarters in Cupertino, Calif., USA. Robust service level agreements, customized for the needs of each customer. Problem Statement Needs to achieve 99.9% system availability across all instances. Deliver consistency to customer base. Needed to achieve a recovery time objective of 4 hours. Needed to achieve a recovery point objective of 1 hour. VERITAS ARCHITECT NETWORK 17

18 Description of Environment Operating System: Solaris Data centers in Phoenix, AZ and Dallas, TX. Approximately 550 servers including Intel (Dell and IBM) and UNIX (Solaris, Compaq, HP). Servers: Hitachi 9960 and Hitachi 7700 disk arrays. Applications: Oracle, SAP, and other databases ranging from 200GB to three terabytes. Over 127 terabytes total storage (raw). Network: OC-12. VERITAS Products VERITAS Foundation Suite VERITAS Volume Replicator VERITAS Global Cluster Manager VERITAS Cluster Server VERITAS NetBackup Success BlueStar saved millions by replicating between dissimilar hardware and without any proprietary network infrastructures. VERITAS products have enabled BlueStar to solve a number of issues that were once slowing its corporate success. Data backup, for instance, was long a frustrating challenge. With the sheer volume of data, plus the number and variety of servers and storage devices, how can it make sure that the libraries are compatible and can be shared across multiple platforms? VERITAS made that happen. Conclusion Best practices for disaster recovery start with tape backup and data redundancy using disk volume mirroring. Shared storage helps keep applications online when administrators deploy a scalable cluster infrastructure in conjunction with an automated disaster recovery plan that facilitates wide area data center migration. As business needs evolve, enterprises can add corresponding layers of availability, building upon a backup strategy that is already in place. By deploying products that enable high availability and disaster recovery, such as an integrated software suite from VERITAS, organizations can protect data and applications in their data center environment while deploying an IT architecture that best fits the requirements of the business. VERITAS ARCHITECT NETWORK 18

19 VERITAS ARCHITECT NETWORK VERITAS Software Corporation Corporate Headquarters 350 Ellis Street Mountain View, CA or For additional information about VERITAS Software, its products, VERITAS Architect Network, or the location of an office near you, please call our corporate headquarters or visit our Web site at Copyright 2003 VERITAS Software Corporation. All rights reserved. VERITAS, the VERITAS Logo and all other VERITAS product names and slogans are trademarks or registered trademarks of VERITAS Software Corporation. VERITAS, the VERITAS Logo Reg. U.S. Pat. & Tm. Off. Other product names and/or slogans mentioned herein may be trademarks or registered trademarks of their respective companies. Specifications and product offerings subject to change without notice.