Oracle ZFS Storage Appliance: How To Avoid LUN Mismatch When Using Replicated Luns to make a ZFS Pool on a Client

Asset ID:	1-72-1963940.1
Update Date:	2016-02-10
Keywords:

Solution Type Problem Resolution Sure

Solution 1963940.1 : Oracle ZFS Storage Appliance: How To Avoid LUN Mismatch When Using Replicated Luns to make a ZFS Pool on a Client

Applies to:

Integrated Software for ZFS ZS3-x Arrays - Version All Versions to All Versions [Release All Releases]
Sun ZFS Storage 7120 - Version All Versions to All Versions [Release All Releases]
Sun Storage 7410 Unified Storage System - Version All Versions to All Versions [Release All Releases]
Sun Storage 7310 Unified Storage System - Version All Versions to All Versions [Release All Releases]
Sun Storage 7210 Unified Storage System - Version All Versions to All Versions [Release All Releases]
7000 Appliance OS (Fishworks)

Symptoms

The Oracle ZFS Storage Appliance had three LUNs presented to a client host that were then used on that host as part of another ZFS pool.

All these LUNs had share level replication actions set on them and it was the replication copies of these LUNs that were used to make a ZFS pool on the client .

An issue occured such that the one of the replication actions got out of sync (or failed) . The result - on the client - was a ZFS pool that was incomplete because one LUN was out of sync with the rest.

To recover, the client host had to rebuild the ZFS pool from newly replicated copies.

Cause

This is a sample of the project status for the share level actions used in this case

Packages:

PROJECT STATE LAST UPDATE
package-000 default idle unknown
package-001 default idle Fri Dec 26 2014 20:31:10 GMT+0000 (UTC)
package-002 default idle unknown
package-003 default idle Fri Dec 26 2014 23:11:19 GMT+0000 (UTC)
package-004 default idle Fri Dec 26 2014 20:16:49 GMT+0000 (UTC)
package-005 default idle Fri Dec 26 2014 20:16:25 GMT+0000 (UTC)
package-006 default idle Fri Dec 26 2014 20:14:48 GMT+0000 (UTC)
package-007 default idle unknown

drprodcn1:shares replication source-000> select package-000 show
Properties:
  id = aefb1c03-0eca-e4e8-d208-bf57b46ce66f
  enabled = true
  state = idle
  state_description = Idle (no update in progress)
  last_sync = unknown
  last_try = Mon Dec 15 2014 17:53:22 GMT+0000 (UTC)
  last_result = The most recent replication update was canceled by an administrator.

drprodcn1:shares replication source-000> select package-002 show
Properties:
  id = 6a2bbf7e-2b66-eb2f-b88f-e51f85ad14b1
  enabled = true
  state = idle
  state_description = Idle (no update in progress)
  last_sync = unknown
  last_try = Fri Dec 19 2014 08:57:10 GMT+0000 (UTC)
  last_result = The most recent replication update failed. No additional information is available. Check replication status on the source system. See the replication documentation for more details.

drprodcn1:shares replication source-000> select package-007 show
Properties:
  id = ec5c6ad7-12ed-685c-c02f-a9c02a96b38f
  enabled = true
  state = idle
  state_description = Idle (no update in progress)
  last_sync = unknown
  last_try = Tue Dec 23 2014 15:04:47 GMT+0000 (UTC)
  last_result = The most recent replication update failed. No additional information is available. Check replication status on the source system. See the replication documentation for more details.

Thus you can see that one share level replication had failed.

Solution

It is recommended that project level replication for LUNs be used.

This would insure that the replication times would be the same for the LUN - and if any failures in replication occured, it would affect all at the same time and not leave one LUN out of sync with the others.

References

<NOTE:1634030.1> - Oracle ZFS Storage Appliance: Replication Best Practices
<NOTE:1937173.1> - Oracle ZFS Storage Appliance: ISCSI LUNs Allocated to Linux Clients Fail Discovery with "Logical Unit Not Accessible" Errors

Attachments

This solution has no attachment