SyncIQ - clean up after failback

dynamox,

What these snaps are for is something new in SyncIQ as they are not necessary for failover and failback to succeed. The SME, and I apologize for my misunderstanding here, was indicating they are a manual process by the SIQ engine, not you. They are there for redundant purposes to protect the data in the case of a failure in the failover/failback event. They are perfectly safe to remove after your failover has completed.

Katie Johnson wrote: dynamox, What these snaps are for is something new in SyncIQ as they are not necessary for failover and failback to succeed. The SME, and I apologize for my misunderstanding here, was indicating they are a manual process by the SIQ engine, not you. They are there for redundant purposes to protect the data in the case of a failure in the failover/failback event. They are perfectly safe to remove after your failover has completed.

Katie,

why are they not removed automatically or at least documented in the SyncIQ documentation ?  They are going to sit there and keep growing, unnecessarily consuming space.

I have yet to get a response that makes sense of why we need mirror_policy to remain on secondary cluster.

Thanks

Hello Dynamox,

The automatic removal, or lack thereof, of these snapshots was a design decision when the feature was implemented as I understand. This will be brought up to the team to get any and all documentation corrected for the SyncIQ module.

As for why the mirror policy needs to stay, in short, it doesn't. Isilon recommends leaving the mirror in place to preserve the LIN map to reduce time to recovery should you need to failover again, but this policy can be removed at your discretion.

Katie Johnson wrote: Hello Dynamox, The automatic removal, or lack thereof, of these snapshots was a design decision when the feature was implemented as I understand. This will be brought up to the team to get any and all documentation corrected for the SyncIQ module.

what was the reasoning behind that design decision ?

Katie Johnson wrote: As for why the mirror policy needs to stay, in short, it doesn't. Isilon recommends leaving the mirror in place to preserve the LIN map to reduce time to recovery should you need to failover again, but this policy can be removed at your discretion.

same as above, why does it need to stay for failover when i can failover within seconds when it's not there initially.

Nothing personally Katie but i am somewhat dissapointed in the responses that we are getting about this functionality.  I am not asking for the source code here, but for design decisions behind why something was implemented the way it is today. Can you get your SyncIQ SME drop in and provide some answers ?

Thank you

Hello All,

I have reached out to some additional resources to get their input here. As soon as I receive any more information, I will post it here. If the additional resources are able, they will supply their expertise here as well.

Hi Katie,

any News on this?

Regards

--Steffen

Hello,

I have not received an update as of yet, I am reaching out again today in hopes of getting more information. I apologize for the delay.

The source policy modification is done by the system, it adds the mirror policy id in order to bind the two policies essentially.

As far as the second question with snapshots, I do not have an answer for. It is definitely something that could be discussed within my team as a future change.

robertmrozik wrote: will try to explain the best I can with some examples on why the failover policy needs to stay. When we create the failover policy "*_mirror" it is tied directly to the original source policy. You do not want to delete the failover policy because the source cluster retains the id of the "*_mirror" policy and future failovers may not succeed depending on the OneFS version you are on. example policy "aggressive": Mirror policy on the target ID: policy-record policy-id="000c29f8777ed9bde555721bd92ceccf" Original policy info after mirror is created: policy.4.common.name {token:99} = "aggressive" policy.4.common.mirror_pid {token:101} = "000c29f8777ed9bde555721bd92ceccf" Note above that in the policies .gc file it holds the mirror ID for reference. In later versions deleting the failover policy is not an issue, i.e. 7.2 but in previous versions this would halt failover/failback.

why are you making changes to original policy and what is that you are doing to it that future failover "may" not succeed ?

robertmrozik wrote: As far as the failover snapshot is concerned this can be removed on the target without issue AFTER failover/failback has been completed. This will avoid snap growth. Keep in mind that you never want to delete a SyncIQ snapshot that is labeled SIQ- -new or SIQ- -latest as this will essentially reset the policy and cause a full re-sync to occur.

why aren't you deleting it as part of the failback process ?

Thanks

robertmrozik wrote: The source policy modification is done by the system, it adds the mirror policy id in order to bind the two policies essentially.

why do they need to be binded together ?  There has to be a logical/engineering reason you are doing this otherwise i would not be able to failover for the very first time.

robertmrozik wrote: As far as the failover snapshot is concerned this can be removed on the target without issue AFTER failover/failback has been completed. This will avoid snap growth. Keep in mind that you never want to delete a SyncIQ snapshot that is labeled SIQ- -new or SIQ- -latest as this will essentially reset the policy and cause a full re-sync to occur. In regards to the linmap, it resides on the target of the policy. So in a failover situation the original source holds the "*_mirror" linmap.

Hi Robert,

thanks for your response. You said we are allowed to delete the Failover snapshot, but not SIQ-%id-latest and SIQ-%id-new. since SIQ-%id-latest grows on the target side until the next Failover i would like to know how i should handle this snapshot? the "snapped" data is (from my point of view) completely useless since it will be discarded on the next Failover.

Regards

--Steffen

I am working to get a more technical response to your question, the primary reason that I am aware of for the association between the original and mirror policy is for informational purposes. The mirror policy will take info from the original policy during its creation. As far as a more engineering level explanation, I will get back to you as soon as I have more info.

There should not be a -latest snapshot on the target if failover/failback completed successfully. The only snapshot that should remain on the target for the specific policy is the SIQ-Failover- - snapshot.