Hello All,
We run two 8.3 filers with a list of vservers and their associated volumes, with each volume snapmirrored (volume level) from the active primary cluster to matching vserver/volumes on the passive secondary.
Both clusters have a similar set of aggregates of just about equal size. Both clusters' aggregates contain the same list of volumes of the same size, with the same space total/used/available on both sets.
But on the target cluster the same aggregates are reporting 30% more used space.
This is about on par with the dedupe savings we're getting on the primary so when I first noticed this my thought was to check that dedupe was OK on the target. But if you look in the webUI, it reports that no "storage efficiency" is available on a replication target, and ended up thinking this meant that the secondary data would have to be full-sized. I even recall asking someone and having this confirmed, but can't recall if that came from the vendor SE or our VAR SE or a support tech or.
Now we're approaching the space limit of the secondary cluster and I'm looking deeper. At this point, as it appears that for each volume the total/used/free space matches after dedupe on the source, I'm thinking that dedupe properties aren't exposed on the target but the data is still a true copy of the deduped original. This is supported by being able to view dedupe stats on the target via the CLI that show the same savings as on the source.
Note that we're also snapshotting these volumes, and while we're deduping daily, we're snapshotting hourly. A colleague mentioned remembering that this could mean mirrored data that's not deduped yet is being replicated full-size. But if so, wouldn't this be reflected in the dedupe stats on the target?
OK, just found that "storage aggregate show -fields usedsize,physical-used" on the primary/source cluster shows that used and physical-used are about identical for all aggrs. On the secondary/target, used is consistently larger than physical-used and the total difference makes up the 30% I'm "missing."
Is this a problem with my reporting? Are we actually OK and I need to look at physical-used instead of used? Or if we're not OK, where is the space being used and can I get it back?
Thanks in advance for your guidance...
Randy
It could be the target is not thin provisioned. What is the output of "vol show -fields space-guarantee,space-guarantee-enabled" for one of the volumes on the source and the target? Do they match?
From: "Rue, Randy" rrue@fredhutch.org To: "'toasters@teaparty.net'" toasters@teaparty.net Sent: Saturday, December 17, 2016 8:09 AM Subject: snapmirror source and target aggregate usage don't match?
<!--#yiv8850567270 _filtered #yiv8850567270 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv8850567270 #yiv8850567270 p.yiv8850567270MsoNormal, #yiv8850567270 li.yiv8850567270MsoNormal, #yiv8850567270 div.yiv8850567270MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", "sans-serif";}#yiv8850567270 a:link, #yiv8850567270 span.yiv8850567270MsoHyperlink {color:blue;text-decoration:underline;}#yiv8850567270 a:visited, #yiv8850567270 span.yiv8850567270MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv8850567270 span.yiv8850567270EmailStyle17 {font-family:"Calibri", "sans-serif";color:windowtext;}#yiv8850567270 .yiv8850567270MsoChpDefault {font-family:"Calibri", "sans-serif";} _filtered #yiv8850567270 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv8850567270 div.yiv8850567270WordSection1 {}-->Hello All, We run two 8.3 filers with a list of vservers and their associated volumes, with each volume snapmirrored (volume level) from the active primary cluster to matching vserver/volumes on the passive secondary. Both clusters have a similar set of aggregates of just about equal size. Both clusters’ aggregates contain the same list of volumes of the same size, with the same space total/used/available on both sets. But on the target cluster the same aggregates are reporting 30% more used space. This is about on par with the dedupe savings we’re getting on the primary so when I first noticed this my thought was to check that dedupe was OK on the target. But if you look in the webUI, it reports that no “storage efficiency” is available on a replication target, and ended up thinking this meant that the secondary data would have to be full-sized. I even recall asking someone and having this confirmed, but can’t recall if that came from the vendor SE or our VAR SE or a support tech or. Now we’re approaching the space limit of the secondary cluster and I’m looking deeper. At this point, as it appears that for each volume the total/used/free space matches after dedupe on the source, I’m thinking that dedupe properties aren’t exposed on the target but the data is still a true copy of the deduped original. This is supported by being able to view dedupe stats on the target via the CLI that show the same savings as on the source. Note that we’re also snapshotting these volumes, and while we’re deduping daily, we’re snapshotting hourly. A colleague mentioned remembering that this could mean mirrored data that’s not deduped yet is being replicated full-size. But if so, wouldn’t this be reflected in the dedupe stats on the target? OK, just found that “storage aggregate show -fields usedsize,physical-used” on the primary/source cluster shows that used and physical-used are about identical for all aggrs. On the secondary/target, used is consistently larger than physical-used and the total difference makes up the 30% I’m “missing.” Is this a problem with my reporting? Are we actually OK and I need to look at physical-used instead of used? Or if we’re not OK, where is the space being used and can I get it back? Thanks in advance for your guidance… Randy _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-
Rue, Randy -
Scott M Gelb