VPLEX: Active metavolume sharing array

This issue is caused by the precheck command seeing that both legs of the active metavolume are on the same back-end array. This may be due to:
 

• The metavolume was initially configured with only one back-end array available, and both legs were set up on that single array. This situation was not updated when a second array was added to the VPLEX.
• The metavolume was initially configured by the user setting two volumes from one array even though two or more arrays were attached to the VPLEX. This is not a supported action where two or more arrays are attached to the VPLEX and must be fixed by reconfiguring the metavolume with the legs being set up on two different arrays.

To correct this error, check if another volume, meeting the required criteria for a meta volume, is available on a second array, if a second array is now available.

Best Practice requirements for a meta volume are there must be two (2) storage volumes that are:
 

• Unclaimed

• 78 GB or larger

• On different arrays

• Thick Provisioned (not built using thin LUNs)

Procedure:
 

1. Check for available metadata volume candidates using KB article 000158150, "VPlex: How to list storage volumes that are eligible candidates that may be used to create metadata volumes", for the process of displaying the storage volumes which meet the criteria for a VPLEX Meta Volume. 

2. Once you have another volume on a different array that meets the criteria, attach this new volume to the current meta volume using the 'meta-volume attach-mirror' CLI command.

3. At the VPlexcli prompt change directory (cd) to the 'system-volumes' context and run the long list,  ' ll ',  command. You should see the active metadata volumes 'operational status' showing as 'degraded' and the 'Health State' as 'minor-failure'.

4. Run the 'rebuild status' command, this should show the meta volume as rebuilding, and the 'rebuild type' should be 'full' as it is a new rebuild.

5. Check the component level of the meta volume to see the newly attached leg. Run the command 'll <meta-volume name>/components', this will show the new component as 'Slot Number 2' as displayed in the example below, its 'operational status' is 'error', and its 'Health State' is 'critical-failure'.

           
           Sample output:

6. Wait for the full rebuild to complete, which may take time, be patient. You can check the status of the rebuild by running the 'rebuild status' command, off and on, until you see that the rebuild has completed.

7. Repeat step 3 and the meta volume should now show its 'Operational Status' and its 'Health State' as 'ok'.

8. Repeat 5 to check that the new leg is showing as 'Slot Number 2' and its 'Operational State' and 'Health State' both show as 'ok'.

9. Remove the leg of the meta volume that is listed as slot 1, as it is on the same array as the leg listed as slot 0, by running the 'meta-volume detach-mirror' command as shown below:

10. Run the command from step 8 again and you should now only see two volumes that are listed, each from a different array, with 'Slot Number' for '0' and '1'.

11. Confirm that the meta volume and backup meta volumes are good by running the CLI command as shown below:

12. Since you created a meta volume, the backup meta volume is not accurate. As you see above in step 11, the metadata backups on cluster-1, where the new meta volume was created for the examples in this KB, show as having last run a backup around the beginning of June. You need to destroy the old backups and configure new backups. To do this, refer to KB article 000038636, "VPLEX: 0x8a4a6006,0x8a4a6003,0x8a4a6005, The automated backup of the metavolume could not be completed (or) No valid backup metavolume exist (or) Metadata Backup could not be destroyed", and follow the steps in the workaround under the Resolution section. Each backup volume must also be on different arrays when two or more arrays are attached to a VPLEX. This is for redundant purposes.