IBM XIV Storage System

Success Story: JoongAng Ilbo
IBM XIV Storage System delivers newsworthy performance for Koreas JoongAng Ilbo
At a Glance: JoongAng Ilbos XIV solution

Customer

JoongAng Ilbo, a leading Korean daily newspaper and magazine publisher

Industry Environment

Communications and Media HP-UX, Microsoft Windows 2003, Microsoft Windows Server, CRM, billing, MIS, Groupware, Media portal, Oracle database, Networker

XIV Systems Challenge

1 To overcome issues related to storage management, load-balancing, and peak time, so as to provide the highest possible quality services to subscribers, sponsors, and employees

Results

Sustains high performance regardless of environment changes Provides an exceptionally easy-to-use interface and simple administration, reducing the IT team workload
Enables highly reliable data service, driving improved customer satisfaction
Founded in 1965, JoongAng Ilbo is a leading Korean media publishing company, producing one of Koreas top three dailies, JoongAng Daily (circulation two million), and numerous magazines. Through a business alliance with the
International Herald Tribune, JoongAng Ilbo also publishes that paper in Korea, along with an English translation of its daily. JoongAng Ilbos parent company, JMnet (JoongAng Media Network), is the publisher of Newsweek Korea and Forbes Korea.
Delivering high-quality data and services
Like most large enterprises, JoongAng Ilbo relies on its IT infrastructure to deliver high-quality data and services to meet its business needs. Needing to upgrade capacity on its existing Hitachi Data Systems (HDS) storage, the JoongAng IT team took the time to investigate new solutions. A newspaper organization typically pushes its IT infrastructure to the limits at month-end, quarter-end, and yearend, explains SK Kim, storage manager at JoongAng Ilbo: With our previous storage system, we often had poor response times at peak points in the day, and particularly at our most business-critical times. Our ability to provide quality serviceson timeis critical to the success of our business, says JinSoo Lee, CIO of JoongAng Ilbo, because it results in higher quality services for our subscribers, our sponsors, and our employees.
IBM XIV: Addressing all needs while saving costs
After evaluating solutions from EMC, HDS and others JoongAng Ilbo chose the IBM XIV Storage System. They joined forces with IBM Business Partner Haywardtech Corporationa distributor of XIV storage in Korea known for its storage expertisefor planning, implementation, training and maintenance. Originally, we aimed to simply upgrade our existing storage capacity, recalls SK Kim. Guided by Haywardtechs industry knowledge and understanding of our pains, we came to realize that the IBM XIV Storage System could clear up all of our problems. We understood that the XIV systems unique architecture and other features could deliver the sustained high performance we sought, regardless of the many changes that transpire in the storage environment over time. JoongAng tested the candidate systems for performance. Recalls JinSoo Lee, We evaluated SQL queries using the SQLIO performance test tool. The XIV system performed more than two and a half times faster than comparable systems. Efficiency is the priority factor when we invest in IT, he adds. The solution we chose had to be highly reliable, cost-effective, able to integrate with our legacy IT components, and able to exibly address ad-hoc business requirements. The IBM XIV Storage System has given us all this. IBM XIVs built-in software offeringvirtualization, snapshots, management, and so forthwas also a decisive differentiator.

Problem-free performance

JoongAng Ilbo replaced its existing storage unit with an XIV storage system. The system is congured in 60 storage volumes to support the companys many enterprise applications, including CRM, billing, MIS, Groupware, Microsoft Exchange, and media portal applications. JoongAng Ilbo runs an Oracle database on Microsoft Windows Server, while backup and archiving is provided by Networker. The infrastructure supports as many as 3,500 concurrent users. JoongAng Ilbo conducted a one-month proof of concept before committing to the XIV platform. After just a few hours of instruction, the media publishers storage team was well equipped to manage and maintain the new system. We changed over from our legacy system to XIV in a single day, recalls SK Kim. Weve now been up and running for a year and a half without a single problem. What more can I say?
Exceptional stability, enhancing customer satisfaction
JoongAng Ilbo has realized numerous IT and, ultimately, business benets since implementing XIV storage. With XIV, we are enjoying great improvements in system reliability, batch processing time, and data volumes allocation, reports JinSoo Lee. Weve also removed bottlenecks during peak production, which had long been a thorn in our side. We now have new levels of business efficiency, which translates to improved customer satisfaction. SK Kim agrees. We now have consistent performance 24x365, including during nancial cut-off periods. Company end users can access the information they need at any time, any day of the year. With IBM XIV, we have an exceptionally stable storage system, even in unforeseen circumstances. When the power went out during building renovations, we didnt lose a single piece of data.
Groundbreaking user experience
Easy storage management, delivered through the simple and intuitive XIV user interface, has enabled the media publisher to reduce administrative overhead signicantly. Said SK Kim of the XIV user interface: Fantasticits a groundbreaking tool.
Efficiency is the priority factor when we invest in IT. The solution we chose had to be highly reliable, cost-effective, able to integrate with our legacy IT components, and able to exibly address ad-hoc business requirements. The IBM XIV Storage System has given us all this.

JinSoo Lee, CIO, JoongAng Ilbo
With IBM XIV, we have an exceptionally stable storage system, even in unforeseen circumstances. When the power went out during building renovations, we didnt lose a single piece of data.
SK Kim, Storage Manager, JoongAng Ilbo
Benets: Getting more with XIV
XIV System Stable system with consistently high performance Automated volume distribution and load-balancing Easy management Business value to JoongAng Ilbo
Improved massive data processing time Greater customer satisfaction No bottlenecks during peak production times
Copyright IBM Corporation 2009 IBM Systems and Technology Group Route 100 Somers, NY 10589 U.S.A. Produced in the United States of America May 2009 All Rights Reserved IBM, the IBM logo, ibm.com, and XIV are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their rst occurrence in this information with a trademark symbol ( or ), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at Copyright and trademark information at ibm.com/legal/copytrade.shtml Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. Other company, product and service names may be trademarks or service marks of others. IBM and Haywardtech Corporation of Korea are separate companies and each is responsible for its own products. Neither IBM nor Haywardtech Corporation of Korea makes any warranties, express or implied, concerning the others products. References in this publication to IBM products, programs or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program or service is not intended to imply that only IBMs product, program or service may be used. Any functionally equivalent product, program or service may be used instead. Offerings are subject to change, extension or withdrawal without notice. All client examples cited represent how some clients have used IBM products and the results they may have achieved. Performance data for IBM and non-IBM products and services contained in this document was derived under specic operating and environmental conditions. The actual results obtained by any party implementing such products or services will depend on a large number of factors specic to such partys operating environment and may vary signicantly. IBM makes no representation that these results can be expected or obtained in any implementation of any such products or services. THE INFORMATION IN THIS DOCUMENT IS PROVIDED AS-IS WITHOUT ANY WARRANTY, EITHER EXPRESSED OR IMPLIED.

Signicantly reduced storage administration overhead

Highly exible platform

Integrated, assets-protective environment

For more information

Contact your IBM sales representative or IBM Business Partner, or visit: www.ibm.com/systems/storage/disk/xiv/ For more information about JoongAng Ilbo, visit: joongangdaily.joins.com For more information about Haywardtech Corporation, visit: www.haywardtech.com

TSC03053-USEN-00

3.1 XIV Remote Mirroring overview
The purpose of mirroring is to create a set of consistent data that can be used by production applications in the event of problems with production volumes or for other purposes. XIV Remote Mirroring is application and operating system independent, and does not require server processor cycle usage.
3.1.1 XIV Remote Mirror terminology
It is worth going through and becoming familiar with several terms used throughout the next chapters involving remote mirroring. A number of terms, meanings, and usage with regards to XIV and synchronous remote mirroring are noted below:
Local site: This site is made up of the primary storage and the servers running
applications with the XIV Storage System.
Remote site: This site holds the mirror copy of the data on another XIV Storage System
and usually standby servers as well. In this case, the remote site is capable of becoming the active production site with consistent data available in the event of a failure at the local site.
Primary: This denotes the XIV designated under normal conditions to serve hosts and have its data replicated to a secondary XIV for disaster recovery purposes. Secondary. This denotes the XIV designated under normal conditions to act as the mirror
(backup) for the primary, and that could be set to replace the primary if the primary fails.
Consistency groups (CG): A consistency group is a set of related volumes on the same XIV Storage System that are treated as a single consistent unit. Consistency groups are supported within Remote Mirroring. Coupling: This is the pairing of volumes or consistency groups (CGs) to form a mirror relationship between the source of the replication (master) and the target (slave). Peer : This is one side of a coupling. It can either be a volume or a consistency group. However, peers must be of the same type (that is, both volumes or CGs). Whenever a coupling is defined, a role is specified for each peer. One peer is designated as the master and the other peer is designated as the slave. Role: This denotes the actual role that the peer is fulfilling:
Master : A role that indicates that the peer serves host requests and acts as the source for replication. Changing a peers role to master from slave may be warranted after a disruption of the current masters service either due to a disaster or to planned service maintenance. Slave: A role that indicates that the peer does not serve host requests and acts as the target for replication. Changing a peers role to slave from master may be warranted after the peer is recovered from a site/system/link failure or disruption that led to the promotion of the other peer from slave to master. Changing roles can also be done in preparation for supporting a planned service maintenance.
Sync job: This applies to async mirroring only. It denotes a synchronization procedure run

Like any continuous or near-continuous remote mirroring solution, XIV Remote Mirroring cannot protect against software data corruption because the corrupted data will be copied as part of the remote mirroring solution. However, the XIV snapshot function provides a point-in-time image that may be used for rapid restore in the event of software data corruption (that occurred after the snapshot was taken), and XIV snapshot may be used in combination with XIV Remote Mirroring, as illustrated in Figure 3-13.

Point in Time Copy

Local Disaster

Regional Disasters

Data Corruption

Single System Failure

Component failures Single system failures
Point In Time Disk Backup, Extra Copies High Availability
Terrorist Attacks Human Error HVAC failures Power failures Building Fire Architectural failures Planned Maintenance
Electric grid failures Natural disasters - Floods - Hurricanes - Earthquakes
Figure 3-13 Combining snapshots with Remote Mirroring

IBMS stemStorageTM

Note that recovery using a snapshot warrants deletion and recreation of the mirror. XIV snapshot (within a single XIV system) Protection for the event of software data corruption can be provided by a point-in-time backup solution using the XIV snapshot function within the XIV system that contains the production volumes. Figure 3-14 shows a single-system point-in-time online backup configuration.
Figure 3-14 Point-in-time online backup configuration
XIV local snapshot plus Remote Mirroring configuration An XIV snapshot of the production (local) volume may be used in addition to XIV Remote Mirroring of the production volume when protection from logical data corruption is required in addition to protection against failures and disasters. The additional XIV snapshot of the production volume provides a quick restore to recover from data corruption. An additional Snapshot of the production (local) volume may also be used for other business or IT purposes (for example, reporting, data mining, development and test, and so on).
Figure 3-15 shows an XIV local snapshot plus Remote Mirroring configuration.
Figure 3-15 Local snapshot plus Remote Mirroring configuration
XIV remote snapshot plus Remote Mirroring configuration An XIV snapshot of the consistent replicated data at the remote site may be used in addition to XIV Remote Mirroring to provide an additional consistent copy of data that can be used for business purposes such as data mining, reporting, and for IT purposes, such as remote backup to tape or development, test, and quality assurance. Figure 3-16 shows an XIV remote snapshot plus Remote Mirroring configuration.

3.5.8 Temporary deactivation and reactivation
This scenario begins with normal operation of XIV remote mirroring from XIV 1 to XIV 2, followed by user deactivation of XIV remote mirroring for a period of time. This scenario may be used to temporarily suspend XIV remote mirroring during a period of peak activity if there is not enough bandwidth to handle the peak load or if the response time impact during peak activity is unacceptable. 1. Deactivate XIV remote mirroring from the master volume at XIV 1 to the slave volume at XIV 2. Changes to the master volume at XIV 1 will be recorded in metadata for synchronous mirroring. 2. Wait until it is acceptable to reactivate mirroring. 3. Reactivate XIV remote mirroring from the master volume at XIV 1 to the slave volume at XIV 2.

3.6 Planning

The most important planning considerations for XIV Remote Mirroring are those related to ensuring availability and performance of the mirroring connections between XIV systems, as well as the performance of the XIV systems. Planning for snapshot capacity usage is also extremely important. To optimize availability, XIV remote mirroring connections must be spread across multiple ports on different adapter cards in different modules, and must be connected to different networks. To optimize capacity usage, the number and frequency of snapshots (both those required for asynchronous replication and any additional user-initiated snapshots) and the workload change rates must be carefully reviewed. If not enough information is available, a snapshot area that is 30% of the pool size may be used as a starting point. Storage pool snapshot usage thresholds must be set to trigger notification (for example, SNMP, e-mail, SMS) when the snapshot area capacity reaches 50%, and snapshot usage must be monitored continually to understand long-term snapshot capacity requirements.
3.7 Advantages of XIV mirroring
XIV remote mirroring provides all the functions typical of remote mirroring solutions in addition to the following advantages: Both synchronous and asynchronous mirroring are supported on a single XIV system. XIV mirroring is supported for consistency groups and individual volumes and mirrored volumes may be dynamically moved into and out of mirrored consistency groups. XIV mirroring is data aware. Only actual data is replicated. Synchronous mirroring automatically resynchronizes couplings when a connection recovers after a network failure. Both FC and iSCSI protocols are supported, and both may be used to connect between the same XIV systems. XIV mirroring provides an option to automatically create slave volumes. XIV allows user specification of initialization and resynchronization speed.

3.11.2 Remote mirror target configuration
The connections to the target (secondary) XIV system must be defined. We assume that the physical connections and zoning have been set up. Target configuration is done from the mirror connectivity menu. The first step is to add the target system. To do this right-click the system image and select Create Target, as shown in Figure 3-51.
Figure 3-51 Create target
Then define the type of mirroring to be used (mirroring or migration) and the type of connection (iSCSI or FC), as shown in Figure 3-52.
Figure 3-52 Target type and protocol
Next, as shown in Figure 3-53 on page 95, connections are defined by clicking the line between the two XIV systems to display the link status detail screen.
Figure 3-53 Define connections
Connections are easily defined by clicking Show Auto Detected Connections. This shows the possible connections and provides an Approve button to define the detected connections. Remember that for FCP ports an initiator must be connected to a target and the proper zoning must be established for the connections to be successful. The possible connections are shown in light grey, as depicted in Figure 3-54.
Figure 3-54 Show possible connections
Connections can also be defined by clicking a port on the primary system and dragging the the corresponding port on the target system. This is shown as a blue line in Figure 3-55 on page 97.
Figure 3-55 Graphically define a connection
Releasing the mouse button initiates the connection and then the status can be displayed, as shown in Figure 3-56.
Figure 3-56 Define connection and view status
Right-click a path and you have options to Activate, Deactivate, and Delete the selected path, as shown in Figure 3-57 on page 98.
Figure 3-57 Paths actions menu
To delete the connections between two XIV systems you have to delete all paths between the two systems and afterwards in the Mirroring Connectivity display delete the target system as shown in Figure 3-58.
Figure 3-58 Delete Target XIV

3.11.3 XCLI examples

XCLI commands can be used to configure connectivity between the primary XIV system and the target or secondary XIV system (Figure 3-59). target_define target="WSC_1300331" protocol=FC xiv_features=yes target_mirroring_allow target="WSC_1300331" target_define target="WSC_6000639" system_id=639 protocol=FC xiv_features=yes target_mirroring_allow target="WSC_6000639" target_port_add fcaddress=50017380014B0183 target="WSC_1300331" target_port_add fcaddress=50017380027F0180 target="WSC_6000639" target_port_add fcaddress=50017380014B0193 target="WSC_1300331" target_port_add fcaddress=50017380027F0190 target="WSC_6000639" target_port_add fcaddress=50017380027F0183 target="WSC_6000639" target_port_add fcaddress=50017380014B0181 target="WSC_1300331" target_connectivity_define local_port="1:FC_Port:8:4" fcaddress=50017380014B0181 target="WSC_1300331" target_port_add fcaddress=50017380027F0193 target="WSC_6000639" target_port_add fcaddress=50017380014B0191 target="WSC_1300331" target_connectivity_define local_port="1:FC_Port:9:4" fcaddress=50017380014B0191 target="WSC_1300331" target_connectivity_define target="WSC_6000639" local_port="1:FC_Port:8:4" fcaddress="50017380027F0180" target_connectivity_define target="WSC_6000639" local_port="1:FC_Port:9:4" fcaddress="50017380027F0190"

Map volumes on standby server and continue working
At this point we map the relevant mirrored volumes to the standby server. For details on how to do this mapping refer to IBM XIV Storage System: Architecture, Implementation, and Usage, SG24-7659. Once the volumes are mapped, we continue working as normal. This is simulated by adding additional data to the server, as illustrated in Figure 4-16.
Figure 4-16 Additional data added to the standby server
Environment with production now at the secondary site
Figure 4-17 illustrates production at the secondary site.
Figure 4-17 Production at secondary site Chapter 4. Synchronous Remote Mirroring
4.5.3 Phase 3: recovery of the primary site
In this phase the primary site is recovered and communication between the primary and secondary sites is restored. We assume that it was not totally damaged and that the data at the primary site is still there (so we can do a resync). Data is being written from the standby server to the secondary XIV. At the primary site the original Windows 2008 production server is now switched off, as illustrated in Figure 4-18.

FC Link FC Link

Mirroring Inactive
Figure 4-18 Primary site recovery
Role changeover at the primary site using the GUI
We are now going to change roles for the master volumes at the primary site and make them slave volumes. Before doing this, ensure that the original production server is shut down. 1. On the primary XIV go to the Remote Mirroring menu. The synchronization status will probably be inactive. Select one coupling (if you select several couplings, you cannot change the role), right-click, and select Change Role, as shown in Figure 4-19.
Figure 4-19 Change master volumes to slave volumes on the primary XIV
2. You will be prompted to confirm the role change. Select OK to confirm (Figure 4-20).
Figure 4-20 Roll change confirmation
Once you have confirmed, the role is changed to slave, as shown in Figure 4-21.
Figure 4-21 New role as slave volume
3. Repeat steps 12 for all the volumes that must be changed.
Role changeover at the primary site using the XCLI
We now change roles for the master volumes at the primary site with the XCLI and make them slave volumes. Before doing this, ensure that the original production server is shut down. 1. On the primary XIV open an XCLI session and run the mirror_change_role command (Example 4-9).
Example 4-9 Change master volumes to slave volumes on the primary XIV

Accessing a snapshot volume from another AIX host
The following procedure makes the data of the snapshot volume available to another AIX host that has no prior definitions of the snapshot volume in its configuration database (ODM). This host that is receiving the snapshot volumes can manage the access to these devices as described here. If the host is using LVM or MPIO definitions that work with hdisks only, follow these steps: 1. The snapshot volume (hdisk) is new to AIX, and therefore the Configuration Manager should be run on the specific Fibre Channel adapter: #cfgmgr -l <fcs#> 2. Determine which of the physical volumes is your snapshot volume: #lsdev -C |grep 2107 3. Certify that all PVIDs in all hdisks that will belong to the new Volume Group were set. Check this information using the lspv command. If they were not set, run the following command for each one to avoid failure of the importvg command: #chdev -l <hdisk#> -a pv=yes 4. Import the snapshot Volume Group: #importvg -y <volume_group_name> <hdisk#>
5. Vary on the Volume Group (the importvg command should vary on the Volume Group): #varyonvg <volume_group_name> 6. Verify consistency of all file systems on the snapshot volumes: #fsck -y <filesystem_name> 7. Mount all the snapshot file systems: #mount <filesystem_name> The data is now available and you can, for example, back up the data residing on the snapshot volume to a tape device. The disks containing the snapshot volumes might have been previously defined to an AIX system, for example, if you periodically create backups using the same set of volumes. In this case, there are two possible scenarios: If no Volume Group, file system, or logical volume structure changes were made, use procedure 1 to access the snapshot volumes from the target system. If some modifications to the structure of the Volume Group were made, such as changing the file system size or modifying logical volumes (LV), then it is recommended to use procedure 2.

Procedure 1

To access the snapshot volumes from the target system if no Volume Group, file system, or logical volume structure changes were made follow these steps: 1. Unmount all the source file systems: #umount <source_filesystem> 2. Unmount all the snapshot file systems: #umount <snapshot_filesystem> 3. Deactivate the snapshot Volume Group: #varyoffvg <snapshot_volume_group_name> 4. Create the snapshots on the XIV. 5. Mount all the source file systems: #mount <source_filesystem> 6. Activate the snapshot Volume Group: #varyonvg <snapshot_volume_group_name> 7. Perform a file system consistency check on the file systems: #fsck -y <snapshot_file_system_name> 8. Mount all the file systems: #mount <snapshot_filesystem>

Procedure 2

If some modifications have been made to the structure of the Volume Group, use the following steps to access the snapshot volumes: 1. Unmount all the snapshot file systems: #umount <snapshot_filesystem>
Chapter 6. Open systems considerations for Copy Services
2. Deactivate the snapshot Volume Group: #varyoffvg <snapshot_volume_group_name> 3. Export the snapshot Volume Group: #exportvg <snapshot_volume_group_name> 4. Create the snapshots on the XIV. 5. Import the snapshot Volume Group: #importvg -y <snapshot_volume_group_name> <hdisk#> 6. Perform a file system consistency check on snapshot file systems: #fsck -y <snapshot_file_system_name> 7. Mount all the target file systems: #mount <snapshot_filesystem>
Accessing the snapshot volume from the same AIX host
In this section we describe a method of accessing the snapshot volume on a single AIX host while the source volume is still active on the same server. The procedure is intended to be used as a guide and might not cover all scenarios. If you are using the same host to work with source and target volumes, you have to use the recreatevg command. The recreatevg command overcomes the problem of duplicated LVM data structures and identifiers caused by a disk duplication process such as snapshot. It is used to recreate an AIX Volume Group (VG) on a set of target volumes that are copied from a set of source volumes belonging to a specific VG. The command will allocate new physical volume identifiers (PVIDs) for the member disks and a new Volume Group identifier (VGID) to the Volume Group. The command also provides options to rename the logical volumes with a prefix you specify, and options to rename labels to specify different mount points for file systems.
Accessing snapshot volumes using the recreatevg command
In this example, we have a Volume Group containing two physical volumes (hdisks) and we want to create snapshot volumes for the purpose of creating a backup. The source volume group is src_snap_vg, containing hdisk2 and hdisk3. The target volume group will be tgt_snap_vg; it will contain the snapshots of hdisk2 and hdisk3. Perform these tasks to make the snapshot volumes available to AIX: 1. Stop all I/O activities and applications that access the source volumes. 2. Create the snapshot on the XIV for hdisk2 and hdisk3 with the GUI or XCLI. 3. Restart applications that access the source volumes. 4. The snapshots will now have the same volume group data structures as the source volumes hdisk2 and hdisk3. Clear the PVIDs from the target hdisks to allow a new Volume Group to be made: #chdev -l hdisk4 -a pv=clear #chdev -l hdisk5 -a pv=clear
5. Issue the lspv command; the result is shown in Example 6-2.
Example 6-2 lspv output before recreating the volume group
# lspv hdisk2 hdisk3 hdisk4 hdisk5

7.6 Asynchronous Remote Mirroring with IBM i
In this section we describe Asynchronous Remote Mirroring of the local IBM i partition disk space. This solution provides continuous availability with a recovery site located at a long distance while minimizing performance impact on production. In this solution, the entire disk space of the production IBM i LPAR resides on the XIV to allow boot from SAN. Asynchronous Remote Mirroring for all XIV volumes belonging to the production partition is established with another XIV located at the remote site. In case of an outage at the production site a remote stand-by IBM i LPAR takes over the production workload with the capability to IPL from Asynchronous Remote Mirroring secondary volumes. Because of the XIV Asynchronous Remote Mirroring design, the impact on production performance is minimal; however, the recovered data at the remote site is typically lagging production data due to the asynchronous nature, although usually just slightly behind. For more information about the XIV Asynchronous Remote Mirroring design and implementation, refer to Remote Mirroring on page 47.
7.6.1 Benefits of asynchronous Remote Mirroring
Solutions with asynchronous mirroring provide significant benefits to an IBM i center, some of which are: The solution provides replication of production data over long distances while minimizing production performance impact.
The solution does not require any special maintenance on the production or standby partition. Practically, the only required task is to set up Asynchronous mirroring for the entire IBM i disk space. Since Asynchronous mirroring is entirely driven by the XIV storage systems, this solution does not use any processor or memory resources from the IBM i production and remote partitions. This is different from other IBM i replication solutions, which use some of the production and recovery partitions resources.
7.6.2 Setting up asynchronous Remote Mirroring for IBM i
The following steps are used to set up asynchronous remote mirroring with consistency group for IBM i volumes: 1. Configure Remote Mirroring as is described in 3.11, Using the GUI or XCLI for Remote Mirroring actions on page 89. 2. Establish and activate asynchronous mirroring for IBM i volumes. a. To establish the asynchronous mirroring on IBM i volumes, using the GUI on the primary XIV, select Volumes Volumes and Snapshots. Right-click each volume to mirror and select Create Mirror from the pop-up menu. In the Create Mirror window, specify Synch Type Asynch, specify the target XIV system and the slave volume to mirror to, desired RPO, and schedule management XIV Internal. For more information about establishing Asynchronous mirroring refer to 5.1, Asynchronous mirroring configuration on page 126. b. To activate asynchronous mirroring on IBM i volumes, using the GUI on the primary XIV, select Remote Mirroring. Highlight the volumes to mirror and select Activate from the pop-up window. After activating, the initial synchronization of mirroring is performed. Figure 7-23 shows the IBM i volumes during initial synchronization: some of them are already in the status RPO OK, one is in RPO lagging status, and some are not yet synchronized.

Bring the host online

After the volumes have been mapped to the host server, the host can be brought online. Perform host administrative procedures. The host must be configured using the XIV host attachment procedures. These include removing any existing/non-XIV multi-pathing software and installing the native multi-pathing drivers, recommended patches, and the XIV Host attachment kit, as identified in the XIV Host Attachment Guides. Install the most current HBA driver and firmware at this time. One or more reboots might be required. Documentation and other software can be found at: http://www.ibm.com/support/search.wss?q=ssg1*&tc=STJTAG+HW3E0&rs=1319&dc=D400&dtm When volume visibility has been verified, the application can be brought up and operations verified. Note: In clustered environments, it is usually recommended that only one node of the cluster be initially brought online after the migration is started, and that all other nodes be offline until the migration is complete. After complete, update all other nodes (driver, host attachment package, and so on), in the same way the primary node was during the initial outage (see step 5 in Perform pre-migration tasks for the host being migrated on page 224).
8.3.5 Complete the data migration on XIV
Figure 8-16 Data migration progress
To complete the data migration, perform the steps described in this section.

Data migration progress

Figure 8-16 shows the progress of the data migrations. The status bar can be toggled between GB remaining, percent complete, and hours/minutes remaining. Figure 8-16 shows four data migrations, one of which has started background copy and three of which have not.
Only one migration is being copied at this same time because there is only one target (DS4700_Ctrl_B). After all of a volumes data has been copied, the data migration achieves synchronization status. After synchronization is achieved, all read requests are served by the XIV Storage System. If source updating was selected the XIV will continue to write data to both itself and the outgoing storage system until the data migration is deleted. Figure 8-17 shows a completed migration.
Figure 8-17 Data migration complete

Delete data migration

After the synchronization has been achieved, the data migration object can be safely deleted without host interruption. Important: If this is an online migration, do not deactivate the data migration prior to deletion, as this causes host I/O to stop and possibly causes data corruption. Right-click to select the data migration volume and choose Delete Data Migration, as shown in Figure 8-18. This can be done without host/server interruption.

Define host (if adding host to a cluster). host_define host=<Host Name> cluster=<Cluster Name> host_define host=Exch01N1 cluster=Exch01
Define host (if not using cluster definition). host_define host=<Name> host_define host=Exch01
Define host port (Fibre Channel host bus adapter port). host_add_port host=<Host Name> fcaddress=<HBA WWPN> host_add_port host=Exch01 fcaddress=123456789abcdef1
Create XIV volume using decimal GB volume size. vol_create vol=<Vol name> size=<Size> pool=<Pool Name> vol_create vol=Exch01_sg01_db size=17 pool=Exchange
Create XIV volume using 512 byte blocks. vol_create vol=<Vol name> size_blocks=<Size in blocks> pool=<Pool Name> vol_create vol=Exch01_sg01_db size_blocks=32768 pool=Exchange
If the local volume was pre-created: Syntax dm_define target=<Target> vol=<Pre-created Volume Name> lun=<Host LUN ID as presented to XIV> source_updating=<yes|no> dm_define target=DMX605 vol=Exch01_sg01_db lun=5 source_updating=no
Test data migration object. Syntax Example Syntax Example dm_test vol=<DM Name> dm_test vol=Exch_sg01_db
Activate data migration object. dm_activate vol=<DM Name> dm_activate vol=Exch_sg01_db
Map volume to host/cluster. Map to host: Syntax Example Map to cluster: Syntax Example map_vol host=<Cluster Name> vol=<Vol Name> lun=<LUN ID> map_vol host=Exch01 vol=Exch01_sg01_db lun=1 map_vol host=<Host Name> vol=<Vol Name> lun=<LUN ID> map_vol host=Exch01 vol=Exch01_sg01_db lun=1
Delete data migration object. If the data migration is synchronized and thus completed: Syntax Example dm_delete vol=<DM Volume name> dm_delete vol=Exch01_sg01_db
If the data migration is not complete it must be deleted by removing the corresponding volume from the Volume and Snapshot menu (or via the vol_delete command). Delete volume (not normally needed). Challenged volume delete (cannot be done via a script, as this command must be acknowledged): Syntax Example Syntax Example Syntax vol_delete vol=<Vol Name> vol_delete vol=Exch_sg01_db
If you want to perform an unchallenged volume deletion: vol_delete -y vol=<Vol Name> vol_delete -y vol=Exch_sg01_db
Delete target connectivity. target_connectivity_delete local_port=1:FC_Port:<Module:Port> fcaddress=<non-XIV storage device WWPN> target=<Name> target_connectivity_delete local_port=1:FC_Port:5:4 fcaddress=0123456789012345 target=DMX605
Example Delete target port. Fibre Channel Syntax Example Delete target. Syntax Example Syntax Example
target_port_delete fcaddress=<non-XIV WWPN> target=<Name> target_port_delete fcaddress=0123456789012345 target=DMX605
target_delete target=<Target Name> target_delete target=DMX605
Change Migration Sync Rate target_config_sync_rates target=<Target Name> max_initialization_rate=<Rate in MB> target_config_sync_rates target=DMX605 max_initialization_rate=100

We now create two new zones. The first zone connects the initiator ports on the XIV to the ESS 800. The second and third zones connects the target ports on the XIV to Dolly (for use after the migration). These are shown in Example 8-19. All six ports on the XIV clearly must have been cabled into the SAN fabric.
Example 8-19 New zoning on the SAN Fabric
ESS800_nextrazap 50:05:07:63:00:c9:0c:21 50:05:07:63:00:cd:0c:21 50:01:73:80:00:23:01:53 50:01:73:80:00:23:01:73 zone: nextrazap_dolly_fcs0 10:00:00:00:c9:53:da:b3 50:01:73:80:00:23:01:41 50:01:73:80:00:23:01:51
nextrazap_dolly_fcs1 10:00:00:00:c9:53:da:b2 50:01:73:80:00:23:01:61 50:01:73:80:00:23:01:71
We then create the migration connections between the XIV and the ESS 800. An example of using the XIV GUI to do this was shown in Define target connectivity (Fibre Channel only). on page 232. In Example 8-20 we use the XCLI to define a target, then the ports on that target, then the connections between XIV and the target (ESS 800). Finally, we check that the links are active=yes and up=yes. We can use two ports on the ESS 800 because it is an active/active storage device.
Example 8-20 Connecting ESS 800 to XIV for migration using XCLI
>> target_define protocol=FC target=ESS800 xiv_features=no Command executed successfully. >> target_port_add fcaddress=50:05:07:63:00:c9:0c:21 target=ESS800 Command executed successfully. >> target_port_add fcaddress=50:05:07:63:00:cd:0c:21 target=ESS800 Command executed successfully. >> target_connectivity_define local_port=1:FC_Port:5:4 fcaddress=50:05:07:63:00:c9:0c:21 target=ESS800 Command executed successfully. >> target_connectivity_define local_port=1:FC_Port:7:4 fcaddress=50:05:07:63:00:cd:0c:21 target=ESS800 Command executed successfully. >> target_connectivity_list Target Name Remote Port FC Port IP Interface Active ESS800 5005076300C90C21 1:FC_Port:5:4 yes ESS800 5005076300CD0C21 1:FC_Port:7:4 yes

Up yes yes

We now define the XIV as a host to the ESS 800. In Figure 8-30 we have defined the two initiator ports on the XIV (with WWPNs that end in 53 and 73) as Linux (x86) hosts called Nextra_Zap_5_4 and NextraZap_7_4.
Figure 8-30 Define the XIV to the ESS 800 as a host
Finally, we can define the AIX host to the XIV as a host using the XIV GUI or XCLI. In Example 8-21 we use the XCLI to define the host and then add two HBA ports to that host.
Example 8-21 Define Dolly to the XIV using XCLI
>> host_define host=dolly Command executed successfully. >> host_add_port fcaddress=10:00:00:00:c9:53:da:b3 host=dolly Command executed successfully. >> host_add_port fcaddress=10:00:00:00:c9:53:da:b2 host=dolly Command executed successfully. After the zoning changes have been done and connectivity and correct definitions confirmed between XIV to ESS and XIV to AIX host, we take an outage on the volume group and related file systems that are going to be migrated. In Example 8-22 we unmount the file system, vary off the volume group, and then export the volume group. Finally, we rmdev the hdisk devices.

9.7.3 Using SVC migration with image mode
This migration method is used when: The extent size must be changed but VDisk mirroring cannot be used, perhaps because the SVC nodes are already constrained for CPU and memory. Because the SVC must be on 4.3 code to support XIV (SVC code level 4.3 being the level that brought in VDisk mirroring), having downlevel SVC firmware is not a valid reason. We want to move the VDisks from one SVC cluster to a different one. We want to move the data away from the SVC without using XIV migration. In these cases we can migrate the VDisks to image mode and take an outage to do the relocation and extent re-size. There will be a host outage, although it can kept short (potentially in the order of seconds or minutes). At a high level the process is as follows: 1. We start with existing VDisks in an existing MDisk group. Possibly the extent size of this MDisk group is small (say 16 MB). We call this the source MDisk group. 2. We create XIV volumes that are the same size (or larger) than the existing VDisks. This might need extra steps, as the XIV volumes must be created using 512 byte blocks. We map these specially sized volumes to the SVC.
3. We migrate each VDisk to image mode using these new volumes (presented as unmanaged MDisks). The new volumes move into the source MDisk group as image mode MDisks and the VDisks become image mode VDisks. 4. We can now remove all the Image Mode MDisks from the source MDisk group. This is the disruptive part of this process. They are now unmanaged MDisks, but the data on these volumes is intact. We could at this point map these volumes to a different SVC cluster or we could remove them from the SVC altogether (in which case the process is complete). 5. We create a new managed disk group that contains only the image mode VDisks, but using the recommended extent size (1024 MB) and present the VDisks back to the hosts. We call this the transition MDisk group. The host downtime is now over. 6. We create another new managed disk group using free space on the XIV, using the same large extent size (1024 MB). We call this the target MDisk group. 7. We migrate the image mode VDisks to managed mode VDisks, moving the data from the transition MDisk group created in step 5 to the target MDisk Group created in step 6. The MDisks themselves are already on the XIV. 8. When the process is complete, we can delete the source MDisks and the source MDisk group (which represent space on the non-XIV storage controller) and the transitional XIV volumes (which represent space on the XIV). 9. We can then use the transitional volume space on the XIV to create more 1632 GB volumes to present to the SVC. These can be added into the existing MDisk group or used to create a new one. This method is detailed in greater depth in 9.10, Using SVC migration with image mode on page 295.

9.8 Using SVC migration to move data to XIV
This process migrates data from a source MDisk Group to a target Mdisk group using the same Mdisk group extent size. These is no interruption to host I/O.
9.8.1 Determine the required extent size and VDisk candidates
We must determine the extent size of the source MDisk group. In Example 9-25 MDisk Group ID 1 is the source group and has an extent size of 256.
Example 9-25 Listing MDisk groups
IBM_2145:SVCSTGDEMO:admin>svcinfo lsmdiskgrp id name status mdisk_count vdisk_count capacity extent_size free_capacity 0 MDG_DS6800 online 399.5GB 16 399.5GB 1 Source_GRP online 50.0GB 256 45.0GB We then must identify the VDisks that we are migrating. We can filter by MDisk Group ID, as shown in Example 9-26, where there is only one VDisk that must be migrated.
Example 9-26 Listing VDisks filtered by MDisk group
IBM_2145:SVCSTGDEMO:admin>svcinfo lsvdisk -filtervalue mdisk_grp_id=1 id name status mdisk_grp_id mdisk_grp_name capacity type 5 migrateme online 1 Source_GRP 5.00GB striped
9.8.2 Create the MDisk group
We must create volumes on the XIV and map them to the SVC cluster. Presuming that we have done this, we then detect them on the SVC, as shown in Example 9-27.
Example 9-27 Detecting new MDisks
IBM_2145:SVCSTGDEMO:admin>svctask detectmdisk IBM_2145:SVCSTGDEMO:admin>svcinfo lsmdiskcandidate id 13 IBM_2145:SVCSTGDEMO:admin>svcinfo lsmdisk -filtervalue mode=unmanaged id name status mode capacity ctrl_LUN_# controller_name 9 mdisk9 online unmanaged 1520.0GB 0000000000000007 XIV 10 mdisk10 online unmanaged 1520.0GB 0000000000000008 XIV 11 mdisk11 online unmanaged 1520.0GB 0000000000000009 XIV 12 mdisk12 online unmanaged 1520.0GB 000000000000000A XIV 13 mdisk13 online unmanaged 1520.0GB 000000000000000B XIV We then create an Mdisk group called XIV_Target using the new XIV MDisks, with the same extent size as the source group. In Example 9-28 it is 256.
Example 9-28 Creating an MDisk group
IBM_2145:SVCSTGDEMO:admin>svctask mkmdiskgrp -name XIV_Target -mdisk 9:10:11:12:13 -ext 256 MDisk Group, id [2], successfully created We confirm the new MDisk group is present. In Example 9-29 we are filtering by using the new ID of 2.
Example 9-29 Checking the newly created MDisk group