Improvement suggestion for cdp ui

[FrenchBlue]

Hello,

Is there a specific place for improvements suggestions? Or here is fine?

Currently if we want to check the size of a replica restore point and the journal files, we have to go to the Replicas view, then check each VM individually by right-clicking->Properties, wich is quite annoying. It would be way better if there were simply 2 more columns on the Replicas view with these values, then we would see all VMs restore point and journal sizes at a glance.

[veremin]

This is a perfect place to submit your requests.

So you want to have two more columns added to the Replicas view: total size and total journal size? This information will not cover individual restore point consumption, though. Plus, the second column will work only for CDP-replicas and not for snapshot-based ones.

Anyway, we will think about how the experience might be improved in future product versions.

Thanks for the feedback; appreciate it.

[FrenchBlue]

Hello, yes, the 2 values that you see when you right-click the VM in the replicas view and select "Properties".

[veremin]

That might require splitting the current "Replicas" view into two nodes because one of the properties (transaction log size) does not concern snapshot-based replication anyhow, which might not be necessarily what we are planning for.

Having said that, we will still give a thought about improving the current approach in the future.

Thanks!

[FrenchBlue]

I don't get the point, I'm only talking about cdp here, nothing to do with snapshot-based replications. BTW, the whole cdp ui needs revamping, it seems that it has been derived from the regular backup jobs interface, including the alerting/mail reporting, but lots of things don't work as they should, because cdp is something else.
I suppose that you already know it and that the resources are more focused on fixing the base cdp functions at the moment, which is fine, but the whole thing still needs a lot of efforts to be really productive and manageable.

[veremin]

The replica view is shared between both replication types, so adding there a column that is related to only one particular type does not seem feasible. But we are keeping an eye on potential improvements, indeed.

the whole cdp ui needs revamping, it seems that it has been derived from the regular backup jobs interface, including the alerting/mail reporting, but lots of things don't work as they should, because cdp is something else.

We'd appreciate if you could elaborate on this portion: what exactly is not working correctly for CDP which has its own reporting built around RPO?

Thanks!

[FrenchBlue]

Hello,

Good idea, I will report here the areas that could be improved, I have lots of ideas I just need to find a suitable image hosting because some will need screenshots.

[FrenchBlue]

Hello,

So, here is a good example to start with, email reporting. Several points below are also the same for the cdp ui in VBR.



1) email title is "Failed", but inside the mail, all VMs have "Success" status so this is a bit confusing. Which VM failed?
2) What's the trigger to send these "failure" emails exactly?
3) SLA 70%? How is it calculated? And all VMs SLA's appear at 100%, so why is the job SLA à 70%
4) Global "Max delay" is indicated at 3 hours, but again, in the list of VMs, all max delays are at zero, so what's right exactly?
5) "Warning: 3". What? When?
6) "Success: 17" but there are only 10 VMs in the cdp job, so it seems again meaningless

There is much confusion, missing info, or even contradictory information in this, so in the end it's quite useless unfortunately.

[veremin]

The data provided in the report does not seem correct. Have you already opened a support ticket for this (so we can check it internally)? Thanks!

[FrenchBlue]

Hello,

No, not yet. cdp reports have always been like that, since the very beginning in V11. Finishing a couple of other cases almost done and I can open another one if required.

[veremin]

The report looks strange, so we'd be interested to analyze the problem further.

Kindly, share with us the ticket number (once you have one) - we will assist with the investigation process.

Thanks!

[FrenchBlue]

Oki will do that. All these replicas have been recreated after cp2 patch (which seems to have solved other issues), but the reports always have been like this since the very beginning of our cdp usage.

[veremin]

They look unexpected to us: contradictory states, SLA discrepancies, etc.

So once we get a new ticket with the required debug data, we will be glad to participate in further issue analysis.

Thanks!

[FrenchBlue]

Hello,

Case created, #06127159

[veremin]

In order to provide help here, we need current screenshots of misbehaving CDP policies coupled with the policy debug logs. It seems that both are currently missing in the given case. Thanks!

[FrenchBlue]

Hello, VBR logs and another screenshot uploaded.

[veremin]

Thanks for the additional details, we will review the case internally.

[veremin]

We are about to take over your ticket and review it this or early this week. I will update the thread, once we have more information. Thanks!

[veremin]

The case is still in the hands of the R&D team. Unfortunately, all our current resources are concentrated on the next cumulative patch release, so we haven't managed to investigate the issue.

I will post an update, as soon as we find something.

Thanks!

[FrenchBlue]

Hello,

No problem, there is no major issue here. But I'm interested in the list of cdp-related fixes of the next cumulative patch Case 06145976 is a real issue.

Thanks.

[veremin]

We’ve seen this ticket and checked it briefly. Based on preliminary investigation, it was not clear whether the CDP policies left the obsolete data and filled the datastore or whether the datastore ran out of free space and thus the policy stopped.

The R&D team is still occupied with patch-related activities and will review the case again next week.

However, if you want to discuss this issue further, consider creating a new thread (in order not to overfill the discussion with side questions).

Thanks!

[FrenchBlue]

Hello,

I had already explained it twice in the mails, and now 3 times..... The datastore full and then the policies pause were a consequence of the obsolete data, not a cause. But indeed, it's a different subject from this thread, so let's keep it in its support case.

Thanks.

[veremin]

We saw that explanation, but debug logs suggested us a different conclusion. Either way, let's wait till our team has time to review both tickets further and see the outcome. Thanks!

[veremin]

The R&D team has checked both tickets:

1) The discrepancy in the report might be explained by the fact that the upper table shows daily information (values aggregated from all sessions executed within the day) while the lower one provides only the latest sessions only. To find the problematic session you might want to use the History node (where all historical information is available).

Plus, it’s worth configuring the RPO reporting mentioned earlier – this way you will receive an email as soon as one of the replicated VMs fails to meet the specified RPO (so errors and warnings will be caught immediately).

2) The logs didn’t confirm the assumption that the CDP policy left over the obsolete transaction logs. The debug data showed that the datastore run out of free space and thus the CDP policy got disabled. The active CDP policy removed the files successfully (which was also tracked in the collected logs).
I’m posting an update here for the convenience of future readers.

If you have any questions regarding the conclusions, it’s better to raise them within the existing support tickets – as forum correspondence isn’t necessarily suitable for prolongated investigation.

Thank you for your understanding.

[FrenchBlue]

Hello,

I'll just comment on 2) as I did already several times in the cases: the datastore out of free space was not at all a cause, but a direct consequence of the terabytes of orphaned files left there by cdp.