Analyzing Global Mirror Change Volume and finding solutions to GMCV problems
mipi 270004DGB0 Visits (236)
In the last blog post, I showed how easy it is to monitor an SVC / Storwize Global Mirror Change Volume (GMCV) with BVQ.
Why is GMCV monitoring so important?
What do you have to answer to, when a service level agreement was signed to ensure data recovery?
Analyzing and finding solutions to the GMCV problem
Using the Monitoring Dashboard, an Analysis Dashboard can be accessed directly from a consistency group, which is in yellow or red.
This analysis dashboard then shows the complete end-to-end connection from the production system to the storage in the secondary system.
Also, in the analysis dashboard the highest attention was paid to clarity and easy to understand charts.
Row 1, you can see the incoming data (blue) written by the servers to the production volumes. This activity leads to further writing on the so-called change volumes (blue) in row 2, which are responsible for ensuring that the changes are transferred. Therefore, the changed volumes are then periodically transferred to the backup volumes (yellow) in the remote system. These are the so-called auxiliary volumes (row 3)
Pict. 1: These are the first 3 lines of the GMCV Analysis dashboard. It shows the data path from the Master Volumes via the
Row 4 of the analysis displays the so-called Overdue time (top row in pict. 2 below). You can easily read which cycle period would be optimal for the consistency group. It is a quick and precise answer, thus a real and easy to understand help to set up the system better.
Row 5 shows the load and latency of the connections between the storage systems. This view helps you determine if the GMCV issue was caused by transmission problems.
Pict. 2: This is row 4 and row 5 of the Analysis dashboard. Row 4 allows to easily determine how long the copy process needed to finish.
The following questions can now be answered:
Objectives of the analysis are:
1. Recognize which Consistency Group is running into problem
2. Identify when these GMCV problems are occurring and which volumes are the triggers
3. Should the cycle period of the GMCV be adjusted?
4. How did the data volumes behave over the entire route?
5. Are there problems in the connection of the storage systems?
6. Should the bandwidth size be increased?
7. Are internal problems in the storage systems the triggers?
With the first 3 rows, you can see exactly how the data volumes change over the route. It is almost unpredictable how the volume of data will change from the Master Volume to the Master Change Volume.
We have already done that in monitoring. However, there is another option, to set up an alert in the system, which informs the administrator directly.
This can be found out very clearly using the analysis dashboards. By scanning around with the mouse, one finds the periods and the triggering volumes very simply. You can also look at historical periods where longer periods such a month worth of historical data can be viewed.
Row 4 - the overdue time gives a direct answer, which can be used to tweak the cycle period to a longer period. Why increase the cycle period? If the cycle period is increased, you also have more changes accumulated. However, that does not mean that there is more data because the GMCV transmits only the changed blocks and with the increased cycle period, it makes it possible that blocks are overwritten several times but only need to be transmitted once. This behavior has to do with the characteristic of the workload.
That is the complexity of the GMCV! The servers write 10 MB/s and the GMCV makes it 20 MB/s or only 2 MB/s! Where does it come from? The GMCV works in blocks and transfers all blocks that have been changed in a cycle. If a server overwrites a block several times in a cycle, then the block is only transferred once. If the server also changes only one bit in a block, then the whole block is transmitted. (For technicians – we are talking about the Grainsize of the FlashCopy)
This makes the GMCV difficult to plan and for that reason, we have table columns under all charts that show how the resulting data volumes behave at all levels.
Therefore, this BVQ analysis is a very good basis for the introduction of GMCV.
Finally, there is a software platform where one can look at one single row to see how big the data flow between the systems is and how the latencies on the line behave. If there is a connection between the GMCV problem and the latency, then one can assume that the issue is a connection problem with a high degree of certainty.
Should the bandwidth size be increased?
If the line is at the limit, then it must be improved. Good that this analysis feature is included in the monitoring platform and it allows you to conclude very quickly whether you need or not to increase the bandwidth size.
Of course, internal problems in the storage systems can be the trigger for a GMCV problem. There are two truths now!
BVQ already has all the data of the storage systems and has a powerful analysis GUI that can be used for further analysis. Therefore, you can literally break down the storage system into pieces with the GUI and analyze it down to the last detail. This work is fun for our BVQ experts.
These analyses are complex and that's why we're happy to help to solve the problem. Also, if you want to learn it yourself, we can provide you with BVQ education session. Nevertheless, the important thing is that now you know you are not left alone with this problem and that is why it is a fantastic truth.
The next step!
Contact us if you are interested. In the USA please contact Ms Rosario Neuman at rosa
The installation of BVQ GMCV only requires a Windows Virtual Machine and a few minutes.