Hi all.
I am working with SSMC v3.7, defining new reports customized to my environment. We make backups from snapshots (all called "snp_<parent-disk-name>") whose life last while the backup is running. Therefore, during the day we have different snapshots in different moments of the time.
I am trying to get a virtual volume performance report only for snapshots disks. The problem when building the report is that SSMC only offers the name of the volumes it just sees in the 3Par in that moment. As far as I know, there is no possibility, through the web interface, to specify something like "snp*" when choosing the disks.
I have done a test. I have configured, through the web interface, one report for four snapshots disks in a moment of the day and exported the reports through the "exports" option of the menu. I have unzipped the file and modified the corresponding json file to specify, in the appropiate field, "snp*" instead of the snapshots disk names, saved the file and zipped al the files again. But, when trying to import the zip file, through the "import" option of the menu, I get the following message:
"<file.zip> is corrupted. Checksum failed."
I don't know if it's possible to do what I am trying to do or if there is a possibility to do it in another way. I have tried the Excel plugin but this only builds graphs from the default reports. I have also checked the documentation and I haven't seen anything that can help me.
I know that I can build the report using the 3par performance commands but I want to make use of the automatic graphs generated by the SSMC.
Any help will be very appreciated.
Thanks in advance.
Regards.
Ana
SOME ISSUES ABOUT SSMC REPORTS
Re: SOME ISSUES ABOUT SSMC REPORTS
Hi.
I'm having some trouble following your chain of thoughts.
What are you trying to get into your report? A combined report for all volumes (snap is a volume) called "snp*" (keep in mind that two different snaps of the same volume with the same name would be considered two different volumes by the 3PAR)? Or are you trying to get one graph per volume called "snp*" ? Would it be enough to get one report for all snaps (regardless of name)?
I'm having some trouble following your chain of thoughts.
What are you trying to get into your report? A combined report for all volumes (snap is a volume) called "snp*" (keep in mind that two different snaps of the same volume with the same name would be considered two different volumes by the 3PAR)? Or are you trying to get one graph per volume called "snp*" ? Would it be enough to get one report for all snaps (regardless of name)?
The views and opinions expressed are my own and do not necessarily reflect those of my current or previous employers.
Re: SOME ISSUES ABOUT SSMC REPORTS
Hi.
Well, I'll try to explain myself better.
What I mean with "snp*" is a way to refer to all the snapshots we create during the day. The snapshots are ephimeral because they dissapear when the backups finish but they allways have the same name when they are created. All of them begin with the word "snp" followed by the parent virtual volume name. For example, snp_D-Cor-1, snpdd_D-Atdi-2, etc. (where D-Cor-1, D-Atdi-2 are the parent volumes that are permanent).
My objective is to create a report with performance information ONLY from snapshots volumes created during all the day. I have seen in the reports menu that there is a possibility to select objects (virtual volumes) based on the type of cpg, provisioning, ... but there is no way to refer only to snapshots volumes.
So, summarizing, ¿is there a possibility to get a performance report for ONLY snapshots volumes throug SSMC?
Thanks in advance.
Ana
Well, I'll try to explain myself better.
What I mean with "snp*" is a way to refer to all the snapshots we create during the day. The snapshots are ephimeral because they dissapear when the backups finish but they allways have the same name when they are created. All of them begin with the word "snp" followed by the parent virtual volume name. For example, snp_D-Cor-1, snpdd_D-Atdi-2, etc. (where D-Cor-1, D-Atdi-2 are the parent volumes that are permanent).
My objective is to create a report with performance information ONLY from snapshots volumes created during all the day. I have seen in the reports menu that there is a possibility to select objects (virtual volumes) based on the type of cpg, provisioning, ... but there is no way to refer only to snapshots volumes.
So, summarizing, ¿is there a possibility to get a performance report for ONLY snapshots volumes throug SSMC?
Thanks in advance.
Ana
Re: SOME ISSUES ABOUT SSMC REPORTS
The way I see it, I don't think so.
There is no general performance "Report Template" for VVs, only exported VVs.
I'm guess taking a guess on the reason why it doesn't exist is that it wouldn't provide any real value. I understand what you're trying to do, but I still don't understand quite what you are trying to achieve...
Remember that snapshots on 3PAR contains the original data in the blocks that did change since the snapshot was taken. So the snapshot would see VV performance numbers as snapshot is being updated by data overwritten in the source volume. I'm assuming you also have a backup server that gets these snapshots presented during backup. If you were interested in the backup speed, you could simply review the performance numbers for the backup hosts (or look at the logs from the backup software).
Another thing I also would question is whether the System Reporter actually keeps performance information about deleted volumes/snaps. It will of course keep the total performance numbers, but most/all references to the deleted volumes/snaps are ... deleted ... from the 3PAR, so when System Reporter is looking at performance data for VV ID 12345, it will probably not be able to figure out that VV ID 12345 was "snp_D-Cor-1" 5 hours ago, hence not being able to make a match (if it was made possible). "snp_D-Cor-1" is most likely only a reference used to allow us humans to keep track of what's what.
The closest thing to this I can find is CLI and "srstatvv -prov snap" with whatever parameter you'ld like (you can throw in VV names etc here, but not sure if it will provide any details for expired/deleted snaps/volumes).
There is no general performance "Report Template" for VVs, only exported VVs.
I'm guess taking a guess on the reason why it doesn't exist is that it wouldn't provide any real value. I understand what you're trying to do, but I still don't understand quite what you are trying to achieve...
Remember that snapshots on 3PAR contains the original data in the blocks that did change since the snapshot was taken. So the snapshot would see VV performance numbers as snapshot is being updated by data overwritten in the source volume. I'm assuming you also have a backup server that gets these snapshots presented during backup. If you were interested in the backup speed, you could simply review the performance numbers for the backup hosts (or look at the logs from the backup software).
Another thing I also would question is whether the System Reporter actually keeps performance information about deleted volumes/snaps. It will of course keep the total performance numbers, but most/all references to the deleted volumes/snaps are ... deleted ... from the 3PAR, so when System Reporter is looking at performance data for VV ID 12345, it will probably not be able to figure out that VV ID 12345 was "snp_D-Cor-1" 5 hours ago, hence not being able to make a match (if it was made possible). "snp_D-Cor-1" is most likely only a reference used to allow us humans to keep track of what's what.
The closest thing to this I can find is CLI and "srstatvv -prov snap" with whatever parameter you'ld like (you can throw in VV names etc here, but not sure if it will provide any details for expired/deleted snaps/volumes).
The views and opinions expressed are my own and do not necessarily reflect those of my current or previous employers.
Re: SOME ISSUES ABOUT SSMC REPORTS
Hi.
Yes, I understand what you mean. But, in our environment, when I generate a graph for all virtual volumes, parent VVs and snapshots, for a whole day, there are points in time when I see that, for example, the IO operations per second for some snapshot volumes is a great value compared to the mean values for this topic for the rest of the VVs. This means the backup is accessing directly to the snapshot volume data because data at the parent VV have been modified after snapshot creation. In this case, the graphical figure doesn't clearly show the drawing for the rest of the VVs because the figures at the Y axis scale up to the maximum value, nearly "hidding" the lower values. This is, mainly, the reason to separate the reporting between the parent VVs and the snapshot VVs: to see clearly the graphs for both types of VVs.
Anyway, the question has been answered and, as a workaround, I can use, as I already knew, the CLI performance commands to get the performance report data that can be converted to a graph through an spreadsheet application.
Thank you very much for all your explanations.
Regards.
Ana
Yes, I understand what you mean. But, in our environment, when I generate a graph for all virtual volumes, parent VVs and snapshots, for a whole day, there are points in time when I see that, for example, the IO operations per second for some snapshot volumes is a great value compared to the mean values for this topic for the rest of the VVs. This means the backup is accessing directly to the snapshot volume data because data at the parent VV have been modified after snapshot creation. In this case, the graphical figure doesn't clearly show the drawing for the rest of the VVs because the figures at the Y axis scale up to the maximum value, nearly "hidding" the lower values. This is, mainly, the reason to separate the reporting between the parent VVs and the snapshot VVs: to see clearly the graphs for both types of VVs.
Anyway, the question has been answered and, as a workaround, I can use, as I already knew, the CLI performance commands to get the performance report data that can be converted to a graph through an spreadsheet application.
Thank you very much for all your explanations.
Regards.
Ana