OC Protection Manager Dynamic Referencing

[mark_schuren]

Hi all,

again I have a question / problem regarding DFPM dynamic referencing, which still annoys me up to the current (5.1) version. This question came up at different customer installs.

Example: Assume a dataset with "Backup" (vault) policy. I configure one volume (which houses a couple of qtrees) as the primary ressource. PM "conforms" it, provisions secondary vol, and initializes a number of SnapVault relationships (one for each qtree plus one for non-qtree-data).

Work fine so far. After that the dynamic referencing works, so if customer adds another qtree to the primary vol (using system manager, CLI or the NMC Provisioning component), then a backup relationship is automatically created and monitored. Very nice.

However, the problem comes with "dynamic DEreferencing"... As an example I assume primary qtrees named qt1, qt2, qt3 and qt4. As soon as qt5 is created, dynamic referencing kicks in and protects this qtree. Fine.

But if one of these qtrees in being DELETED (e.g. by using system manager - even when using then Provisioning component in NMC), there is no automatic de-referencing.

Why is that? My customers sometimes archive / delete old shares / qtrees - yes they do 😉 some of them do it regulary 🙂

What happens then is:

- On next monitoring interval, DFM discovers that the qtree has been deleted, and marks it as deleted in the DB (without checking for dependent relationships)

- DFPM quietly "forgets" about the relationship, which it has once created.

- The relationship is silently removed from the dataset, and does not show up in external relationships (probably it cannot be mapped by DFM monitor because the primary qtree object is "marked deleted").

- However, both source and destination Filers still know about the relationship! "snapvault status" on both primary and secondary system still shows it. And they both have a common snapshot for it.

- There's no way from within OnCommand to "clean up" (or even "see") this relationship anymore. It just sits there on the Filers, gets old, and after weeks somebody notices the "too old snapshots" alert.

- A manual look into CLI or system manager then shows the reason: a "too old vault relationship"

My current workaround/cleanup method is:

- Do manual "snapvault release" for the deleted qtree on the source filer

- Delete old baseline snap on source if still there after release

- Do manual "snapvault stop" for the deleted qtree on the destination

- Delete old baseline snap if still there after stop

So:

How useful is dynamic referencig without dynamic DE-referencing??

How useful is a "unified" monitoring / backup system that does not clean up or even show backup relationships (which were created by itself) where the primary ressource has been deleted...?

My main question is:

Will that finally be fixed in OCUM 5.2 ??

[adaikkap]

Hi Mark,

     To answer your question to my knowledge its not fixed in OCUM 5.2. The current way to handle is not to use dynamic referencing if you keep deleting qtrees.

I strongly recommend you raise a case with this behavior so that it could be fixed in an upcoming release.

Regards

adai

[mark_schuren]

Hi Adai,

so if I get it right OCUM would clean up a relationship when the primary qtree gets deleted, just only because dynamic referencing is/was NOT active?

From all my installs and lab testing, dynamic referencing is a very good any higly appreciated feature. But an existing SV relationship (managed by OCUM) is always "automagically orphaned" by deleting one primary qtree (on purpose).

The only way to prevent that is to have all the qtrees within the dataset seperately as the primary ressource (or imported relationship) - which makes autoamtic cleanup work, but kills the dynamic referencing...

To be honest, I'm not sure if want to keep myself busy with NGS tech support regarding a feature that doesn't exist in the product... I'm a solution architect / PS consultant, always busy in projects, so no time to gather logs etc. to finally hear from NGS that deleting a qtree and expecting OCUM to cleanup its own stuff (or at least give a warning about this) is a non-existing feature... My customers call me regularly because of this "feature" - they LOVE dyn ref, but they cannot understand why deletion of a qtree causes these orphans. I also cannot, and I lack the time of explain this again to level 1 tech support 😉

Please just take it as an RFE from a senior field guy, and maybe put it onto a "future version wishlist" if you can.

Thanks, regards,

Mark

[adaikkap]

Hi Mark,

     I have already passed on your feedback to the Engg teams. Here is a response that I got back from them. I an not saying your expectation is wrong. I am filing a RFE for the same so it gets addressed in a future release.

This was intended as the preferred behavior when the DFM could not find once discovered objects on the filer anymore. Our Mantra has always been not to destroy (data OR relationships). There are many reasons why an object such as a qtree or volume would seem as deleted to DFM (delayed monitoring, busy filers, volumes going offline temporarily and others). We DID NOT want to assume that the object is deleted and destroy it along with its existing relationship when it very well could have been alive and just not visible to DFM (we have had angry customers in the past who suddenly found their objects destroyed). The assumption for the existing behavior was that if the user wants to delete objects and their relationships, they will do it directly from the filer and they would give them much better control. Even when the primary members are removed from the dataset, we make the relationship external and do not destroy it.

Regards

adai

[mark_schuren]

Hi Adai, thanks for the info.

I understand that automatic delete / cleanup is not a good thing for objects that seem to be deleted (maybe are just temporarily unavailable).

However, there are two things / requests from customers regarding this specific behavior:

- When a dynamically referenced qtree is deleted ON PURPOSE USING storage system CLI/API, the corresponding relationship is NOT listed under external relationships afterwards!

I think dfmmonitor marks it as deleted as soon as it marks the qtree as…? THIS is not logic. The admin needs to see it in external relationships, in order to not forget it, and take manual care about it.

- When a dynamically referenced qtree is deleted ON PURPOSE USING NMC Provisioning capability – why does NMC UI not ask what to do with the corresponding relationship?

I personally think this simply is a missing UI feature. Just a little checkbox “cleanup relationships when deleting this qtree” would make the problem go away, this would be logic for the admin, and would automate the cleanup just like the prior creation of the relationship was automated .

Mark

Von: Adaikkappan Arumugam

Gesendet: Samstag, 23. Februar 2013 04:52

An: Mark Schuren

Betreff: - Re: OC Protection Manager Dynamic Referencing

<https://communities.netapp.com/index.jspa>

Re: OC Protection Manager Dynamic Referencing

created by Adaikkappan Arumugam<https://communities.netapp.com/people/adaikkap> in OnCommand Management Software - View the full discussion<https://communities.netapp.com/message/101128#101128>

Hi Mark,

I have already passed on your feedback to the Engg teams. Here is a response that I got back from them. I an not saying your expectation is wrong. I am filing a RFE for the same so it gets addressed in a future release.

This was intended as the preferred behavior when the DFM could not find once discovered objects on the filer anymore. Our Mantra has always been not to destroy (data OR relationships). There are many reasons why an object such as a qtree or volume would seem as deleted to DFM (delayed monitoring, busy filers, volumes going offline temporarily and others). We DID NOT want to assume that the object is deleted and destroy it along with its existing relationship when it very well could have been alive and just not visible to DFM (we have had angry customers in the past who suddenly found their objects destroyed). The assumption for the existing behavior was that if the user wants to delete objects and their relationships, they will do it directly from the filer and they would give them much better control. Even when the primary members are removed from the dataset, we make the relationship external and do not destroy it.

Regards

adai

Reply to this message by replying to this email -or- go to the message on NetApp Community<https://communities.netapp.com/message/101128#101128>

Start a new discussion in OnCommand Management Software by email<mailto:discussions-community-products_and_solutions-storage_management_software@communities.netapp.com> or at NetApp Community<https://communities.netapp.com/choose-container.jspa?contentType=1&containerType=14&container=2026>