Unsolved
This post is more than 5 years old
5 Posts
0
33643
September 11th, 2013 23:00
Compellent, SRM and Data Progression
Hi there,
We have two Compellent SANs located at different datacentres. The datacentres run as active/active. SAN1 replicates volumes to SAN2 and vice-versa. Now this all works fine, but the issue we have come across is as follows:
DC1 has volumes presented to our VMware infrastructure. On there we have VMs that are protected by SRM. The volumes at DC1 has some data on Tier 2 and some on Tier3. Over time with replication running to DC2 with the recommended storage profile the majority of the replicated volumes end up on Tier 3. Mainly due to data progression running against the replicated volumes and the data not being "active" it is moved down the tiers.
The problem arises in case SRM needs to be invoked. Tier 3 is only rated for around 2000 IOPS. When SRM kicks in and mounts the replicated volumes to the VMware infrastructure at DC2, because the majority of the data sits on Tier 3 which is just too slow and makes the VMs unusable.
As mentioned the DCs run as active/active so we have the same issue in reverse from DC2 to DC1.
So in order to get around this issue we've had to force the replicated volumes to Tier 2. So what we end up with is the day-to-day volume sits on Tier 2 and 3, but the replica sits at Tier 2 at the other DC. This is chewing up a lot of valuable Tier 2 storage.
Now I realise we could purchase more Tier 3 storage to increase the IOPS capacity, but what would be better is to make data progression aware of what tier the source volume has its data.
DELL-Kenny K
685 Posts
0
September 12th, 2013 07:00
Mvandev,
What I would recommend in this situation would be for you to do a phone home so that the Compellent Co-Pilot will be able to get the logs from the system. Once you do that I would say to say to call the Compellent Copilot team at 866-397-8673 and they will be able to assist you in making all the necessary changes to get your performance optimal.
mvandev
5 Posts
0
September 12th, 2013 17:00
Hi Kenny,
We've tried that a number of times and the general response is that it will be fixed in the next firmware release. We also have/had the optimize reporting and that has not helped. I will try again though.
mvandev
5 Posts
0
September 12th, 2013 18:00
So just got off the phone with Co-Pilot. Apparently the feature I am after is not available and isn't on a roadmap. Because the replicated data isn't active data progression will move it down the tier. So that leaves only a couple of options:
Surely we can't be the only place that has run into this issue or sees it as being an issue.
mtanen
118 Posts
0
September 12th, 2013 20:00
Why could you not just kick off a CMM (assuming you have the space) with a higher storage profile as part of the failover? There would be a delay in performance of course, but it might get you closer to what you want if you can tolerate either a prep prior to the failover or a longer window right after.
mvandev
5 Posts
0
September 12th, 2013 21:00
Thanks for the suggestion, but under that scenario I won't be able to provide the business with an appropriate level of confidence in case of unplanned DR. If it was a planned failover, then yes maybe if I had the space. With the current setup I have a clearer understanding of what performance would be like if we had to failover.
Bryan Adamsny
1 Message
0
October 18th, 2013 10:00
Is there any kind of debug option to disable migration on the DR controller? Then under a fail over you could re-enable the feature. I would be surprised if there isn't such a command -just not publicly discussed. I'd push co-pilot for this or the dev team.
mvandev
5 Posts
0
October 20th, 2013 23:00
I wouldn't want to rely on a non-documented feature.
However we have come up with a solution that should work for us. We have split the OS and Data drives onto different datastores and are only forcing the OS datastore to Tier 2, and leaving the Data one on Tier2/3. This should allow the VMs to start up ok.