Topic
  • 12 replies
  • Latest Post - ‏2019-02-18T09:55:42Z by Nils Haustein
mmetts
mmetts
7 Posts

Pinned topic how to express an inverse weight in applying an ILM policy

‏2019-02-11T22:37:57Z | mmapplypolicy weight

Hi, 

We have two storage tiers in our spectrum scale cluster and I'm trying to express a once-a-day policy to move colder files into the slower pool and hotter files into the faster pool.  so far i have this (below).  But I think my weight functions might be working backward.  In other words, in the rule labeled SLOW_DATA1, I want to grab the coldest files first rather than the hottest one assuming access days is > 120.  Would WEIGHT(-1* FILE_HEAT) do that or am I just thinking about this all wrong anyway?  I would really appreciate some help.

 

Thanks,

Mike

 

RULE 'default' SET POOL 'system'

RULE 'SLOW_DATA1' MIGRATE FROM POOL 'system'
THRESHOLD(90,50) WEIGHT(FILE_HEAT)
TO POOL 'slowdata'
LIMIT(95)
WHERE DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME) > 120

RULE 'SLOW_DATA2' MIGRATE FROM POOL 'system'
THRESHOLD(90,70) WEIGHT(FILE_HEAT)
TO POOL 'slowdata'
LIMIT(95)
WHERE DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME) > 60

RULE 'SLOW_DATA3' MIGRATE FROM POOL 'system'
THRESHOLD(90,80) WEIGHT(FILE_HEAT)
TO POOL 'slowdata'
LIMIT(95)

RULE 'FAST_DATA1' MIGRATE FROM POOL 'slowdata'
TO POOL 'system'
LIMIT(80)
WHERE DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME) < 5
 

  • Nils Haustein
    Nils Haustein
    8 Posts

    Re: how to express an inverse weight in applying an ILM policy

    ‏2019-02-12T19:12:43Z  

    Hi Mike,

    The WEIGHT must be an integer. The files associated with the highest integer value in the WEIGHT clause are migrated first.

    Two thoughts on this:

    1. I think the file heat is 0 for files that have not been accessed for 60 days and longer. So WEIGHTING on fileheat for such files may not  make sense. Isn't the access_time a good indication for fileheat in your example?

    2. The three SLOW_DATA rules seem to be identical except of the THRESHOLDs. The first rule may lower the threshold to 50 %, so the second and the third rule may never apply, because they require 90 % to be triggered. What are you trying to achieve with this?

    Some questions:

    Do you run this policy daily using a script? If so, is there a reason you use thresholds? I typically use thresholds only with active policies that are triggered automatically.

    What is your purpose with these rules?

    I have written a whitepaper about ILM policies and rules. May be you find some good inspiration in there:

    http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102642

     

  • mmetts
    mmetts
    7 Posts

    Re: how to express an inverse weight in applying an ILM policy

    ‏2019-02-12T19:31:35Z  

    Hi Mike,

    The WEIGHT must be an integer. The files associated with the highest integer value in the WEIGHT clause are migrated first.

    Two thoughts on this:

    1. I think the file heat is 0 for files that have not been accessed for 60 days and longer. So WEIGHTING on fileheat for such files may not  make sense. Isn't the access_time a good indication for fileheat in your example?

    2. The three SLOW_DATA rules seem to be identical except of the THRESHOLDs. The first rule may lower the threshold to 50 %, so the second and the third rule may never apply, because they require 90 % to be triggered. What are you trying to achieve with this?

    Some questions:

    Do you run this policy daily using a script? If so, is there a reason you use thresholds? I typically use thresholds only with active policies that are triggered automatically.

    What is your purpose with these rules?

    I have written a whitepaper about ILM policies and rules. May be you find some good inspiration in there:

    http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102642

     

    Hi Nils,

    We have two storage pools and I'd like to do a decent job of keeping the more frequently accessed data in the faster one.  I suppose to me that means to actively look at access times and move the less accessed files to the slower pool and then also "promote" to the faster pool files that have recently been accessed for the first time in awhile.

    We run a cron job that fires off mmapplypolicy once a night on weekdays.  It would be nice if I could take a median but I haven't found anything to suggest that that's possible.  I did enable FILE_HEAT on the cluster and I also thought I saw in the documentation something about WEIGHT working with floats.  In any case, since posting my question, I have tried something like this and not gotten an error:  WEIGHT(1/FILE_HEAT) ... I just don't know if it's actually doing anything with it.

    The reason I have multiple threshold calls is that I saw that in an example in some IBM documentation.  To refine what I really want, maybe it's something like this:

     

    If the fast pool is between 90 and 50 percent full, I want to move to the slow pool all files not accessed in the last X days starting with the biggest and coldest first.  I want to do this unless and until the fast pool hits 50 percent full or the slow pool has reached 95 percent full.

    If the fast pool is below 80 percent full, I want to move to the fast pool all files in the slow pool which have been accessed in the last Y days starting with the hottest and largest files first.

     

    For now, let's say X = 60 and Y = 5.  How would you recommend achieving these?

    I wish there was something a little more dynamic.  Since There are only 2 pools at this point, a median (of days since last access) seems like it would be handy but I don't know how to do that.

    I would love to read your white paper but the link doesn't appear to work.  Please repost when you get a chance.

     

    Thanks,

    Mike

    Updated on 2019-02-13T00:02:55Z at 2019-02-13T00:02:55Z by mmetts
  • mmetts
    mmetts
    7 Posts

    Re: how to express an inverse weight in applying an ILM policy

    ‏2019-02-12T19:58:14Z  
    • mmetts
    • ‏2019-02-12T19:31:35Z

    Hi Nils,

    We have two storage pools and I'd like to do a decent job of keeping the more frequently accessed data in the faster one.  I suppose to me that means to actively look at access times and move the less accessed files to the slower pool and then also "promote" to the faster pool files that have recently been accessed for the first time in awhile.

    We run a cron job that fires off mmapplypolicy once a night on weekdays.  It would be nice if I could take a median but I haven't found anything to suggest that that's possible.  I did enable FILE_HEAT on the cluster and I also thought I saw in the documentation something about WEIGHT working with floats.  In any case, since posting my question, I have tried something like this and not gotten an error:  WEIGHT(1/FILE_HEAT) ... I just don't know if it's actually doing anything with it.

    The reason I have multiple threshold calls is that I saw that in an example in some IBM documentation.  To refine what I really want, maybe it's something like this:

     

    If the fast pool is between 90 and 50 percent full, I want to move to the slow pool all files not accessed in the last X days starting with the biggest and coldest first.  I want to do this unless and until the fast pool hits 50 percent full or the slow pool has reached 95 percent full.

    If the fast pool is below 80 percent full, I want to move to the fast pool all files in the slow pool which have been accessed in the last Y days starting with the hottest and largest files first.

     

    For now, let's say X = 60 and Y = 5.  How would you recommend achieving these?

    I wish there was something a little more dynamic.  Since There are only 2 pools at this point, a median (of days since last access) seems like it would be handy but I don't know how to do that.

    I would love to read your white paper but the link doesn't appear to work.  Please repost when you get a chance.

     

    Thanks,

    Mike

    Found this in the documentation:

     

    WEIGHT (WeightExpression)

    Establishes an order on the matching files. Specifies an SQL expression with a numeric value that can

    be converted to a double-precision floating point number. The expression can refer to any of the file

    attributes and can include any constants and any of the available SQL operators or built-in functions.

  • Nils Haustein
    Nils Haustein
    8 Posts

    Re: how to express an inverse weight in applying an ILM policy

    ‏2019-02-13T08:54:54Z  
    • mmetts
    • ‏2019-02-12T19:58:14Z

    Found this in the documentation:

     

    WEIGHT (WeightExpression)

    Establishes an order on the matching files. Specifies an SQL expression with a numeric value that can

    be converted to a double-precision floating point number. The expression can refer to any of the file

    attributes and can include any constants and any of the available SQL operators or built-in functions.

    Hi Mike,

    first of all my apology for the wrong link, here is the right one:

    https://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102642

    And you are correct regarding the WEIGH clause allowing floating point numbers. I have not played However, if you use WEIGHT(1/FILE_HEAT) and FILE_HEAT is 0, it won't work. I think using FILE_HEAT for such long access times is not valuable.

    Let look for your requirements.

    1. If the fast pool is between 90 and 50 percent full, I want to move to the slow pool all files not accessed in the last X days starting with the biggest and coldest first.  I want to do this unless and until the fast pool hits 50 percent full or the slow pool has reached 95 percent full.

    Between 90 and 50 % means that the trigger should be 50 %. So your threshold can be THRESHOLD(50,40) for the first rule SLOW_DATA1. I took 40 % as min threshold as an example, can be lower than this.

    RULE 'SLOW_DATA1' MIGRATE FROM POOL 'system'
    THRESHOLD(50,40) WEIGHT(access_age)
    TO POOL 'slowdata'
    LIMIT(95)
    WHERE DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME) > X

    2. If the fast pool is below 80 percent full, I want to move to the fast pool all files in the slow pool which have been accessed in the last Y days starting with the hottest and largest files first.

    Likewise your trigger for the migration is 80 %. So your SLOW_DATA2 policy could look like this:

    RULE 'SLOW_DATA2' MIGRATE FROM POOL 'system'
    THRESHOLD(80,70) WEIGHT(access_age)
    TO POOL 'slowdata'
    LIMIT(95)
    WHERE DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME) > 60

     

    So you work with two policies and different thresholds. I put a weight on access_age which is this macro (put it on top of your policy):

    define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME)))

     

    If you look at the whitepaper, I typically differentiate between active and schedule policies. The active policy is the one you apply with mmchpolicy and it must be simple and THRESHOLD based. The scheduled policy is run periodically using mmapplypolicy and it does not have to be threshold based. So the active and schedule policies should not be the same. The example above is for a schedule policy. The active policy is the last line of defense, perhaps triggering at 90 and it should just move file out of system pool, like this:

    define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME)))

    RULE 'default' SET POOL 'system'

    RULE 'AUTOMIG' MIGRATE FROM POOL 'system'
    THRESHOLD(90,70) WEIGHT(access_age)
    TO POOL 'slowdata'

     

    I have not found a method within the policies to calculate the median of access_time. It could be done with an extra script, where you run a list policy to show all files and their access time and then calculate the median. The list rule could look like this:

    RULE 'listall' list 'all-files' SHOW( varchar(ACCESS_TIME) || '  ' )

    To run this rule you can use mmapplypolicy:

    mmapplypolicy fsname -P this-policy-file -f prefix -I defer

    This will list all files and store the result in a file named prefix.list.all-files (prefix can be a directory as well).

    May be using the macro access_age in the SHOW clause also works, have not tried it yet.

     

    Hope this help. Sorry for the strange formatting above. I attach the latest version policy guide.

    Attachments

  • mmetts
    mmetts
    7 Posts

    Re: how to express an inverse weight in applying an ILM policy

    ‏2019-02-13T19:55:44Z  

    Hi Mike,

    first of all my apology for the wrong link, here is the right one:

    https://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102642

    And you are correct regarding the WEIGH clause allowing floating point numbers. I have not played However, if you use WEIGHT(1/FILE_HEAT) and FILE_HEAT is 0, it won't work. I think using FILE_HEAT for such long access times is not valuable.

    Let look for your requirements.

    1. If the fast pool is between 90 and 50 percent full, I want to move to the slow pool all files not accessed in the last X days starting with the biggest and coldest first.  I want to do this unless and until the fast pool hits 50 percent full or the slow pool has reached 95 percent full.

    Between 90 and 50 % means that the trigger should be 50 %. So your threshold can be THRESHOLD(50,40) for the first rule SLOW_DATA1. I took 40 % as min threshold as an example, can be lower than this.

    RULE 'SLOW_DATA1' MIGRATE FROM POOL 'system'
    THRESHOLD(50,40) WEIGHT(access_age)
    TO POOL 'slowdata'
    LIMIT(95)
    WHERE DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME) > X

    2. If the fast pool is below 80 percent full, I want to move to the fast pool all files in the slow pool which have been accessed in the last Y days starting with the hottest and largest files first.

    Likewise your trigger for the migration is 80 %. So your SLOW_DATA2 policy could look like this:

    RULE 'SLOW_DATA2' MIGRATE FROM POOL 'system'
    THRESHOLD(80,70) WEIGHT(access_age)
    TO POOL 'slowdata'
    LIMIT(95)
    WHERE DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME) > 60

     

    So you work with two policies and different thresholds. I put a weight on access_age which is this macro (put it on top of your policy):

    define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME)))

     

    If you look at the whitepaper, I typically differentiate between active and schedule policies. The active policy is the one you apply with mmchpolicy and it must be simple and THRESHOLD based. The scheduled policy is run periodically using mmapplypolicy and it does not have to be threshold based. So the active and schedule policies should not be the same. The example above is for a schedule policy. The active policy is the last line of defense, perhaps triggering at 90 and it should just move file out of system pool, like this:

    define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME)))

    RULE 'default' SET POOL 'system'

    RULE 'AUTOMIG' MIGRATE FROM POOL 'system'
    THRESHOLD(90,70) WEIGHT(access_age)
    TO POOL 'slowdata'

     

    I have not found a method within the policies to calculate the median of access_time. It could be done with an extra script, where you run a list policy to show all files and their access time and then calculate the median. The list rule could look like this:

    RULE 'listall' list 'all-files' SHOW( varchar(ACCESS_TIME) || '  ' )

    To run this rule you can use mmapplypolicy:

    mmapplypolicy fsname -P this-policy-file -f prefix -I defer

    This will list all files and store the result in a file named prefix.list.all-files (prefix can be a directory as well).

    May be using the macro access_age in the SHOW clause also works, have not tried it yet.

     

    Hope this help. Sorry for the strange formatting above. I attach the latest version policy guide.

    Nils,

    Thanks so much for your help.  I think I'm starting to get the hang of this.  So here's my scheduled policy based on your guidance:

    define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME)))

    RULE 'SLOW_DATA' MIGRATE FROM POOL 'system'
    THRESHOLD(50,40) WEIGHT(access_age)
    TO POOL 'slowdata'
    LIMIT(95)
    WHERE DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME) > 60

    RULE 'FAST_DATA' MIGRATE FROM POOL 'slowdata'
    WEIGHT(1.0/access_age)
    TO POOL 'system'
    LIMIT(79)
    WHERE DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME) < 5

    ...and this is the active policy:

    define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME)))

    RULE 'default' SET POOL 'system'

    RULE 'AUTOMIG' MIGRATE FROM POOL 'system'
    THRESHOLD(90,70) WEIGHT(access_age)
    TO POOL 'slowdata'

     

    Please let me know what you think of these.  I'm curious about the "active" policy.  Are you implying that it will work continuously?  My impression was that other than "SET POOL" these all have to be run with mmapplypolicy.  It seems like the distinction might be that the scheduled policy is just sitting in a file and I run it with a cron job with mmapplypolcy -P but does that also overlay (in this example) or run in concert with the 'AUTOMIG' policy.  I guess what I'm asking is whether I should use mmchpolicy on the active one and then just let the scheduled one sit in a file and invoke it with cron?

    Thanks for you perspective on FILE_HEAT.  After thinking about your comments and looking at the documentation more closely I agree that it doesn't make sense for us yet.  The distinction between 'system' and 'slowdata' for us is 10,000 RPM drives vs. 7,200 RPM drives.  The lower tier costs about half as much per TB but I don't think the performance difference is all that dramatic - please correct me if I'm wrong there.  So if a file is mis-allocated for a few hours or even a day I don't think it's going to matter much.  We might add another super fast tier of storage (Vexata) before too long and then it think FILE_HEAT might be more meaningful.  In our situation now, I'm just really trying to keep these two pools balanced.

    Thanks for the white paper as well, I'll take a look.  I really appreciate your help up to now and look forward to further impressions from you regarding the above.

    Best,

    Mike

     

  • Nils Haustein
    Nils Haustein
    8 Posts

    Re: how to express an inverse weight in applying an ILM policy

    ‏2019-02-14T08:47:14Z  
    • mmetts
    • ‏2019-02-13T19:55:44Z

    Nils,

    Thanks so much for your help.  I think I'm starting to get the hang of this.  So here's my scheduled policy based on your guidance:

    define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME)))

    RULE 'SLOW_DATA' MIGRATE FROM POOL 'system'
    THRESHOLD(50,40) WEIGHT(access_age)
    TO POOL 'slowdata'
    LIMIT(95)
    WHERE DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME) > 60

    RULE 'FAST_DATA' MIGRATE FROM POOL 'slowdata'
    WEIGHT(1.0/access_age)
    TO POOL 'system'
    LIMIT(79)
    WHERE DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME) < 5

    ...and this is the active policy:

    define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME)))

    RULE 'default' SET POOL 'system'

    RULE 'AUTOMIG' MIGRATE FROM POOL 'system'
    THRESHOLD(90,70) WEIGHT(access_age)
    TO POOL 'slowdata'

     

    Please let me know what you think of these.  I'm curious about the "active" policy.  Are you implying that it will work continuously?  My impression was that other than "SET POOL" these all have to be run with mmapplypolicy.  It seems like the distinction might be that the scheduled policy is just sitting in a file and I run it with a cron job with mmapplypolcy -P but does that also overlay (in this example) or run in concert with the 'AUTOMIG' policy.  I guess what I'm asking is whether I should use mmchpolicy on the active one and then just let the scheduled one sit in a file and invoke it with cron?

    Thanks for you perspective on FILE_HEAT.  After thinking about your comments and looking at the documentation more closely I agree that it doesn't make sense for us yet.  The distinction between 'system' and 'slowdata' for us is 10,000 RPM drives vs. 7,200 RPM drives.  The lower tier costs about half as much per TB but I don't think the performance difference is all that dramatic - please correct me if I'm wrong there.  So if a file is mis-allocated for a few hours or even a day I don't think it's going to matter much.  We might add another super fast tier of storage (Vexata) before too long and then it think FILE_HEAT might be more meaningful.  In our situation now, I'm just really trying to keep these two pools balanced.

    Thanks for the white paper as well, I'll take a look.  I really appreciate your help up to now and look forward to further impressions from you regarding the above.

    Best,

    Mike

     

    Hi Mike, thanks for the feedback.

    It is as you describe, you set the active policy using mmchpolicy. Please first check your policy first (mmlspolicy) to make sure you do not loose anything. Your active policy must include the placement policy, so it would look like this:

    RULE 'default' SET POOL 'system'

    define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME)))

    RULE 'default' SET POOL 'system'

    RULE 'AUTOMIG' MIGRATE FROM POOL 'system'
    THRESHOLD(90,70) WEIGHT(access_age)
    TO POOL 'slowdata'

     

    This is your last line of defense. It will kick in automatically when the system pool reaches 90%. you need to define a callback which catches the LOWDISKSPACE event and invokes this policy (see whitepaper). Hopefully it will never kick in, because the scheduled policy is smarter and takes care that your pools are balanced. But there may be conditions where the scheduled policy does not work, e.g. if within the last 20 days a lot of data is ingested and you migrate if the file is older than 20 days.

     

    Your scheduled policy is smarter, it migrates more intelligent. Of course, it is based on static values for the access time. It would be nice if it would work with a median of access time. But this is not included and has to be programmed in addition.

     

    Good luck and let me know if you have question.

  • mmetts
    mmetts
    7 Posts

    Re: how to express an inverse weight in applying an ILM policy

    ‏2019-02-14T16:12:20Z  

    Hi Mike, thanks for the feedback.

    It is as you describe, you set the active policy using mmchpolicy. Please first check your policy first (mmlspolicy) to make sure you do not loose anything. Your active policy must include the placement policy, so it would look like this:

    RULE 'default' SET POOL 'system'

    define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME)))

    RULE 'default' SET POOL 'system'

    RULE 'AUTOMIG' MIGRATE FROM POOL 'system'
    THRESHOLD(90,70) WEIGHT(access_age)
    TO POOL 'slowdata'

     

    This is your last line of defense. It will kick in automatically when the system pool reaches 90%. you need to define a callback which catches the LOWDISKSPACE event and invokes this policy (see whitepaper). Hopefully it will never kick in, because the scheduled policy is smarter and takes care that your pools are balanced. But there may be conditions where the scheduled policy does not work, e.g. if within the last 20 days a lot of data is ingested and you migrate if the file is older than 20 days.

     

    Your scheduled policy is smarter, it migrates more intelligent. Of course, it is based on static values for the access time. It would be nice if it would work with a median of access time. But this is not included and has to be programmed in addition.

     

    Good luck and let me know if you have question.

    Thanks, Nils.  Just to be sure, in your example for an active policy, you have this twice:

    RULE 'default' SET POOL 'system'

    This is just a typo and I only need it once (first line), correct?

    Thanks,

    Mike

     

  • Nils Haustein
    Nils Haustein
    8 Posts

    Re: how to express an inverse weight in applying an ILM policy

    ‏2019-02-14T18:49:04Z  
    • mmetts
    • ‏2019-02-14T16:12:20Z

    Thanks, Nils.  Just to be sure, in your example for an active policy, you have this twice:

    RULE 'default' SET POOL 'system'

    This is just a typo and I only need it once (first line), correct?

    Thanks,

    Mike

     

    Sorry Mike, my fault. you already hat the placement rule in the example you provided above and I copied it again. So having the placement policy (SET POOL) once is enough.

     

    Good luck.

  • mmetts
    mmetts
    7 Posts

    Re: how to express an inverse weight in applying an ILM policy

    ‏2019-02-15T16:21:30Z  

    Sorry Mike, my fault. you already hat the placement rule in the example you provided above and I copied it again. So having the placement policy (SET POOL) once is enough.

     

    Good luck.

    Nils,

    Hi.  One last sanity check.  I have created an active policy that looks like this:

    bash-4.4# mmlspolicy projects -L
    RULE 'default' SET POOL 'system'
    define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME)))
    RULE 'AUTOMIG' MIGRATE FROM POOL 'system'
    THRESHOLD(90,79) WEIGHT(access_age)
    TO POOL 'slowdata'

    Then, I created a callback like this:

    # mmaddcallback MIGRATION --command /usr/lpp/mmfs/bin/mmstartpolicy --event lowDiskSpace,noDiskSpace --parms "%eventName %fsName -N crcossa1,crcossa2 -s /tmp --single-instance"

    I just want to confirm that this callback looks right for an internal pool to internal pool active policy.  For instance, it seems like this call back could be triggered by EITHER a full SYSTEM pool or a full SLOWDATA pool.  Do I need to create any distinction there or is what I have fine?

    Thanks,

    Mike 

     

     

     

  • marc_of_GPFS
    marc_of_GPFS
    50 Posts

    Re: how to express an inverse weight in applying an ILM policy

    ‏2019-02-15T17:13:48Z  
    • mmetts
    • ‏2019-02-15T16:21:30Z

    Nils,

    Hi.  One last sanity check.  I have created an active policy that looks like this:

    bash-4.4# mmlspolicy projects -L
    RULE 'default' SET POOL 'system'
    define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME)))
    RULE 'AUTOMIG' MIGRATE FROM POOL 'system'
    THRESHOLD(90,79) WEIGHT(access_age)
    TO POOL 'slowdata'

    Then, I created a callback like this:

    # mmaddcallback MIGRATION --command /usr/lpp/mmfs/bin/mmstartpolicy --event lowDiskSpace,noDiskSpace --parms "%eventName %fsName -N crcossa1,crcossa2 -s /tmp --single-instance"

    I just want to confirm that this callback looks right for an internal pool to internal pool active policy.  For instance, it seems like this call back could be triggered by EITHER a full SYSTEM pool or a full SLOWDATA pool.  Do I need to create any distinction there or is what I have fine?

    Thanks,

    Mike 

     

     

     

    You might "enjoy" the GROUP POOL feature which was designed expressly for the purpose of redistributing data over two or more pools, based on whatever WEIGHT function you'd like to specify...

    See the Admin guide, in the ILM chapter, ...

    GROUP POOL PoolName -- Defines a group pool. This rule supports the concept of distributing data files over several GPFS disk pools.

     ...

    You can "repack" a group pool by WEIGHT. Migrate files of higher weight to preferred disk pools
    by specifying a group pool as both the source and the target of a MIGRATE rule.

    ...

     

  • mmetts
    mmetts
    7 Posts

    Re: how to express an inverse weight in applying an ILM policy

    ‏2019-02-17T01:06:45Z  

    You might "enjoy" the GROUP POOL feature which was designed expressly for the purpose of redistributing data over two or more pools, based on whatever WEIGHT function you'd like to specify...

    See the Admin guide, in the ILM chapter, ...

    GROUP POOL PoolName -- Defines a group pool. This rule supports the concept of distributing data files over several GPFS disk pools.

     ...

    You can "repack" a group pool by WEIGHT. Migrate files of higher weight to preferred disk pools
    by specifying a group pool as both the source and the target of a MIGRATE rule.

    ...

     

    Thanks, Marc.  I'll take a look at that.

    Best,

    Mike

  • Nils Haustein
    Nils Haustein
    8 Posts

    Re: how to express an inverse weight in applying an ILM policy

    ‏2019-02-18T09:55:42Z  
    • mmetts
    • ‏2019-02-15T16:21:30Z

    Nils,

    Hi.  One last sanity check.  I have created an active policy that looks like this:

    bash-4.4# mmlspolicy projects -L
    RULE 'default' SET POOL 'system'
    define(access_age,(DAYS(CURRENT_TIMESTAMP) - DAYS(ACCESS_TIME)))
    RULE 'AUTOMIG' MIGRATE FROM POOL 'system'
    THRESHOLD(90,79) WEIGHT(access_age)
    TO POOL 'slowdata'

    Then, I created a callback like this:

    # mmaddcallback MIGRATION --command /usr/lpp/mmfs/bin/mmstartpolicy --event lowDiskSpace,noDiskSpace --parms "%eventName %fsName -N crcossa1,crcossa2 -s /tmp --single-instance"

    I just want to confirm that this callback looks right for an internal pool to internal pool active policy.  For instance, it seems like this call back could be triggered by EITHER a full SYSTEM pool or a full SLOWDATA pool.  Do I need to create any distinction there or is what I have fine?

    Thanks,

    Mike 

     

     

     

    Hi Mike,

     

    regarding the call back:

    # mmaddcallback MIGRATION --command /usr/lpp/mmfs/bin/mmstartpolicy --event lowDiskSpace,noDiskSpace --parms "%eventName %fsName -N crcossa1,crcossa2 -s /tmp --single-instance"

    You may not need --single-instance. Also -s /tmp is default. Only set -s if it is different than /tmp. Note, -s specifies a local temp directory, for the file lists. For large file systems you need sufficient capacity in the temp dir. It defaults to /tmp. So as long as you have sufficient space in /tmp, you do not have to worry.

    Depending on the GPFS level you may set -g explicitely, since 5.0.2 it is set to the config variable sharedTmpDir which I think defaults to .mmSharedTmpDir in the file system root.

    If the performance for migration from system to slowdata is not good, you could consider parms line -m and -B. The default usually works.

     

    Note, I also thought about group policies, but did not really find a good solution for your requirements.

    Regards Nils