Users Guide

Exception case
Most times, in cases of a single failure, such as a PowerStore node failure during import with host I/O, both import and I/Os are
not impacted. The other node takes over. In rare cases, if import is not able to continue due to such failures, automatic cancel
occurs and I/Os are redirected back to the source volume.
Sometimes, the node recovery time might be long and host I/Os might experience latency issues. In worst cases, the I/O
timeout expires, leading to temporary data unavailability. Recovery for such cases occurs once the node that went down
recovers fully.
If the node cannot reboot or the recovery of the node is taking too long, an option exists to go back to the source. Do a force
cancel of the import. Some manual intervention may be required at the host side that is based on the I/O load and platform.
After the host recovery step, I/Os can resume at the source again. Once the PowerStore node has recovered and PowerStore
cluster is healthy, you can attempt imports again. If you run into a problem in this procedure, it is recommended that you
contact your service provider.
Host reboot during a non-disruptive import
An unplanned host reboot during import is possible. In the case of a non-disruptive import, the import process handles this
case. If the import has progressed beyond the cutover step, import continues. If it has not, the import rolls back, which means
the import gets automatically canceled and I/Os continue go to the source. These actions apply to both stand alone and
host clusters. I/O failures may occur due to the host reboot, which is more likely in the stand-alone host case since, in the
host-cluster case, the surviving node takes over. However, I/O failures may occur even without any ongoing import sessions.
It is possible that in some configurations, for example, iSCSI, the automatic login is not enabled. Also, the host to source SAN
paths, as described in Import network overview on page 65, are not live after reboot. In such cases, this connection must be
set up before cancel can be initiated. However, imports may continue because these SAN paths are not used during import. For
example, in a Windows-based host with iSCSI connections, you must enable the option to add the connection to favorite
targets to ensure that the iSCSI connections are reestablished after any reboot.
Failures during agentless import
Some failures might be intermittent in nature, for example, due to the load of the system or network. Usually, if the import
attempt is not successful, the I/Os are not affected and they continue with the source volumes. A simple retry of the import
should suffice. Sometimes, the resolution of network or load issues is required before retrying the import. When an import fails,
the error message attempts to indicate what went wrong without getting too technical. If repeated attempts to resolve the
issue fail, contact your service provider.
If the destination loses back end connection with the source system in the SAN path during an agentless import, the import
changes to the Cancel Required state. It is possible that the errors between the PowerStore cluster and the source
network result in I/O errors to a user application. When import changes to the Cancel Required state, an alert is raised to
reconfigure the user application to use the source volume. After reconfiguring the user application to use the source volume,
cancel the import session manually. Import can be retried after the SAN paths from the PowerStore cluster to the source
system issues are resolved.
PowerStore is a dual-node, multi-appliance scale-out cluster. Typically, most failures are not fatal and are handled by the
inherent PowerStore high availability design. The import orchestrator runs inside the PowerStore appliance and is as highly
available as the PowerStore appliance. However, should there be an extreme case where a PowerStore cluster goes down
during import before cutover, reconfigure the user application back to the source system. If the entire appliance is down, both
nodes of the appliance are down. However, in a multi-appliance cluster, ongoing imports continue in other running appliances.
The imports, for which the destination volume is on that specific appliance which is down, stall. In this case it is recommended
that the appliance be brought up first before trying to cancel the stalled session.
In case of a PowerStore node failure during import, both import and I/Os are not impacted. The other node takes over. If import
is not able to continue, it changes to the Cancel Required state. When import changes to this state, an alert is raised to
reconfigure the user application to use the source volume. After reconfiguring the user application to use the source volume,
cancel the import session manually.
Sometimes, the node recovery time might be long and host I/Os might experience latency issues. In worst cases, the I/O
timeout expires, leading to temporary data unavailability. If the node cannot reboot or the recovery of the node is taking too
long, reconfigure the user application back to the source array. Recovery for such cases occurs once the node that went down
Fault handling by PowerStore import
67