Josean01

1 Rookie

•

7 Posts

0

1210

May 11th, 2020 08:00

Getting an error in failover proccess when trying to enable_image_access.

Hi.
I want to expose a problem that we are encountering with RecoverPoint when trying to failover in an installation with only a non-production copy.

From the DR site to the site of the old production (failover has been done previously in the opposite direction, that is, I am now trying to reestablish the situation as if it were the failback process) we're getting an error.
This failover process is being done by CLI for project needs, since it requires giving the commands to an orchestrator.
As it was said, when in this failover process we try to execute the command enable_images_access it gives an error in the parameter "copy" (Error: Invalid 'copy' parameter).
We do not understand what the problem may be, because by GUI, this failover process in both directions is always carried out correctly.
These are the commands that are executed before failover and as you can see the command "enable_images_access" gives an error, previously the group is verified to see its situation with the command "get_group_state".

enable_image_access group=SCLU_MXSS3BUS1001_TEST_IRO copy=TEST IRO image=latest_image access_mode=logged
Error: Invalid 'copy' parameter.
Type 'help enable_image_access' for help with this command.

get_group_state group=SCLU_MXSS3BUS1001_TEST_IRO
Group:
SCLU_MXSS3BUS1001_TEST_IRO:
Enabled: YES
Transfer source: DR_SCLU_MXSS3BUS1001_TEST_IRO
Copy:
DR_SCLU_MXSS3BUS1001_TEST_IRO:
Enabled: YES
Active primary RPA: RPA 3
Storage access: DIRECT ACCESS (marking data)
TEST IRO:
Enabled: YES
Active primary RPA: RPA 3
Journal: DISTRIBUTING IMAGES TO STORAGE
Storage access: NO ACCESS
Max journal size: 1.09 TB
Link:
DR_SCLU_MXSS3BUS1001_TEST_IRO->TEST IRO:
Data Transfer: ACTIVE
Sync mode: NO

We are doing something wrong, but we are not able to see where the error is. Someone who can help us ...

Thank you.

Responses(6)

DELL-Sam L

Moderator

•

7.1K Posts

0

May 12th, 2020 12:00

Hello Josean01

Here is a link to a KB that may help.

https://dell.to/35XLjVY

Please let us know if you have any other questions.

J

Josean01

1 Rookie

•

7 Posts

0

May 14th, 2020 02:00

Hi, DELL-Sam L.

Something must be wrong with link : https://dell.to/35XLjVY

I'm receiving this error message :

"We can't log you in. Check for an invalid assertion in the SAML Assertion Validator (available in Single Sign-On Settings) or check the login history for failed logins."

Could you please, help me ?, another way to get to that URL?.

Thanks a lot, best regards.

DELL-Sam L

Moderator

•

7.1K Posts

0

May 14th, 2020 11:00

Here is what the KB states.

Issue	Issue: (Impact on customer): Can't do any configuration change (test copy, failover, image access) when production XtremIO array is down and RPAs at the production are up. Impacted Configuration & Settings: XtremIO at the production. Impact on RP: Can't perform any configuration change on the relevant CG to DR (test copy, failover, image access). Symptoms found in the logs: In management logs at the DR site: 2017/07/02 21:45:07.284 - #2 - 15342/14862 - MgmtAction: groupCopyID = GroupCopy(842247067 SiteUID(0x5b28ea4d) 0)checkXioCopy: exceeded maximum number of XiO snapshots on array arrayID = ARRAY_XIO-1499f64 numOfDesiredSnapshots:64 maxXioSnapshots:NoOption Warning seen when trying to do Image Access: From the RecoverPoint GUI/CLI: Error: The specified "Maximum number of snaps has exceeded the number of snaps supported by the XtremIO array. (N/A)"

Cause	Root cause: Can't read information from the XtremIO array, which block the configuration change at management server.

Change	Production RPAs were up and the XtremIO was down during disaster.

Resolution	Resolution: Dell EMC engineering is currently investigating this issue. A permanent fix is still in progress. Contact the Dell EMC Customer Support Center or your service representative for assistance and reference this solution ID. Workaround: Shut down the RPAs at the production site where the XtremIO is down.

I

Idan

675 Posts

0

May 18th, 2020 12:00

You're missing quotes on the copy name. Try the following:

enable_image_access group=SCLU_MXSS3BUS1001_TEST_IRO copy='TEST IRO' image=latest_image access_mode=logged

J

Josean01

1 Rookie

•

7 Posts

0

May 19th, 2020 03:00

Hi Idan.
Thanks for your post. Following your instructions the problem has been resolved. After putting the arguments "copy" in the commands "enable_image_access" and "failover" in single quotes they have worked. This time the behavior of these commands has been strange to me because I have not been able to see in any manual that both commands should be enclosed in quotes. In fact we have done many "Test Copy" like DR Test and "enable_image_access" without quotes in "copy" argument have always worked.
Testing in the Test environment we have, to practice the failover procedure, I have personally run "enable_image_access" and "failover" to bring the output to the DR site without putting the "copy" argument in quotes and it has always worked for me as well. However, when I have tried to return the production to its original site from the DR site (failback procedure) it is when these problems have arisen.
Can we say then that in the failback process, when we failover from DR to Prod is it necessary to put this "copy" argument in quotes? only in the failback process? Is there any other time when this "copy" argument should be in quotes?
These questions are only to be able to document the procedure to our client.
Thank you very much Idan for your support, I have already fixed this procedure and I can continue with the other cases of production unavailability.

Thanks a lot, best regards.

I

Idan

675 Posts

0

June 3rd, 2020 11:00

Thanks for the update, glad it was helpful

View All

No Events found!