Hitachi storage systems

GDR Version 1.2, or later, supports disaster recovery (DR) for third-party vendor storage from Hitachi. Hitachi storage system supports asynchronous data replication for long-distance through Hitachi Universal Replicator (HUR) technology.

Notes:

GDR 1.2 supports the following version of the Hitachi storage system: Hitachi Virtual Storage Platform (VSP) G1000 and Hitachi VSP G400.
GDR 1.2 supports only asynchronous mode of storage replication.
The DR failover rehearsal function is not supported on Hitachi storage systems.

To successfully use the HUR technology, you must correctly plan for its implementation. Before you continue, your environment must meet the following requirements:

The GDR sites and the KSYS subsystem must be configured.
HUR support must be configured.

The setup of GDR disaster recovery for Hitachi mirrored storage system involves the following steps:

Plan the storage deployment and replication necessary for your environment. This process is related to the applications and middleware that must be deployed in the environment that you want to include in the recovery management by the GDR solution.
Use the storage configuration tools that are provided by Hitachi to configure the storage devices you have defined in step 1, and deploy the devices.
Use the ksysmgr interface to discover the deployed storage devices and to define the disaster recovery policies for the applications or virtual machines that are using the mirrored storage.

Hitachi HUR storage management uses Command Control Interface (CCI) operations from the AIX® operating system and GDR environment. The KSYS subsystem uses CCI to discover and integrate the Hitachi storage replication into the disaster recovery framework of GDR. This integration manages disaster recovery for applications that use the mirrored storage. In the GDR solution, the storage agents, which are added to the KSYS configuration settings, interact with the corresponding CCI software in each site.

Hitachi Command Control Interface (CCI)

The remote and in-system replication software from Hitachi requires the following CCI components to manage the disk pairs:

Command device: The command devices are located in storage systems. CCI uses the command device as the interface to the storage system from the host. The command device accepts commands from the host and executes them on the storage system. The command device is a dedicated logical volume.
Hitachi Open Remote Copy Manager (HORCM): The HORCM is located in the CCI server. The HORCM operates as a daemon process. When activated, the HORCM refers to CCI configuration definition files that are also located on the CCI server. The HORCM instance communicates with the storage system and remote servers.

HORCM definition files describe the storage systems, pair volumes, and data paths. When you run a command, CCI uses the information in the HORCM files to identify target volumes of the command.

Two HORCM files are required for each pair. One file describes the primary volumes (P-VOLs), and the other file describes the secondary volumes (S-VOLs). The following figure shows an example setup of Hitachi storage configuration with two HORCM instances.

Figure 1. Relationship between storage agents and storage disks

Example of Hitachi storage configuration

Requirements

The GDR solution requires the following components for Hitachi storage configuration:

Command Control Interface (CCI) software for AIX. For more information about CCI, see Hitachi Command Control Interface (CCI) documentation that is maintained by Hitachi. The CCI software must also be installed on the KSYS LPAR to communicate with the CCI server.
The GDR solution requires CCI version 01-39-03/04 with model RAID-Manager/AIX.

Limitations

Consider the following limitations when you use the Hitachi storage systems in the GDR solution:

Only Hitachi Universal Replicator (HUR) technology is supported for asynchronous mirroring. The synchronous mirroring is not supported.
The device names (dev_name attributes) must map to logical devices and the device groups (dev_group attributes) must be defined under the HORCM_LDEV section in the horcm.conf file.
The GDR solution uses the dev_group attribute for any basic operation that is related to the Hitachi storage systems. Some examples of basic operations are pairresync, pairevtwait, and horctakeover. If several device names exist in a device group, the device group must be consistency-enabled.
For command devices, the Command Device Security option in the Command Device Attributes panel must be disabled. If the Command Device Security option is enabled, the required information, such as logical device (LDEV) ID, journal volume ID, consistency group ID, and volume type, are not displayed in any command output. The KSYS subsystem needs these information to monitor the state of storage subsystem disks.
The command devices can be protected by using user authentication. However, in the GDR solution, best practice is to disable user authentication for all the Hitachi disks, including the disks designated as command device, that are managed by the GDR solution. Otherwise, many of the disk management functions of the KSYS subsystem might report incorrect information and indeterminate behavior.
The GDR solution does not trap Simple Network Management Protocol (SNMP) notification events for HUR storage. If an HUR link goes down when the hosts are functional and later the HUR link is repaired, you must manually resynchronize the disk pairs.
The KSYS subsystem does not control the creation of disk pairs. You must create the disk pairs before you start the KSYS partition.
Dynamic manipulation of disk groups is not supported for Hitachi storage systems. The KSYS subsystem might break the grouping of the disks in a disk group during the group manipulation operation. When a disk is removed from a disk group, the disk moves into simplex state.
The following cases result in disk removal from a disk group. In these cases, the Hitachi storage subsystem removes the pair relationship.
- Removing disks from a virtual machine
- Performing Live Partition Mobility operation or Remote Restart operation across host groups
- Restoring a snapshot
- Unmanaging a virtual machine from the KSYS subsystem
- Removing a host from host group and adding the host to another host group
- Removing a cluster
You must recreate the disk pair explicitly before you add the same disk or virtual machine to the GDR management.
Hosts that are managed by the GDR solution cannot contain volume groups with both HUR-protected and non-HUR-protected disks. A host must contain an HUR-protected disk.
All hosts within a site that are managed by the GDR solution must use the same HORCM instance.
All disks within a site must belong to the same journal volume.