HP Storage Provisioning Manager HP 3PAR StoreServ Peer Persistence

Transcription

1 Technical white paper HP Storage Provisioning Manager HP 3PAR StoreServ Peer Persistence Handling HP 3PAR StoreServ Peer Persistence with HP Storage Provisioning Manager Click here to verify the latest version of this document 1

2 Table of Contents Terminology used... 3 Scope and limitations... 3 HP 3PAR Peer Persistence Concepts... 3 Separate SPM instances managing the two sites... 4 Single SPM instance managing the two sites... 4 Impact on SPM... 8 What an SPM administrator must do Separate SPM instance managing two sites Single SPM instance managing two sites Troubleshooting Peer Persistence unavailable due to volume unexpectedly removed from Remote Copy group on source array While activating a destination volume, SPM created a new zone instead of reusing the existing zone Destination volume is not returned as a candidate after importing into SPM

3 Introduction HP 3PAR StoreServ Storage Systems provide various capabilities and can be used in conjunction with the HP Storage Provisioning Manager (SPM) in the HP Matrix Operating Environment. The HP 3PAR StoreServ Peer Persistence software allows 3PAR StoreServ systems located in different data centers at metropolitan distances to act as peers to each other, presenting continuous storage system access to hosts connected to them. Peer Persistence is used for network load balancing, site, or data center failover. This technical white paper describes HP 3PAR Storage Peer Persistence and the impact of Peer Persistence on SPM when HP 3PAR StoreServ Peer Persistence is applied to an HP 3PAR StoreServ Storage System imported into SPM. It also provides recommendations on the HP 3PAR Storage Peer Persistence. Note HP 3PAR Peer Persistence is not supported with an SPM version earlier than 2.5. The SPM 2.5 release included enhancements for the automated replication support (new Remote Copy requirements) that enable Peer Persistence support. Customers using Matrix 7.5 with SPM 2.5 might have already defined SPM storage templates using new Remote Copy requirements and those services can participate in Peer Persistence. Other customers might be adding Matrix/SPM to an environment using 3PAR Peer Persistence and can define SPM storage templates with Remote Copy requirements for the volumes protected by Peer Persistence (and can also have templates for volumes not participating in Peer Persistence). Terminology used This technical white paper identifies the storage system that contains the data to be failed over by HP 3PAR StoreServ Peer Persistence as the source or primary array. The components, such as pools and volumes included in the array are termed as source components. The array that changes role from primary to secondary is termed as legacy. The storage system to which the data will be failed over is termed as the destination or secondary array. The components, such as pools and volumes included in the array are termed as destination components. A volume is considered online if it exists on an array that is reachable from SPM and has been imported into the SPM catalog. A volume is considered as offline if it is imported but has been removed from the array or the array it belongs to is momentarily (or definitively) not reachable, for example, due to lack of connectivity, expired credentials, and so on. Scope and limitations SPM does not support triggering HP 3PAR StoreServ Peer Persistence activity. This document provides corrective actions that you can take if Peer Persistence is triggered for an HP 3PAR StoreServ Storage System with SPM managed volumes. This document addresses two cases: 1. Primary and secondary sites managed by different SPM instances 2. Primary and secondary sites managed by single SPM instance For 3PAR Peer Persistence support and Uniform VMware vsphere Metro Storage Cluster, firmware versions on both 3PAR StoreServ arrays must be MU2 or later. For Microsoft multisite failover cluster, the version must be or later. HP 3PAR Peer Persistence Concepts Peer Persistence is a high availability configuration between two data centers in which the ESXi/Windows hosts are set up in a cluster configuration with access to storage arrays at both sites. Storage volumes created on one storage array are replicated to the other array using synchronous Remote Copy to ensure that the volumes are synchronized at all times. Peer Persistence software takes advantage of the Asymmetric Logical Unit Access (ALUA) capability that allows paths to an SCSI device to be marked as having different characteristics. With ALUA, the same LUN can be exported from both arrays simultaneously, but only the paths accepting writes to the volume are marked as active. The paths to the secondary site volume are marked as standby preventing the host 3

4 from performing any I/O using those paths. In the event of a non-disruptive array volume migration scenario, the standby paths are marked as active and host traffic to the primary storage array is redirected to the secondary storage array without impact to the hosts. Figure 1 shows a recommended Peer Persistence configuration. Figure 1. Peer Persistence setup Peer Persistence is performed either as part of failover (automatic) or network load balancing (planned). Depending on whether Peer Persistence is done for the array or a Remote Copy group, the respective component switches the role from primary to secondary and vice versa. Automatic switchover is handled by Quorum Witness (QW) software and planned switchover can be performed by running the CLI command at the source array. Separate SPM instances managing the two sites In this case, separate SPM instances manage the two sites or arrays (primary and secondary). Prior to switchover, the SPM instance managing the primary site will have services created for the primary site volumes. At the secondary site, a separate instance of SPM manages the secondary volumes. After switchover, the two SPM instances continue to manage their same individual sites and volumes with the volumes roles changed. Single SPM instance managing the two sites In this case, a single SPM instance manages both sites or arrays. Prior to switchover, SPM imports the primary array and manages primary volumes. After switchover, SPM manages the new primary volumes (earlier secondary volumes, not known to SPM). At any given time, SPM manages only the primary volume. The role can be for volumes at the primary or secondary site. 4

5 Note The Matrix Operating Environment (including Matrix OE infrastructure orchestration and Matrix OE visualization) supports only the configuration of a single SPM instance managing two sites. Matrix OE does not support separate SPM instances managing two sites. In the case of a single SPM instance managing both the sites/arrays (Figures 2 and 4), the secondary site SPM screenshots in Figures 9 through 11 can be safely ignored without losing any information. Figure 2. Before Peer Persistence (separate instances of SPM managing the arrays) Active Path Host Standby Path Sync direction Primary Array Secondary Array SPM SPM 5

6 Figure 3. Before Peer Persistence (single instance of SPM managing the arrays) Active Path Host Standby Path Sync direction Primary Array Secondary Array SPM A Peer Persistence switchover begins with the primary component (array or Remote Copy group) switching the role to secondary and the secondary component switching to the primary role. Figures 2 and 3 show the direction of data synchronization and the I/O path before Peer Persistence. Once the roles are switched, the host paths switch from active to standby mode and vice versa. After the role switchover, I/O operations occur from the host to the new primary volume and the data synchronization occurs from this volume to the new secondary volume, that is, in the reverse direction. During the role switchover, I/O operations are temporarily blocked. Once the switchover is completed, the host performs an SCSI inquiry to detect the change in target ports and thereby the new active path. Any blocked I/Os are performed through the new active path and to the new primary volume. All further I/O operations go through the new active path as shown in Figures 4 and 5. 6

7 Figure 4. After Peer Persistence (separate instances of SPM managing the arrays) Standby Path Host Active Path Sync direction Secondary Array Primary Array SPM SPM Figure 5. After Peer Persistence (single instance of SPM managing the arrays) Standby Path Host Active Path Sync direction Secondary Array Primary Array SPM 7

8 For more information on HP 3PAR StoreServ Peer Persistence, see the HP 3PAR Peer Persistence, Achieve high availability in your multisite federated environment and Implementing Microsoft multisite clustering using HP 3PAR Peer Persistence white papers, the HP 3PAR Management Console User Guide, and the HP 3PAR StoreServ Management Console 2.3 User Guide. Note The Peer Persistence feature works based on Remote Copy functionality. So, it is assumed that the users referring to this document are aware of HP 3PAR Remote Copy feature as well as the Remote Copy feature in SPM. For more information on Remote Copy feature, see the HP 3PAR Remote Copy Software User Guide. For more information on SPM use of 3PAR Remote Copy, see the HP Storage Provisioning Manager (SPM) version 2.5 User Guide. Impact on SPM Switchover results in change in the role of a Remote Copy group and the Remote Copy paired volumes of that group. The change in role reflects in SPM after the volume is refreshed either by background refresh or manual refresh. Peer Persistence does not change the zoning between the host and array. It also does not affect the presentation of volume to the host. Hence, there is no impact on the Host requirement of the SPM service. Note As the volumes are already presented to the host, the zone will already exist. To ensure reuse of the same zone during service activation, make sure to configure a port group. Specify the appropriate port group name for the Suggested Fibre Channel Port Group Name requirement. If port groups are not configured, SPM can use any of the target ports on the array and the SPM selection might not match the selection and zoning already performed by the storage administrator. Use of the optional port groups feature of SPM can force selection to be among the appropriate set of target ports. Port groups are defined in XML files and specified in SPM storage template requirements. Figures 6 and 7 show the primary volume PeerPersist_ume and its consistency group indicating that the volume is primary in the Remote Copy group PeerPersistence1. Figure 8 shows the service Peer Persist Service1 at the primary site. Figure 6. Primary volume PeerPersist_ume before Peer Persistence 8

9 Figure 7. Primary volume PeerPersist_ume s continuous copy association before Peer Persistence Figure 8. Primary site service Peer Persist Service1 before Peer Persistence See Figures 9 through 11 for the secondary volume PeerPersist_ume_back and the service Peer Persistence Backup Service 1 at secondary site. 9

10 Figure 9. Secondary volume PeerPersist_ume_back before Peer Persistence (two SPMs) Figure 10. Secondary volume PeerPersist_ume_back s continuous copy association before Peer Persistence (two SPMs) 10

11 Figure 11. Secondary site service Peer Persistence Backup Service1 before Peer Persistence (two SPMs) As part of the support for Peer Persistence, SPM matches the Remote Copy requirement of the SPM service against the already bound secondary volume at the primary site. The now secondary volume is still part of Remote Copy group and hence satisfies the Remote Copy requirement. As all requirements are validated as Match, the service remains resourced and conformant. The service at the primary site ( Peer Persist Service1 that contains the Remote Copy requirement) is bound to the secondary volume PeerPersist_ume that was the primary volume prior to Peer Persistence, Figure 12. The service is resourced and conformant after Peer Persistence (Figure 13). Figure 12. ume PeerPersist_ume at the primary site after Peer Persistence 11

12 Figure 13. Service Peer Persist Service1 at the primary site after Peer Persistence At the secondary site, the service with no Remote Copy requirement that is bound to the secondary volume continues to bind to the now primary volume with no change in requirements. As the volume is already bound to the service, the check for existence of Remote Copy requirement in the service is not performed. This keeps the service resourced and conformant. The primary volume PeerPersist_ume_back (previously the secondary volume, Figure 14) is bound to the service Peer Persistence backup Service1 with no Remote Copy requirement. The service is resourced and conformant post Peer Persistence activity (Figure 15). Figure 14. ume PeerPersist_ume_back at the secondary site after Peer Persistence 12

13 Figure 15. Service Peer Persistence Backup Service1 at the secondary site after Peer Persistence What an SPM administrator must do To use SPM with 3PAR Peer Persistence, ensure that the SPM template at the primary site includes a Remote Copy requirement. There is no need to have an SPM template with a Remote Copy requirement at the secondary site. Secondary site backup volumes are created by Remote Copy, imported into SPM, and activated using the HP Matrix Default Storage Template, which must not have a Remote Copy requirement. In SPM, for a service to bind to a primary volume of a Remote Copy group, the service must have the Remote Copy requirement matching that group. For the service to bind to the secondary volume, the service must not contain a Remote Copy requirement. Note In case of switchover due to failover where one array goes down, the volumes in that array lose the Remote Copy relationship with volumes in the other array. In such cases, the services bound to these volumes must have the Remote Copy requirement removed (if present) and be reactivated to keep the service in conformant state. The Matrix Operating Environment (including Matrix OE infrastructure orchestration and Matrix OE visualization) supports only the configuration of a single SPM instance managing the two sites. Matrix OE does not support separate SPM instances managing the two sites. Separate SPM instance managing two sites With the support for role switchover by the Remote Copy group and containing volumes, the service which is already bound to a primary volume continues to bind to the same volume as a secondary volume with Remote Copy requirement being part of the service requirements. On switchover, the service with no Remote Copy requirement bound to a secondary volume continues to bind to the same volume as a primary volume without requiring the addition of the Remote Copy requirement to the service. Overall, the SPM administrator need not perform any corrective actions at SPM post switchover to keep the previously created services resourced and conformant. Single SPM instance managing two sites SPM cannot automatically adjust its catalog to manage the changed primary volume after Peer Persistence. To manage the destination volume (the newly primary volume) instead of the legacy volume (the earlier primary volume), the SPM administrator must use the SPM GUI to perform the following tasks: 13

14 Note As the service remains conformant after switchover, you can skip these steps if you want to manage the same volume that is already bound to the service. 1. Note down the volumes that are associated with the respective services. Also note the security group to which the volumes belong and any associated tags. This information is required when the services are reassigned to the secondary volumes. 2. Deactivate the services that use the legacy volumes. Important Ensure that you change the deactivation policy to No Action as the remote copy pair, group and volume must not get deleted as part of service deactivation. 3. Remove the legacy volumes from the SPM catalog using the Remove ume option. This is necessary because the legacy volumes and destination volumes have identical UUIDs. If the legacy volumes are not removed from the SPM catalog, SPM does not discover and import the corresponding destination volumes. 4. Import the destination array if not already imported. 5. Import the destination pool if not already imported. 6. Import the destination volumes using the same security groups (and tags) used with the legacy volumes. 7. Reassign the services deactivated earlier, ensuring that each one is activated with the destination volume corresponding to the source volume used by that service. Note 1. Due to the change in Remote Copy group roles, the Group Name, Target Array and Target Pool requirement values need to be modified to match the newly imported volume to get this volume as a candidate. 2. To reuse existing zones, ensure that the SPM port groups are defined and an appropriate port group name is specified for the Suggested Fibre Channel Port Group Name requirement. The service remains nonconformant if the service (or service template) requires components (array, pool, and so on) specific to the primary array. In this case, it is necessary to modify the service (or service template) requirement to make it require components that belong to the destination array. Warning Because all destination volumes have to be imported by hand by the SPM administrator, service deactivation with deactivation policy No Action does not automatically remove these volumes. The administrator must manually remove the volumes from SPM catalog that are no longer required by SPM services. 14

15 Troubleshooting Peer Persistence unavailable due to volume unexpectedly removed from Remote Copy group on source array Symptom After the switchover, the Peer Persistence feature is unavailable for a destination volume that is no longer part of a Remote Copy group on the destination array. Cause The Peer Persistence feature is unavailable for the destination volume if the deactivation policy is not changed by the administrator from Recycle to No Action during deactivation of the SPM service bound to source volume. If the Remote Copy pair for the source volume bound to the service was created by SPM, then both source and destination volumes were removed from Remote Copy group as part of successful service deactivation. If the Remote Copy group was created by SPM and contained no other volumes, it was also deleted. If the volume was created by SPM and it was successfully removed from Remote Copy group by SPM, then the volume was deleted from the SPM catalog and from the array. Action To ensure continued successful use of Peer Persistence for the destination volume: Recreate the Remote Copy group, if required. Recreate the source volume on the array and import it into the SPM catalog, if required. Add the volume to the Remote Copy group. Activate the service with newly imported volume. Change the deactivation policy of the SPM service from Recycle to No Action. While activating a destination volume, SPM created a new zone instead of reusing the existing zone Symptom SPM created a new zone when activating a destination array volume rather than reusing an existing zone. Cause This issue occurs if the target ports that SPM selects for the destination array are different from the target ports selected by the administrator and configured in the existing zone. Action Configure a port group in SPM through an XML file, appropriately specifying the target ports of an existing zone in the same port group. Add a Suggested Fibre Channel Port Group Name requirement to the SPM service and specify the port group name that has the required target ports. Reactivate the service in SPM and reuse the existing zone. The administrator must manually delete the zone created earlier by SPM. 15

16 Destination volume is not returned as a candidate after importing into SPM Symptom When requesting candidates from the SPM managing the destination array, the expected destination volume is not returned after importing into the SPM catalog. Cause This issue occurs if the Remote Copy requirement was not updated correctly to match the Remote Copy group name, target array and pool of the volume. After the switchover, the Remote Copy group name of the destination volume is different from that of the source volume. The group name of the destination volume is generally same as that of the group name of the source volume with.r<systemid> appended to it. Also, due to a change in sync direction, the target array and pool are reversed. So, the Remote Copy requirement must be updated to match the change. Action Verify if the SPM service Remote Copy requirement contains the appropriate Remote Copy group name, target array, and target pool. 16

17 Sign up for updates Copyright 2016 Hewlett Packard Enterprise Company, L.P. The information contained herein is subject to change without notice. The only warranties for HPE products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HPE shall not be liable for technical or editorial errors or omissions contained herein , May 2016