Forum Discussion

prakashk01's avatar
prakashk01
Level 3
11 years ago
Solved

Why RestartLimit Attribute not comes by default for resource type Appliction?

Hello

When I look at resource (Appliction) I do not find RestartLimit available to make any modification, But when I look the that specific type (Application) of a resources, I can see a RestartLimit, I can understand I need to add these manually.

How can I make it by default whenever I add a new resource, it has to come up from the appropiate type?

business continuity
Cluster Server
Solaris
  • kjbss's avatar
    kjbss
    11 years ago

    The default value for the RestartLimit attribute for the Application-Type is '0'; that is, "do not attempt to restart a failed resource of Application-Type; instead, begin fault processing for this resource on the first occurrence of a failed Monitor entry point".

    The RestartLimit is a Type attribute not a resource attribute.  


    However, you get the choice of either setting it at the Type-level:

    -$ hatype -modify RestartLimit 2


    ...in which case EVERY Application-Type resource in your cluster will inherit this attribute value (unless overridden).

    OR, you can set this at the resource-level by overriding the RestartLimit Type-level attribute:

     -$ hares -override <yourResourceNmae> RestartLimit


    ...and then you can set up a RestartLimit limit for that resource:

     -$ hares -modify <yourResourceName> RestartLimit 2


    ...in which case this value is ONLY applicable to the specific resource defined above.

     

    So, if you know that for most of your Application-Type resources in your cluster you want to have a RestartLimit of 3, then set that at the Type-level:

    -$ hatype -modify RestartLimit 3


    And then for any exceptions to this "cluster-specific value", individually set the RestartLimit to suit individual resource requirements:

     -$ hares -override <yourResourceName> RestartLimit
 -$ hares -modify <yourResourceName> RestartLimit 10

     

    The other possibility is that you can clone the Application agent and create your own agent, which is a copy, but has a different name and most importantly for this issue, a different Type which has a different RestartLimit value defined within it.  This, in fact, is how we changed static-Type-level attributes prior to the "-override" feature was added to VCS.  (I am not sure, but I think there is a very good chance that Symantec would not support problems with Agent-Types that have been cloned, so that is another consideration).

    Now-a-days it is generally preferable to simply use the the "-override" feature (which is 100% supported by Symantec).

     

5 Replies

Sort By
  • kjbss's avatar
    kjbss
    Level 5
    11 years ago

    The default value for the RestartLimit attribute for the Application-Type is '0'; that is, "do not attempt to restart a failed resource of Application-Type; instead, begin fault processing for this resource on the first occurrence of a failed Monitor entry point".

    The RestartLimit is a Type attribute not a resource attribute.  


    However, you get the choice of either setting it at the Type-level:

    -$ hatype -modify RestartLimit 2


    ...in which case EVERY Application-Type resource in your cluster will inherit this attribute value (unless overridden).

    OR, you can set this at the resource-level by overriding the RestartLimit Type-level attribute:

     -$ hares -override <yourResourceNmae> RestartLimit


    ...and then you can set up a RestartLimit limit for that resource:

     -$ hares -modify <yourResourceName> RestartLimit 2


    ...in which case this value is ONLY applicable to the specific resource defined above.

     

    So, if you know that for most of your Application-Type resources in your cluster you want to have a RestartLimit of 3, then set that at the Type-level:

    -$ hatype -modify RestartLimit 3


    And then for any exceptions to this "cluster-specific value", individually set the RestartLimit to suit individual resource requirements:

     -$ hares -override <yourResourceName> RestartLimit
 -$ hares -modify <yourResourceName> RestartLimit 10

     

    The other possibility is that you can clone the Application agent and create your own agent, which is a copy, but has a different name and most importantly for this issue, a different Type which has a different RestartLimit value defined within it.  This, in fact, is how we changed static-Type-level attributes prior to the "-override" feature was added to VCS.  (I am not sure, but I think there is a very good chance that Symantec would not support problems with Agent-Types that have been cloned, so that is another consideration).

    Now-a-days it is generally preferable to simply use the the "-override" feature (which is 100% supported by Symantec).

     

  • prakashk01's avatar
    prakashk01
    Level 3
    11 years ago

    No, I guess you miss understood my query, I have no issues in setting RestartLimit for an application resource.

    My query is, I can see RestartLimit in Application type

    hatype -disp Application | grep -i restart
    Application  RestartLimit           0
     

    I am adding a new reource called testapp and the type is Application

    # hares -add TestApp Application AutoSG
    VCS NOTICE V-16-1-10242 Resource added. Enabled attribute must be set before agent monitors
     

    # hares -disp TestApp | grep -i restart
    TestApp      TriggerResRestart     global     0
     

    Here I do not see a "RestartLimit" for my new resource which I have created type as Application

    What I have to do in order to get the "RestartLimit" while creating a resource itself.

  • kjbss's avatar
    kjbss
    Level 5
    11 years ago

    OK... 

     

    Because your new resource TestApp is of Type Application, the RestartLimit is going to be that of it's type -- that is, it inherits the attribute from the Application Type definition.  Therefore, in your example the RestartLimit for you TestApp resouce is already '0' (the current value of the RestartLimit attribute of the "Application" Type).

     

    That is how it works.  Hopefully that is clear.  

     

    Now, if you wanted your TestApp resource to have a RestartLimit of 5, then you need to first overrride the inherited value:

     

    -$ hares -override TestApp RestartLimit

     

    ...and then set it to 5 ONLY for your specific resource:

     

    -$ hares -modify TestApp RestartLimit 5

     

    ...and now, once you have overridden the RestartLimit attribute, you will see it as part of the resource attributes for your resource:

     

    -$ hares -display TestApp | grep RestartLimit

     

    ...you would see it set to '5'.... Try it, you'll like it...

     

  • prakashk01's avatar
    prakashk01
    Level 3
    11 years ago

    I really thank you for your kind update.

    override comes into picture only when I do not have a attribute for the resource which is available in resource type

    But my question was, when I can see the attribute called restartlimit in resource type Applciation and when I add a resource type Application I do not see them (hares -disp <resource name>). not even the default value 0

     

    why?

    and in future, I have added ample of new resources and I want them to be part of resource what should I do?

    In simple when I do hares -add <resourcename> <sgname> I want to see the restartlimit attribute (by default)

     

     

  • kjbss's avatar
    kjbss
    Level 5
    11 years ago

    You will not see the RestartLimit when you display the attributes of a resource, because it is not a resource attribute.  

    There is NO WAY to see the RestartLimit attribute "by default" simply by doing "hares -add <res> <Type> <sgname>" and then "hares -display <res> | grep RestartLimit".  It is not going to happen.  That is not how it works; end of story.  

    If you want to see the in-effect RestartLimit and you know you have NOT overridden it, then you MUST display the attributes of the Type, because that is the ONLY place where the RestartLimit  attribute is defined.  

    That is all "by design, and how it works".  It may take some getting used to, but there is no getting around it.  

    Keep in mind that there are loads more Type-level attributes that all behave the same as we are discussing here in regards to the RestartLimit attribute...

    Let's pretend your TestApp resource takes 10 minutes to normally complete the online procedure.  In order to give it enough time, you need to extend the default OnlineTimeout value from the default of 300 seconds to 600 seconds.  

    But at the same time you do not want all Application-Type resources in your entire cluster to have a 10 minute OnlineTimeout.  Therefore you override the Application-Type-level attribute 'OnlineTimeout' so that you can modify it to be 600 seconds only for the TestApp resource.  

    Only after overrding the OnlineTimeout attritbute will you be able to see it when you do "hares -display TestApp | grep OnlineTimeout".