Start a Conversation

Unsolved

This post is more than 5 years old

1101

May 19th, 2014 06:00

Storage usage reporting when using smartpool tiering.

Here is my scenario.  Currently our user data resides on a Celerra and uses CTA to archive to a Centera.  For our storage billing we bill Celerra space as tier 2 and Centera as tier 3. Archiving to Centera allows us to keep tier 2 costs down.  We are now migrating all user data to an Isilon.  We have S and NL nodes.  What I am wondering is, if we migrate the data to the S nodes and then use smartpools to move older data to the NL nodes, is there a way for us to determine how much data in a specific directory resides on the S and NL nodes.  We would like to be able to bill S node storage as tier 2 and NL node storage as tier 3 but I have been unable to determine on my own if this is possible.  Any insight into this woudl be greatly appreciated.

1.2K Posts

May 20th, 2014 04:00

Couple of thoughts here:

1. Unfortunately, InsightIQ can report the usage by directory and by pool/tier, but not by both at the same time...

2. The SmartPools job report shows usage by "filepool"  (= SmartPool rule), but only globally....

3. Try out:

isi filepool apply -r -s

which is probably the closest match to your needs (in 6.5: isi smartpools)

If run shortly after a full SmartPools job, it shouldn't perform too many

actual file migrations, and thus might be reasonable fast.

4. Even faster is a dry run (no migrations):

isi filepool apply -r -s -n

but it only counts the files per filepool/rule, and doesn't report the consumed space.

5.

isi get -D

reveals the pool where a single files resides, and never

changes its placement or layout, nevertheless it is usually

too slow to be applied on very large file sets.

hth

-- Peter

May 21st, 2014 06:00

I haven't found a good way to do this.

What I do is have 2 "chargeback" pools - one for primary storage and one for secondary.  Data that is SmartPooled down to secondary storage still gets charged at primary rates.  I have SmartPool policies that will migrate data that becomes stale from S to NL, but if the data becomes active again, it will migrate back to S.  That means that I have to have some percentage of free space in my S pools for this.

Yes, I can walk the file system and find out where every file lives but there's no way to do this quickly, and especially not real time.  Even the FSA data can get stale pretty quickly on busy clusters and not complete a run for a month or two.

Our customers are internal, so "good enough" reporting is acceptable to us.

May 21st, 2014 09:00

We don't charge our users for the overhead or the snapshots but obviously factor those into our cost per TB.  Some applications use fewer snapshots or larger files and pay more than they should, but others have a high change rate and lots of little files and get a break.  It all works out in the end but we've found that it's hard enough to get our customers to forecast disk space without them trying to figure out what the change rate is so we can calculate snapshot overhead.  And, of course, this varies over the life of each project...

1.2K Posts

May 21st, 2014 09:00

Do you include protection overhead, and snapshots?

We decided to stick to regular ("apparent") file sizes,

but it is not really fair...

All relevant directories here are either on X or on NL pool,

that makes it an easy call for us.

No Events found!

Top