Topic
  • 4 replies
  • Latest Post - ‏2012-05-08T05:04:36Z by dlmcnabb
SystemAdmin
SystemAdmin
2092 Posts

Pinned topic Use of callbacks and manager nodes

‏2012-05-07T18:49:57Z |
Hi all, this is a question about the mmaddcallback functionality, and it's appropriate-ness on certain nodes.

Here's the scenario:

  • local NSD cluster with 7 manager nodes serving filesystem fs0.
  • remote GPFS cluster mounting cluster fs0.

I'd like to set a callback when a softQuota violation is detected. I've done all of the dirty work, and verified things are called appropriately, but I have a question about which nodes to run this on.

Since this type of callback is a local event, which nodes should it be running on?

From The Fine Manual:

:softQuotaExceeded
: Triggered when the file system manager detects that a user or fileset quota has been exceeded.

So if a user on a remoteCluster exceeds their soft quota, should this callback be set on ALL of the local NSD cluster manager nodes (-N managernodes), or just the filesystem manager node (from mmlsmgr)?

If the primary filesystem manager node (from mmlsmgr) goes down, does the callback need to be moved?

I guess I'm just not fully understanding the significance of 'local' callbacks with which node the callback would indeed be local to.

Thanks in advance.

~Steve
Updated on 2012-05-08T05:04:36Z at 2012-05-08T05:04:36Z by dlmcnabb
  • dlmcnabb
    dlmcnabb
    1012 Posts

    Re: Use of callbacks and manager nodes

    ‏2012-05-07T19:43:42Z  
    It happens on whichever "manager" node is the FS manager for that particular filesystem. So you need the callback script ready on all the manager nodes, since you won't know which one will be the manager at any particular moment.
  • dlmcnabb
    dlmcnabb
    1012 Posts

    Re: Use of callbacks and manager nodes

    ‏2012-05-07T19:47:38Z  
    • dlmcnabb
    • ‏2012-05-07T19:43:42Z
    It happens on whichever "manager" node is the FS manager for that particular filesystem. So you need the callback script ready on all the manager nodes, since you won't know which one will be the manager at any particular moment.
    If you have quorum nodes that are not manager nodes, then if all the manager nodes fail but you still have quorum, one of the quorum nodes may get assigned the FS manager. So the callback script would have to be on the quorum nodes as well.
  • SystemAdmin
    SystemAdmin
    2092 Posts

    Re: Use of callbacks and manager nodes

    ‏2012-05-08T02:23:11Z  
    • dlmcnabb
    • ‏2012-05-07T19:43:42Z
    It happens on whichever "manager" node is the FS manager for that particular filesystem. So you need the callback script ready on all the manager nodes, since you won't know which one will be the manager at any particular moment.
    Okay, that makes sense, and was the original plan, but I figured I'd ask anyways.

    About this though:
    ---
    "It happens on whichever "manager" node is the FS manager for that particular filesystem. So you need the callback script ready on all the manager nodes, since you won't know which one will be the manager at any particular moment."
    ---

    What do you mean by any particular moment? If you mean that at any time, a new manager could be elected due to various reasons (hardware failure, eviction from cluster, etc), okay. But normally isn't it safe to assume that the FS manager will stay the same, unless it is either changed manually through administrative action, or a unexpected failure?

    Regardless, I'll certainly take the advice, thanks!
  • dlmcnabb
    dlmcnabb
    1012 Posts

    Re: Use of callbacks and manager nodes

    ‏2012-05-08T05:04:36Z  
    Okay, that makes sense, and was the original plan, but I figured I'd ask anyways.

    About this though:
    ---
    "It happens on whichever "manager" node is the FS manager for that particular filesystem. So you need the callback script ready on all the manager nodes, since you won't know which one will be the manager at any particular moment."
    ---

    What do you mean by any particular moment? If you mean that at any time, a new manager could be elected due to various reasons (hardware failure, eviction from cluster, etc), okay. But normally isn't it safe to assume that the FS manager will stay the same, unless it is either changed manually through administrative action, or a unexpected failure?

    Regardless, I'll certainly take the advice, thanks!
    If the current FS manager dies or is mmshutdown, the CM will appoint another manager node to take over. You can also move the manager using mmchmgr. Those are the only reasons it would move.