ga32-0639-03

IBM XIV Storage System

Theory of Operation

GA32-0639-03

��

Note:

Before using this information and the product it supports, read the information in “Notices used in this document” on pagev and “Notices” on page 105.

Third Edition (August 2009)

The following paragraph does not apply to any country (or region) where such provisions are inconsistent withlocal law.

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION “AS IS” WITHOUTWARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THEIMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states (orregions) do not allow disclaimer of express or implied warranties in certain transactions; therefore, this statementmay not apply to you.

Order publications through your IBM representative or the IBM branch office serving your locality.

© Copyright International Business Machines Corporation 2009.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.

Contents

Introduction . . . . . . . . . . . . . vPurpose and scope . . . . . . . . . . . . v

Document version . . . . . . . . . . . vIntended audience . . . . . . . . . . . vRelated documentation . . . . . . . . . . vNotices used in this document . . . . . . . vDocument conventions. . . . . . . . . . viTerms and abbreviations . . . . . . . . . vi

Getting information, help, and service . . . . . viHow to send your comments . . . . . . . . vi

Chapter 1. Overview: The IBM XIVStorage System . . . . . . . . . . . 1Features and functionality . . . . . . . . . . 1Hardware overview . . . . . . . . . . . . 1

Hardware components . . . . . . . . . . 1Supported interfaces . . . . . . . . . . . 3Management options . . . . . . . . . . 4

Reliability . . . . . . . . . . . . . . . 4Redundant components and no single point offailure . . . . . . . . . . . . . . . 5Data mirroring. . . . . . . . . . . . . 5Self-healing mechanisms . . . . . . . . . 5Protected cache . . . . . . . . . . . . 5Redundant power . . . . . . . . . . . 5

Performance . . . . . . . . . . . . . . 6Total load balance . . . . . . . . . . . 6Intelligent caching for improved performance . . 6

Functionality . . . . . . . . . . . . . . 7Upgradability . . . . . . . . . . . . . 8

Chapter 2. Volumes and snapshotsoverview . . . . . . . . . . . . . . 9The volume life cycle . . . . . . . . . . . 10Snapshots . . . . . . . . . . . . . . . 11

Redirect on write . . . . . . . . . . . 11Auto-delete priority . . . . . . . . . . 12Snapshot name and association . . . . . . . 13The snapshot lifecycle . . . . . . . . . . 13

Chapter 3. Host System Attachment . . 19Balanced traffic and no single point of failure . . . 19Attaching volumes to hosts . . . . . . . . . 19Advanced host attachment . . . . . . . . . 19Clustering hosts into LUN maps . . . . . . . 20

Volume mappings exceptions . . . . . . . 20Host system attachment commands . . . . . . 22

Chapter 4. Consistency groupsoverview . . . . . . . . . . . . . . 25Creating a consistency group . . . . . . . . 25Taking a snapshot of a consistency group . . . . 25The snapshot group life cycle . . . . . . . . 27Restoring a consistency group . . . . . . . . 28

Chapter 5. Storage pools overview. . . 29

Chapter 6. Thin provisioning . . . . . 31

Chapter 7. Target connectivity. . . . . 35Defining a remote target object . . . . . . . . 35Adding ports to remote target . . . . . . . . 36Connecting between local and target ports . . . . 36Symmetric connectivity for mirroring . . . . . . 38

Chapter 8. Synchronous remotemirroring . . . . . . . . . . . . . . 39Remote mirroring basic concepts . . . . . . . 39Remote mirroring operation . . . . . . . . . 40Configuration options . . . . . . . . . . . 41

Volume configuration . . . . . . . . . . 41Communication errors . . . . . . . . . . 42Coupling activation. . . . . . . . . . . 42

Synchronous mirroring statuses. . . . . . . . 43Link status . . . . . . . . . . . . . 44Operational status . . . . . . . . . . . 44Synchronization status. . . . . . . . . . 44

I/O operations . . . . . . . . . . . . . 46Synchronization process . . . . . . . . . . 46

State diagram. . . . . . . . . . . . . 47Mandatory coupling . . . . . . . . . . 47Best-effort coupling recovery . . . . . . . 48Uncommitted data . . . . . . . . . . . 48Constraints and limitations . . . . . . . . 48Last-consistent snapshots . . . . . . . . . 48Last consistent snapshot timestamp . . . . . 49Secondary locked error status . . . . . . . 49

Role switchover . . . . . . . . . . . . . 50Role switchover when remote mirroring isoperational . . . . . . . . . . . . . . 50Role switchover when remote mirroring isnonoperational . . . . . . . . . . . . . 50

Switch secondary to primary . . . . . . . 51Secondary consistency . . . . . . . . . . 51Switch primary to a secondary . . . . . . . 52

Resumption of remote mirroring after role change 52Reconnection when both sides have the same role 53

Miscellaneous . . . . . . . . . . . . . 53Remote mirroring and consistency groups . . . 53Using remote mirroring for media error recovery 54Supported configurations . . . . . . . . . 54I/O performance versus synchronization speedoptimization . . . . . . . . . . . . . 54Implications regarding other commands . . . . 54

Chapter 9. IP and Ethernet connectivity 57Ethernet ports . . . . . . . . . . . . . 57IP and Ethernet connectivity. . . . . . . . . 57Management connectivity . . . . . . . . . 60

© Copyright IBM Corp. 2009 iii

Field technician ports . . . . . . . . . . . 60Configuration guidelines summary . . . . . . 61

Chapter 10. Data migration . . . . . . 63Data migration overview . . . . . . . . . . 63I/O handling in data migration. . . . . . . . 64Data migration stages . . . . . . . . . . . 65Handling failures . . . . . . . . . . . . 66

Chapter 11. Event handling . . . . . . 67Event information . . . . . . . . . . . . 67Viewing events . . . . . . . . . . . . . 68Defining events notification rules . . . . . . . 68

Alerting events configuration limitations . . . 69Defining destinations . . . . . . . . . . . 69Defining gateways . . . . . . . . . . . . 69

Chapter 12. Access control . . . . . . 71User roles and permission levels . . . . . . . 71Predefined users. . . . . . . . . . . . . 72Application administrator . . . . . . . . . 73

User groups . . . . . . . . . . . . . 73User group and host associations . . . . . . 73Command conditions . . . . . . . . . . 74

Authentication methods . . . . . . . . . . 75Native authentication . . . . . . . . . . 75LDAP-authentication . . . . . . . . . . 76Switching between LDAP and nativeauthentication modes . . . . . . . . . . 78

Logging and event reporting . . . . . . . . 79Command execution log . . . . . . . . . 79Object creation tracking . . . . . . . . . 79Event report destinations . . . . . . . . . 80

Access control commands . . . . . . . . . 80Glossary of access control concepts . . . . . . 81

Chapter 13. TPC interoperability . . . . 83

Chapter 14. Hot upgrade . . . . . . . 85

Chapter 15. Other features . . . . . . 87

Glossary . . . . . . . . . . . . . . 89

Safety and environmental notices . . . 95Safety notices and labels . . . . . . . . . . 95

Danger notices . . . . . . . . . . . . 95Labels . . . . . . . . . . . . . . . 96Caution notices . . . . . . . . . . . . 97Attention notices . . . . . . . . . . . 97Laser safety . . . . . . . . . . . . . 98Rack safety . . . . . . . . . . . . . 99Product recycling and disposal . . . . . . 100Battery return program . . . . . . . . . 102Fire suppression systems . . . . . . . . 103

Notices . . . . . . . . . . . . . . 105Notices . . . . . . . . . . . . . . . 106Copyrights . . . . . . . . . . . . . . 107Trademarks . . . . . . . . . . . . . . 107Electronic emission notices . . . . . . . . . 107

Federal Communications Commission (FCC)Class A Statement . . . . . . . . . . . 108Industry Canada Class A Emission ComplianceStatement . . . . . . . . . . . . . 108Avis de conformité à la réglementationd’Industrie Canada . . . . . . . . . . 108European Union (EU) ElectromagneticCompatibility Directive . . . . . . . . . 108Australia and New Zealand Class A statement 109Germany Electromagnetic CompatibilityDirective . . . . . . . . . . . . . . 109People’s Republic of China Class A ElectronicEmission Statement . . . . . . . . . . 110Taiwan Class A warning statement . . . . . 110Japan VCCI Class A ITE Electronic EmissionStatement. . . . . . . . . . . . . . 110Korean Class A Electronic Emission Statement 110

Index . . . . . . . . . . . . . . . 111

iv IBM XIV Storage System: Theory of Operation

Introduction

The IBM XIV Storage System is designed for secure, dependable, enterprise-gradedata storage and access, straightforward installation and upgrading, and fullscalability. The system contains proprietary and innovative algorithms that offsethardware malfunctions, minimize maintenance, and provide flexibility. The systemuses off-the-shelf hardware components that are easy to integrate and support.

Purpose and scope

This document contains a complete hardware and software system overview of theIBM XIV Storage System. Relevant tables, charts, graphic interfaces, sampleoutputs, and appropriate examples are also provided.

Document version

This document supports version 10.1 of the IBM XIV Storage System code.

Intended audience

This document is a reference for administrators and IT staff that work with theIBM XIV Storage System.

Related documentation

The IBM XIV XCLI User Manual provides the commands used in the IBM XIVCommand Line Interface (XCLI). This document can be obtained from the IBM XIVStorage System Information Center at http://publib.boulder.ibm.com/infocenter/ibmxiv/r2/index.jsp by clicking IBM XIV Storage System → Productdocumentation in the left navigation pane.

Notices used in this document

The caution and danger statements used in this document also appear in themultilingual IBM Systems Safety Notices document. Each caution and dangerstatement is numbered for easy reference to the corresponding statements in thesafety document.

The following types of notices and statements are used in this document:

Note These notices provide important tips, guidance, or advice.

ImportantThese notices provide information or advice that might help you avoidinconvenient or problem situations.

AttentionThese notices indicate possible damage to programs, devices, or data. Anattention notice is placed just before the instruction or situation in whichdamage could occur.

CautionThese statements indicate situations that can be potentially hazardous to

© Copyright IBM Corp. 2009 v

http://publib.boulder.ibm.com/infocenter/ibmxiv/r2/index.jsp

http://publib.boulder.ibm.com/infocenter/ibmxiv/r2/index.jsp

people because of some existing condition, or where a potentiallydangerous situation might develop because of some unsafe practice. Acaution statement is placed just before the description of a potentiallyhazardous procedure step or situation.

DangerThese statements indicate situations that can be potentially lethal orextremely hazardous to people. A danger statement is placed just beforethe description of a potentially lethal or extremely hazardous procedurestep or situation.

Document conventions

The following conventions are used in this document:

boldfaceText in boldface represents menu items and lowercase or mixed-casecommand names.

italics Text in italics is used to emphasize a word. In command syntax, it is usedfor variables for which you supply actual values.

monospaceText in monospace identifies the data or commands that you type, samplesof command output, or examples of program code or messages from thesystem.

Terms and abbreviations

A complete list of terms and abbreviations can be found in the “Glossary” on page89.

Getting information, help, and serviceIf you need help, service, technical assistance, or just want more information aboutIBM products, you will find a variety of sources to assist you. Table 1 provides alist of Web pages that you can view to get information about IBM products andservices and to find the latest technical information and support:

Table 1. IBM Web sites for help, information and service

Web site Description

http://www.ibm.com Main IBM home page

http://www.ibm.com/storage/support IBM Support home page

http://www.ibm.com/planetwide IBM Support page with pointers to therelevant contact information for a specificcountry

How to send your commentsYour feedback is important in helping us provide the most accurate andhigh-quality information. If you have comments or suggestions for improving thisdocument, send us your comments by e-mail to [email protected] or use theReaders’ Comments form at the back of this publication. Be sure to include thefollowing:v Exact publication title

vi IBM XIV Storage System: Theory of Operation

http://www.ibm.com

http://www.ibm.com/storage/support

http://www.ibm.com/planetwide

mailto:[email protected]

v Form number (for example, GC26-1234-02)v Page numbers to which you are referring

If the Reader’s Comment Form in the back of this manual is missing, you candirect your mail to:

International Business Machines CorporationInformation DevelopmentDepartment GZW9000 South Rita RoadTucson, Arizona 85744-0001 U.S.A.

When you send information to IBM®, you grant IBM a nonexclusive right to use ordistribute the information in any way it believes appropriate without incurring anyobligation to you.

Introduction vii

viii IBM XIV Storage System: Theory of Operation

Chapter 1. Overview: The IBM XIV Storage System

This chapter covers the various features and functions of the IBM XIV StorageSystem, including an overview of its hardware and software components. Thisoverview includes a brief description of its key design issues from the system’spoint of view, but does not cover the functionality from the user’s point of view,which is covered in the subsequent chapters.

Features and functionalityThe IBM XIV Storage System is characterized by the following set of features:v iSCSI and Fibre Channel (FC) interfacesv Multiple host accessv Management software, including a graphical user interface (GUI) and a

command-line interface (CLI)v Support for query of configuration information by Tivoli Productivity Center 4.1.v Support for managing snapshot operations with Tivoli Storage Manager for

Copy Services v. 6.1v Volume cloning (snapshots)v Replication of a volume to a remote systemv Easy assignment and reassignment of storage capacity

Note: The term storage capacity refers to the total storage capacity, and does nottake into account the amount of storage used for data-redundancy or mirroringand other data-related tasks.

v Remote configuration managementv Notifications of events through e-mail, SNMP, or SMS messagesv No single-point-of-failurev Fault tolerance, failure analysis, and self-healing algorithmsv Non-intrusive maintenance and upgradesv Fast rebuild time in the event of disk failurev Uniform performance across all volumes - no ″hot spots″

Hardware overviewThis section provides a general overview of the IBM XIV Storage System hardware.

Hardware componentsThe IBM XIV Storage System configuration includes data modules, interfacemodules, Ethernet switches, and uninterruptible power supply units.

The following figures show the IBM XIV Storage System major hardwarecomponents as they are seen from front and back.

© Copyright IBM Corp. 2009 1

Interface ModulesEach contains 12 disk drive modules (DDMs), CPU, Cache and HostInterface adaptors.

Host Interface adaptorsEach interface module provides Fibre Channel ports. Some hostinterface modules also provide iSCSI ports. Hosts may attach to thesystem by using the Fibre Channel and iSCSI ports. (See the mostcurrent version of the XIV Interoperability Matrix for specificsupported configurations.)

SATA disk drives and Cache memoryEach Interface module contains 12 SATA disk drives and cachememory. SATA disk drives are used as the non-volatile memory forstoring data in the storage grid and cache memory is used forcaching data previously read, pre-fetching of data from a disk, andfor delayed destaging of previously written data.

Data modulesEach Data module contains 12 SATA disk drives and cache memory. SATAdisk drives are used as the nonvolatile memory for storing data in thestorage grid and cache memory is used for caching data previously read,prefetching of data from a disk, and for delayed destaging of previouslywritten data.

Uninterruptible power supply module complexThe uninterruptible power supply module complex consists of threeuninterruptible supply units. It maintains an internal power supply in the

Figure 1. IBM XIV Storage System

2 IBM XIV Storage System: Theory of Operation

http://www-947.ibm.com/systems/support/storage/systems.html

event of a temporary failure of the external power supply. In the case of acontinuous external power failure, the uninterruptible power supplymodule complex maintains power long enough for a safe and orderedshutdown of the IBM XIV Storage System. The complex can sustain thefailure of one uninterruptible power supply unit while protecting againstexternal power failures.

Ethernet switch RPSA redundant power source for the Ethernet switches .

Maintenance moduleAllows remote support access using a modem.

ATS The Automatic Transfer System (ATS) switches between line cords in orderto allow redundancy of external power.

ModemAllows the system to receive a connection for remote access by IBMsupport. The modem connects to the maintenance module.

Ethernet switchesProvide redundant internal GB Ethernet networks. All the modules in thesystem are linked through an internal redundant Gigabit Ethernet network.The network is composed of two independent Ethernet switches. Eachmodule is directly attached to both switches, and the switches are alsolinked to each other. Because the switches are configured in anactive-active configuration, the network topology uses maximumbandwidth while being tolerant to any individual failure in a networkcomponent (port, link, or switch), and to multiple failures.

Hardware connectivity

Data and interface modules are generically referred to as ″modules″. Modulescommunicate with each other by means of the internal Gigabit Ethernet network.Each module contains redundant Gigabit Ethernet ports used for module tomodule communication. The ports are all linked to the internal network throughthe redundant Ethernet switches. In addition, for monitoring purposes, the UPSsare directly connected by Ethernet and USB to individual modules.

Supported interfacesThe following interfaces are supported by the IBM XIV Storage System:v Fibre Channel for host-based I/Ov Gigabit Ethernet for host-based I/O using the iSCSI protocolv Gigabit Ethernet for management (GUI or CLI) connectivityv Remote access interfaces:

– Call-home connection - connecting the IBM XIV Storage System to an IBMtrouble-ticketing system.

– Broadband connection (VPN) - provides a two-way broadband access to thesystem for remote access by IBM support.

– Modem - for incoming calls only. The customer has to provide telephone lineand number. The modem provides secondary means for providing remoteaccess for IBM Support.

Chapter 1. Overview: The IBM XIV Storage System 3

Management optionsThe IBM XIV Storage System provides several management options.

GUI and CLI management applicationsThese applications must be installed on each workstation that will be usedfor managing and controlling the system. All configurations andmonitoring aspects of the system can be controlled through the GUI or theCLI.

SNMPThird-party SNMP-based monitoring tools are supported using the IBMXIV MIB.

E-mail notificationsThe IBM XIV Storage System can notify users, applications or both throughe-mail messages regarding failures, configuration changes, and otherimportant information.

SMS notificationsUsers can be notified through SMS of any system event.

ReliabilityIBM XIV Storage System reliability features include data mirroring, spare storagecapacity, self-healing mechanisms, and data virtualization.

Figure 2. The IBM XIV Storage System Interfaces


Redundant components and no single point of failureAll IBM XIV Storage System hardware components are fully redundant, andensure failover protection for each other to prevent a single point of system failure.

System failover processes are transparent to the user because they are swiftly andseamlessly completed.

Data mirroringData arriving from the host for storage is temporarily placed in two separatecaches before it is permanently written to two disk drives located in separatemodules. This guarantees that the data is always protected against possible failureof individual modules, and this protection is in effect even before data has beenwritten to the nonvolatile disk media.

Self-healing mechanismsThe IBM XIV Storage System includes built-in mechanisms for self-healing to takecare of individual component malfunctions and to automatically restore full dataredundancy in the system within minutes.

Self-healing mechanisms dramatically increase the level of reliability in the IBMXIV Storage System. Rather than necessitating a technician’s on-site intervention inthe case of an individual component malfunction to prevent a possible malfunctionof a second component, the automatically restored redundancy allows a relaxedmaintenance policy based on a pre-established routine schedule.

Self-healing mechanisms are not just started after individual componentmalfunction takes place. Often, potential problems are identified well before theymight occur with the help of advanced algorithms of preventive self-analysis thatare continually running in the background. In all cases, self-healing mechanismsimplemented in the IBM XIV Storage System identify all data portions in thesystem for which a second copy has been corrupted or is in danger of beingcorrupted. The IBM XIV Storage System creates a secure second copy out of theexisting copy, and it stores it in the most appropriate part of the system. Takingadvantage of the full data virtualization, and based on the data distributionschemes implemented in the IBM XIV Storage System, such processes arecompleted with minimal data migration.

As with all other processes in the system, the self-healing mechanisms arecompletely transparent to the user, and the regular activity of responding to I/Odata requests is thoroughly maintained with no degradation to systemperformance. Performance, load balance, and reliability are never compromised bythis activity.

Protected cacheIBM XIV Storage System cache writes are protected. Cache memory on a module isprotected with ECC (Error Correction Coding). All write requests are written totwo separate cache modules before the host is acknowledged. The data is laterdestaged to disks.

Redundant powerRedundancy of power is maintained in the IBM XIV Storage System through thefollowing means:


v Three UPSs - the system can run indefinitely on two UPSs. No systemcomponent will lose power if a single UPS fails.

v Redundant power supplies in each data and interface module. There are twopower supplies for each module and each power supply for a module ispowered by a different UPS.

v Redundant power for Ethernet switches - each Ethernet switch is powered bytwo UPSs. One is a direct connect; one is through the Ethernet switch redundantpower supply.

v Redundant line cords - to protect against the loss of utility power, two line cordsare supplied to the ATS. If utility power is lost on one line cord, the ATSautomatically switches to the other line cord, without impacting the system.

v In the event of loss of utility power on both line cords, the UPSs will maintainpower to the system until an emergency destage of all data in the system can beperformed. Once the emergency destage has completed, the system will performa controlled power down.

PerformanceIBM XIV Storage System performance features include total load balancing,intelligent caching, disk-drive error handling, and 1 Gb Ethernet connections.

Total load balanceThe fundamental principle of the IBM XIV Storage System architecture is to evenlydistribute the handling and storage of data (associated with its logical volumes)across all hardware components in the system.

This optimum state of total load balance is preserved in all circumstances andunder any kinds of configuration changes in the system, including changes due tofailing hardware, so that the very high performance parameters that derive from itare fully scalable.

Moreover, the load distribution of IBM XIV Storage System is maintained whenexpanding the system. When modules are added, data already written to thesystem is redistributed in order to evenly spread the data among all modules anddisk drives in the expanded system. At least two copies of the data are maintainedwithin the system for the entire redistribution process. Reliability, availability, andperformance are unaffected during and after these redistribution processes.

Data distribution in the IBM XIV Storage System is equivalent to a full, optimalvirtualization of volumes across the storage resources of the system. Under thisvirtualization, I/O activity performed in the system takes full advantage of all theavailable physical resources at any point in time. Write or read requests directed atany particular volume harness the entire CPU power, internal bandwidth, and diskcapacity, nearly eliminating bottlenecks.

Intelligent caching for improved performanceThe IBM XIV Storage System provides intelligent caching through advancedalgorithms for cache management, and through the use of a distributed cache.

The algorithms used by the IBM XIV Storage System use innovative approaches forpromotion, demotion and destaging data in the cache memory. In addition, thesystem uses highly efficient and novel prefetch routines. These algorithms aretransparent to the host requesting the data. They result in short response times andlow latencies for data requests handled by the system.


Additionally, each data or interface module caches data only for its local disks.This provides the benefit of allowing a very high bandwidth connection betweenthe cache and the drives being cached. Also, because each data and interfacemodule devotes its full processing power to managing an independent cache, andbecause this independent cache only handles data for its local disks, smaller slotscan be freely used without degrading performance. The IBM XIV Storage Systemuses cache slots as small as 4KB, or as large as 1MB, allowing highly efficient useof the cache memory. Cache slot size is automatically determined by the system,and varies based on the access patterns of the data in the region being cached.

FunctionalityIBM XIV Storage System functions include point-in-time copying, automaticnotifications, and ease of management through a GUI or CLI.

Snapshot management

The IBM XIV Storage System provides powerful snapshot mechanisms for creatingpoint-in-time copies of volumes. These snapshots can be used for backup, testing,or recovery from logical errors.

The snapshot mechanisms include the following features:v Differential snapshots, where only the data that differs between the source

volume and its snapshot consumes storage spacev Instant creation of a snapshot without any interruption of the application,

making the snapshot available immediatelyv Practically unlimited quantity of snapshots, with no minimal performance or

space overheadv Writable snapshots, which can be used for a testing environment; storage space

is only required for actual data changesv Snapshot of a writable snapshot can be takenv High performance that is independent of the number of snapshots or volume

size

Consistency groups for snapshots

Volumes can be put in a consistency group to create consistent point-in-timesnapshots of all the volumes in a single operation. This is essential for applicationsthat use several volumes concurrently and need a consistent snapshot of all thesevolumes.

Storage pools

The storage space of the IBM XIV Storage System can be administrativelyportioned into storage pools to enable the control of storage space consumption forspecific applications or departments. Storage pools are used to control the storageresources of volumes and snapshots.

Remote monitoring and diagnostics

IBM XIV Storage System can email important system events to IBM Support. Thisallows IBM to immediately dispatch service personnel when a hardware failureoccurs. Additionally, IBM support personnel can conduct remote support andgenerate diagnostics for both maintenance and support purposes. All remote


support is subject to customer permission and remote support sessions areprotected with a challenge response security mechanism.

SNMP

Third-party SNMP-based monitoring tools are supported for the IBM XIV StorageSystem MIB.

Multipathing

The parallel design underlying the activity of the Host Interface modules and thefull data virtualization achieved in the system implement thorough multi-pathingaccess algorithms. Thus, as the host connects to the system through severalindependent ports, each volume can be accessed directly through any of the HostInterface modules, and no interaction has to be established across the variousmodules of the host interface complex.

Automatic event notifications

The system can be set to automatically transmit appropriate alarm notificationmessages through SNMP traps, or e-mail messages. The user can configure varioustriggers for sending events and various destinations depending on the type andseverity of the event. The system can also be configured to send notifications untila user acknowledges their receipt.

Management through GUI and CLI

The IBM XIV Storage System offers a user-friendly and intuitive GUI applicationand CLI commands to configure and monitor the system. These feature snapshotsfor restoring data, and all required volume and host management functionality.

For more information, see “Introduction” on page v and the IBM XIV XCLI UserManual.

External replication mechanisms

External replication and mirroring mechanisms in the IBM XIV Storage System arean extension of the internal replication mechanisms and of the overall functionality ofthe system. These features provide protection against a site disaster to ensureproduction continues. Snapshots of the secondary volume can be taken withoutstopping the mirroring. The mirroring can be performed over either Fibre Channelor iSCSI, and the host-to-storage protocol is independent of the mirroring protocol.

UpgradabilityThe IBM XIV Storage System is available in a partial rack system comprised of asfew as six (6) modules, or as many as fifteen (15) modules per rack. Partial racksystems may be upgraded by adding data and interface modules, up to themaximum of fifteen (15) modules per rack.


Chapter 2. Volumes and snapshots overview

The volume is the basic data-storage entity as defined by the SCSI protocol. Avolume is a list of blocks (where the size of each block is 512 bytes), that are beingpresented to a SCSI host as a logical disk. Using the SCSI protocol that isimplemented over FC or iSCSI, the host can read and write volume data.

Snapshots of volumes represent the data on a volume at a specific point in time.Figure 3 shows a volume with snapshots taken at two different points in time.

Virtualization, mirroring, and thin provisioning of volumes is facilitates through::

SnapshotsAn unlimited number of snapshots can be taken without impactingperformance.

Consistency groupsVolumes can be grouped into consistency groups to take simultaneoussnapshots of a large number of volumes and easily manage snapshots forthese volumes.

Storage poolsVolumes must be associated with storage pools to manage storage capacityfor a set of volumes.

Note: In the storage system industry literature, volumes are sometimes referred toas disks, LUNs or devices.

volumes_and_snapshots

time

Snapshot

Volume I/O I/OI/OI/O VolumeI/O

Snapshot

I/O I/OI/O

• Name:Volume_1.snapshot_00001• Created:t1

I/O I/OI/OI/O

• Name:Volume_1.snapshot_00002• Created:t2

• Name:Volume_1 Name:Volume_1

t1 t2

•

Figure 3. A volume is shown with snapshots taken at two different points in time.


The volume life cycleThe volume is the basic data container that is presented to the hosts as a logicaldisk.

The term volume is sometimes used for an entity that is either a volume or asnapshot. Hosts view volumes and snapshots through the same protocol.Whenever required, the term master volume is used for a volume to clearlydistinguish volumes from snapshots.

Each volume has two configuration attributes: a name and a size. The volumename is an alphanumeric string that is internal to the IBM XIV Storage System andis used to identify the volume to both the GUI and CLI commands. The volumename is not related to the SCSI protocol. The volume size represents the number ofblocks in the volume that the host sees.

The volume can be managed by the following commands:

Create Defines the volume using the attributes you specify

Resize Changes the virtual capacity of the volume. For more information, seeChapter 6, “Thin provisioning,” on page 31.

Copy Copies the volume to an existing volume or to a new volume

FormatClears the volume

Lock Prevents hosts from writing to the volume

UnlockAllows hosts to write to the volume

RenameChanges the name of the volume, while maintaining all of the volumespreviously defined attributes

Delete Deletes the volume

The following query commands list volumes:

Listing VolumesThis command lists all volumes, or a specific volume according to a givenvolume or pool.

Finding a Volume Based on a SCSI Serial NumberThis command prints the volume name according to its SCSI serialnumber.

These commands are available when you use both the IBM XIV Storage SystemGUI and the IBM XIV Command Line Interface (XCLI). See the IBM XIV XCLI UserManual for the commands that you can issue in the XCLI.

Figure 4 on page 11 shows the commands you can issue for volumes.


SnapshotsA snapshot is a logical volume whose contents are identical to that of a givensource volume at a specific point-in-time.

The IBM XIV Storage System uses advanced snapshot mechanisms to create avirtually unlimited number of volume copies without impacting performance.Snapshot taking and management are based on a mechanism of internal pointersthat allow the master volume and its snapshots to use a single copy of data for allportions that have not been modified.

This approach, also known as Redirect-on-Write (ROW) is an improvement of themore common Copy-on-Write (COW), which translates into a reduction of I/Oactions, and therefore storage usage.

Redirect on writeThe IBM XIV Storage System uses the Redirect-on-Write (ROW) mechanism.

The following items are characteristics of using ROW when a write request isdirected to the master volume:1. The data originally associated with the master volume remains in place.2. The new data is written to a different location on the disk.3. After the write request is completed and acknowledged, the original data is

associated with the snapshot and the newly written data is associated with themaster volume.

Volume

Volume

Create

Delete

• Name:Volume_1• Size:171GB

• ResizeFormatLock/unlockRename

•••

Copy

I/O I/OI/O I/O I/O I/OI/O I/O I/O I/OI/O I/O

I/O I/O

volume_life_cycle

Figure 4. Volume operations

Chapter 2. Volumes and snapshots overview 11

The original data is never copied as part of this command. As a result, the actualdata activity involved in taking the snapshot is drastically reduced. Moreover, ifthe size of the data involved in the write request is equal to the system’s slot size,there is no need to copy any data at all. If the write request is smaller than thesystem’s slot size, there is still much less copying than with the standard approachof Copy-on-Write. Figure 5 provides an example of ROW.

The metadata established at the beginning of the snapshot mechanism isindependent of the size of the volume to be copied. This approach allows the userto achieve the following important goals:

Continuous backupAs snapshots are taken, backup copies of volumes are produced atfrequencies that resemble those of Continuous Data Protection (CDP). Instantrestoration of volumes to virtually any point in time is easily achieved incase of logical data corruption at both the volume level and the file level.

ProductivityThe snapshot mechanism offers an instant and simple method for creatingshort or long-term copies of a volume for data mining, testing, andexternal backups.

Auto-delete prioritySnapshots can be associated with an auto-delete priority to control the order inwhich snapshots are automatically deleted.

Taking volume snapshots gradually fills up storage space according to the amountof data that is modified in either the volume or its snapshots. To free up spacewhen the maximum storage capacity is reached, the system can refer to theauto-delete priority to determine the order in which snapshots are deleted. Ifsnapshots have the same priority, the snapshot that was created first is deletedfirst.

Figure 5. Example of the Redirect-on-Write process


Snapshot name and associationA snapshot is always created from a volume. The name of a snapshot is eitherautomatically assigned by the system at creation time or given as a parameter ofthe XCLI command that creates it. The snapshot’s auto-generated name is derivedfrom its volume’s name and a serial number. The following are examples ofsnapshot names:MASTERVOL.snapshot_XXXXXNewDB-server2.snapshot_00597

Parameter Description Example

MASTERVOL The name of the volume. NewDB-server2

XXXXX A five-digit, zero filledsnapshot number.

00597

The snapshot lifecycleThe roles of the snapshot determine its life cycle.

Figure 6 shows the life cycle of a snapshot.

The following list describes the life cycle:

Create Creates the snapshot.

RestoreCopies the snapshot back onto the volume. The main snapshotfunctionality is the capability to restore the volume.

snapshot_life_cycle

time

Snapshot

Volume

Take a snapshot

I/O I/OI/OI/O VolumeI/O

SnapshotUnlock

Snapshot

Duplicate

Volume

Restore

SnapshotI/O I/OI/OI/O I/O I/O I/O I/OSnapshot

I/O I/O I/O I/O Volume

Override

Snapshot

Snapshot of a snapshot

Name: Volume_1

Name: Volume_1.snapshot_00002 Name: Volume_1.snapshot_00002

Locked:No••

• Name:Volume_1.snapshot_00004Created: 2008-08-13 15:26Locked:YesDeletion Priority:1

•••

• Name:Volume_1.snapshot_00001Created: 2008-08-13 15:22Locked:YesDeletion Priority:1

•

I/O is overriden

Figure 6. The snapshot life cycle


UnlockingUnlocks the snapshot to make it writable and sets the status to Modified.Re-locking the unlocked snapshot disables further writing, but does notchange the status from Modified.

DuplicateDuplicates the snapshot. Similar to the volume, which can be snapshottedinfinitely, the snapshot itself can be duplicated.

A snapshot of a snapshotCreates a backup of a snapshot that was written into. Taking a snapshot ofa writable snapshot is similar to taking a snapshot of a volume.

Overwriting a snapshotOverwrites a specific snapshot with the content of the volume.

Delete Deletes the snapshot.

Creating a snapshotFirst, a snapshot of the volume is taken. The system creates a pointer to thevolume, hence the snapshot is considered to have been immediately created. Thisis an atomic procedure that is completed in a negligible amount of time. At thispoint, all data portions that are associated with the volume are also associated withthe snapshot.

Later, when a request arrives to read a certain data portion from either the volumeor the snapshot, it reads from the same single, physical copy of that data.

Throughout the volume life cycle, the data associated with the volume iscontinuously modified as part of the ongoing operation of the system. Whenever arequest to modify a data portion in the master volume arrives, a copy of theoriginal data is created and associated with the snapshot. Only then the volume ismodified. This way, the data originally associated with the volume at the time thesnapshot is taken is associated with the snapshot, effectively reflecting the way thedata was before the modification.

Locking and unlocking snapshotsInitially, a snapshot is created in a locked state, which prevents it from beingchanged in any way related to data or size, and only enables the reading of itscontents. This is called an image or image snapshot and represents an exact replica ofthe master volume when the snapshot was created.

An image snapshot can be unlocked after it is created. The first time a snapshot isunlocked, the system initiates an irreversible procedure that puts the snapshot in astate where it acts like a regular volume with respect to all changing operations.Specifically, it allows write requests to the snapshot. This state is immediately setby the system and brands the snapshot with a permanent modified status, even ifno modifications were performed. A modified snapshot is no longer an imagesnapshot.

An unlocked snapshot is recognized by the hosts as any other writable volume. Itis possible to change the content of unlocked snapshots, however, physical storagespace is consumed only for the changes. It is also possible to resize an unlockedsnapshot.

Master volumes can also be locked and unlocked. A locked master volume cannotaccept write commands from hosts. The size of locked volumes cannot bemodified.


Duplicating image snapshotsA user can create a new snapshot by duplicating an existing snapshot. Theduplicate is identical to the source snapshot. The new snapshot is associated withthe master volume of the existing snapshot, and appears as if it were taken at theexact moment the source snapshot was taken. For image snapshots that have neverbeen unlocked, the duplicate is given the exact same creation date as the originalsnapshot, rather than the duplication creation date.

With this feature, a user can create two or more identical copies of a snapshot forbackup purposes, and perform modification operations on one of them withoutsacrificing the usage of the snapshot as an untouched backup of the mastervolume, or the ability to restore from the snapshot.

A snapshot of a snapshotWhen duplicating a snapshot that has been changed using the unlock feature, thegenerated snapshot is actually a snapshot of a snapshot. The creation time of thenewly created snapshot is when the command was issued , and its content reflectsthe contents of the source snapshot at the moment of creation.

After it is created, the new snapshot is viewed as another snapshot of the mastervolume.

Restoring volumes and snapshotsThe restoration operation provides the user with the ability to instantly recover thedata of a master volume from any of its locked snapshots.

Restoring volumes

A volume can be restored from any of its snapshots. Performing the restorationreplicates the selected snapshot onto the volume. As a result of this operation, themaster volume is an exact replica of the snapshot that restored it. All othersnapshots, old and new, are left unchanged and can be used for further restoreoperations. A volume can even be restored from a snapshot that has been writtento. Figure 7 on page 16 shows a volume being restored from three differentsnapshots.


Restoring snapshots

The snapshot itself can also be restored from another snapshot. The restoredsnapshot retains its name and other attributes. From the host perspective, thisrestored snapshot is considered an instant replacement of all the snapshot contentwith other content. Figure 8 on page 17 shows a snapshot being restored from twodifferent snapshots.

restoring_a_volume

�me

Snapshot

Volume I/O I/OI/OI/OI/O

Name: Volume_1.snapshot_00001

I/O I/OI/OI/O

Snapshot

I/O I/O I/O

Snapshot

I/O Volume

Restoring a volume

I/O I/OI/OI/OI/O I/O I/OI/O



Figure 7. Restoring volumes


Full Volume CopyWith Full Volume Copy, you can instantly create a full copy of a volume. FullVolume Copy overwrites an existing volume, and at the time of its creation it islogically equivalent to the source volume.

After the copy is made, both volumes are independent of each other. Hosts canwrite to either one of them without affecting the other. This is somewhat similar tocreating a writable (unlocked) snapshot, with the following differences andsimilarities:v Creation time and availability - Both Full Volume Copy and creating a snapshot

happen almost instantly. Both the new snapshot and volume are immediatelyavailable to the host. This is because at the time of creation, both the source andthe destination contain the exact same data and share the same physical storage.

v Singularity of the copy operation - Full Volume Copy is implemented as asingle copy operation into an existing volume, overriding its content andpotentially its size. The existing target of a volume copy can be mapped to ahost. From the host perspective, the content of the volume is changed as onetransaction. In contrast, creating a new writable snapshot creates a new objectthat has to be mapped to the host.

v Space allocation - With Full Volume Copy, all the required space for the targetvolume is reserved at the time of the copy. If the storage pool that contains thetarget volume cannot allocate the required capacity, the operation fails and hasno effect. This is unlike writable snapshots, which are different in nature.

v Taking snapshots and mirroring the copied volume - The target of the FullVolume Copy is a master volume. This master volume can later be used as asource for taking a snapshot or creating a mirror. However, at the time of thecopy, neither snapshots nor remote mirrors of the target volume are allowed.

restoring_a_snapshot

time

Snapshot

Volume I/O I/OI/OI/OI/O I/O I/OI/OI/O

Snapshot

I/O I/O I/OI/O

Restoring a snapshot

I/O I/OI/OI/OI/O I/O I/OI/O

I/O I/OI/OI/OI/O I/O I/OI/O Snapshot

Name:Volume_1.snapshot_00001

Name:Volume_1.snapshot_00002

Figure 8. Restoring snapshots


v Redirect-on-write implementation - With both Full Volume Copy and writablesnapshots, while one volume is being changed, a redirect-on-write operation willensure a split so that the other volume maintains the original data.

v Performance - Unlike writable snapshots, with Full Volume Copy, the copyingprocess is performed in the background even if no I/O operations areperformed. Within a certain amount of time, the two volumes will use differentcopies of the data, even though they contain the same logical content. Thismeans that the redirect-on-write overhead of writes occur only before the initialcopy is complete. After this initial copy, there is no additional overhead.

v Availability - Full Volume Copy can be performed with source and targetvolumes in different storage pools.


Chapter 3. Host System Attachment

The IBM XIV Storage System can attach to hosts of various operating systems.

Note: The term host system attachment was previously known as host connectivity ormapping. These terms are obsolete.

Balanced traffic and no single point of failureAll host traffic (I/O) is served through up to six interface modules (modules 4-9).Although the IBM XIV Storage System distributes the traffic between I/O modulesand data modules, the storage administrator is responsible for ensuring that hostI/O operations are equally distributed among the different interface modules.

The workload balance should be watched and reviewed when host traffic patternschange. The IBM XIV Storage System does not automatically balance incominghost traffic. The storage administrator is responsible for ensuring that hostconnections are made redundantly in such a way that a single failure, such as in amodule or HBA, will not cause all paths to the machine to fail. In addition, thestorage administrator is responsible for making sure the host workload isadequately spread across the different connections and interface modules.

Attaching volumes to hostsWhile the IBM XIV Storage System identifies volumes and snapshots by name,hosts identify volumes and snapshots according to their logical unit number(LUN).

A LUN is an integer that is used when attaching a system’s volume to a registeredhost. Each host can access some or all of the volumes and snapshots on the storagesystem, up to a set maximum. Each accessed volume or snapshot is identified bythe host through a LUN.

For each host, a LUN identifies a single volume or snapshot. However, differenthosts can use the same LUN to access different volumes or snapshots.

Advanced host attachmentThe IBM XIV Storage System provides flexible host attachment options.

The following host attachment options are available:v Definition of different volume mappings for different ports on the same hostv Support for hosts that have both Fibre Channel and iSCSI ports. Although it is

not advisable to use these two protocols together to access the same volume, adual configuration can be useful in the following cases:– As a way to smoothly migrate a host from Fibre Channel to iSCSI– As a way to access different volumes from the same host, but through

different protocols


Clustering hosts into LUN mapsClusters provide identical mappings for a set of hosts. To do this, a cluster isidentified as an entity that groups several hosts together and assigns the samemapping to all of the hosts. The mapping of volumes to LUN identifiers is definedper cluster and applies to all the hosts in the cluster.

Because the IBM XIV Storage System does not maintain a hierarchy of clusters,there is no way to define different mappings for different hosts that belong to thesame cluster.

After you add a host to a cluster, you can perform either of the following tasks:v Changing the host’s mapping to the cluster’s mappingv Changing the cluster’s mapping to be identical to the mapping of the newly

added host

After you remove a host from a cluster the following conditions still apply:v The host’s mapping remains the same as cluster’s mapping.v The mapping definitions do not revert to the host’s original mapping before it

was added to the cluster.v The administrator can change the host’s mapping.

Volume mappings exceptionsWhenever the mapping process fails, the IBM XIV Storage System issues anexception. These exceptions are described in the following sections.

Mapping a volume to a host within a cluster

FunctionalityThis command maps a volume to a host within a cluster.

Relevant CLI commandmap_vol

Nature of the exceptionThe command specifies a volume or a LUN and a cluster, where thevolume or LUN are already mapped to a host that belongs to this cluster.

Result One of the following (see the examples below):v The command fails.v The command doesn’t fail. The user is asked to approve a warning

message saying the specific mapping will be established.

ExamplesIn the following examples, host1 is a host that belongs to cluster cluster1.The cluster has a mapping of vol1 to LUN1.v Example 1

Commandmap_vol host=host1 vol=vol1 lun=lun1

Result The command fails, as such a mapping already exists for thevolume and LUN.

v Example 2



Result The command fails, as such a mapping already exists for theLUN.

v Example 3


Result The command fails, as such a mapping already exists for thevolume.

v Example 4


Result The command succeeds following a warning that the mapping ishost-specific and the host already has a mapping.

Listing volumes that are already mapped

FunctionalityThis command lists volumes that are already mapped to host and cluster.

Relevant CLI commandvol_mapping_list

Nature of the exceptionThe command lists all hosts and clusters to which the volume is mapped.This list includes hosts that are part of a cluster, given that they have ahost-specific mapping to the volume.

Listing mappings

FunctionalityThis command lists mappings of volumes to a specific host or cluster.

Relevant CLI commandmapping_list

Nature of the exceptionFor each listed mapping, the command indicates whether it iscluster-based.

Adding a host to a cluster

FunctionalityThis command adds a host to a cluster.

Relevant CLI commandcluster_add_host

Nature of the exceptionHost-specific mappings are removed, leaving only cluster mappings.

Removing a host from a cluster

FunctionalityThis command removes a host from a cluster.

Relevant CLI commandcluster_remove_host

Nature of the exceptionThe host retains all of its cluster-specific mappings.

Chapter 3. Host System Attachment 21

Host system attachment commandsThe IBM XIV Storage System manages host attachment through host commands,cluster commands, and mapping commands.

Table 2 and Figure 9 on page 23 list the command sets that are available.

Table 2. Commands used for host attachment

Command set Commands

Host commands For adding and managing hosts and providing them withports, the following commands are available:

v host_define

v host-add_port

v host_remove_port

v host_update

v host_list

v host_rename

v host_delete

Cluster commands For creating and managing clusters, and populating themwith hosts, the following commands are available:

v cluster_create

v cluster_add_host

v cluster_remove_host

v cluster_list

v cluster_rename

v cluster_delete

Mapping commands For creating and managing maps and populating them withhosts, the following commands are available:

v map_vol

v unmap_vol

v mapping_list

v vol_mapping_list

Other As of today, HP-UX hosts requires a special attachmentmethod, provided by the following command:

v special_type_set


Figure 9. Host system attachment commands

Chapter 3. Host System Attachment 23

Chapter 4. Consistency groups overview

Consistency groups can be used to take simultaneous snapshots of multiplevolumes, thus ensuring consistent copies of a group of volumes.

Creating a synchronized snapshot set is especially important for applications thatuse multiple volumes concurrently. A typical example is a database application,where the database and the transaction logs reside on different storage volumes,but all of their snapshots must be taken at the same point in time.

This chapter contains the following sections:v “Creating a consistency group”v “Taking a snapshot of a consistency group”v “The snapshot group life cycle” on page 27v “Restoring a consistency group” on page 28

Creating a consistency groupYou can create an empty consistency group or one that contains volumes. Witheither method, you can add volumes at a later time.

The functionality of a consistency group is similar to the functionality of volumes.The main advantage of a consistency group is the ability to take snapshots ofmultiple volumes simultaneously.

Taking a snapshot of a consistency groupTaking a snapshot for the entire consistency group means that a snapshot is takenfor each volume of the consistency group at the same point-in-time. Thesesnapshots are grouped together to represent the volumes of the consistency groupat a specific point in time.

ConsistencyGroup

Add Volume to aConsistency Group

Remove Volume

Create a Consistency Group fora Volume

Volumecg_snapshots_create

Delete

Create a consistency Group

SnapshotGroup

Volume

Figure 10. The consistency group’s life-cycle


In Figure 11, a snapshot is taken for each for consistency group’s volumes in thefollowing order:

Time = t0

Prior to taking the snapshots, all volumes in the consistency group areactive and being read from and written to.

Time = t1

When the command to snapshot the consistency group is issued, I/O issuspended .

Time = t2

Snapshots are taken at the same point in time.

Time = t3

I/O is resumed and the volumes continue their normal work.

Time = t4

After the snapshots are taken, the volumes resume active state andcontinue to be read from and written to.

Most snapshot operations can be applied to each snapshot in a grouping, known asa snapshot set. The following items are characteristics of a snapshot set:v A snapshot set can be locked or unlocked. When you lock or unlock a snapshot

set, all snapshots in the set are locked or unlocked.v A snapshot set can be duplicated.v A snapshot set can be deleted. When a snapshot set is deleted, all snapshots in

the set are also deleted.

A snapshot set can be disbanded which makes all the snapshots in the setindependent snapshots that can be handled individually. The snapshot set itself isdeleted, but the individual snapshots are not.

time

Volume_1

Volume_2

Volume_3

I/O I/OI/OI/O

I/O I/OI/OI/O

I/O I/OI/OI/O

I/O I/OI/OI/O

I/O I/OI/OI/O

I/O I/OI/OI/O

t0 t1 t2 t3 t4

Consistency Group

I/O is suspended

I/O is resum

ed

Snapshots are taken

Figure 11. A snapshot is taken for each volume of the consistency group


The snapshot group life cycleMost snapshot operations can be applied to snapshot groups, where the operationaffects every snapshot in the group.

Taking a snapshot groupCreates a snapshot group. See “Taking a snapshot of a consistency group”on page 25.

Restoring consistency group from a snapshot groupThe main purpose of the snapshot group is the ability to restore the entireconsistency group at once, ensuring that all volumes are synchronized tothe same point in time. See “Restoring a consistency group” on page 28.

Listing a snapshot groupThis command lists snapshot groups with their consistency groups and thetime the snapshots were taken.

Note: All snapshots within a snapshot group are taking at the same time.

Lock and unlockSimilar to unlocking and locking an individual snapshot, the snapshotgroup can be rendered writable, and then be written to. A snapshot groupthat is unlocked cannot be further used for restoring the consistency group,even if it is locked again.

The snapshot group can be locked again. At this stage, it cannot be used torestore the master consistency group. In this situation, the snapshot groupfunctions like a consistency group of its own.

OverwriteThe snapshot group can be overwritten by another snapshot group.

Figure 12. Most snapshot operations can be applied to snapshot groups

Chapter 4. Consistency groups overview 27

RenameThe snapshot group can be renamed.

DuplicateThe snapshot group can be duplicated, thus creating another snapshotgroup for the same consistency group with the time stamp of the firstsnapshot group.

Disbanding a snapshot groupThe snapshots that comprise the snapshot group are each related to itsvolume. Although the snapshot group can be rendered inappropriate forrestoring the consistency group, the snapshots that comprise it are stillattached to their volumes. Disbanding the snapshot group detaches allsnapshots from this snapshot group but maintains their individualconnections to their volumes. These individual snapshots cannot restorethe consistency group, but they can restore its volumes individually.

Changing the snapshot group deletion priorityManually sets the deletion priority of the snapshot group.

Deleting the snapshot groupDeletes the snapshot group along with its snapshots.

Restoring a consistency groupRestoring a consistency group is a single action in which every volume thatbelongs to the consistency group is restored from a corresponding snapshot thatbelongs to an associated snapshot group.

Not only does the snapshot group have a matching snapshot for each of thevolumes, all of the snapshots have the same time stamp. This implies that therestored consistency group contains a consistent picture of its volumes as theywere at a specific point in time.

Note: A consistency group can only be restored from a snapshot group that has asnapshot for each of the volumes. If either the consistency group or the snapshotgroup has changed after the snapshot group is taken, the restore action does notwork.


Chapter 5. Storage pools overview

The storage space of the IBM XIV Storage System is portioned into storage pools,where each volume belongs to a specific storage pool.

Storage pools provide the following benefits:

Improved management of storage spaceSpecific volumes can be grouped together in a storage pool. This enablesyou to control the allocation of a specific storage space to a specific groupof volumes. This storage pool can serve a specific group of applications, orthe needs of a specific department.

Improved regulation of storage spaceSnapshots can be automatically deleted when the storage capacity that isallocated for snapshots is fully consumed. This automatic deletion isperformed independently on each storage pool. Therefore, the size limit ofthe storage pool is reached, only the snapshots that reside in the affectedstorage pool are deleted. For more information, see “Auto-delete priority”on page 12.

Storage pools as logical entities

A storage pool is a logical entity and is not associated with a specific disk ormodule. All storage pools are equally spread over all disks and all modules in thesystem.

As a result, there are no limitations on the size of storage pools or on theassociations between volumes and storage pools. For example:v The size of a storage pool can range from as small as 34 GB to as large as the

entire system without any limitation.v The size of a storage pool can be increased, limited only by the free space on the

system.v The size of a storage pool can be decreased, limited only by the space consumed

by the volumes and snapshots in that storage pool.v Volumes can be moved between storage pools without any limitations, as long

as there is enough free space in the target storage pool.

All of the above transactions are accounting transactions, and do not impose anydata copying from one disk drive to another. These transactions are completedinstantly.

Moving volumes between storage pools

For a volume to be moved to a specific storage pool, there must be enough roomfor it to reside there. If a storage pool is not large enough, the storage pool must beresized, or other volumes must be moved out to make room for the new volume.

A volume and all its snapshots always belong to the same storage pool. Moving avolume between storage pools automatically moves all its snapshots together withthe volume.


Chapter 6. Thin provisioning

The IBM XIV Storage System supports thin provisioning, which provides theability to define logical volume sizes that are much larger than the physicalcapacity installed on the system. Physical capacity needs only to accommodatewritten data, while parts of the volume that have never been written to do notconsume physical space.

This chapter discusses:v Volume hard and soft sizesv System hard and soft sizesv Pool hard and soft sizesv Depletion of hard capacity

Volume hard and soft sizes

Without thin provisioning, the size of each volume is both seen by the hosts andreserved on physical disks. Using thin provisioning, each volume is associatedwith the following two sizes:

Hard volume sizeThis reflects the total size of volume areas that were written by hosts. Thehard volume size is not controlled directly by the user and depends onlyon application behavior. It starts from zero at volume creation orformatting and can reach the volume soft size when the entire volume hasbeen written. Resizing of the volume does not affect the hard volume size.

Soft volume sizeThis is the logical volume size that is defined during volume creation orresizing operations. This is the size recognized by the hosts and is fullyconfigurable by the user. The soft volume size is the traditional volumesize used without thin provisioning.

System hard and soft size

Using thin provisioning, each IBM XIV Storage System is associated with a hardsystem size and soft system size. Without thin provisioning, these two are equal tothe system’s capacity. With thin provisioning, these concepts have the followingmeaning:

Hard system sizeThis is the physical disk capacity that was installed. Obviously, thesystem’s hard capacity is an upper limit on the total hard capacity of allthe volumes. The system’s hard capacity can only change by installing newhardware components (disks and modules).

Soft system sizeThis is the total limit on the soft size of all volumes in the system. It is notrelated to any direct system attribute, and can be set to be larger than thehard system size if thin provisioning is used.

The soft system size is a purely logical limit, but should not be set to an arbitraryvalue. It must be possible to upgrade the system’s hard size to be equal to the softsize, otherwise applications can run out of space. This requirement means that


enough floor space should be reserved for future system hardware upgrades, andthat the cooling and power infrastructure should be able to support theseupgrades. Because of the complexity of these issues, the setting of the system’s softsize can only be performed by IBM XIV support.

Pool hard and soft sizes

The concept of storage pool is also extended to thin provisioning. When thinprovisioning is not used, storage pools are used to define capacity allocation forvolumes. The storage pools control if and which snapshots are deleted when thereis not enough space.

When thin provisioning is used, each storage pool has a soft pool size and a hardpool size, which are defined and used as follows:

Hard pool sizeThis is the physical storage capacity allocated to volumes and snapshots inthe storage pool. The hard size of the storage pool limits the total of thehard volume sizes of all volumes in the storage pool and the total of allstorage consumed by snapshots. Unlike volumes, the hard pool size is fullyconfigured by the user.

Soft pool sizeThis is the limit on the total soft sizes of all the volumes in the storagepool. The soft pool size has no effect on snapshots.

Thin provisioning is managed for each storage pool independently. Each storagepool has its own soft size and hard size. Resources are allocated to volumes withinthis storage pool without any limitations imposed by other storage pools. This is anatural extension of the snapshot deletion mechanism, which is applied evenwithout thin provisioning. Each storage pool has its own space, and snapshotswithin each storage pool are deleted when the storage pool runs out of spaceregardless of the situation in other storage pools.

The sum of all the soft sizes of all the storage pools is always the same as thesystem’s soft size and the same applies to the hard size.

Storage pools provide a logical way to allocate storage resources per application orper groups of applications. With thin provisioning, this feature can be used tomanage both the soft capacity and the hard capacity.

Depletion of hard capacity

Thin provisioning creates the potential risk of depleting the physical capacity. If aspecific system has a hard size that is smaller than the soft size, the system willrun out of capacity when applications write to all the storage space that is mappedto hosts. In such situations, the system behaves as follows:

Snapshot deletionSnapshots are deleted to provide more physical space for volumes. Thesnapshot deletion is based on the deletion priority and creation time.

Volume lockingIf all snapshots have been deleted and more physical capacity is stillrequired, all the volumes in the storage pool are locked and no writecommands are allowed. This halts any additional consumption of hardcapacity.


Note: Space that is allocated to volumes that is unused (that is, the differencebetween the volume’s soft and hard size) can be used by snapshots in the samestorage pool.

The thin provisioning implementation in the IBM XIV Storage System managesspace allocation per storage pool. Therefore, one storage pool cannot affect anotherstorage pool. This scheme has the following advantages and disadvantages:

Storage pools are independentStorage pools are independent in respect to the aspect of thin provisioning.Thin provisioning volume locking on one storage pool does not create aproblem in another storage pool.

Space cannot be reused across storage poolsEven if a storage pool has free space, this free space is never reused foranother storage pool. This creates a situation where volumes are lockeddue to the depletion of hard capacity in one storage pool, while there isavailable capacity in another storage pool.

Important: If a storage pool runs out of hard capacity, all of its volumes are lockedto all write commands. Although write commands that overwrite existing data canbe technically serviced, they are blocked to ensure consistency.

Chapter 6. Thin provisioning 33

Chapter 7. Target connectivity

The target connectivity feature defines the communication topology between alocal storage system and a remote storage system. The defined communicationenables remote mirroring and data migration between the two storage systems.

The connectivity can be defined so that both local and target storage systems canwrite to and read from each other.

Setting up the target connectivity feature includes the following actions:1. Defining a remote target object2. Adding ports to the target system3. Defining connectivity between local and remote target ports4. Allowing symmetric connectivity for mirroring

This chapter explains the concepts behind remote target definitions, and alsodescribes the process of manually defining remote targets through CLI commands.

Defining a remote target objectDefine a remote target object in order to allow for data migration (from anystorage system) or mirroring, or mirroring (from other IBM XIV Storage Systems).

The remote target object - a storage system other than the local - is definedthrough the target_define command. The target_define command specifies thefollowing connectivity attributes:

target The local name of the target storage system.

protocolThe protocol used to access the remote target (either Fibre Channel oriSCSI).

iscsi_nameThe iSCSI name of the target.

system_idThe ID of the target as viewed by the target.

xiv_featuresDeclares whether the target is an IBM XIV Storage System. If so, mirroringis applicable. If not, only data migration is applicable.

Remote target objects are referenced in the mirror_create (the command thatcreates a remote mirror) and dm_create (creating a data migration process)commands.

Target-related commands

Remote target objects can be manipulated through the following commands:

target_deleteDeletes a target. The deleted target is no longer viewed by the local storagesystem.


target_renameRenames the target.

Note: The attribute that is renamed is the name of the target as viewed bythe local storage system.

target_listLists the target’s ports along with their activity status andmirroring-related values (see further on this chapter).

target_updateUpdates mirroring-related attributes.

Adding ports to remote targetAfter a remote target object is defined, you can add the remote target portaddresses to the local system.

Defining a port is done by simply providing the Fibre Channel port or iSCSIaddress. This is done according to the following guidelines:v The port type must conform to the target type.v Both iSCSI target and the iSCSI initiator ports on the remote system are required

for remote mirroring.v

The ports are added to the system through the target_port_add command. Thiscommand provides the local system with the following:

target The name of the target system.

ipaddressThe IP address of the port on the target system (for iSCSI type targetsonly).

fcaddressThe FC address of the port on the target system (for FC type targets only).

The added port is set to active state, making it available for use.

Port-related commands

After the ports are added, they can be managed using the following commands:

target_port_deleteDeletes the address of a specific target port.

target_port_deactivateSets the port to be unavailable for use without deleting it.

target_port_activateReactivate an inactive port.

target_port_listListing ports of a given target along with their addresses and active status.

Connecting between local and target portsOnce added, the target system’s ports are connected to the ports of the localsystem.


The connectivity between ports is an optional path that is available for use. It isdefined using the target_connectivity_define command:

target The target system.

ipaddress/fcaddressThe port address (ipaddress for iSCSI; fcaddress for FC).

local_ipinterfaceThe interface on the local system.

local_portThe FC port (applicable for FC connectivity only).

Table 3. Port connectivity commands

Command Description

target_connectivity_define This command is used to define connectivity between alocal system port and a remote port on a remote target.This command defines the connectivity as an optional paththat can be used. The user must ensure that the two portsare actually connected.

fc_connectivity_listipinterface_run_traceroute

These commands are used to list which remote target portsare visible. Local target ports are shown using thefc_connectivity_list command and remote target IPinterfaces are listed using the ipinterface_run_traceroutecommand.

target_connectivity_list This command is used to view the current definitions andthe current connection status.

target_connectivity_deletetarget_connectivity_activatetarget_connectivity_deactivate

These commands are used to delete, activate, anddeactivate target connectivity.

Port connectivity-related commands

List commands

fc_connectivity_listLists all available targets throughout the FC network.

ipinterface_run_tracerouteLists all available connectivity to remote IP nodes using the ICMPtrace-route mechanism.

target_connectivity_listLists the local system’s ports definitions and status.

Management commands

target_connectivity_deleteDeletes a port connectivity.

target_connectivity_deactivateSetting a connection between ports to be unavailable.

target_connectivity_activateActivates a deactivated connectivity.

Chapter 7. Target connectivity 37

Symmetric connectivity for mirroringRemote mirroring features role switchover between the local and remote system.This requires the target system to have a symmetric connection to the local system.That is, just as the local system have a definition of the remote system, the remotesystem has to view the local system as its own remote.

Symmetric connectivity is achieved through the target_mirroring_allowcommand.


Chapter 8. Synchronous remote mirroring

IBM XIV Storage System features synchronous remote mirroring for disasterrecovery. Remote mirroring can be used to replicate the data between twogeographically remote sites. The replication ensures uninterrupted businessoperation if there is a total site failure.

Remote mirroring provides data protection for the following types of site disasters:

Site failureWhen a disaster happens to a site that is remotely connected to anothersite, the second site takes over and maintains full service to the hostsconnected to the first site. The mirror is resumed after the failing siterecovers.

Split brainAfter a communication loss between the two sites, each site maintains fullservice to the hosts. After the connection is resumed, the sites complementeach other’s data to regain mirroring.

Remote mirroring basic conceptsRemote mirroring provides continuous availability of critical information in thecase of a disaster scenario.

A typical remote mirroring configuration involves the following two sites:

Primary siteThe location of the master storage system.

A local site that contains both the data and the active servers.

Secondary siteThe location of the secondary storage system.

A remote site that contains a copy of the data and standby servers.Following a disaster at the master site, the servers at the secondary sitebecome active and start using the copy of the data.

MasterThe volume or storage system which is mirrored. The master volume orstorage system is usually at the master site.

Slave The volume or storage system to which the master is mirrored. The slavevolume or storage system is usually at the Secondary site.

One of the main goals of remote mirroring is to ensure that the secondary sitecontains the same (consistent) data as the master site. With remote mirroring,services are provided seamlessly by the hosts and storage systems at the secondarysite.

The process of ensuring that both storage systems contain identical data at alltimes is called remote mirroring. Remote mirroring is performed during each writeoperation. The write operation issued by a host is sent to both the master and theslave storage systems.


To ensure that the data is also written to the secondary system, acknowledgementof the write operation is only issued after the data has been written to both storagesystems. This ensures the consistency of the secondary storage system to themaster storage system except for the contents of any last, unacknowledged writeoperations. This form of mirroring is called synchronous mirroring.

In a remote mirroring system, reading is performed from the master storagesystem, while writing is performed on both the master and the slave storagesystems, as previously described.

The IBM XIV Storage System supports configurations where server pairs performalternate master or secondary roles with respect to their hosts. As a result, a serverat one site might serve as the master storage system for a specific application,while simultaneously serving as the secondary storage system for anotherapplication.

Remote mirroring operationRemote mirroring operations involve configuration, initialization, ongoing operation,handling of communication failures, and role switching activities.

The following list defines the remote mirroring operation activities:

ConfigurationLocal and remote replication peers are defined by an administrator whospecifies the and secondary volumes. For each coupling, severalconfiguration options can be defined.

InitializationRemote mirroring operations begin with a master volume that containsdata and a formatted slave volume. The first step is to copy the data fromthe master volume to the slave volume. This process is called initialization.Initialization is performed once in the lifetime of a remote mirroringcoupling. After it is performed, both volumes are considered synchronized.

Ongoing OperationAfter the initialization process is complete, remote mirroring is activated.During this activity, all data is written to the master volume and then tothe slave volume. The write operation is complete after anacknowledgement from the slave volume. At any point, the master andslave volumes are identical except for any unacknowledged (pending)writes.

Handling of Communication FailuresFrom time to time the communication between the sites might break down,and it is usually preferable for the primary site to continue its function andto update the secondary site when communication resumes. This process iscalled synchronization.

Role SwitchingWhen needed, a replication peer can change its role from master to slaveor vice versa, either as a result of a disaster at the primary site,maintenance operations, or because of a drill that tests the disasterrecovery procedures.


Configuration optionsThe remote mirroring configuration process involves configuring volumes andvolume pair options.

When a pair of volumes point to each other, it is referred to as a coupling. In acoupling relationship, two volumes participate in a remote mirroring system with theslave peer serving as the backup for the master peer. The coupling configuration isidentical for both master volumes and slave volumes.

“Configuration options” describes the configuration options that are available forvolumes and couplings.

Volume

Role

v Values -– None– Secondary

v Definitions - Role designation of a volume.

Peer

v Values - Remote target identification and the name of thevolume on the remote target.

v Definitions - Identifies the peer volume.

Coupling

Activation

v Values -– Active– Standby

v Definitions - Activates or deactivates remote mirroring.

For more information about configuring volumes and configuring couplings, see“Volume configuration” and “Communication errors” on page 42.

Volume configurationThe role of each volume and its peer volumes on the IBM XIV Storage Systemmust be defined for it to function within the remote mirroring process.

The following concepts are to be configured for volumes and the relations betweenthem:v Volume rolev Peer

The volume role is the current function of the volume. The following volume rolesare available:

None The volume is created using normal volume creation procedures and is notconfigured as part of any remote mirroring configuration.

Master volumeThe volume is part of a mirroring coupling and serves as the mastervolume.

Chapter 8. Synchronous remote mirroring 41

All write operations are made to this master volume. It ensures that writeoperations are made to the slave volume before acknowledging theirsuccess.

Slave volumeThis volume is part of a mirroring coupling and serves as a backup to themaster volume.

Data is read from the slave volume, but cannot be written to it.

A peer is a volume that is part of a coupling. A volume with a role other than nonehas to have a peer designation, and a corresponding master or slave volumeassigned to it.

Configuration errors

In some cases, configuration on both sides might be changed in a non-compatibleway. This is defined as a configuration error. For example, switching the role of onlyone side when communication is down causes a configuration error whenconnection resumes.

Mixed configurationThe volumes on a single storage system can be defined in a mixture ofconfigurations.

For example, a storage system can contain volumes whose role is defined asmaster, as well as volumes whose roles are defined as slave. In addition, somevolumes might not be involved in a remote mirroring coupling at all.

The roles assigned to volumes are transient. This means a volume that is currentlya master volume can be defined as a slave volume and vice versa. The term localrefers to the master volume, and remote refers to the slave volume for processesthat switch the master and slave assignments.

Communication errorsWhen the communication link to the secondary volume fails or the secondaryvolume itself is not usable, processing to the volume continues as usual. Thefollowing occurs:v The system is set to an unsynchronized state.v All changes to the master volume are recorded and then applied to the slave

volume after communication is restored.

Coupling activationRemote mirroring can be manually activated and deactivated per coupling. Whenit is activated, the coupling is in Active mode. When it is deactivated, the couplingis in Standby mode.

These modes have the following functions:

Active Remote mirroring is functioning and the data is being written to both themaster and the slave volumes.

StandbyRemote mirroring is deactivated. The data is not being written to the slavevolume, but it is being recorded in the master volumes which will latersynchronize the slave volume.


In this mode, the administrator cannot deactivate remote mirroring if thecoupling type is Mandatory. Standby mode is used mainly whenmaintenance is performed on the secondary site or during communicationbetween the sites. In this mode, the master volumes do not generate alertsthat the mirroring has failed.

The coupling lifecycle has the following characteristics:v When a coupling is created, it is always initially in Standby mode.v Only a coupling in Standby mode can be deleted.v Transitions between the two states can only be performed from the UI and on

the volume.

Synchronous mirroring statusesThe status of the synchronous remote mirroring volume represents the state of thestorage volume in regard to its remote mirroring operation.

The state of the volume is a function of the status of the communication link andthe status of the coupling between the master volume and the slave volume.Table 4 describes the various statuses of a synchronous remote mirroring volumeduring remote mirroring operations.

Table 4. Synchronous mirroring statuses

Entity Name Values Definition

Link Status v Up

v Down

Specifies if thecommunications link is upor down.


Table 4. Synchronous mirroring statuses (continued)

Entity Name Values Definition

Coupling Operational status v Operational

v Non-operational

Specifies if remotemirroring is working.

Synchronizationstatus

v Initialization

v Synchronized

v Unsynchronized

v Consistent

v Inconsistent

Specifies if the master andslave volumes areconsistent.

Last-secondary-timestamp

Point-in-time date Time stamp for when thesecondary volume waslast synchronized.

Synchronizationprocess progress

Synchronization status Amount of data remainingto be synchronizedbetween the master andslave volumes due tonon-operational coupling.

Secondary locked Boolean True, if secondary waslocked for writing due tolack of space; otherwisefalse. This can happenduring thesynchronization processwhen there is not enoughspace for thelast-consistent snapshot.

Configuration error Boolean True, if the configurationof the master andsecondary slave isinconsistent.

Link statusThe status of the communication link can be either up or down. The link status ofthe master volume is, of course, also the link status of the slave volume.

Operational statusThe coupling between the master and slave volumes is either operational ornon-operational. To be operational, the link status must be up and the coupling mustbe activated. If the link is down or if the remote mirroring feature is in Standbymode, the operational status is non-operational.

Synchronization statusThe synchronization status reflects the consistency of the data between the masterand slave volumes. Because the purpose of the remote mirroring feature is toensure that the slave volume is an identical copy of the master volume, this statusindicates whether this objective is currently attained.

“Synchronization status” describes the possible synchronization statuses for themaster volume.

InitializationThe first step in remote mirroring is to create a copy of the data from the


master volume to the slave volume, at the time when the mirroring was setto place. During this step, the coupling status remains initialization.

Synchronized (master volume only)This status indicates that all data that was written to the primary volumeand acknowledged has also been written to the secondary volume. Ideally,the primary and secondary volumes should always be synchronized. Thisdoes not imply that the two volumes are identical because at any time,there might be a limited amount of data that was written to one volume,but was not yet written to its peer volume. This means that their writeoperations have not yet been acknowledged. These are also known aspending writes.

Unsynchronized (primary volume only)

After a volume has completed the initialization stage and achieved thesynchronized status, a volume can become unsynchronized.This occurs when it is not known whether all the data that was written tothe primary volume was also written to the secondary volume. This statusoccurs in the following cases:v Communications link is down - As a result of the communication link

going down, some data might have been written to the primary volume,but was not yet written to the secondary volume.

v Secondary system is down - This is similar to communication linkerrors because in this state, the primary system is updated while thesecondary system is not.

v Remote mirroring is deactivated - As a result of the remote mirroringdeactivation, some data might have been written to the primary volumeand not to the secondary volume.

It is always possible to reestablish the synchronized status when the link isreestablished or the remote mirroring feature is reactivated, no matter what wasthe reason for the unsynchronized status.

Because all updates to the primary volume that are not written to the secondaryvolume are recorded, these updates are written to the secondary volume. Thesynchronization status remains unsynchronized from the time that the coupling isnot operational until the synchronization process is completed successfully.

Synchronization progress statusDuring the synchronization process while the secondary volumes are beingupdated with previously written data, the volumes have a dynamicsynchronization process status.

This status is comprised of the following sub-statuses:

Size to completeThe size of data that requires synchronization.

Part to synchronizeThe size to synchronize divided by the maximum size-to-synchronize sincethe last time the synchronization process started. For couplinginitialization, the size-to-synchronize is divided by the volume size.

Time to synchronizeEstimate of the time, which is required to complete the Synchronizationprocess and achieve synchronization, based on past rate.


Last secondary time stampA time stamp is taken when the coupling between the primary and secondaryvolumes becomes non-operational.

This time stamp specifies the last time that the secondary volume was consistentwith the primary volume. This status has no meaning if the coupling’ssynchronization state is still initialization. For synchronized coupling, thistimestamp specifies the current time. Most importantly, for an unsynchronizedcoupling, this timestamp denotes the time when the coupling becamenon-operational.

The timestamp is returned to current only after the coupling is operational and theprimary and secondary volumes are synchronized.

I/O operationsI/O operations are performed on the primary and secondary volumes acrossvarious configuration options.

I/O on the primary

“I/O operations” describes I/O operations on the primary volume.

Read All data is read from the primary (local) site regardless of whether thesystem is synchronized.

Write Applies to both the Best-effort and Mandatory coupling types.v If the coupling is operational, data is written to both the primary and

secondary volumes.v If the coupling is non-operational, an error is returned.

The error reflects the type of problem that was encountered. For example,remote mirroring has been deactivated, there is a locked secondary error,or there is a link error.

I/O on the secondary

A secondary volume can have LUN maps and hosts associated with it, but it isonly accessible as a read-only volume. These maps are used by the backup hostswhen a switchover is performed. When the secondary volume becomes theprimary volume, hosts can write to it on the remote site. When the primaryvolume becomes a secondary volume, it becomes read-only and can be updatedonly by the new primary volume. “I/O operations” describes I/O operations onthe secondary volume.

Read Data is read from the secondary volume like from any other volume.

Write Applies to both the Best-effort and Mandatory coupling types. An attemptto write on the secondary volume results in a volume read-only SCSI error.

Synchronization processWhen a failure condition has been resolved, remote mirroring begins the process ofsynchronizing the coupling. This process updates the secondary volume with allthe changes that occurred while the coupling was not operational.

This section describes the process of synchronization.


State diagramCouplings can be in the Initialization, Synchronized, Timestamp, or Unsychronizedstate.

The following diagram, “State diagram” shows the various coupling states that theIBM XIV Storage System assumes during its lifetime, along with the actions thatare performed in each state.

The following list describes each coupling state:

InitializationThe secondary volume has a Synchronization status of Initialization.During this state, data from the primary volume is copied to the secondaryvolume.

SynchronizedThis is the working state of the coupling, where both the primary andsecondary volumes are consistent.

TimestampRemote mirroring has become non-operational so a time stamp is recorded.During this status, the following actions take place:1. Coupling deactivation, or the link is down2. Coupling is reactivated, or the link is restored.

UnsynchronizedRemote mirroring is non-operational because of a communications failureor because remote mirroring was deactivated. Therefore, the primary andsecondary volumes are not synchronized. When remote mirroring resumes,steps are taken to return to the Synchronized state.

Mandatory couplingThe synchronization process is not relevant for a system that is set to Mandatorymode. Systems set to Mandatory mode have their entire storage processing halted

Figure 13. Coupling states and actions


with errors when the secondary volume becomes unavailable. Mandatory modemeans that both the primary and secondary volumes are still synchronized.

Best-effort coupling recoveryRemote mirroring recovers from non-operational coupling.

When remote mirroring recovers from a non-operational coupling, the followingactions take place:v If the secondary volume is in the Synchronized state, a last-consistent snapshot

of the secondary volume is created and named with the stringsecondary-volume-time-date-consistent-state.

v The primary volume updates the secondary volume until it reaches theSynchronized state.

v The primary volume deletes the special snapshot after all couplings that mirrorvolumes between the same pair of systems are synchronized.

Uncommitted dataWhen the coupling is in an Unsynchronized state, for Best-effort coupling, thesystem must track which data in the primary volume has been changed, so thatthese changes can be committed to the secondary when the coupling becomesoperational again.

The parts of the primary volume that must be committed to the secondary volumeand must be marked are called uncommitted data.

Note: There is only metadata that marks the parts of the primary volume thatmust be written to the secondary volume when the coupling becomes operational.

Constraints and limitationsCoupling has constraints and limitations.

The following constraints and limitations exist:v The Size, Part, or Time-to-synchronize are relevant only if the Synchronization

status is Unsynchronized.v The last-secondary-time stamp is only relevant if the coupling is

Unsynchronized.

Last-consistent snapshotsBefore the synchronization process is initiated, a snapshot of the secondary volumeis created. A snapshot is created to ensure the usability of the secondary volume incase of a primary site disaster during the synchronization process.

If the primary volume is destroyed before synchronization is completed, thesecondary volume might be inconsistent because it might have been only partiallyupdated with the changes that were made to the primary volume. The reason for apossible inconsistency is the fact that the updates were not necessarily performedin the same order in which they were written by the hosts.

To handle this situation, the primary volume always creates a snapshot of thelast-consistent secondary volume after re-connecting to the secondary machine, andbefore starting the synchronization process.v No snapshot is created for couplings that are in the initialization state.


v The last consistent snapshot of all secondary volumes that have primaryvolumes on the same system are created on the same time and data consistencybetween them is ensured.

v The last-consistent snapshots are deleted after all the couplings on the systemwhich use the same system for secondary volume are synchronized. This isperformed in order to properly handle situations where there are datadependencies between the volumes.

Support considerationsv Only the XIV support team can delete the last consistent snapshot. The XIV

support team uses the delete_mirror_snapshots CLI command.v The XIV support team can also configure a mirroring so that it does not create

the last consistent snapshot. This is required when the system that contains thesecondary volume is fully utilized and an additional snapshot cannot be created.

Last consistent snapshot timestampA timestamp is taken when the coupling between the primary and secondaryvolumes becomes non-operational. This timestamp specifies the last time that thesecondary volume was consistent with the primary volume.

This status has no meaning if the coupling type is Mandatory, or if the coupling’ssynchronization state is still Initialization. For synchronized couplings, thistimestamp specifies the current time. Most importantly, for unsynchronizedcouplings, this timestamp denotes the time when the coupling becamenon-operational.

Table 5 provides an example of a failure situation and describes the time specifiedby the timestamp.

Table 5. Example of the last consistent snapshot time stamp process

Time Status of coupling Action Last consistenttimestamp

Up to 12:00 Operational andsynchronized

Current

12:00 - 1:00 Failure caused thecoupling to becomenon-operational. Thecoupling isUnsynchronized.

Writing continues to the primaryvolume. Changes are marked so thatthey can be committed later.

12:00

13:00 Connectivity resumes andremote mirroring isoperational.Synchronization begins.The coupling is stillUnsynchronized.

All changes since the connection wasbroken are committed to thesecondary volume, as well as currentwrite operations.

12:00

13:15 Synchronized Current

Secondary locked error statusWhile the synchronization process is in progress, there is a period in which thesecondary volume is not consistent with the primary volume, and a last-consistentsnapshot is maintained. While in this state, I/O operations to the secondaryvolume can fail because there is not enough space. There is not enough spacebecause every I/O operation potentially requires a copy-on-write of a partition.


Whenever I/O operations fail because there is not enough space, all couplings inthe system are set to the secondary-locked status and the coupling becomesnon-operational. The administrator is notified of a critical event, and can free spaceon the system containing the secondary volume.

If this situation occurs, contact an IBM XIV field engineer. After there is enoughspace, I/O operations resume and remote mirroring can be reactivated.

Role switchover

Role switchover when remote mirroring is operationalRole switching between primary and secondary volumes can be performed fromthe IBM XIV Storage System GUI or the XCLI after the remote mirroring functionis operational. After role switchover occurs, the primary volume becomes thesecondary volume and vice versa.

There are two typical reasons for performing a switchover when communicationsbetween the volumes exist. These are:

Drills Drills can be performed on a regular basis to test the functioning of thesecondary site. In a drill, an administrator simulates a disaster and teststhat all procedures are operating smoothly.

Scheduled maintenanceTo perform maintenance at the primary site, switch operations to thesecondary site on the day before the maintenance. This can be done as apreemptive measure when a primary site problem is known to occur.

This switchover is performed as an automatic operation acting on the primaryvolume. This switchover cannot be performed if the primary and secondaryvolumes are not synchronized.

Role switchover when remote mirroring is nonoperationalA more complex situation for role switching is when there is no communicationbetween the two sites, either because of a network malfunction, or because theprimary site is no longer operational. The XCLI command for this scenario isreverse_role. Because there is no communication between the two sites, thecommand must be issued on both sites concurrently, or at least beforecommunication resumes.

Switchover procedures differ depending on whether the primary and secondaryvolumes are connected or not. As a general rule, the following is true:v When the coupling is deactivated, it is possible to change the role on one side

only, assuming that the other side will be changed as well before communicationresumes.

v If the coupling is activated, but is either unsynchronized, or nonoperational dueto a link error, an administrator must either wait for the coupling to besynchronized, or deactivate the coupling.

v On the secondary volume, an administrator can change the role even if couplingis active. It is assumed that the coupling will be deactivated on the primaryvolume and the role switch will be performed there as well in parallel. If not, aconfiguration error occurs.


Switch secondary to primaryThe role of the secondary volume can be switched to primary using the IBM XIVStorage System GUI or the XCLI. After this switchover, the following is true:v The secondary volume is now the primary.v The coupling has the status of unsynchronized.v The coupling remains in standby mode, meaning that the remote mirroring is

deactivated. This ensures an orderly activation when the role of the other site isswitched.

The new primary volume starts to accept write commands from local hosts.Because coupling is not active, in the same way as any primary volume, itmaintains a log of which write operations should be sent to the secondary whencommunication resumes.

Typically, after switching the secondary to the primary volume, an administratoralso switches the primary to the secondary volume, at least before communicationresumes. If both volumes are left with the same role, a configuration error occurs.

Secondary consistencyIf the user is switching the secondary to a primary volume, and a snapshot of thelast-consistent state exists, then the link was broken during the process ofsynchronizing. In this case, the user has a choice between using the most-updatedversion, which might be inconsistent, or reverting to the last_consistent snapshot.Table 6 outlines this process.

Table 6. Disaster scenario leading to a secondary consistency decision

Time Status of remote mirroring Action

Up to 12:00 Operational Volume A is the primary volume and volume Bis the secondary volume.

12:00 Nonoperational because ofcommunications failure

Writing continues to volume A and volume Amaintains the log of changes to be committedto volume B.

13:00 Connectivity resumes andremote mirroring is operational.

A last_consistent snapshot is generated onvolume B. After that, volume A starts to updatevolume B with the write operations thatoccurred since communication was broken.

13:05 Primary site is destroyed and allinformation is lost.

13:10 Volume B is becoming the primary. Theoperators can choose between using themost-updated version of volume B, whichcontains only parts of the write operationscommitted to volume A between 12:00 and13:00, or use the last-consistent snapshot,which reflects the state of volume B at 12:00.

If a last-consistent snapshot exists and the role is changed from secondary toprimary, the system automatically generates a snapshot of the volume. Thissnapshot is named most_updated snapshot. It is generated to enable a safe reversionto the latest version of the volume, when recovering from user errors. Thissnapshot can only be deleted by the IBM XIV Storage System support team.

If the coupling is still in the initialization state, switching cannot be performed. Inthe extreme case where the data is needed even though the initial copy was notcompleted, a volume copy can be used on the primary volume.


Switch primary to a secondaryWhen coupling is inactive, the primary machine can switch roles. After such aswitch, the primary volume becomes the secondary one.

Unsynchronized primary becoming a secondary

Because the primary volume is inactive, it is also in the unsynchronized state, andit might have an uncommitted data list. All these changes will be lost. When thevolume becomes secondary, this data must be reverted to match the data on thepeer volume, which is now the new primary volume. In this case, an event iscreated, summarizing the size of the changes that were lost.

The uncommitted data list has now switched its semantics, and instead of being alist of updates that the local volume (old primary, new secondary) needs to updateon the remote volume (old secondary, new primary), the list now represents theupdates that need to be taken from the remote to the local volume.

Upon reestablishing the connection, the local volume (current secondary, whichwas the primary) will update the remote volume (new primary) with thisuncommitted data list to update, and it is the responsibility of the new primaryvolume to synchronize these lists to the local volume (new secondary).

Resumption of remote mirroring after role changeWhen the communication link is resumed after a switchover of roles in which bothsides were switched, the coupling now contains one secondary and one primaryvolume. See “Reconnection when both sides have the same role” on page 53 forthe description of the behavior of the system if there is a user error and both sideshave the same role.

Note: After a role switchover, the coupling is in standby. The coupling can beactivated before or after the link resumes.

Table 7 describes the system when the coupling becomes operational, meaning afterthe communications link has been resumed and the coupling has been reactivated.When communications is resumed, the new primary volume (old secondary) mightbe in the unsynchronized state, and have an uncommitted data list to synchronize.

The new secondary volume (old primary), might have an uncommitted data list tosynchronize from the new primary volume. These are write operations that werewritten after the link was broken and before the role of the volume was switchedfrom primary to secondary. These changes must be reverted to the content of thenew primary volume. Both lists must be used for synchronization by the newprimary volume.

Table 7. Resolution of uncommitted data for synchronization of the new primary volume

Time Status of remotemirroring

Action

Up to12:00

Operational andsynchronized

Volume A is the primary volume and volume B is thesecondary volume.

12:00 to12:30

Communication failure,coupling becomesnonoperational

Volume A still accepts write operations from the hosts andmaintains an uncommitted data list marking these writeoperations. For example, volume A accepted a write operationto blocks 1000 through 2000, and marks blocks 1000 through2000 as ones that need to be copied to volume B afterreconnection.


Table 7. Resolution of uncommitted data for synchronization of the new primaryvolume (continued)

Time Status of remotemirroring

Action

12:30 Roles changed on bothsides

Volume A is now secondary and volume B is primary. VolumeA should now revert the changes done between 12:00 and 12:30to their original values. This data reversion is only performedafter the two systems reconnect. For now, volume A reverts thesemantics of the uncommitted data list to be data that needs tobe copied from volume B. For example, blocks 1000 through2000 need to be copied now from volume B.

12:30 to13:00

Volume B is primary,volume A is secondary,coupling isnonoperational

Volume A does not accept changes because it is a secondary ina nonoperational coupling. volume B is now a primary in anonoperational coupling, and maintains its own uncommitteddata list of the write operations that were performed since itwas defined as the primary. For example, if the hosts wroteblocks 1500 through 2500, volume B marks these blocks to becopied to volume A.

13:00 Connectivity resumes Volume B and volume A communicate and volume B mergesthe lists of uncommitted data. Volume B copies to volume Aboth the blocks that changed in volume B between 12:30 and13:00, as well as the blocks that changed in volume A between12:00 and 12:30. For example, volume B could copy to volumeA blocks 1000 through 2500, where blocks 1000 through 1500would revert to their original values at 12:00 and blocks 1500through 2500 would have the values written to volume Bbetween 12:30 and 13:00. Changes written to volume Abetween 12:00 and 12:30 are lost.

Reconnection when both sides have the same roleSituations where both sides are configured to the same role can only occur whenone side was switched while the link was down. This is a user error, and the usermust follow these guidelines to prevent such a situation:v Both sides need to change roles before the link is resumed.v As a safety measure, it is recommended to first switch the primary to secondary.

If the link is resumed and both sides have the same role, the coupling will notbecome operational.

To solve the problem, the user must use the role switching mechanism on one ofthe volumes and then activate the coupling.

In this situation, the system behaves as follows:v If both sides are configured as secondary volumes, a minor error is issued.v If both sides are configured as primary volumes, a critical error is issued. Both

volumes will be updated locally with remote mirroring being nonoperationaluntil the condition is solved.

Miscellaneous

Remote mirroring and consistency groupsRemote mirroring is fully detached from consistency groups. The followingassumptions ensure that consistency group procedures are compatible with theremote mirroring function:


v All volumes in a consistency group are mirrored on the same system (as allprimaries on a system are mirrored on the same system).

v The last_consistent snapshot is created and deleted system-wide, and therefore itis consistent across the consistency group.

Note: An administrator can incorrectly switch the roles of some of the volumes ina consistency group, while keeping others in their original role. This is notprevented by the system and is detected at the application level.

Using remote mirroring for media error recoveryIf a media error is discovered on one of the volumes of the coupling, the peervolume is then used for a recovery.

Supported configurationsv Either fibre-channel or iSCSI can serve as the protocol between the primary and

secondary volumes. A volume accessed through one protocol can besynchronized using another protocol.

v The remote system must be defined as an XIV Storage System in theremote-target connectivity definitions.

v All the peers of volumes that belong to the same consistency group on a systemmust reside on a single remote system.

v Primary and secondary volumes must contain the same number of blocks.

I/O performance versus synchronization speed optimizationThe IBM XIV Storage System has two global parameters, controlling the maximumrate used for initial synchronization and for synchronization after nonoperationalcoupling.

These rates are used to prevent a situation where synchronization uses too many ofthe system or communication line resources.

This configuration parameter can be changed at any time. These parameters are setby the IBM XIV Storage System technical support representative.

Implications regarding other commandsv Renaming a volume changes the name of the last_consistent and most_updated

snapshots.v Deleting all snapshots does not delete the last_consistent and most_updated

snapshot.v Resizing a primary volume resizes its secondary volume.v A primary volume cannot be resized when the link is down.v Resizing, deleting, and formatting are not permitted on a secondary volume.v A primary volume cannot be formatted. If a primary volume must be formatted,

an administrator must first deactivate the mirroring, delete the mirroring, formatboth the secondary and primary volumes, and then define the mirroring again.

v Secondary or primary volumes cannot be the target of a copy operation.v Locking and unlocking are not permitted on a secondary volume.v Last_consistent and most_updated snapshots cannot be unlocked.v Deleting is not permitted on a primary volume.v Restoring from a snapshot is not permitted on a primary volume.


v Restoring from a snapshot is not permitted on a secondary volume.v A snapshot cannot be created with the same name as the last_consistent or

most_updated snapshot.


Chapter 9. IP and Ethernet connectivity

The following topics provide a basic explanation of the various Ethernet ports andIP interfaces that can be defined and various configurations that are possiblewithin the IBM XIV Storage System.

The IBM XIV Storage System IP connectivity provides:v iSCSI services over IP or Ethernet networksv Management communication

Ethernet ports

The following three types of Ethernet ports are available:

iSCSI service portsThese ports are used for iSCSI over IP or Ethernet services. A fullyequipped rack is configured with six Ethernet ports for iSCSI service.These ports should connect to the user’s IP network and provideconnectivity to the iSCSI hosts. The iSCSI ports can also acceptmanagement connections.

Management portsThese ports are dedicated for IBM XIV Command Line Interface (XCLI)and IBM XIV Storage System GUI communications, as well as being usedfor outgoing SNMP and SMTP connections. A fully equipped rack containsthree management ports.

Field technician portsThese ports are used for incoming management traffic only (usage is bothXCLI and IBM XIV Storage System GUI access). The ports are utilized onlyfor the field technician’s laptop computer and must not be connected to theuser’s IP network.

IP and Ethernet connectivity

External system communication is performed through the patch panel. The orderof the ports included in the patch panel are shown in Figure 14 on page 58, andoutlined in Table 8 on page 58.


Table 8. Detailed patch panel layout

Function,label, or both

From(See Note 1.)

Position(port number) Comment

Fibre channel(See Note 2.)

Module 9Module 8Module 7Module 6Module 5Module 4

1 - 32 - 4

Ports providing connectivity for fibre-channel communications.The fibre-channel connectivity arrangement is the same for allmodules (module 9 through module 4).

In a partial rack configuration of six modules, only thefibre-channel ports for modules 5 and 6 are active.

iSCSI Module 9 1 Ports providing iSCSI connectivity.

In a partial rack configuration of six modules, none of the iSCSIports is active.

Module 9 2

Module 8 1

Module 8 2

Module 7 1

Module 7 2

Management Module 6 1 Ports providing both IBM XIV Command Line Interface (XCLI)and IBM XIV Storage System GUI based interface access, aswell as both SNMP and SMTP connectivity.

Module 5 1

Module 4 1

VPN Module 6 1 Ports providing communication to a virtual private network(VPN).Module 4 1

Figure 14. Patch panel layout


Table 8. Detailed patch panel layout (continued)

Function,label, or both

From(See Note 1.)

Position(port number) Comment

Laptop Module 5 1 Ports for the field service technician to connect a laptop. Thisport is used for XCLI and IBM XIV Storage System GUIcommunication only.Module 4 1

Maintenance Module 1 Ports that provide connections to the maintenance module.

Reserved N/A 1 Reserved for future use.

N/A 1 Reserved for future use.

Notes:

1. Not applicable (N/A)

2. The fibre channel label does not actually appear on the patch panel. It is only used in this table to indicate theposition of the fibre-channel ports.

Note: Modem cables are plugged directly into the modem.

iSCSI connections

iSCSI ports are connected through the customer’s IP or Ethernet network to iSCSIhosts. iSCSI ports are used when performing the following functions:v As an iSCSI target serves hosts through the iSCSI protocolv As an iSCSI initiator for remote mirroring when connected to anotherv As an iSCSI initiator for data migration when connected to a third party iSCSI

storage systemv As XCLI and IBM XIV Storage System GUI access over the iSCSI ports

iSCSI definitions

iSCSI ports can be defined according to the following criteria:v Each iSCSI port can be defined as an IP interface.v Groups of Ethernet iSCSI ports on the same module can be defined as a single

link aggregation group (IEEE standard: 802.3ad), provided that they meet thefollowing criteria:– Ports defined as a link aggregation group must be connected to the same

Ethernet switch, and a parallel link aggregation group must be defined onthat Ethernet switch.

– Although a single port is defined as a link aggregation group of one, the IBMXIV Storage System support representative can override this configuration ifsuch a setup is not operable with the customer Ethernet switches.

v The following configuration options are listed for each iSCSI IP interface:– IP address (mandatory)– Network mask (mandatory)– Default gateway (optional)– MTU

Default1,536

Maximum8,192

Chapter 9. IP and Ethernet connectivity 59

Management connectivity

Management connectivity is used for the following functions:v Executing XCLI commands through the IBM XIV Command Line Interface

(XCLI)v Controlling the IBM XIV Storage System through the IBM XIV Storage System

GUIv Sending e-mail notification messages and SNMP traps about event alerts

To ensure management redundancy in case of module failure, the IBM XIV StorageSystem management function is accessible from three different IP addresses. Eachof the three IP addresses is handled by a different hardware module. The variousIP addresses are transparent to the user and management functions can beperformed through any of the IP addresses. These addresses can be accessedsimultaneously by multiple clients. Users only need to configure the IBM XIVStorage System GUI or XCLI for the set of IP addresses that are defined for thespecific system.

Note: All management IP interfaces must be connected to the same subnet and usethe same network mask, gateway, and MTU.

XCLI and IBM XIV Storage System GUI management

The IBM XIV Storage System management connectivity system allows users tomanage the system from both the XCLI and IBM XIV Storage System GUI.Accordingly, the XCLI and IBM XIV Storage System GUI can be configured tomanage the system through iSCSI IP interfaces. Both XCLI and IBM XIV StorageSystem GUI management is run over TCP port 7778. With all traffic encryptedthrough the Secure Sockets Layer (SSL) protocol.

System-initiated IP communication

The IBM XIV Storage System can also initiate IP communications to send eventalerts as necessary. Two types of system-initiated IP communications exist:

Sending e-mail notifications through the SMTP protocolE-mails are used for both e-mail notifications and for SMS notificationsthrough the SMTP to SMS gateways.

Sending SNMP traps

Note: SMPT and SNMP communications can be initiated from any of thethree IP addresses. This is different from XCLI and IBM XIV StorageSystem GUI, which are user initiated. Accordingly, it is important toconfigure all three IP interfaces and to verify that they have networkconnectivity.

Field technician ports

The IBM XIV Storage System supports two Ethernet ports. These ports arededicated for the following reasons:v Field technician usev Initial system configuration


v Direct connection for service staff when they can not connect to customernetwork

v Directly manage the IBM XIV Storage System through a laptop computer

Laptop connectivity - configuring using DHCP

Two field technician ports are provided for redundancy purposes. This ensures thatfield technicians will always be able to connect a laptop to the IBM XIV StorageSystem. These two ports use a Dynamic Host Configuration Protocol (DHCP)server. The DHCP server will automatically assign IP addresses to the user’s laptopand connects the laptop to the IBM XIV Storage System network. A laptopconnected to any of the field technician ports is assigned an IP address and theIBM XIV Storage System GUI or IBM XIV Command Line Interface (XCLI) willtypically use the predefined configuration direct-technician-port.

Note: The two field technician laptop ports are used only to connect directly to theIBM XIV Storage System and should never be connected to the customer’snetwork.

Laptop connectivity - configuring without DHCP

If the technician’s laptop is not setup to receive automatic IP configurationinformation through DHCP, the laptop should be defined using these parameters:

IP address:14.10.202.1

Netmask:255.255.255.0

Gateway:none

MTU:1536

The field technician ports accept both XCLI and IBM XIV Storage System GUIcommunications. SNMP and SMTP alerts are not sent through these ports.

Note: Each of the field technician ports is connected to a different module.Therefore, if a module fails, the port will become inoperative. When this happens,the laptop should be connected to the second port. See “IP and Ethernetconnectivity” on page 57 for descriptions of the ports on each module.

Configuration guidelines summary

When shipped, the IBM XIV Storage System does not have any IP managementconfigurations. Accordingly, the following procedures should be performed whenfirst setting up the system:v Connecting a laptop to one of the field technician laptop ports on the patch

panelv Configuring at least one management IP interfacev Continuing the configuration process from either the technician port or from the

configured IP interface

Chapter 9. IP and Ethernet connectivity 61

Note: It is important to define all three management IP interfaces and to testoutgoing SNMP and SMTP connections from all three interfaces. The dest_testcommand can be used to test outgoing notifications on a specific module.


Chapter 10. Data migration

The use of any new storage system frequently requires the transfer of largeamounts of data from the previous storage system to the new IBM XIV StorageSystem. This can require many hours or even days; usually an amount of time thatmost enterprises cannot afford to be without a working system. The data migrationfeature enables production to be maintained while data transfer is in progress.

Given the nature of the data migration process, it is recommended that you consultand rely on the IBM XIV Storage System support team when planning a datamigration.

Data migration overviewThe data migration feature enables the smooth transition of a host working withthe previous storage system to an IBM XIV Storage System by:v Immediately connecting the host to the XIV Storage System and providing the

host with direct access to the most up-to-date data even before data has beencopied from the previous storage system.

v Synchronizing the XIV Storage System from the previous storage system bytransparently copying the contents of the previous storage system to the XIVStorage System as a background process.

During data migration, the host is connected directly to the XIV Storage Systemand is disconnected from the previous storage system. The XIV Storage System isconnected to the previous storage system, as shown in Figure 15. The XIV StorageSystem and the previous storage system must remain connected, until both storagesystems are synchronized and data migration is completed. The previous storagesystem perceives the XIV Storage System as a host, reading from and optionallywriting to the volume that is being migrated. The host reads and writes data to theXIV Storage System, while the XIV Storage System might need to read or write thedata to the previous storage system to serve the command of the host.

The communication between the host and the XIV Storage System and thecommunication between the XIV Storage System and the previous storage system

Figure 15. The Data migration process is performed per volume.


can be fibre-channel or iSCSI. Furthermore, they function as two independentsystems and do not have to use the same communication protocol, meaning thatthe communication protocol between the host and the XIV Storage System can bedifferent than the communication protocol between the XIV Storage System andthe previous storage system.

I/O handling in data migrationServing read requests

During this stage the IBM XIV Storage System will serve all the host’s data readrequests. This will be performed in a transparent manner without requiring anyaction by the host, as follows:v If the requested data has already been copied to the XIV Storage System, it is

served from the XIV Storage System.v If the requested data has not yet been copied to the XIV Storage System, the XIV

Storage System will retrieve it from the previous storage system and then serveit to the host.

Serving write requests

During this stage the XIV Storage System will serve all host’s data write requests.This will be performed in a transparent manner without requiring any action bythe host.

Data migration provides the following two alternative XIV Storage Systemconfigurations for handling write requests from a host:

Source updating:A host’s write requests are written by the XIV Storage System to the XIVStorage System, as well as to the previous storage system. In this case, theprevious storage system remains completely updated during thebackground copying process. Throughout the process, the volume of theprevious storage system and the volume of the XIV Storage System areidentical.

Write commands are performed synchronously, so the XIV Storage Systemonly acknowledges the write operation after writing to itself, writing to theprevious storage system, and receiving an acknowledgement from theprevious storage system. Furthermore, if, due to a communication error orany other error, the writing to the previous storage system fails, the XIVStorage System will report to the host that the write operation has failed.

No source updating:A host’s write requests are only written by the XIV Storage System to theXIV Storage System and are not written to the previous storage system. Inthis case, the previous storage system is not updated during thebackground copying process, and therefore the two storage systems willnever be synchronized. The volume of the previous storage system willremain intact and will not be changed throughout the data migrationprocess.


Data migration stagesFigure 16 describes the process of migrating a volume from a previous storagesystem to the IBM XIV Storage System. It also shows how the XIV Storage Systemsynchronizes its data with the previous storage system, and how it handles thedata requests of a host throughout all these stages of synchronization.

Initial configuration

The XIV Storage System volume must be formatted before data migration canbegin. The XIV Storage System must be connected as a host to the previous storagesystem whose data it will be serving.

The volume on the previous storage system and the volume on the XIV StorageSystem must have an equal number of blocks. This is verified upon activation ofthe data migration process.

You can then initiate data migration and configure all hosts to work directly andsolely with the XIV Storage System.

Data migration is defined through the dm_define command.

Testing�the�Data�MigrationConfiguration

Step�1

Step�2

Activating�Data�MigrationStep�3

Allowing Access�by�theTarget�Storage�SystemStep�4

Initial�Configuration

Background�Copying�andServing�I/Os

Synchronization�is AchievedStep�5

Deleting�Data�MigrationStep�6

Figure 16. Data migration steps

Chapter 10. Data migration 65

Testing the data migration configuration

Before connecting the host to the XIV Storage System, use the dm_test XCLIcommand to test the data migration definitions to verify that the XIV StorageSystem can access the previous storage system.

Activating data migration

After you have tested the connection between the XIV Storage System and theprevious storage system, activate data migration using the dm_activate XCLIcommand and connect the host to the XIV Storage System. From this pointforward, the host reads and writes data to the XIV Storage System, and the XIVStorage System will read and optionally write to the previous storage system.

Data migration can be deactivated using the dm_deactivate command. It can thenbe activated again. While the data migration is deactivated, the volume cannot beaccessed by hosts (neither read nor write access).

Background copying and serving I/O operations

Once data migration is initiated, it will start a background process of sequentiallycopying all the data from the previous storage system to the XIV Storage System.

Synchronization is achieved

After all of a volume’s data has been copied, the data migration achievessynchronization. After synchronization is achieved, all read requests are servedfrom the XIV Storage System.

If source updating was set to Yes, the XIV Storage System will continue to writedata to both itself and the previous storage system until data migration settings aredeleted.

Deleting data migration

Data migration is stopped by using a delete command. It cannot be restarted.

Handling failuresUpon a communication error or the failure of the previous storage system, the IBMXIV Storage System will stop serving I/O operations to hosts, including both readand write requests.

If the XIV Storage System encounters a media error on the previous storage system(meaning that the XIV Storage System cannot read a block on the previous storagesystem), then the XIV Storage System will reflect this state on its own storagesystem (meaning that it will mark this same block and an error on its own storagesystem). The state of this block will indicate a media error even though the disk inthe XIV Storage System has not failed.


Chapter 11. Event handling

The IBM XIV Storage System monitors the health, the configuration changes, andthe activity of your storage systems, and generates system events. These events areaccumulated by the system and can help the user in the following two ways:v Users can view past events using various filters. This is useful for

troubleshooting and problem isolation.v Users can configure the system to send one or more notifications, which are

triggered upon the occurrence of specific events. These notifications can befiltered according to the events, severity and code. Notifications can be sentthrough e-mail, SMS messages, or SNMP traps.

Event informationEvents are created by various processes, including the following:v Object creation or deletion, including volume, snapshot, map, host, and storage

poolv Physical component eventsv Network events

Each event contains the following information:v A system-wide unique numeric identifierv A code that identifies the type of the eventv Creation timestampv Severityv Related system objects and components, such as volumes, disks, and modulesv Textual descriptionv Alert flag, where an event is classified as alerting by the event notification rules,

as described in “Defining events notification rules” on page 68v Cleared flag, where alerting events can be either uncleared or cleared. This is

only relevant for alerting events.

Event information can be classified with one of the following severity levels:

CriticalRequires immediate attention

Major Requires attention soon

Minor Requires attention within the normal business working hours

WarningNonurgent attention is required to verify that there is no problem

InformationalNormal working procedure event


Viewing eventsThe IBM XIV Storage System provides a the following variety of criteria fordisplaying a list of events:v Before timestampv After timestampv Codev Severity from a certain value and upv Alerting events, meaning events that are sent repeatedly according to a snooze

timerv Uncleared alerts

The number of displayed filtered events can be restricted.

Defining events notification rulesThe IBM XIV Storage System monitors the health, configuration changes, andactivity of your storage systems and sends notifications of system events as theyoccur. Event notifications are sent according to the following rules:

Which eventsThe severity, event code, or both, of the events for which notification issent.

Where The destinations or destination groups to which notification is sent, such ascellular phone numbers (SMS), e-mail addresses, and SNMP addresses.

Notifications are sent according to the following rules:

DestinationThe destinations or destination groups to which a notification of an eventis sent. Destinations are described in “Defining destinations” on page 69.

Filter A filter that specifies which events will trigger the sending of an eventnotification. Notification can be filtered by event code, minimum severity(from a certain severity and up), or both.

AlertingTo ensure that an event was indeed received, an event notification can besent repeatedly until it is cleared by an XCLI command or the IBM XIVStorage System GUI. Such events are called alerting events. Alerting eventsare events for which a snooze time period is defined in minutes. Thismeans that an alerting event is resent repeatedly each snooze time intervaluntil it is cleared. An alerting event is uncleared when it is first triggered,and can be cleared by the user. The cleared state does not imply that theproblem has been solved. It only implies that the event has been noted bythe relevant person who takes the responsibility for fixing the problem.There are two schemes for repeating the notifications until the event isclear: snooze and escalation.

SnoozeEvents that match this rule send repeated notifications to the samedestinations at intervals specified by the snooze timer until they arecleared.

EscalationYou can define an escalation rule and escalation timer, so that if events arenot cleared by the time that the timer expires, notifications are sent to the


predetermined destination. This enables the automatic sending ofnotifications to a wider distribution list if the event has not been cleared.

Alerting events configuration limitationsThe following limitations apply to the configuration of alerting rules:v Rules cannot escalate to nonalerting rules, meaning to rules without escalation,

snooze, or both.v Escalation time should not be defined as shorter than snooze time.v Escalation rules must not create a loop (cycle escalation) by escalating to itself or

to another rule that escalates to it.v The configuration of alerting rules cannot be changed while there are still

uncleared alerting events.

Defining destinationsEvent notifications can be sent to one or more destinations, meaning to a specificSMS cell number, e-mail address, or SNMP address, or to a destination groupcomprised of multiple destinations. Each of the following destinations must bedefined as described:

SMS destination

An SMS destination is defined by specifying a phone number. When defining adestination, the prefix and phone number should be separated because some SMSgateways require special handling of the prefix.

By default, all SMS gateways can be used. A specific SMS destination can belimited to be sent through only a subset of the SMS gateways.

E-mail destination

An e-mail destination is defined by an e-mail address. By default, all SMTPgateways are used. A specific destination can be limited to be sent through only asubset of the SMTP gateways.

SNMP managers

An SNMP manager destination is specified by the IP address of the SNMPmanager that is available to receive SNMP messages.

Destination groups

A destination group is simply a list of destinations to which event notifications canbe sent. A destination group can be comprised of SMS cell numbers, e-mailaddresses, SNMP addresses, or any combination of the three. A destination groupis useful when the same list of notifications is used for multiple rules.

Defining gatewaysEvent notifications can be sent by SMS, e-mail, or SNMP manager. This stepdefines the gateways that will be used to send e-mail or SMS.

Chapter 11. Event handling 69

E-mail (SMTP) gateways

Several e-mail gateways can be defined to enable notification of events by e-mail.By default, the IBM XIV Storage System attempts to send each e-mail notificationthrough the first available gateway according to the order that you specify.Subsequent gateways are only attempted if the first attempted gateway returns anerror. A specific e-mail destination can also be defined to use only specificgateways.

All event notifications sent by e-mail specify a sender whose address can beconfigured. This sender address must be a valid address for the following tworeasons:v Many SMTP gateways require a valid sender address or they will not forward

the e-mail.v The sender address is used as the destination for error messages generated by

the SMTP gateways, such as an incorrect e-mail address or full e-mail mailbox.

E-mail-to-SMS gateways

SMS messages can be sent to cell phones through one of a list of e-mail-to-SMSgateways. One or more gateways can be defined for each SMS destination.

Each such e-mail-to-SMS gateway can have its own SMTP server, use the globalSMTP server list, or both.

When an event notification is sent, one of the SMS gateways is used according tothe defined order. The first gateway is used, and subsequent gateways are onlytried if the first attempted gateway returns an error.

Each SMS gateway has its own definitions of how to encode the SMS message inthe e-mail message.


Chapter 12. Access control

The IBM XIV Storage System features role-based authentication either natively orby using LDAP-based authentication. The system provides:

Role-based access controlBuilt-in roles for access flexibility and a high level of security according topredefined roles and associated tasks.

Two methods of access authenticationThe IBM XIV Storage System supports the following methods ofauthenticating users:

Native authenticationThis is the default mode for authentication of users and groups onthe IBM XIV Storage System. In this mode, users and groups areauthenticated against a database on the system.

LDAP When enabled, authenticates the users against an LDAP repository.

User roles and permission levelsUser roles allow specifying which roles are applied and the various applicablelimits. Table 9 describes the currently available roles, their level of access andtypical use.

Note: None of these system-defined users have access to data.

Table 9. Available user roles

User role Permissions and limits Typical usage

Read only Read only users can only list andview system information.

The system operator, typically, butnot exclusively, is responsible formonitoring system status andreporting and logging allmessages.


Table 9. Available user roles (continued)

User role Permissions and limits Typical usage

Applicationadministrator

Only application administratorscan perform the following tasks:

v Creating snapshots ofspecifically assigned volumes

v Mapping their own snapshot toa specifically assigned host

v Deleting their own snapshot

Application administratorstypically manage applications thatrun on a particular server.Application managers can bedefined as limited to specificvolumes on the server. Typicalapplication administratorfunctions are the following:

v Managing backupenvironments:

– Creating a snapshot forbackups

– Mapping a snapshot tobackup server

– Deleting a snapshot afterbackup is complete

– Updating a snapshot for newcontent within a volume

v Managing software testingenvironment:

– Creating a new applicationinstance

– Testing the new applicationinstance

Storageadministrator

The storage administrator haspermission to perform allfunctions, except:

v Maintenance of physicalcomponents or changing thestatus of physical components

v Only the predefinedadministrator, named admin,can change the passwords ofother users

Storage administrators areresponsible for all administrationfunctions.

Technician The technician is limited to thefollowing tasks:

v Physical system maintenance

v Phasing components in or outof service

Technicians maintain the physicalcomponents of the system. Onlyone predefined technician isspecified per system. Techniciansare IBM XIV Storage Systemtechnical support team members.

Notes:

1. All users can view the status of physical components; however, onlytechnicians can modify the status of components.

2. User names are case sensitive.3. Passwords are case sensitive.

Predefined usersThere are several predefined users configured on the IBM XIV Storage System.These users cannot be deleted.


Storage administratorThis user id provides the highest level of customer access to the system.

Predefined user name: admin

Default password: adminadmin

TechnicianThis user id is used only by IBM XIV Storage System service personnel.

Predefined user name: technician

Default password: Password is predefined and is used only by the IBMXIV Storage System technicians.

smis_userThis user has read-only permissions and is used to provide access for IBMTivoli TPC and TSM software. If you change the password of this user id,you will need to engage IBM XIV support to restore interoperability withTivoli-TPC and TSM.

Note: Predefined users are always authenticated by the IBM XIV Storage System,even if LDAP authentication has been activated for these users.

Application administratorThe primary task of the application administrator is to create and managesnapshots. Application administrators manage snapshots of a specific set ofvolumes. The user group to which an application administrator belongs determinesthe set of volumes which the application administrator is allowed to manage.

User groupsA user group is a group of application administrators who share the same set ofsnapshot creation permissions. This enables a simple update of the permissions ofall the users in the user group by a single command. The permissions are enforcedby associating the user groups with hosts or clusters. User groups have thefollowing characteristics:v Only users who are defined as application administrators can be assigned to a

group.v A user can belong to only a single user group.v A user group can contain up to eight users.v If a user group is defined with access_all=″yes″, application administrators who

are members of that group can manage all volumes on the system.

Storage administrators create the user groups and control the various permissionsof the application administrators.

User group and host associationsHosts and clusters can be associated with only a single user group. When a userbelongs to a user group that is associated with a host, it is possible to managesnapshots of the volumes mapped to that host. See “Command conditions” onpage 74 for additional information about commands for application administrators.User and host associations have the following properties:v User groups can be associated with both hosts and clusters. This enables limiting

application administrator access to specific volumes.

Chapter 12. Access control 73

v A host that is part of a cluster cannot also be associated with a user group.v When a host is added to a cluster, the associations of that host are broken.

Limitations on the management of volumes mapped to the host is controlled bythe association of the cluster.

v When a host is removed from a cluster, the associations of that host become theassociations of the cluster. This enables continued mapping of operations so thatall scripts will continue to work.

Listing hostsThe command host_list lists all groups associated with the specified host,showing information about the following fields:

Range All hosts, specific host

DefaultAll hosts

Listing clustersThe command cluster_list lists all clusters that are associated with a usergroup, showing information about the following fields:

Range All clusters, specific cluster

DefaultAll clusters

Command conditionsThe application administrator can perform specific operations through a set ofcommands. Many of the commands are condition-dependent. Table 10 lists thevarious commands that application administrators can execute according toassociation definitions and applicable conditions. If the application administrator isa member of a group defined with access_all="yes", then it is possible to performthe command on all volumes.

Table 10. Application administrator commands

Relevant command Conditions

cg_snapshot_create At least one volume in the consistency group is mappedto a host or cluster that is associated with a user groupcontaining the user executing the command.

map_volunmap_vol

Application administrators can use these commands tomap snapshots of volumes that meet both of thefollowing conditions:

1. The volumes were created by an applicationadministrator.

2. The master volume is mapped to a host or clusterassociated with a user group containing the user.

vol_locksnapshot_duplicatesnapshot_deletesnapshot_change_priority

The snapshot master volume is mapped to a host orcluster that is associated with the user group containingthe user and the snapshot that was created by anapplication administrator.

snap_group_locksnap_group_duplicatesnap_group_deletesnap_group_change_priority

At least one of the master volumes of the snapshots inthis group is mapped to a host or cluster that isassociated with the user group containing the user, andthe specific snapshot group was created by anapplication administrator.


Table 10. Application administrator commands (continued)

Relevant command Conditions

snapshot_create The volume is mapped to a host or cluster that isassociated with the user group containing the userexecuting the command. If the command overwrites asnapshot, then the overwritten snapshot must be onepreviously created by an application administrator.

Authentication methodsThe following authentication methods are available:

Native (default)The user is authenticated by the IBM XIV Storage System based on thesubmitted username and password, which are compared to user credentialsdefined and stored on the IBM XIV Storage System.

The user must be associated with an IBM XIV Storage System user rolethat specifies pertinent system access rights.

This mode is set by default.

LDAP

The user is authenticated by an LDAP directory based on the submittedusername and password, which are used to connect with the LDAP server.

Note: See the LDAP section for details.

Predefined users authenticationThe administrator, technician and smis_user roles are always authenticatedby the IBM XIV Storage System, regardless of the authentication mode.They are never authenticated by LDAP.

Native authenticationThis is the default mode for authentication of users and groups on the IBM XIVStorage System. In this mode, users and groups are authenticated against adatabase on the system. User management is performed locally on the IBM XIVStorage System.

User configurationConfiguring users requires defining the following options:

Role Specifies the role category that each user has when operating the system.The role category is mandatory. See Table 9 on page 71 in “User roles andpermission levels” on page 71 for explanations of each role.

Name Specifies the name of each user allowed to access the system.

PasswordAll user-definable passwords are case sensitive.Passwords are mandatory, can be 6 to 12 characters long, use uppercase orlowercase letters as well as the following characters: ~!@#$%^&*()_+-={}|:;<>?,./\[] .

E-mail E-mail is used to notify specific users about events through e-mailmessages. E-mail addresses must follow standard addressing procedures.E-mail is optional. Range: Any legal e-mail address.


Phone and area codePhone numbers are used to send SMS messages to notify specific usersabout events. Phone numbers and area codes can be a maximum of 63digits, hyphens (-) and periods (.) Range: Any legal telephone number; Thedefault is N/A

Password managementPassword management is very straightforward in the IBM XIV Software System.The IBM XIV Software System provides a high level of security. The followingrestrictions apply when working with passwords:v For security purposes, passwords are not shown in user lists.v Passwords are user changeable. Users can change only their own passwords.v A user with the predefined password of admin can change the passwords of

other users.v Passwords are changeable from both the XCLI and the IBM XIV Storage System

GUI.v Passwords are case-sensitive.

Range: 6 - 12 characters (a - z, A - Z, 0 - 9)

LDAP-authenticationLightweight Directory Access Protocol (LDAP) support enables the IBM XIVStorage System to authenticate users through an LDAP repository. When LDAPauthentication is enabled, the username and password of a user accessing the IBMXIV Storage System (through CLI or GUI) are used by the IBM XIV system to logininto a specified LDAP directory. Upon a successful login, the IBM XIV StorageSystem retrieves the user’s IBM XIV group membership data stored in the LDAPdirectory, and uses that information to associate the user with an IBM XIVadministrative role.

The IBM XIV group membership data is stored in a customer defined,pre-configured attribute on the LDAP directory. This attribute contains stringvalues which are associated with IBM XIV administrative roles. These values mightbe LDAP Group Names, but this not required by the IBM XIV Storage System. Thevalues the attribute contains, and their association with IBM XIV administrativeroles, are also defined by the customer.

The IBM XIV system will support communication with a single LDAP directory ata time. The LDAP directory is specified by the customer. The LDAP authenticationconfiguration will enable specification of multiple LDAP servers that the IBM XIVStorage System may connect to if a given LDAP server is inaccessible.

The predefined XIV administrative IDs “admin”, “technician”, and “smis-user” arealways authenticated by the IBM XIV Storage System, whether or not LDAPauthentication is enabled.

Following are responsibilities and data maintained by the IBM XIV system and theLDAP directory:

LDAP directory

v Responsibilities - user authentication for IBM XIV users, and assignmentof IBM XIV related group in LDAP.

v Maintains - Users, username, password, designated IBM XIV relatedLDAP groups associated with IBM XIV Storage System.

IBM XIV Storage System


v Responsibilities - Determination of appropriate user role by mappingLDAP group to an IBM XIV role, and enforcement of IBM XIV usersystem access.

v Maintains - mapping of LDAP group to IBM XIV role.

Using LDAPIn order to use LDAP authentication, you must perform the following major steps:v Define an LDAP server and system parametersv Identify an LDAP attribute in which to store values associated with IBM XIV

user rolesv Define a mapping between values stored in the LDAP attribute and IBM XIV

user rolesv Enable LDAP authentication

Once LDAP has been configured and enabled, users (other than the predefinedusers) will have login credentials authenticated by the LDAP server, rather thanthe IBM XIV Storage System itself.

LDAP use casesThis section outlines possible use cases for LDAP-enabled access control.

LDAP Configuration ScenarioFollowing is an overview of an LDAP configuration scenario:1. Storage administrator defines the LDAP server(s) to the IBM XIV

storage system.2. Storage administrator defines the LDAP base DN, communication, and

timeout parameters to the IBM XIV storage system.

Figure 17. The XIV Storage System logs on to a specified LDAP directory


3. Storage administrator defines the LDAP XIV group attribute to be usedfor storing associations between LDAP groups and XIV storageadministrator roles for the storage administrator and readonly roles usingthe ldap_config_set command.

4. Storage administrator defines the mapping between LDAP group nameand IBM XIV application administrator roles using theuser_group_create command.

5. Storage administrator enables LDAP authentication.

LDAP Login ScenariosFollowing is an overview of login processes when LDAP authentication isenabled:

GUI Authentication scenario

1. User launches the IBM XIV Storage SystemGUI.2. IBM XIV Storage System presents the user with a login screen.3. User logs in submitting the required user credentials (e.g.,

username and password).4. IBM XIV Storage System attempts to log into LDAP directory

using the user-submitted credentials.5. If login fails, a corresponding error message is returned to the

user.6. If login succeeds, the IBM XIV Storage System will determine

the IBM XIV role corresponding to the logged-in user, byretrieving the user-related attributes from the LDAP directory.These attributes were previously specified by the IBMXIV-to-LDAP mapping.

The XIV system sets a security context for the user sessionand presents a pertinent welcome screen.

CLI Authentication scenario

1. User submits a CLI with user credentials (username andpassword).

2. The IBM XIV Storage System attempts to log into LDAPdirectory using the user-submitted credentials.

3. If login fails, a corresponding error message is returned to theuser.

4. If login succeeds, the IBM XIV Storage System will determinethe IBM XIV Storage System role corresponding to thelogged-in user, by retrieving the user-related attributes from theLDAP directory. These attributes were previously specified bythe IBM XIV-to-LDAP mapping.v The IBM XIV Storage System will inspect whether the user

role is allowed to issue the CLI.v If the CLI is permitted for the user’s role, it will be issued

against the system, and any pertinent response will bepresented to the user.

v If the CLI is not permitted for the user’s role, the IBM XIVStorage System will send an error message to the user.

Switching between LDAP and native authentication modesThis section describes system behavior when switching between LDAPauthentication and native authentication.


After changing authentication modes from native to LDAP

The system will start authenticating users other than ″admin″, ″technician″, or″smis_user″ against the LDAP server, rather than the local IBM XIV storage systemuser database. However, the local user account data will not be deleted:v Users without an account on the LDAP server will not be granted access to the

XIV system.v Users with an LDAP account who are not associated with an XIV role on the

LDAP directory will not be granted access to the XIV system.v Users with an LDAP account who are associated with an XIV role on the LDAP

directory will be granted access to the XIV system if the following conditions aremet:– The XIV role on LDAP is mapped to a valid XIV role on the XIV system– The user is associated only to one XIV role on LDAP

The following commands related to user account management will be disabled.These operations must be performed on the LDAP directory.v user_definev user_renamev user_updatev user_group_add_userv user_group_remove_user

After changing authentication modes from LDAP to native

The system will start authenticating users against the locally defined IBM XIV userdatabase. Users and groups which were defined prior to switching from native toLDAP authentication will be reenabled. The IBM XIV system will allow localmanagement of users and groups. The following commands related to user accountmanagement will be enabled:v user_definev user_renamev user_updatev user_group_add_userv user_group_remove_user

Users must be defined locally on XIV and be associated with local IBM XIV usergroups in order to gain access to the system.

Logging and event reporting

Command execution logThe IBM XIV Software System provides logs for tracking command execution andwho has performed the command. This log is implemented through the event log.

Object creation trackingFor each system object such as a volume, host, snapshot, consistency group, orpool, the system keeps track of the user who executed the command that createdthe object. This is part of the object’s attributes shown in the relevant listcommand.


Event report destinationsThe system provides mechanisms for sending reports to variety of destinations,including:v Telephone numbersv E-mail addresses

The configured e-mail or phone number per user can serve as the destinations forthese notifications. See “User configuration” on page 75 for an explanation ofdestination parameters.

For a detailed explanation about handling events and setting up notification, seeChapter 11, “Event handling,” on page 67.

Access control commandsThe following IBM XIV Command Line Interface (XCLI) commands are availablefor managing role-based access control (RBAC). For a detailed explanation of thesecommands, see the chapter detailing “Access control” in the relevant (for therelease you are using) IBM XIV XCLI User Manual.

You can use the following user-related commands to manage role-based accesscontrol:

user_defineDefines a new user.

user_updateUpdates the attributes of the user.

user_listLists all users, or a specific user.

user_renameRenames the user.

user_deleteDeletes the user.

You can also use the following user group-related commands to manage role-basedaccess control:

user_group_createCreates a user group.

user_group_updateAssigns the user group with a Lightweight Directory Access Protocol (LDAP)role.

user_group_add_userAdds a user to a user group.

user_group_remove_userRemoves a user from a user group.

user_group_listLists all user groups along with their users.

user_group_renameRenames a user group.


user_group_deleteDeletes a user group.

The following list of access-related commands can be used to manage role-basedaccess control:

access_defineAssociates a user group with a host and a cluster.

access_deleteDissociates a user group from the host and cluster with which it is associated.

access_listLists access associations.

You can also use the following LDAP server configuration-related commands:

ldap_config_setConfigures an LDAP server to work with the IBM XIV Storage System.

ldap_config_getLists the configuration attributes of an LDAP server the works with the storagesystem.

ldap_mode_setEnables LDAP authentication to the storage system.

ldap_mode_getReturns the authentication mode of the storage system.

ldap_user_testThis command authenticates the user’s credentials on the LDAP machine.

The following commands are available in non-LDAP mode and are not available inLDAP mode:

user_defineDefining a new user on the XIV system.

user_updateModifying the XIV user’s details.

user_renameRenaming an XIV user.

user_group_add_userAdding a user the an XIV application administrator user group.

user_group_remove_userRemoving a user from an XIV application administration user group.

Glossary of access control conceptsThe following key definitions apply throughout the discussion on role-based accesscontrol:

LDAP Lightweight Directory Access Protocol.

LDAP attributeA property of an LDAP object, with a single or multiple values. A specialobject attribute is designated by an LDAP administrator to hold user groupmemberships values corresponding to XIV Storage System roles.


LDAP authenticationA method for authenticating users by validating the user’s submittedcredentials against data stored on an LDAP directory.

LDAP DirectoryA hierarchical database stored on an LDAP server and accessed throughLDAP calls.

LDAP ServerA server that provides directory services through LDAP.

LDAP statusThe status of an LDAP server.

Microsoft® Active DirectoryMicrosoft Active Directory provides a directory (lookup), DNS andauthentication services.

XIV MappingAn association of data on the LDAP server (a specific LDAP attribute) anddata on the XIV Storage System. This is required to determine which accessrights to grant to an authenticated LDAP user.


Chapter 13. TPC interoperability

The IBM XIV Storage System integrates with Tivoli Storage Productivity Center(TPC) by providing system configuration information to TPC.

TPC then displays this information to TPC end users. In addition to query support,TPC provides a means to launch the XIV GUI directly from within the TivoliProductivity Center GUI.

Queries of system configuration are supported starting with Tivoli StorageProductivity Center (TPC) version 4.1 and IBM XIV Storage System microcodeversion 10.1. TPC will be allowed to query configuration data including:v Storage poolsv Volumesv Disksv Hosts and host mappingsv Fibre Channel ports

These queries, when combined with SCSI inquiry data TPC collects from the hosts,will allow TPC to correlate LUNs reported by the IBM XIV Storage System toLUNs as seen by the host systems. Also, when the IBM XIV Storage System is aback end to the IBM System Storage SAN Volume controller (SVC), TPC cancorrelate LUNs reported by the IBM XIV Storage System to SVC managed disks(MDisks).

The support for TPC is comprised of a CIM agent which is embedded on the IBMXIV storage system. This agent queries the IBM XIV storage system using thesmis_user ID. The smis_user ID is allowed read only access to the IBM XIV storagesystem.

Figure 18. TPC interoperability with IBM XIV Storage System


The IBM XIV CIM provider will publish itself as a service using the ServiceLocation Protocol (SLP) as a Service Agent (SA). This CIMOM (CommonInformation Model Object Manager) provider broadcasts its address to allow adirectory look-up by a CIM agent, in this case, TPC. This then allows TPC to queryfor the IP address, namespace, and supported profiles for the IBM XIV CIMprovider, thus discovering it.

Although the communication between the CIM agent and TPC is SMIS based, notesting for SMIS compliance other than that required for TPC integration has beendone as of the current release, and SMIS for platforms other than TPC is notsupported.

IBM XIV CLI commands associated with Tivoli include the following:v smis_add_userv smis_list_usersv smis_remove_users

Note that these commands refer to users of the CIM provider, not the base IBMXIV Storage system. So, for example, a user added with smis_add_user would notbe allowed to log into the IBM XIV storage system using the IBM XIV CLI.


Chapter 14. Hot upgrade

Non-disruptive-code-load (previously dubbed Hot Upgrade) enables the IBM XIVStorage System to change the system’s software from a current version to anotherversion without disrupting the application service.

The upgrade process runs on all modules in parallel and is designed to be quickenough so that the applications’ service on the hosts will not be damaged. Theupgrade requires that neither data migration nor rebuild processes are run, andthat all internal network paths are active. Firmware upgrades are not part of thehot-upgrade procedure, and should be run when needed in a module-by-modulefashion (by phasingout each module).


Chapter 15. Other features

The IBM XIV Storage System introduces the following features.

Target Port Group Support (TPGS) support

The IBM XIV Storage Systeml supports for Target Port Group Support – or TPGS,enabling automatic detection of IBM XIV Storage System port configurations andcharacteristics by hosts.

Without TPGS support, manual steps are warranted to configure host-to-systemconnectivity for maximized performance and to accommodate port failurescenarios where a path goes offline. The IBM XIV Storage System can response tohost [INQUIRY and REPORT_TARGET_PORT_GROUPS] requests with details thatenable the host to identify the IBM XIV Storage System ports properly thusenabling automatic performance optimization, and appropriate failover behaviorswith no manual intervention required.

Host specific mapping per volume

Host specific mapping per volume means a specific volume per host in addition tocommon cluster mapping. This feature allows for defining specific volumemappings to hosts within a cluster.

This functionality enables for example to specify that Host H1 that belongs tocluster C1 can have a specific mapping to a LUN not already specified for thecluster.

Such feature facilitates administration of a group of hosts that share most of theirmappings yet require specific additional mappings nonetheless.

Support for thousands of mirrors

The number of supported mirrors has increased from 128 to over 16,000 mirrors,thereby enabling complete mirroring of systems with a large number of volumes.

Data migration for LUN>127 (up to 512)

The number of the LUNs that can be specified by IBM XIV Storage Systemadministrators is increased to 512, up from 127.

Support for 256 pools

The number of pools that are supported by the IBM XIV Storage System is now256.

Object meta-data for CLI scripts and host software

This feature enables definition and removal of metadata for many system objects,including volume, pool, target, and more.


Support center integration

The Support Center facilitates secure and easy remote support for the IBM XIVStorage System at customer sites. The feature covers an ability to define andconfigure an IBM XIV Storage System server dedicated to serve as Support Center.This server is accessible over the Internet, and will accept SSH authenticatedconnections from both machines and support personnel.

Technician event

The new Technician event concerns the creation of a special event in response to adedicated command run by a technician, in order to signal the event center thatthe technician started/finished working on a system and that the events generatedbetween those two events need be treated differently (e.g., ignored).

Retention of fast reservation

The IBM XIV Storage System supports preservation of SCSI reservations afternon-disruptive-code-load.

Challenge response

The IBM XIV Storage System can minimize potential abuse of user accesscredentials by introducing a process that requires the technician to obtain a newkey before making a connection to the system for support purposes.

Cables are regarded to as components

Version 10.1 of XIV introduces a new component type: Ethernet_Cable. Aside fromthe standard component fields, this new component has the following additionalattributes:

currrently_connected_toan ID indicating to which component the cable is currently connected to

should_be_connected_toan ID indicating to which component the cable SHOULD be connected to,based on the configuration

link_statusUP/DOWN - depending on the actual link status

interface_roleindicator of the interface role - currently only Internal interfaces aremapped to components


Glossary

The following is an alphabetical list of terms and abbreviations that are usedthroughout this document.

Active directoryMicrosoft Active Directory (AD) provides directory (lookup), DNS andauthentication services.

Alerting eventAn event that triggers recurring event notifications until it is cleared.

API See Application program interface (API).

Application program interface (API)The interface through which the application accesses the operating systemand the other services.

Authorization levelThe authorization level determines the permitted access level to thevarious functions of the IBM XIV Storage System GUI:

Read onlyOnly viewing is allowed.

Full Enables access to all the configuration and control functions,including shutdown of the system. This level requires a password.

Auto delete priorityAs the storage capacity reaches its limits, snapshots are automaticallydeleted to make more space. The deletion takes place according to thevalue set for each snapshot, as follows:

1 last to be deleted

4 first to be deleted

Each snapshot is given a default auto delete priority of 1 at creation.

Best effort modeA mode of remote mirroring in which I/O operation is not suspendedwhen communication between a primary and secondary volume is broken.

Clearing eventsThe process of stopping the recurring event notification of alerting events.

CLI The IBM XIV Command Line Interface (XCLI). See Command line interface(CLI)

Command line interface (CLI)The nongraphical user interface used to interact with the system throughset commands and functions. The IBM XIV Command Line Interface(XCLI) for the IBM XIV Storage System.

Completion codeThe returned message sent as a result of running CLI commands.

Consistency groupA cluster of specific volumes that can all be snapshotted simultaneously asa group, thus creating a synchronized snapshot. The volumes in aconsistency group are grouped into a single volume set. The volume set


can be snapshotted into multiple snapshot sets under the specificconsistency group. See also Snapshot set, Volume set.

CouplingA primary volume and a secondary volume connected together throughmirroring definitions.

Data moduleA module dedicated to data storage. A fully-configured rack contains 9dedicated data modules, each with 12 disks.

Default storage poolThe default storage pool when a volume is created.

DestinationSee Event destination.

EscalationA process in which event notifications are sent to a wider list of eventdestinations because the event was not cleared within a certain time.

Event destinationAn address for sending event notifications.

Event notification ruleA rule that determines which users are to be notified, for which events andby what means.

Event notificationThe process of notifying a user about an event.

Event A user or system activity that is logged (with an appropriate message).

Fabric The hardware that connects workstations and servers to storage devices ina SAN. The SAN fabric enables any-server-to-any-storage deviceconnectivity through the use of fibre-channel switching technology.

FC-AL Also known as arbitrated loop. A fibre-channel topology that requires nofibre-channel switches. Devices are connected in a one-way loop fashion.

FC-HBAFibre-channel host bus adapter.

FC See Fibre channel.

Fibre channelSerial data transfer architecture developed by a consortium of computerand mass storage device manufacturers and now being standardized byANSI.

Functional areaOne of the high level groupings of icons (functional modules) of theleft-hand pane of the IBM XIV Storage System GUI screen. For example:Monitor, Configuration or Volume management. See Functional module.

Functional moduleOne of the icons of a functional area, on the left-hand pane of the IBM XIVStorage System GUI screen. For example, System (under Monitor) or Hostsand LUNs (under Configuration). See Functional area.

Graphical user interface (GUI)On-screen user interface supported by a mouse and a keyboard.

GUI See Graphical user interface (GUI).


H/W Hardware.

HBA Host bus adapter.

Host interface moduleThe interface data module serves external host requests with the ability tostore data. A fully-configured rack has 6 interface data modules.

Host A host is a port name of a host that can connect to the system. The systemsupports fibre channel and iSCSI hosts.

I/O Input/output.

Image snapshotA snapshot that has never been unlocked. It is the exact image of themaster volume it was copied from, at the time of its creation. See alsosnapshot.

Internet ProtocolSpecifies the format of packets (also called datagrams), and theiraddressing schemes. See also Transmission Control Protocol (TCP).

IOPs Input/output (I/O) per second.

IP See Internet Protocol.

iSCSI Internet SCSI. An IP-based standard for linking data storage devices over anetwork and transferring data by carrying SCSI commands over IPnetworks.

LatencyAmount of time delay between the moment an operation is issued, and themoment it is committed.

LDAP Lightweight Directory Access Protocol.

LDAP attributeA special object attribute is designated by an LDAP administrator to holduser group memberships values corresponding to XIV Storage Systemroles.

LDAP authenticationA method for authenticating users by validating the user’s submittedcredentials against data stored on an LDAP directory.

LDAP directoryA hierarchical database stored on an LDAP server and accessed throughLDAP calls.

LDAP serverA server that provides directory services through LDAP.

LDAP statusThe status of an LDAP server.

Load balancingEven distribution of load across all components of the system.

LockingSetting a volume (or snapshot) as unwritable (read-only).

LUN mapA table showing the mappings of the volumes to the LUNs.

LUN Logical unit number. Exports a systems volume into a registered host.

Glossary 91

Mandatory modeA mode of remote mirroring in which I/O operation stops whenever thereis no communication to the secondary volume.

Master volumeA volume that has snapshots is called the master volume of its snapshots.

MIB Management information base. A database of objects that can be monitoredby a network management system. SNMP managers use standardized MIBformats to monitor SNMP agents.

Microsoft Active directorySee Active Directory

Mirror volumeA volume that contains a backup copy of the original volume.

MirroringSee Remote mirroring.

Modified StateA snapshot state. A snapshot in modified state can never be used forrestoring its master volume.

MultipathingEnables host interface modules direct access to any volume.

Peer Denotes a constituent side of a coupling. Whenever a coupling is defined,a designation is specified for each peer - one peer is designated primaryand the other is designated secondary.

Pool See Storage pool.

Primary volumeA volume that is mirrored for backup on a remote storage system.

Rack The cabinet that stores all of the hardware components of the system.

Remote mirroringThe process of replicating a volume on a remote system.

Remote target connectivityA definition of connectivity between a port set of a remote target and amodule on the local storage system.

Remote targetAn additional storage system used for mirroring, data migration, and soon.

Role Denotes the actual role that the peer is fulfilling as a result of a specificcondition, either a master or a slave.

Rule See Event notification rule.

SAN Storage area network.

SCSI Small computer system interface.

Secondary volumeA volume that serves as a backup of a primary volume.

SMS gatewayAn external server that is used to send SMSs.


SMTP gatewayAn external host that is used to relay e-mail messages through the SMTPprotocol.

Snapshot setThe resulting set of synchronized snapshots of a volume set in aconsistency group. See also Consistency group, Volume set.

SnapshotA point-in-time snapshot or copy of a volume. See also Image snapshot.

SNMP agentA device that reports information through the SNMP protocol to SNMPmanagers.

SNMP managerA host that collects information from SNMP agents through the SNMPprotocol.

SNMP trapAn SNMP message sent from the SNMP agent to the SNMP manager,where the sending is initiated by the SNMP agent and not as a response toa message sent from the SNMP manager.

SNMPSimple Network Monitor Protocol. A protocol for monitoring networkdevices. See also MIB, SNMP agent, SNMP manager, SNMP trap.

SnoozeThe process of sending recurring event notifications until the events arecleared.

Storage poolA reserved area of virtual disk space serving the storage requirements ofthe volumes.

SynchronizationThe process of making the primary volume and secondary volumeidentical after a communication down time or upon the initialization of themirroring.

Target See Remote target.

TCP/IPSee Transmission Control Protocol, Internet Protocol.

Thin provisioningThin provisioning provides the ability to define logical volume sizes thatare much larger than the physical capacity installed on the system.

Transmission Control ProtocolTransmission Control Protocol (TCP) on top of the Internet Protocol (IP)establishes a virtual connection between a destination and a source overwhich streams of data can be exchanged. See also IP.

Trap See SNMP trap.

Unassociated volumeA volume that is not associated with a consistency group. See Consistencygroup.

Uninterruptible power supplyThe uninterruptible power supply provides battery backup power for a

Glossary 93

determined period of time, particularly to enable the system to powerdown in a controlled manner, on the occurrence of a lengthy power outage.

Volume cloningCreating a snapshot from a volume.

Volume setA cluster of specific volumes in a consistency group, which can all besnapshotted simultaneously, thus, creating a synchronized snapshot of allof them. The volume set can be snapshotted into multiple snapshot sets ofthe specific consistency group. See also Snapshot set, Volume set.

VolumeA discrete unit of storage on disk, tape or other data recording mediumthat supports some form of identifier and parameter list, such as a volumelabel or input/output control.

A volume is a logical address space, having its data content stored on thesystems disk drives. A volume can be virtually any size as long as the totalallocated storage space of all volumes does not exceed the net capacity ofthe system. A volume can be exported to an attached host through a LUN.A volume can be exported to multiple hosts simultaneously. See alsoStorage pool, Unassociated volume.

WWPNWorld Wide Port Name

XCLI IBM XIV Command Line Interface (XCLI) command set. See Command lineinterface.

XDRP The disaster recovery program for the XIV Storage System – The remotemirror feature of the XIV Storage System.

XIV mappingAn association of data on the LDAP server (a specific LDAP attribute) anddata on the XIV Storage System. This is required to determine the accessrights that should be granted to an authenticated LDAP user.


Safety and environmental notices

This section contains information about:v Safety notices and labelsv Laser safetyv Rack safetyv Product recycling and disposalv Battery return programv Fire suppression systems

Safety notices and labels

When using this product, observe the danger, caution, and attention noticescontained in this guide. The notices are accompanied by symbols that represent theseverity of the safety condition.

The following sections define each type of safety notice and provide examples.

The following notices and statements are used in IBM documents. They are listedbelow in order of increasing severity of potential hazards. Follow the links formore detailed descriptions and examples of the danger, caution, and attentionnotices in the sections that follow.v Note: These notices provide important tips, guidance, or advice.v “Attention notices” on page 97: These notices indicate potential damage to

programs, devices, or data.v “Caution notices” on page 97: These statements indicate situations that can be

potentially hazardous to you.v “Danger notices”: These statements indicate situations that can be potentially

lethal or extremely hazardous to you. Safety labels are also attached directly toproducts to warn of these situations.

v In addition to these notices, “Labels” on page 96 may be attached to the productto warn of potential hazards.

Danger notices

A danger notice calls attention to a situation that is potentially lethal or extremelyhazardous to people. A lightning bolt symbol accompanies a danger notice torepresent a dangerous electrical condition. A sample danger notice follows.

DANGER

An electrical outlet that is not correctly wired could placehazardous voltage on metal parts of the system or the devices thatattach to the system. It is the responsibility of the customer toensure that the outlet is correctly wired and grounded to preventan electrical shock.


A comprehensive danger notice provides instructions on how to avoid shockhazards when servicing equipment. Unless instructed otherwise, follow theprocedures in the following danger notice.

DANGER

Electrical voltage and current from power, telephone, andcommunication cables are hazardous.

To avoid a shock hazard:

v Do not connect or disconnect any cables or perform installation,maintenance, or reconfiguration of this product during anelectrical storm.

v Connect all power cords to a properly wired and groundedelectrical outlet. Ensure outlet supplies proper voltage and phaserotation according to the system rating plate.

v Connect any equipment that will be attached to this product toproperly wired outlets.

v When possible, use one hand only to connect or disconnectsignal cables.

v Never turn on any equipment when there is evidence of fire,water, or structural damage.

v Disconnect the attached power cords, telecommunicationssystems, networks, and modems before you open the devicecovers, unless instructed otherwise in the installation andconfiguration procedures.

v Connect and disconnect cables as described below wheninstalling, moving, or opening covers on this product or attacheddevices.

To Disconnect:

1. Turn everything OFF (unless instructed otherwise).

2. Remove power cords from the outlet.

3. Remove signal cables from connectors.

4. Remove all cables from devices.

To Connect:

1. Turn everything OFF (unless instructed otherwise).

2. Attach all cables to devices.

3. Attach signal cables to connectors.

4. Attach power cords to outlet.

5. Turn device ON.

Labels

As an added precaution, safety labels are often installed directly on products orproduct components to warn of potential hazards.


The actual product safety labels might differ from these sample safety labels:

DANGER

Hazardous voltage, current, or energy levels are presentinside any component that has this label attached.

Do not service, there are no serviceable parts.

DANGER

Multiple power cords

To remove all power to the device, disconnect all power cords.

Caution notices

A caution notice calls attention to a situation that is potentially hazardous topeople because of some existing condition. A caution notice can be accompaniedby different symbols, as shown in the examples in Table 11.

Table 11. Caution notice symbols

If the symbol is... It means...

A hazardous electrical condition with less severity thanelectrical danger.

A generally hazardous condition not represented by othersafety symbols.

A hazardous condition due to the use of a laser in theproduct. Laser symbols are always accompanied by theclassification of the laser as defined by the U. S.Department of Health and Human Services (for example,Class I, Class II, and so forth).

Sample caution notices:

CAUTION:This product is equipped with a 3–wire (two conductors and ground)power cable and plug. Use this power cable with a properly groundedelectrical outlet to avoid electrical shock.

CAUTION:Data processing environments can contain equipment transmitting onsystem links with laser modules that operate at greater than Class 1power levels. For this reason, never look into the end of an opticalfiber cable or open receptacle.

Attention notices

An attention notice indicates the possibility of damage to a program, device, orsystem, or to data. An exclamation point symbol may accompany an attention

Safety and environmental notices 97

notice, but is not required. A sample attention notice follows:

Attention: Do not bend a fibre cable to a radius less than 5 cm (2inches); you can damage the cable. Tie wraps are not recommended foroptical cables because they can be easily overtightened, causing damageto the cable.

Laser safety

When using an NVRAM5 or NVRAM6 cluster media converter, the storage systemmust be installed in a restricted access location.

CAUTION:This product contains a Class 1M laser. Do not view directly with opticalinstruments. (C028)

This equipment contains Class 1 laser products, and complies with FDA radiationPerformance Standards, 21 CFR Subchapter J and the international laser safetystandard IEC 825-2.

CAUTION:Data processing environments can contain equipment transmitting onsystem links with laser modules that operate at greater than Class 1 powerlevels. For this reason, never look into the end of an optical fiber cable oropen receptacle.

Attention: In the United States, use only SFP or GBIC optical transceivers thatcomply with the FDA radiation performance standards, 21 CFR Subchapter J.Internationally, use only SFP or GBIC optical transceivers that comply with IECstandard 825–1. Optical products that do not comply with these standards mayproduce light that is hazardous to the eyes.

Usage restrictions

The optical ports of the modules must be terminated with an optical connector orwith a dust plug.


Rack safety

Rack installation

DANGER

v Always lower the leveling pads on the rack cabinet.

v Always install stabilizer brackets on the rack cabinet.

v To avoid hazardous conditions due to uneven mechanicalloading, always install the heaviest devices in the bottom of therack cabinet. Always install servers and optional devices startingfrom the bottom of the rack cabinets.

v Rack-mounted devices are not to be used as a shelf or workspace. Do not place any object on top of rack-mounted devices.

v Each rack cabinet might have more than one power cord. Besure to disconnect all power cords in the rack cabinet beforeservicing any device in the rack cabinet.

v Connect all devices installed in a rack cabinet to power devicesinstalled in the same rack cabinet. Do not plug a power cordfrom a device installed in one rack cabinet into a power deviceinstalled in a different rack cabinet.

CAUTION:

v Do not install a unit in a rack where the internal rack ambienttemperatures will exceed the manufacturer’s recommended ambienttemperature for all your rack-mounted devices.

v Do not install a unit in a rack where the air flow is compromised.Ensure that air flow is not blocked or reduced on any side, front, orback of a unit used for air flow through the unit.

v Consideration should be given to the connection of the equipmentto the supply circuit so that overloading of the circuits does notcompromise the supply wiring or overcurrent protection.

v To provide the correct power connection to a rack, refer to therating labels located on the equipment in the rack to determine thetotal power requirement of the supply circuit.

v This drawer is a fixed drawer and should not be moved forservicing unless specified by manufacturer. Attempting to move thedrawer partially or completely out of the rack may cause the rack tobecome unstable or cause the drawer to fall out of the rack.


Rack relocation (19″ rack)

CAUTION:Removing components from the upper positions in the rack cabinet improvesrack stability during relocation. Follow these general guidelines whenever yourelocate a populated rack cabinet within a room or building:

v Reduce the weight of the rack cabinet by removing equipment starting at thetop of the rack cabinet. When possible, restore the rack cabinet to theconfiguration of the rack cabinet as you received it. If this configuration is notknown, you must do the following:

– Remove all devices in the 32U position and above.

– Ensure that the heaviest devices are installed in the bottom of the rackcabinet.

– Ensure that there are no empty U-levels between devices installed in therack cabinet below the 32U level.

– If the rack cabinet you are relocating is part of a suite of rack cabinets,detach the rack cabinet from the suite.

– Inspect the route that you plan to take when moving the rack to eliminatepotential hazards.

– Verify that the route that you choose can support the weight of the loadedrack cabinet. Refer to the documentation that came with your rack cabinetfor the weight of a loaded rack cabinet.

– Verify that all door openings are at least 760 x 2030 mm (30 x 80 in.).

– Ensure that all devices, shelves, drawers, doors, and cables are secure.

– Ensure that the four leveling pads are raised to their highest position.

– Ensure that there is no stabilizer bracket installed on the rack cabinetduring movement.

– Do not use a ramp inclined at more than ten degrees.

– Once the rack cabinet is in the new location, do the following:

- Lower the four leveling pads.

- Install stabilizer brackets on the rack cabinet.

- If you removed any devices from the rack cabinet, repopulate the rackcabinet from the lowest position to the highest position.

– If a long distance relocation is required, restore the rack cabinet to theconfiguration of the rack cabinet as you received it. Pack the rack cabinet inthe original packaging material, or equivalent. Also, lower the levelingpads to raise the casters off of the pallet and bolt the rack cabinet to thepallet.

For additional information, refer to the documentation for your rack cabinet.

Product recycling and disposal

This unit must be recycled or discarded according to applicable local and nationalregulations. IBM encourages owners of information technology (IT) equipment toresponsibly recycle their equipment when it is no longer needed. IBM offers avariety of product return programs and services in several countries to assistequipment owners in recycling their IT products. Information on IBM productrecycling offerings can be found on IBM’s Internet site at: www.ibm.com/ibm/environment/products/index.shtml


http://www.ibm.com/ibm/environment/products/index.shtml


Esta unidad debe reciclarse o desecharse de acuerdo con lo establecido en lanormativa nacional o local aplicable. IBM recomienda a los propietarios de equiposde tecnología de la informacion (TI) que reciclen responsablemente sus equiposcuando éstos ya no les sean utiles. IBM dispone de una serie de programas yservicios de devolucion de productos en varios países, a fin de ayudar a lospropietarios de equipos a reciclar sus productos de TI. Se puede encontrarinformacion sobre las ofertas de reciclado de productos de IBM en el sitio web deIBM

www.ibm.com/ibm/environment/products/index.shtml.

Notice: This mark applies only to countries within the European Union (EU) andNorway.

Appliances are labelled in accordance with European Directive 2002/96/ECconcerning waste electrical and electronic equipment (WEEE). The Directivedetermines the framework for the return and recycling of used appliances asapplicable throughout the European Union. This label is applied to variousproducts to indicate that the product is not to be thrown away, but ratherreclaimed upon end of life per this Directive.

Remarque: Cette marque s’applique uniquement aux pays de l’Union Européenneet à la Norvège.

L’etiquette du système respecte la Directive européenne 2002/96/EC en matière deDéchets des Equipements Electriques et Electroniques (DEEE), qui détermine lesdispositions de retour et de recyclage applicables aux systèmes utilisés à traversl’Union européenne. Conformément à la directive, ladite étiquette précise que leproduit sur lequel elle est apposée ne doit pas être jeté mais être récupéré en fin devie.

In accordance with the European WEEE Directive, electrical and electronicequipment (EEE) is to be collected separately and to be reused, recycled, orrecovered at end of life. Users of EEE with the WEEE marking per Annex IV of theWEEE Directive, as shown above, must not dispose of end of life EEE as unsortedmunicipal waste, but use the collection framework available to customers for thereturn, recycling and recovery of WEEE. Customer participation is important tominimize any potential effects of EEE on the environment and human health dueto the potential presence of hazardous substances in EEE. For proper collection andtreatment, contact your local IBM representative.



Battery return program

This product may contain a sealed lead acid, nickel cadmium, nickel metalhydride, lithium, or lithium ion battery. Consult your user manual or servicemanual for specific battery information. The battery must be recycled or disposedof properly. Recycling facilities may not be available in your area. For informationon disposal of batteries outside the United States, go to www.ibm.com/ibm/environment/products/batteryrecycle.shtml or contact your local waste disposalfacility.

In the United States, IBM has established a return process for reuse, recycling, orproper disposal of used IBM sealed lead acid, nickel cadmium, nickel metalhydride, and other battery packs from IBM Equipment. For information on properdisposal of these batteries, contact IBM at 1-800-426-4333. Please have the IBM partnumber listed on the battery available prior to your call.

For Taiwan:

Please recycle batteries.

For the European Union:

Notice: This mark applies only to countries within the European Union (EU).

Batteries or packaging for batteries are labeled in accordance with EuropeanDirective 2006/66/EC concerning batteries and accumulators and waste batteriesand accumulators. The Directive determines the framework for the return andrecycling of used batteries and accumulators as applicable throughout theEuropean Union. This label is applied to various batteries to indicate that thebattery is not to be thrown away, but rather reclaimed upon end of life per thisDirective.

Les batteries ou emballages pour batteries sont étiquetés conformément auxdirectives européennes 2006/66/EC, norme relative aux batteries et accumulateursen usage et aux batteries et accumulateurs usés. Les directives déterminent lamarche à suivre en vigueur dans l’Union Européenne pour le retour et le recyclage


http://www.ibm.com/ibm/environment/products/batteryrecycle.shtml

http://www.ibm.com/ibm/environment/products/batteryrecycle.shtml

des batteries et accumulateurs usés. Cette étiquette est appliquée sur diversesbatteries pour indiquer que la batterie ne doit pas être mise au rebut mais plutôtrécupérée en fin de cycle de vie selon cette norme.

In accordance with the European Directive 2006/66/EC, batteries and accumulatorsare labeled to indicate that they are to be collected separately and recycled at endof life. The label on the battery may also include a chemical symbol for the metalconcerned in the battery (Pb for lead, Hg for mercury and Cd for cadmium). Usersof batteries and accumulators must not dispose of batteries and accumulators asunsorted municipal waste, but use the collection framework available to customersfor the return, recycling and treatment of batteries and accumulators. Customerparticipation is important to minimize any potential effects of batteries andaccumulators on the environment and human health due to the potential presenceof hazardous substances. For proper collection and treatment, contact your localIBM representative.

This notice is provided in accordance with Royal Decree 106/2008 of Spain: Theretail price of batteries, accumulators and power cells includes the cost of theenvironmental management of their waste.

For California:

Perchlorate Material - special handling may apply. See www.dtsc.ca.gov/hazardouswaste/perchlorate.

The foregoing notice is provided in accordance with California Code ofRegulations Title 22, Division 4.5 Chapter 33. Best Management Practices forPerchlorate Materials. This product, part or both may include a lithium manganesedioxide battery which contains a perchlorate substance.

Fire suppression systems

A fire suppression system is the responsibility of the customer. The customer’s owninsurance underwriter, local fire marshal, or a local building inspector, or both,should be consulted in selecting a fire suppression system that provides the correctlevel of coverage and protection. IBM designs and manufactures equipment tointernal and external standards that require certain environments for reliableoperation. Because IBM does not test any equipment for compatibility with firesuppression systems, IBM does not make compatibility claims of any kind nordoes IBM provide recommendations on fire suppression systems.


Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document inother countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user’s responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not give youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A.

For license inquiries regarding double-byte character set (DBCS) information,contact the IBM Intellectual Property Department in your country or sendinquiries, in writing, to:

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chome, Minato-kuTokyo 106-0032, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law:INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATIONS “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express orimplied warranties in certain transactions, therefore, this statement may not applyto you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publications. IBM may make improvementsand/or changes in the product(s) and/or program(s) described in this publicationat any time without notice.

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of those Websites. The materials at those Web sites are not part of the materials for this IBMproduct and use of those Web sites is at your own risk.


IBM may use or distribute any of the information you supply in any way itbelieves appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM CorporationAlmaden Research650 Harry RoadBldg 80, D3-304, Department 277San Jose, CA 95120-6099U.S.A.

Such information may be available, subject to appropriate terms and conditions,including in some cases, payment of a fee.

The licensed program described in this document and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement or any equivalent agreementbetween us.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurements may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

This information is for planning purposes only. The information herein is subject tochange before the products described become available.

If you are viewing this information softcopy, the photographs and colorillustrations may not appear.

Notices

This document is confidential and proprietary to IBM XIV.

Contents of this and any related documentation may not be copied or transmittedin any printed or electronic manner or format, or in any other way disclosed toothers, for any purpose other than that for which it is furnished, without the priorwritten consent of IBM Ltd.

Brand names and product names mentioned in this manual may be trademarks orregistered trademarks of their respective companies and are hereby acknowledged.


2009 IBM. All rights reserved. IBM XIV, the XIV logo, and Storage Reinvented aretrademarks of IBM XIV. All other trademarks are the property of their respectiveowners.

June, 2009 Document Revision 10.1.0

IBM Information Systems Corporate Headquarters:

USAXIV Inc.175 Crossing Blvd., Suite 400Framingham, MA 01702Tel: +1-800-4700-XIV (+1-800-470-0948)Fax: +972-3-6959749

IsraelXIV Ltd.1 Azrieli CenterTel Aviv 67021Tel: +972-3-6074672

[email protected]

www.xivstorage.com

Copyrights

Copyright 2009 IBM Corporation. All rights reserved. Printed in the U.S.A.

References in this documentation to IBM products, programs, or services do notimply that IBM intends to make these available in all countries in which IBMoperates. Any reference to an IBM product, program or service is not intended tostate or imply that only IBM’s product, program or service may be used. Anyfunctionally equivalent product, program or service that does not infringe any ofIBM’s intellectual property rights may be used instead of the IBM product,program or service. Evaluation and verification of operation in conjunction withother products, except those expressly designated by IBM, are the user’sresponsibility.

Trademarks

IBM, the IBM logo, and ibm.com® are trademarks or registered trademarks ofInternational Business Machines Corp., registered in many jurisdictions worldwide.Other product and service names might be trademarks of IBM or other companies.A current list of IBM trademarks is available on the Web at “Copyright andtrademark information” at http://www.ibm.com/legal/copytrade.shtml.

Microsoft is a trademark of Microsoft Corporation in the United States, othercountries, or both.

Electronic emission notices

The following statements apply to this product. The statements for other productsintended for use with this product will appear in their accompanying manuals.

Notices 107

http://www.ibm.com/legal/copytrade.shtml

Federal Communications Commission (FCC) Class AStatement

Note: This equipment has been tested and found to comply with the limits for aClass A digital device, pursuant to Part 15 of the FCC Rules. These limits aredesigned to provide reasonable protection against harmful interference when theequipment is operated in a commercial environment. This equipment generates,uses, and can radiate radio frequency energy and, if not installed and used inaccordance with the instruction manual, may cause harmful interference to radiocommunications. Operation of this equipment in a residential area is likely to causeharmful interference, in which case the user will be required to correct theinterference at his own expense.

Properly shielded and grounded cables and connectors must be used in order tomeet FCC emission limits. IBM is not responsible for any radio or televisioninterference caused by using other than recommended cables and connectors or byunauthorized changes or modifications to this equipment. Unauthorized changesor modifications could void the user’s authority to operate the equipment.

This device complies with Part 15 of the FCC Rules. Operation is subject to thefollowing two conditions: (1) this device may not cause harmful interference, and(2) this device must accept any interference received, including interference thatmay cause undesired operation.

Industry Canada Class A Emission Compliance Statement

This Class A digital apparatus complies with Canadian ICES-003.

Avis de conformité à la réglementation d’Industrie Canada

Cet appareil numérique de la classe A est conform à la norme NMB-003 duCanada.

European Union (EU) Electromagnetic Compatibility Directive

This product is in conformity with the protection requirements of EU CouncilDirective 89/336/EEC on the approximation of the laws of the Member Statesrelating to electromagnetic compatibility. IBM cannot accept responsibility for anyfailure to satisfy the protection requirements resulting from a non-recommendedmodification of the product, including the fitting of non-IBM option cards.

This product has been tested and found to comply with the limits for Class AInformation Technology Equipment according to European Standard EN 55022. Thelimits for Class A equipment were derived for commercial and industrialenvironments to provide reasonable protection against interference with licensedcommunication equipment.

Attention: This is a Class A product. In a domestic environment this product maycause radio interference in which case the user may be required to take adequatemeasures.

Properly shielded and grounded cables and connectors must be used in order toreduce the potential for causing interference to radio and TV communications andto other electrical or electronic equipment. Such cables and connectors are available


from IBM authorized dealers. IBM cannot accept responsibility for any interferencecaused by using other than recommended cables and connectors.

European Community contact:IBM Technical RegulationsPascalstr. 100, Stuttgart, Germany 70569Tele: 0049 (0)711 7851176Fax: 0049 (0)711 785 1283e-mail: [email protected]

Australia and New Zealand Class A statement

Attention: This is a Class A product. In a domestic environment this product maycause radio interference in which case the user may be required to take adequatemeasures.

Germany Electromagnetic Compatibility Directive

Deutschsprachiger EU Hinweis:

Hinweis für Gerte der Klasse A EU-Richtlinie zur ElektromagnetischenVertrglichkeit

Dieses Produkt entspricht den Schutzanforderungen der EU-Richtlinie2004/108/EG zur Angleichung der Rechtsvorschriften über die elektromagnetischeVertrglichkeit in den EU-Mitgliedsstaaten und hlt die Grenzwerte der EN 55022Klasse A ein.

Um dieses sicherzustellen, sind die Gerte wie in den Handbüchern beschrieben zuinstallieren und zu betreiben. Des Weiteren dürfen auch nur von der IBMempfohlene Kabel angeschlossen werden. IBM übernimmt keine Verantwortung fürdie Einhaltung der Schutzanforderungen, wenn das Produkt ohne Zustimmung derIBM verndert bzw. wenn Erweiterungskomponenten von Fremdherstellern ohneEmpfehlung der IBM gesteckt/eingebaut werden.

EN 55022 Klasse A Gerte müssen mit folgendem Warnhinweis versehen werden:

″Warnung: Dieses ist eine Einrichtung der Klasse A. Diese Einrichtung kann imWohnbereich Funk-Störungen verursachen; in diesem Fall kann vom Betreiberverlangt werden, angemessene Mabnahmen zu ergreifen und dafüraufzukommen.″

Deutschland: Einhaltung des Gesetzes über die elektromagnetischeVertrglichkeit von Gerten

Dieses Produkt entspricht dem ″Gesetz über die elektromagnetische Vertrglichkeitvon Gerten (EMVG).″ Dies ist die Umsetzung der EU-Richtlinie 2004/108/EG inder Bundesrepublik Deutschland.

Zulassungsbescheinigung laut dem Deutschen Gesetz über dieelektromagnetische Vertrglichkeit von Gerten (EMVG) (bzw. der EMC EGRichtlinie 2004/108/EG) für Gerte der Klasse A

Dieses Gert ist berechtigt, in übereinstimmung mit dem Deutschen EMVG dasEG-Konformittszeichen - CE - zu führen.

Notices 109

Verantwortlich für die Konformittserklrung des EMVG ist die IBM DeutschlandGmbH, 70548 Stuttgart.

Generelle Informationen:

Das Gert erfüllt die Schutzanforderungen nach EN 55024 und EN 55022 KlasseA.

People’s Republic of China Class A Electronic EmissionStatement

Taiwan Class A warning statement

Japan VCCI Class A ITE Electronic Emission Statement

Korean Class A Electronic Emission Statement


Index

Aabout this document

how to send your comments viaccess control

commands 80access_all 74, 75Active mode 42adding ports to remote target 36address, IBM viadvanced host attachment 19alarm notification 7algorithms 5, 7application administrator 71, 73

access_all 74command conditions 74

associationsuser groups and hosts 73

asynchronous mirroring 39asynchronous remote mirroring

role transmission 71attention notice 97authentication

xiv 75auto delete priority 12automatic

recovery from failure 5automatic event notifications 7

Bbackup

continuous 11, 13, 14backups 41bandwidth 1battery return 102Broadband connection 3

CCables as components 87cache

protection 5cache memory 1caching 6Call-home connection 3caution notices 97

definition 97examples 97

CDP (continuous data protection) 13, 14Challenge response 87Class A electronic emission notice 108CLI

management options 4CLI (command line interface) 7CLI management 60clustering

hosts 20command execution log 79commands

fc_connectivity_list 37

commands (continued)host attachment 20, 22ipinterface_run_traceroute 37target_connectivity_activate 37target_connectivity_deactivate 37target_connectivity_define 37target_connectivity_delete 37target_connectivity_list 37

comments, how to send vicomponent

redundancy 5components, hardware 1configuration

multi-rack 7configuration guidelines summary 61connectivity 19consistency group 9, 28

creating 25consistency groups 7

and remote mirroring 53overview 25restore 28restoring 25snapshots 26, 27

continuous backup 11, 13, 14Copy-on-Write (COW) 11, 13, 14coupling

activation 42constraints and limitations 48definition 41last consistent snapshot

timestamp 49last-consistent snapshots 48mandatory 48modes 42states 47types 42uncommitted data 48

COW (Copy-on-Write) 11, 13, 14creating

consistency group 25

Ddanger notices 95

definition 95example 95

Data (Cache) modules 1data migration 35

deleting 65failures 66I/O handling 64overview 63read requests 64stages

activating 65initial configuration 65synchronization 65testing 65

write requests 64Data migration 87

Data mirroring 5Data module 1data virtualization 5, 7defining gateways 69destination groups 69destinations

defining 69e-mail 69SMS 69

diagnostics 7disaster recovery 39disaster recovery types 39, 40disposal 100

Ee-mail (SMTP) gateways 69e-mail destination 69e-mail notifications 4e-mail-to-SMS gateways 69electronic emission notices

Australia and New Zealand Class Astatement 109

European Union EMC Directiveconformance statement 108

Federal Communications Commission(FCC) statement 108

Industry Canada Class A emissioncompliance statement 108

Japanese Voluntary Control Councilfor Interference (VCCI)statement 110

Korean Class A warningstatement 110

People’s Republic of China Class Awarning statement 110

Taiwanese Class A warningstatement 110

environmentalnotices 95

error code protection 5Ethernet connectivity 57Ethernet ports 57

field technician ports 57iSCSI service ports 57management ports 57

eventhandling 67information 67notification rules 68viewing 68

event notifications 7event report destinations 80external replication mechanisms 7

Ffailover process 5fc_connectivity_list 37FCC Class A notice 108


features and functionality 1fibre-channel connectivity 57field technician ports

Ethernet ports 60laptop connectivity

configuring using DHCP 60configuring without DHCP 60

fire suppression 103form, reader comment viFull Volume Copy 17

Ggateways

defining 69e-mail (SMTP) 69e-mail-to-SMS 69

global spare storage 5glossary 89groups, destination 69GUI

management options 4GUI (graphic user interface) 7GUI management 60

Hhard capacity, depletion 31hardware components 1HBA 19host

clustering 20host connectivity 19Host Interface module 1Host specific mapping per volume 87host system attachment 19hosts

associations 73hot upgrade 85how to send your comments vi

II/O 19I/O operations 46IBM

address viimage snapshots

duplicating 15initialization

synchronization status 44installation

rack 99intelligent caching 6interfaces

supported 3IP communication, system-initiated 60IP connectivity 57IP connectivity, guidelines summary 61ipinterface_run_traceroute 37iSCSI connectivity 57iSCSI ports

definition criteria 57functionalities 57

Llabels, safety 96laser safety 98last secondary timestamp 46LDAP

authentication 75, 76use cases 77, 78

link statussynchronous mirroring statuses 44

load balancing 6logical unit numbers 19

Mmanagement connectivity 60management options 4managers, SNMP 69mapping, LUN, 19master site 39master volumes 10mechanisms

self-healing 5mirroring

data 5remote 39

Modem 3modes

Active 42Standby 42

moduledata 1Host Interface 1UPS 1

modulescache 5

multi-rack configuration 7multipathing 7

NNon-disruptive code load 85nonvolatile disk media 5notices 105

attention 97caution 97danger 95electronic emission 108FCC, Class A 108safety and environmental 95types 95

notificationse-mail 4SMS 4SNMP 4

Oobject creation tracking 79Object meta-data for CLI scripts and host

software 87operational status

synchronous mirroring statuses 44optical port terminators 98options

management 4

Ppartial rack

patch panel layout 57password management 76patch panel 57pending writes 44point of failure 5predefined users 72provisioning

thin 7provisioning, thin 31

Rrack installation

safety 99rack relocation 100

safety 100rack safety 99reader comment form processing virecycling 100Redirect-on-Write (ROW) 11, 13, 14redundancy 5redundant components 5redundant power 5reliability 5remote mirroring 35, 39

and consistency groups 53basic concepts 39, 40best-effort coupling recovery 48configuration options 41coupling 42disaster recovery types 39, 40for media error recovery 54operation 39, 40resuming after role change 52role switchover 50synchronization 44, 46synchronous mirroring statuses 43volume configuration 41

remote monitoring 7replication mechanisms 7restoring 28

snapshots 15volumes 15

restrictions, usage 98Retention of fast reservation 87role switchover 50

when remote mirroring isnonoperational 50

when remote mirroring isoperational 50

role transmissionwithin the asynchronous mirroring

process 71role-based access control

application administrator 73command execution log 79configuring users 75event report destinations 80object creation tracking 79

ROW (Redirect-on-Write) 11, 13, 14


Ssafety

environmental notices 95labels 95laser 98notices 95rack 99rack installation 99rack relocation 100

safety labels 96scrubbing 5SCSI error

while writing to a secondaryvolume 46

secondary site 39self-healing

mechanism 5self-healing mechanisms 5single point of failure 5SMS destination 69SMS notifications 4snapshot 15Snapshot

association 13name 13serial number 13

snapshot groups 26, 27, 28snapshot management 7snapshots 9, 11, 13, 14

auto delete priority 12depletion of hard capacity 31duplicating 15locking and unlocking 14restoring 15

Snapshots 11snapshotting 11, 13, 14

consistency groups 7snapshot management 7

Snapshotting 11SNMP 7SNMP managers 69SNMP notifications 4spare storage 5Standby mode 42states

coupling 47storage

global spare 5storage administrator 19storage pool 9

depletion of hard capacity 31hard and soft sizes 31

storage pools 7moving volumes 29overview 29

Support center integration 87Support for 256 pools 87Support for thousands of mirrors 87switchover 50symantec

Support for Symantec StorageFoundation Thin&Reclaim 87

symmetric connectivity for mirroring 38synchronization 45synchronization status

synchronous mirroring statuses 44

synchronizedremote mirroring 39

synchronous mirroring 39statuses 43

synchronous mirroring statuses 46synchronous remote mirroring

I/O operations 46system

hard and soft sizes 31system attachment

see: host system attachment 19

Ttarget connectivity 35, 36, 37Target connectivity 38target object

defining 35Target Port Group Support (TPGS)

support 87target_connectivity_activate 37target_connectivity_deactivate 37target_connectivity_define 37target_connectivity_delete 37target_connectivity_list 37Technician event 87terminators

optical ports 98thin provisioning 7, 31time stamp 46transmission

of roles 71

Uuncommitted data 48United States electronic emission Class A

notice 108United States FCC Class A notice 108upgradability 9UPS module 1usage restrictions 98use cases

LDAP 77, 78user groups 73

associations 73user roles

application administrator 71permission levels 71read only 71storage administrator 71technician 71

Vvolume

configuration 41volume configuration

mixed configuration 42volumes 9, 10

Full Volume Copy 17hard and soft sizes 31restoring 15

Xxiv authentication 75

Index 113

Readers’ Comments — We’d Like to Hear from You

IBM XIV Storage SystemTheory of Operation

Publication No. GA32-0639-03

We appreciate your comments about this publication. Please comment on specific errors or omissions, accuracy,organization, subject matter, or completeness of this book. The comments you send should pertain to only theinformation in this manual or product and the way in which the information is presented.

For technical questions and information about products and prices, please contact your IBM branch office, yourIBM business partner, or your authorized remarketer.

When you send comments to IBM, you grant IBM a nonexclusive right to use or distribute your comments in anyway it believes appropriate without incurring any obligation to you. IBM or any other organizations will only usethe personal information that you supply to contact you about the issues that you state on this form.

Comments:

Thank you for your support.

Send your comments to the address on the reverse side of this form.

If you would like a response from IBM, please fill in the following information:

Name Address

Company or Organization

Phone No. E-mail address

Readers’ Comments — We’d Like to Hear from YouGA32-0639-03

GA32-0639-03

��Cut or FoldAlong Line

Cut or FoldAlong Line

Fold and Tape Please do not staple Fold and Tape

Fold and Tape Please do not staple Fold and Tape

PLACE

POSTAGE

STAMP

HERE

International Business Machines

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

_

��

U.S.A

GA32-0639-03

ga32-0639-03

Documents