IBM XIV Storage System Series Asynchronous Mirroring Promoting System Optimization for Business Continuity Contents 2 The impact of data unavailability 4 Key requirements of asynchronous mirroring solutions 6 Powerful XIV mirroring features 9 High performance mirroring 10 Flexible XIV deployment and implementation 11 Minimal administration 13 Low total cost of ownership 13 Conclusion 14 The XIV Storage System series Executive summary This paper highlights the importance of mirroring as a data protection strategy to minimize risk of data and system unavailability and the advantages of IBM XIV Storage System asynchronous mirroring. It covers the system s essential mirroring solution characteristics and organizational mirroring requirements that ensure business continuity. While this paper touches on the value of synchronous mirroring in certain situations, its primary focus is asynchronous mirroring. Reading this paper will give you a clear understanding of effective enterprise mirroring implementations and the IBM XIV Storage System series solution, which offers a comprehensive, successful mirroring strategy for today and the future. Introduction Enterprises rely on their data for business success. It is impossible for most organizations to function day-to-day without online information about customers and products or the data infrastructure that supports business processes. Organizations use data replication to ensure data is available in the event of a system failure or a disaster that degrades system functionality or renders a data center inaccessible. Regardless of the cause equipment failure, natural disaster, or terrorist attack companies need to implement a method to minimize and remedy the adverse business outcomes of these situations, which can heavily impact revenues,
expose organizations to high risk, and cause a slew of other serious problems. Data mirroring, one of the primary data replication methods, enables organizations to preserve data by copying it to secondary systems as it is created online. Measuring the impact of data unavailability Two measures define mirroring solution recovery requirements for organizations: recovery point objective (RPO) and recovery time objective (RTO). RPO describes the acceptable amount of data loss measured in time. The RPO is the point in time to which one must recover data as defined by the organization. This is generally a definition of what an organization determines is an acceptable loss in a disaster situation. Acceptable data loss Critical applications; financial data, transactions Productivity applications; email Low priority backup applications; testing environment 0+ Seconds Minutes Hours RPO RTO defines the maximum acceptable amount of time to restore both data and the systems to access the data in order to prevent unacceptable consequences associated with a break in business continuity. The optimal RPO and RTO are zero (zero data loss and zero recovery time following a disaster), but such objectives may not be always possible or justified due to implementation, support, and recovery costs, and the latency resulting from the distance between replication sites. While mission-critical applications typically require a very low RPO, non-critical applications may be able to suffice with a high RPO. For instance, a backup routine that runs once a day can have an RPO of 24 hours. Assigning a low RPO to non-critical applications wastes precious system and network resources. Figure 1: RPO and data value. The higher the RPO, the higher the potential data loss Synchronous versus asynchronous mirroring Synchronous mirroring and asynchronous mirroring are two approaches for accommodating application-mirroring requirements. With synchronous mirroring, data written by a host to a storage volume (the Master peer on a primary system) is replicated to a secondary storage system (the Slave peer) before the write 2
completion acknowledgement is sent back to the host. This approach yields complete data currency between the Master and the Slave (RPO of 0), yet introduces latency while the host waits for acknowledgement. 1. Host writes new data to Master Synchronous mirroring With asynchronous mirroring, data written to the Master is acknowledged immediately to the originating host, yet is replicated to the Slave at a later time. Therefore, asynchronous mirroring offers lower write latency at the cost of increased RPO (less data currency and lack of synchronization between the Master and Slave). 2. Master replicates to Slave Extended response time lag 3. Slave acknowledges write by Master 4. Master acknowledges write by host Host Master Slave Asynchronous mirroring 1. Host writes new data to Master Asynchronous mirroring is advantageous for a variety of use cases and is a compelling solution for replication between distant sites, since it eliminates the latency inherent to synchronous mirroring; it can offer lower implementation costs as well. Synchronization gap between peers 2. Master acknowledges write by host 3. Master replicates to Slave 4. Slave acknowledges write by Master Host Master Slave Effective asynchronous-mirroring planning and implementation can both minimize the currency gap between mirrored peers and help organizations realize better data availability with lower implementation and operational costs. The RPO possible with asynchronous mirroring is a function of variables such as network bandwidth, line quality, distance, latency, and mirroring system functionality. RPO can range from mere seconds to minutes or hours, depending on application requirements and the mirroring implementation. With its low latency and flexibility in supporting low and high RPOs, asynchronous mirroring is an attractive option, particularly when long distance, low latency replication is required. Figure 2: Synchronous and asynchronous mirroring. With synchronous mirroring, RPO is 0, yet response times increase as the distance between peers increases. With asynchronous mirroring response times are not dependent on link bandwidth and quality, but the RPO is greater than 0. IBM XIV Storage System series asynchronous mirroring The IBM XIV Storage System series, with pioneering architecture and a powerful feature set, offers comprehensive asynchronous mirroring functionality that helps guarantee data availability in the event of failure or disaster, providing valuable enterprise-class benefits not available in traditional mirroring solutions. 3
Key requirements of asynchronous mirroring solutions In addition to being reliable, mirroring solutions need to provide other essential data replication features: Requirement #1: An enterprise-class feature set Low RPO for prioritized applications. Because of the severe repercussions that data loss can have on organizations, minimal data loss with quick data recovery is a principal mirroring solution requirement. Synchronous mirroring enables administrators to restore all Master data from its corresponding Slave peer at the price of increased write latency. This solution, however, is appropriate for replication distances no greater than 62 miles/100 km (potentially up to 186 miles/300 km with more powerful equipment and infrastructure). Synchronous mirroring is less appropriate over links where latency is already pronounced. Asynchronous mirroring virtually eliminates latency concerns at the price of reduced data currency, with the RPO reflecting the organization s acceptable amount of data loss in time units. An RPO setting of 30 seconds indicates that the Slave s data currency should be no more than 30 seconds older than the Master s. An RPO equal to or less than 30 seconds is common for many high-end mirrored applications. Multiple RPOs. In an optimal environment, all applications would mirror with an RPO of 0. Factors governing application profiles, disaster recovery (DR) requirements, replication topology, infrastructure, and cost rarely enable organizations to realize this objective. Assigning the same RPO for all mirrored applications regardless of their data s criticality can typically result in suboptimized bandwidth utilization and impaired performance. In order to balance application criticality with available resources and networking bandwidth, most organizations prefer instead to set individual RPOs per application. Assigning application-based RPOs can help organizations optimize bandwidth utilization for mirroring, accommodating a mix of low and high criticality applications. Support for application-consistent recovery points. An application-consistent recovery point represents the data whose state is guaranteed to be consistent from an application perspective. Creating an application-consistent snapshot on a storage system requires integrated host software that generates the snapshot only after ensuring an application-consistent state. In addition, creating application-consistent snapshots requires host processing, which can adversely affect application response time. A crash consistent recovery point recovers data to the point in time at which the crash occurred, but does not guarantee application data integrity. Therefore, to promote recovery data integrity, an application-consistent recovery point is superior to a crash consistent recovery point. The ability to support both application- and crash-consistent recovery for any mirror is extremely advantageous, since it allows organizations to implement their preferred recovery approach based on data criticality. Ability to consistently mirror a group of volumes. Applications may require consistent replication of more than one volume. For example, a database application that spans multiple volumes requires cross-volume mirroring consistency. 4
Requirement #2: Enterprise-class mirroring performance High-performance mirroring is critical for facilitating low RPO replication with little to no impact on general application performance. The storage system should provide high performance even when mirroring is configured over suboptimal links that experience intermittent disruptions. Requirement #3: Flexible mirroring deployment and implementation Flexible topology configurations. The most common mirroring topology is a one-to-one mirror between systems at different sites, with multisite organizations increasingly implementing or considering multisystem/multisite mirroring configurations. Two popular options for such deployments are the many-to-one and one to-many topologies (see Figures 7 and 8 below). With the one-to-many configuration, a single system (hosting one or more Master volumes) replicates to several systems (functioning as Slaves). Each of the Master s mirrored volumes replicates to one of several Slaves. This enables the organization to distribute replication load across multiple links and share the recovery responsibility among multiple sites. A many-to-one configuration replicates multiple independent Masters to a single designated Slave system at a single recovery site. As with the one-to-many configuration, the many-to-one configuration also leverages multiple links for distributed replication. A hybrid option (see Figure 9 below) combining characteristics of both one-to-many and many-to-one topologies is not uncommon. Organizations are increasingly considering using iscsi (Internet Small Computer System Interface) links for low-cost inter-site mirroring. Customers expect advanced mirroring solutions to offer mirroring over both Fibre Channel (FC) and iscsi. Bidirectional mirroring. Traditional storage mirroring implementations may be unidirectional with replication from a local system (also referred to as a Primary system) to a remote system (also referred to as a Secondary system) but not the other way around. More advanced configurations allow each system to function as a Master for certain volumes and as a Slave for other volumes. This configuration enables organizations to distribute the application load and traffic to better accommodate business needs and performance goals offering greater storage deployment flexibility. Ability to accommodate changing mirroring requirements. Mirroring requirements are dynamic; they are dependent upon business requirements, infrastructure changes, and/or new application priorities. Increasingly, organizations are evaluating improved disaster recovery topologies for their environments, wanting to make changes to their topologies with minimal effort. For example, an organization may want to change an existing synchronous mirror configuration to asynchronous replication. Being able to make this type of change without reinitializing the Slave helps minimize mirroring setup time, maximizing system availability and optimizing utilization of network bandwidth for other mirror processing. Requirement #4: Minimal administrative overhead Mirroring deployments are notorious for their complexity and heavy setup and implementation requirements as well as hefty planning, training, and setup time. Overly imposing and cryptic mirroring documentation often makes the implementation more cumbersome. 5
Mirroring complexity notwithstanding, enterprise-class mirroring should be streamlined, offering significantly lower effort than traditional solutions. The enterprise mirroring solution should feature: 1. Easy and quick setup. Mirroring configuration options should be laid out clearly, with remote connectivity easily defined through a graphical user interface (GUI) or a straightforward command line interface (CLI). Volume mirroring should be a seamless process, with minimum setup steps. 2. Streamlined management. Mirroring management should feature streamlined status monitoring with automatic alerting. Mirroring displays should be simple and straightforward. Common mirroring management tasks, such as changing a mirroring role or adding a volume to a consistency group, should be easy to perform. 3. Simple testing and failover processes. The mirroring solution should enable customers to easily test and validate the mirroring configuration and replica. More importantly, the solution must feature a reliable, no-fuss failover process that does not mandate extensive training. 4. Comprehensive and clear reporting and alerting. The mirroring solution should feature effective, helpful mirroring status reporting and alerts when the RPO cannot be accommodated, and clearly indicate the networking issues that risk attainment of the RPO. The powerful XIV storage mirroring feature set The IBM XIV storage meets and exceeds enterprise-class mirroring requirements through a rich set of features. Proven snapshot-based technology for asynchronous mirroring. Asynchronous mirroring employs patented IBM XIV breakthrough snapshot technology, which streamlines implementation while demonstrating stellar performance for low-rpo mirroring applications. In contrast with traditional snapshot implementations, IBM XIV snapshot technology is an inherent part of the base system architecture; it has not been appended to a preexisting system architecture. This level of integration obviates architectural restrictions that have traditionally prevented systems from providing high snapshot related performance. Notable IBM XIV snapshot mirroring features include: Support for a large number of snapshots Functionality to snapshot a volume, a volume consistency group, or another snapshot Ability to restore a volume, a volume consistency group, or a snapshot from a snapshot High performance by leveraging effective snapshot technology Smart IBM XIV asynchronous mirroring design. With asynchronous mirroring, mirror-related snapshots are used to determine the data that needs to be replicated. The system uses these snapshots to capture the state of the Master being mirrored. XIV asynchronous mirroring attains synchronization between Master and Slave peers through a recurring data replication process, called a Sync Job, which is triggered automatically according to user-configurable schedules. (The Sync Job can also be triggered manually or via a script.) The Sync Job takes a snapshot of the Master and looks for data differences between that snapshot and the previous mirroring-related Master snapshot on the Slave. The Sync Job then replicates Master data corresponding to these differences with the Slave. At the completion of a Sync Job, new mirroring-related snapshots are created on the Slave and the Master. 6
Master peer most_recent Slave peer Local site Replication Remote site last_replicated last_replicated Figure 3: Asynchronous mirroring snapshots. The IBM XIV system maintains three snapshots per mirror coupling: two on the Master and one on the Slave. The system captures a consistent (recoverable) Master state in the last_replicated snapshot (stored on both Master and Slave). The most_recent snapshot represents the most recent Master state that needs to be replicated to the Slave. The system determines the data to replicate by comparing the Master s most_recent to the last_replicated snapshots. Low RPO for critical applications. The IBM XIV system supports mirroring RPOs as low as 30 seconds and replication intervals as low as 20 seconds. Independent RPO and interval. In addition to IBM XIV system support for broad RPO and interval ranges, the IBM XIV mirroring implementation allows administrators to set RPOs and intervals for each mirror independently (or per IBM XIV consistency group). This enables administrators to accommodate mirroring requirements based on application criticality, rather than forcing them to set the same RPO for all applications which could cause inefficient utilization of system resources and adversely impact performance. Automatic and manual replication. The IBM XIV system supports both automatic and manual initiation of asynchronous replication jobs. With automatic replication, the system allows administrators to specify schedules based on intervals ranging from 20 seconds to 12 hours. Manual replication makes it possible to create an ad hoc synchronization job or to trigger a synchronization job from a script. Manual replication can be coordinated with host activities to create snapshots that represent application-consistent recovery points. For additional business continuity benefit, the system allows administrators to concurrently employ both manual and schedule-based replication types for each mirror enabling manual synchronization for mirrors already using an interval based schedule. Support for both application- and crash-consistent recovery. The XIV system supports both applicationand crash-consistent recovery points for any given mirror. Support for mirroring volume groups. With IBM XIV system support for mirrored consistency groups, administrators can mirror volume groups consistently, easily adding volumes to mirroring groups and safely removing volumes from them without stopping or otherwise affecting volume mirroring. Online and off line initialization options. The objective of the initialization process is to establish an initial replica of the Master state on the Slave. XIV storage initialization establishes a baseline for the master state when mirroring begins. IBM XIV online initialization enables over-the-wire Slave initialization. 7
Online (over-the-wire) initialization Offline initialization Initialization starts Time Initialization starts Time Master Initialization replicates initial image to the Slave Master finishes Initialization Slave Initialization starts Initialization finished and ongoing mirroring can commence Master Initialization compares images and only replicates differences Initialization complete Slave Initialization starts Initialization finished and ongoing mirroring can commence Figure 4: Online initialization. After a new mirror is defined, a snapshot of the Master is taken, representing the initial peer state. When mirroring is first activated, the system identifies the data that needs be replicated as part of the initialization phase. An over the-wire synchronization process then replicates the data from the Master to the Slave. The IBM XIV offline initialization feature enables administrators to initialize the Slave peer without requiring an inter-site link to replicate the Master to the Slave. When a mirror is first activated after offline initialization, the system takes a snapshot of the Master, compares that snapshot with the Slave replica, and replicates differences to the Slave. One of the salient benefits of an off-line initialization implementation is that prior to ongoing mirroring, the system verifies the Slave s contents against the Master and does not automatically assume the Slave is a valid replica. Figure 5: Offline initialization. Instead of running an over-the-wire initialization, a backup of the Master can be shipped to a remote recovery site. Once the backup is restored on the Slave, the system can establish mirroring after first comparing the Master with the restored Slave replica. This approach can shorten the initialization process considerably and optimize bandwidth utilization. The mirror is defined with a parameter indicating that a Master replica exists on a remote system. Based on this parameter, the system determines that offline initialization is set. Maximized data resilience thanks to mirroring. With mirroring, an IBM XIV system can overcome a storage media error on the Master system using data from its Slave. IBM XIV supports both synchronous mirroring and asynchronous mirroring recovery (as long as the media error is in a partition shared between the volume and the Last Replicated Snapshot). 8
IBM XIV mirroring also enables effective scrubbing that compares data between local and remote systems. IBM XIV scrubbing is a nonstop background activity that verifies the integrity and redundancy of stored data by examining each data partition on the system. This process enables essential early detection of drive read/write errors, minimizing their impact and expediting recovery processes. The scrubbing process runs continuously on all modules, checking all drives in parallel, and all drive areas (including areas never written to). With IBM XIV mirroring, when the scrubbing process encounters a partition mirrored on a remote target, it compares the partition copies and looks for data inconsistencies between primary and remote machines. High performance with IBM XIV mirroring Enterprise-class data replication demands a powerful solution to accommodate low RPO mirroring requirements without impairing overall application performance. Following are notable IBM XIV features that facilitate high mirroring performance: High memory utilization minimizes disk access and maximizes mirroring speed. The IBM XIV system maximizes the utilization of cache memory for asynchronous mirroring replication. This minimizes time- and process-intensive disk access for high performance data replication. Notably, the IBM XIV caching implementation and large memory also enable better resilience during link disconnections and link bandwidth fluctuations, and minimize the mirroring performance impact on non-mirrored volumes that might experience cache conflicts. Low replication granularity minimizes replication traffic. IBM XIV asynchronous mirroring is extremely efficient, replicating only actual data changes; if one block of data changes, only one block is replicated. This low granularity replication helps maximize the network bandwidth available for mirroring applications. Independent RPO and interval configuration helps administrators match RPO with application criticality. IBM XIV system support for independently set RPOs and intervals per mirror enables administrators to optimally accommodate mirroring requirements based on application criticality. One example is setting a low RPO for critical applications, setting relatively high RPOs for lower priority applications and specifying the same minimal interval for all mirrors. This configuration permits the system to prioritize replication based on application RPO which helps promote increased performance. Offline initialization maximizes bandwidth and reduces initialization time. Offline initialization reduces mirroring initialization time, maximizing available network bandwidth for non-initialization replication traffic. The benefit is pronounced with low-bandwidth mirroring links. Manual replication helps optimize mirroring scheduling. IBM XIV manual replication makes it possible for administrators to schedule mirroring at specified hours for any given application to efficiently accommodate traffic peaks and maximize the replication rate. 9
Multiple mirroring target support maximizes potential replication bandwidth. IBM XIV system support for multiple target connectivity enables organizations to harness expanded connectivity bandwidth for mirroring instead of requiring all mirroring traffic to go through a single dedicated line. Replication throttling enables control over synchronization rates per target. The IBM XIV mirroring solution features the ability to dynamically accommodate connections with fluctuating bandwidth and latency. The system examines the bandwidth and I/O latency of the mirroring link and adjusts its I/O rate to the estimated available bandwidth. This accommodation of fluctuating bandwidth characteristics minimizes potential replication disruptions that could degrade performance. Flexible IBM XIV deployment and implementation IBM XIV asynchronous mirroring presents administrators with flexible deployment and implementation options, streamlining both setup and maintenance activities alike. Connectivity with multiple targets allows for flexible deployment choices Each IBM XIV system can set mirroring relationships with up to eight other systems Each IBM XIV system features simultaneous support for separate replication sources and targets per system. A system can therefore function as a Master peer for some mirrors and as a Slave peer for other mirrors Each IBM XIV system can support hundreds of mirrors Each mirror can be configured to run independently over FC or iscsi A mirror can be defined either for a single volume or for a volume group (consistency group) The system supports both synchronous and asynchronous mirroring Each mirror can have an independent schedule type and interval Mirror topology configurations supported include: one-to-one, one-to-many, many-to-one, and hybrid XIV System2 XIV System3 XIV System4 XIV System5 XIV System6 XIV System7 XIV System1 XIV System8 XIV System9 Figure 6: Each system can set mirroring relationships with up to 8 other systems 10
Figure 7: Many-to-one topology. One system (or site) serves as a central hub target for all other systems Figure 9: Hybrid IBM XIV topology. Some systems (or sites) function as both Master and Slave Independent RPO and interval configuration helps administrators tailor RPO to application priority and available resources. IBM XIV system support for independently set RPO and interval per mirror enables administrators to optimally accommodate mirroring requirements based on application criticality. Minimal administration with IBM XIV asynchronous mirroring Asynchronous mirroring is simple to set up and manage, with straightforward support for mirroring failover and failback. Figure 8: One-to-many topology. One system (or site) replicates to multiple targets 11
Powerful GUI functionality. The IBM XIV storage sports an intuitive GUI console and a simple command line interface that facilitate streamlined administration, supporting these key mirroring features: Clear status monitoring and alerting: the system generates system events and monitors critical asynchronous mirroringrelated processes to produce important mirroring assessment information and statistics Easy mirroring schedule assignment and adjustment Ability to easily change mirroring peer roles from Master to Slave and vice versa Straightforward failover and failback Simple deployment configuration using graphical topology tools Independent RPO and interval settings. IBM XIV administrators can specify an independent RPO per mirror without adjusting the mirroring interval. Assignment of the same minimal interval to all mirrors enables the system to prioritize replication with no user intervention. Consistency group support. IBM XIV administrators can easily manage a mirrored volume group using commands that apply to the whole group, including activation, deactivation, role change, and streamlined restoration of consistent volume groups from a remote site after local site disruption. Automatic dynamic sync rate control. With IBM XIV dynamic sync rate control, no administrator intervention is needed to tune the system to accommodate fluctuating link speed. Easy failover process. The IBM XIV system facilitates easy mirroring failover through a single command that changes the role of the specified peer. Easy support for planned maintenance scenarios. The IBM XIV system makes it easy to validate the mirror replica on the Slave without disrupting the mirroring process. The administrator simply creates a duplicate of the mirrored replica and maps that copy to a host. When both mirroring peers are available, IBM XIV facilitates changing peer roles by enabling mirror switching. With this feature, the administrator instructs the system to simultaneously switch the roles of both peers in a specified mirroring relationship; the Master changes to become the Slave and vice versa. Figure 10: The IBM XIV GUI displays a user-friendly view of the deployment topology Quick, streamlined failback. The system facilitates a streamlined failback process by supporting offline initialization. The storage administrator initializes the original Master with data from the current Master (the promoted Slave). As already noted, offline initialization helps an organization avoid long resynchronization periods, especially with suboptimal lines, and realize improved bandwidth utilization. 12
Mirroring is an integral function of the IBM XIV solution at no extra cost. With the IBM XIV storage system series, all mirroring functionality and features are available out-of-the-box at no extra charge: Synchronous mirroring Asynchronous mirroring Scheduled and manual replication Support for mirrored volumes and consistency groups Mirroring failover and recovery Online and offline initialization Graphical user interface for storage management Figure 11: The IBM XIV mirroring GUI features a clear status display and easy-to-use functionality, such as change role. Low total cost of ownership The IBM XIV asynchronous mirroring function can help organizations realize reduced setup and operational costs which translates into lower TCO. Off line initialization helps save precious time and cost. With offline initialization, administrators can expedite initialization by eliminating over-the-wire traffic. This approach benefits performance and leads to cost savings as well. A good case for offline initialization is with mirroring failback, in which restoring a Master after failover can demand long, costly initialization; offline initialization eliminates this overhead. Offline initialization can also avoid over-the-wire traffic when changing mirroring type from synchronous to asynchronous. Support for mirroring over iscsi helps reduce costs. Due to its potential cost savings, replication over iscsi is becoming a viable mirroring option for enterprises. The IBM XIV system supports mirroring over iscsi, facilitating streamlined deployment at reduced costs. Effective bandwidth utilization. With IBM XIV asynchronous mirroring, only the data changes on the Master peer replicate to the Slave peer: if one block changes, only one block is replicated. The IBM XIV system maintains strong control over synchronization rates per mirror, which helps attain efficient bandwidth utilization. Optimized performance warrants no extra hardware. High performance asynchronous mirroring does not warrant special hardware or hardware upgrades, e.g., cache upgrades. The IBM XIV system maintains the optimal hardware configuration to support enterprise-class mirroring. Conclusion Data is often considered the most important asset of an enterprise and absolutely critical to business success. The IBM XIV system features powerful asynchronous mirroring that satisfies short- and long-term enterprise-class requirements for data mirroring. With the IBM XIV system, asynchronous mirroring is easy to set up and offers flexible configuration options, providing simple data restoration and recovery to support organizations business continuity objectives. The special blend of breakthrough IBM XIV storage architecture and features places its asynchronous mirroring solution in the highest echelon of mirroring solutions by ensuring data availability in the event of failure or disaster and maintaining enterprise-class performance with low RPO/quick RTO mirroring, while minimizing overall costs. Mirroring leverages thin-provisioning functionality. The IBM XIV system supports mirroring of thinly provisioned volumes, ensuring efficient, low-cost space consumption and allocation for mirroring applications. 13
About the IBM XIV Storage System series IBM XIV storage is proven, high-end disk storage designed by listening to customers and addressing their storage challenges across the broadest spectrum of business applications. The XIV series offers highly affordable storage suitable for even the most demanding workloads, providing tier 1 consistent high performance and high reliability at tier 2 costs. Never compromising performance for reliability, the XIV grid architecture deploys massive parallelism to allocate system resources evenly at all times and scale seamlessly, without the need for complex, time-consuming tuning and configuration. Comprehensive XIV storage disaster recovery infrastructure and functionality, including synchronous and asynchronous mirroring, self-healing, internal data redundancy, and flexible failover and failback scenarios promote reliable, effective, expedited enterprise disaster recovery strategies. A recognized industry leader in enterprise storage manageability, the XIV system sets a new standard for ease of use by automating most tasks and providing an exceptionally intuitive user interface. It also offers any-time, anywhere monitoring via the IBM XIV Mobile Dashboard app for mobile devices. The XIV architecture enables performance to grow with capacity and tightly meshes with cloud technologies for even greater agility in meeting business needs. For more information To learn more about the IBM XIV Storage System series, please contact your IBM representative or IBM Business Partner, or visit the following website: ibm.com/storage/disk/xiv Additionally, IBM Global Financing can help you acquire the IT solutions that your business needs in the most cost-effective and strategic way possible. We ll partner with credit-qualified clients to customize an IT financing solution to suit your business goals, enable effective cash management, and improve your total cost of ownership. IBM Global Financing is your smartest choice to fund critical IT investments and propel your business forward. For more information, visit: ibm.com/financing About the author Rami Elron is a senior product manager within the IBM Systems and Technology Group. He is a subject matter expert in storage architecture, mirroring, and security. He has been helping drive technical strategy and innovation for the IBM XIV Storage System series since 2008. He can be contacted at relron@il.ibm.com. The XIV Storage System has met with rapid market acceptance and success, with thousands of installations in diverse industries worldwide, including financial services, healthcare, energy, education and manufacturing. The XIV series supports a wide range of workload needs, from capacity-hungry to ultrahigh performance. It integrates easily with virtualization, email, database, analytics, data protection and other solutions from leading providers, such as Microsoft, IBM, SAP, Oracle, SAS, VMware and Symantec. The XIV series plays a key role in IBM s end-to-end dynamic infrastructure solutions, integrating with IBM ProtecTIER, SONAS, SAN Volume Controller, IBM Storwize V7000 and IBM Tivoli products. 14
Notes
Copyright IBM Corporation 2012 IBM Corporation Route 100 Somers, NY 10589 Produced in the United States of America January 2012 IBM, the IBM logo, ibm.com, ProtecTIER, Storwize, Tivoli, and XIV are trademarks of International Business Machines Corporation in the United States, other countries or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol ( or ), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. Other product, company or service names may be trademarks or service marks of others. A current list of IBM trademarks is available on the web at Copyright and trademark information at ibm.com/legal/copytrade.shtml Microsoft is a trademark of Microsoft Corporation in the United States, other countries, or both. This document is current as of the initial date of publication and may be changed by IBM at any time. Not all offerings are available in every country in which IBM operates. The performance data discussed herein is presented as derived under specific operating conditions. Actual results may vary. It is the user s responsibility to evaluate and verify the operation of any other products or programs with IBM products and programs. THE INFORMATION IN THIS DOCUMENT IS PROVIDED AS IS WITHOUT ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING WITHOUT ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OR CONDITION OF NON-INFRINGEMENT. IBM products are warranted according to the terms and conditions of the agreements under which they are provided. Statements regarding IBM s future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Please Recycle TSW03094-USEN-00