locked
Multiple alerts from cluster servers RRS feed

  • Question

  • Hi,

    I am facing issue like getting multiple alerts from cluster servers for a single event.

    I have written registry based discovery against my SQL  cluster servers for custom based rules. I am trying to alert for a created event by my application. The event is created well only once in the physical active node. But it alerted thrice for the same event. One for physical node, one for virtual name and another one for cluster name. I think since I have written the discovery target as Windows.computer, it’s alerting thrice. I am also  thinking that I did some mistake in the discovery. Kindly help me to fix this issue. I have given the relevant screen shots below. My SCOM environment is R2 and I am using Auth Console to write my MP.

    I have read some of the docs that i may need to use "Invirtualnode" property with my discovery. I added the below line but got the "The Microsoft Operations Manager Expression Filter Module could not initialize properly. " error.

     

    $Target/Property[Type="Windows!Microsoft.Windows.Server.Computer"]/IsVirtualNode$ 

     

    Please guide me what are all the properties, i need to include in the discovery. I have given below my discovery code.

     

    <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.FilteredRegistryDiscoveryProvider">

              <ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>

              <RegistryAttributeDefinitions>

                <RegistryAttributeDefinition>

                  <AttributeName>ServerRole</AttributeName>

                  <Path>SOFTWARE\myTeam\ServerRole</Path>

                  <PathType>1</PathType>

                  <AttributeType>1</AttributeType>

                </RegistryAttributeDefinition>

              </RegistryAttributeDefinitions>

              <Frequency>3600</Frequency>

              <ClassId>$MPElement[Name="Myteam.Corp.SQLServer.Class"]$</ClassId>

              <InstanceSettings>

                <Settings>

                  <Setting>

                    <Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Name>

                    <Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>

                  </Setting>

                </Settings>

              </InstanceSettings>

              <Expression>

                <SimpleExpression>

                  <ValueExpression>

                    <XPathQuery Type="String">Values/ServerRole</XPathQuery>

                  </ValueExpression>

                  <Operator>Equal</Operator>

                  <ValueExpression>

                    <Value Type="String">SQLSVR</Value>

                  </ValueExpression>

                </SimpleExpression>

              </Expression>

            </DataSource>

     

    Fid

    Regards,
    Wednesday, March 31, 2010 6:04 PM

Answers

  • Clustering is tricky, your choices depend on whether your application is cluster aware. Pasting in a document that explains some of this.

    Note that from an infrastructure side, the way OM does cluster monitoring is that the agent on the active node does monitoring on behalf of the virtual server. That's why agent proxy is required and also why your workflows need to be remotable. Upon failover, the new active node does monitoring. Another thing to consider is that there is an override if the customer implements multiple network names for a resource group, by default we only discover one.

    Take a deep breath, here's the doc.

     

    When you develop a management pack for a cluster aware application or product, you need to take special steps to help the OpsMgr health service to make the right decisions for discoveries, tasks, monitors and rules to run correctly against monitoring classes that represent the operating components in cluster aware applications.  To do this, you take advantage of the IsVirtualNode property on the Windows.Server.Computer class from the Microsoft.Windows.Library management pack.  This property is provide to allow MP authors to create management packs that are MSCS cluster aware by implementing special discovery logic so that your monitoring logic only “activates” the monitoring required on the virtual node and not on either of the physical nodes that make up a cluster.  The management pack author has to choose to check for whether the application is in a clustered state, and then only “discover” the application components on the virtual node of the cluster.

    Often, MP authors read this first paragraph and conclude that becoming cluster aware is something they can do in the management pack.  Most of them fail.  The reason is that to be cluster aware, the application itself has to provide two critical pieces of information that are impossible for the MP author to manufacture.  These two items are:

    ·         AppInstalledInClusteredConfiguration:  This flag, which is just a variable name for illustrative purposes, indicates that the application MSI has dropped the bits for the app in a clustered configuration.

    ·         ClusteredApplicationItemIsOnActiveNode:  this flag, also illustrative, is used to tell anyone interested that the particular clustered element (via clustered resource group) is on the currently active node in the cluster.

    When these two items are not discernible in the discovery scripts in a management pack, it will not be possible to successfully make the MP be cluster aware.  If the app installer doesn’t leave a breadcrumb that indicates that the app is in a clustered configuration, and if the running application does not provide a way to tell if a particular node is the currently active node, then the best the MP author can do is make sure the app ignores clusters by making sure the “isVirtual” flag on the computer class is blank.

    For example, the newest SQL server MP added support for SQL clusters. This was made possible because SQL provides special table entries to reflect that the server is in an MSCS cluster, and also provides details that name the active instance.  This enabled the MP to be written to determine that the SQL instance is clustered and helped the MP discovery discern which node was active.

    Assuming that the above cluster awareness is provided by the application installer and the running application logic, you can the successfully make the MP be aware of clusters. 

    One way to do this is to add a special parameter to your discovery logic, and another is by deriving your monitoring nodes (classes) from Microsoft.Windows.Cluster.VirtualServer.  Both of these options are explored in the sections below.  But first, let’s look at the considerations from a conceptual perspective.

    Node 1

    Node 2

    Virtual Node

     

     

     

     


    Figure 1:  Conceptual cluster view

    Figure 1 shows a diagram of a hypothetical MSCS cluster.  There are two agent managed computers (node 1, node 2) and a virtual node that is the logical address of the cluster that is used to provide the high availability behavior that MSCS enables.  Typically, the applications that use the clustered resource direct calls to the virtual node, and not the physicals since this makes the cluster status (one active, one inactive or active/active invisible to the upstream (calling) application elements.

    When SCOM is monitoring a MSCS cluster, there are three computers being managed.  Two of them are the physical nodes (typically an agent-managed computer), and one virtual node. The virtual node is a computer from the Ops Manager perspective – but since it does not really exist, it is always configured in an “agentless” configuration.

    Note:  Since Ops Manager must manage the virtual node in agentless configuration, all discovery and monitoring rules (and monitors, etc) in a cluster aware MP must be marked for “allow proxy” and for “remotable” behaviors.  The “allow proxy” setting will allow Ops Manager to see the events and counters on the real from the virtual managed instance; the “remotable” will allow agentless managed configuration.

    The first trick to making a management pack for a clustered application is to make sure that the operation components (as represented by classes defined in the management pack) are only discovered on the virtual node and not discovered on the physical nodes.  This approach lets the cluster aware application be monitored from a service level perspective and allows the MP author to not have to keep track of which is the active or inactive nodes – you are monitoring the clustered components – which are projections of the active physical node.

    Operations manager provides a property on Microsoft.Windows.Server.Computer base class that is useful for determining whether the agent is seeing the virtual node or a physical node.  The agent runs workflows – and runs them in the context of the node that it is examining.  The property named “isVirtualNode” is used in the discovery rule for your MP to limit discovery of the clustered elements of your product to only the virtual node.  Since there are always at least three agent invocations to worry about (one for each physical node, and the remote monitoring of the virtual node), you must only discover the classes that represent the clustered application components on the agent context that is managing the virtual node.

    The second consideration to making a management pack work in an clustered environment is to write all scripts in a way that prevents them from using local system resources.  Since the agent that manages the virtual node is always remote, the workflows that it runs will also be remotely running.  For the script writer, this means avoiding things like local path names, registry keys or other resources that would normally be accessible locally.  Instead, they must always connect remotely (WMI, for instance) and be able to know the remote reference that lets you connect to the right computer – the virtual.

    A third consideration involves event based workflows (e.g. rules and monitors that utilize events).  If the software logs events under the name of the virtual node instead of the physical node, the event parameters need to take this into account.  For example if you are passing a computer name into a workflow as a configuration parameter, you need to use a reference that looks like

    <ComputerName>

    $Target/Host/Property[Type=Windows!Microsoft.Windows.Computer”]/NetworkName$>

    </ComputerName>[1]

     instead of

     <Computername>.</ComputerName>

    Other factors to plan for when supporting clustered configurations is that the OM infrastructure itself has to be configured to support the cluster.  The Management Pack Guide that helps your customers be successful with the MP should point out the following:

    ·         Agents on the cluster physical nodes – these need to be installed on all physical cluster nodes.

    ·         All agents on these nodes need to be configured to “allow agent proxying”

    ·         When the agents are correctly configured on the physical node, the virtual node will automatically be discovered and listed in the “agentless managed” view in the administration section of the Ops Manager console.

    ·         This agentless managed computer is the one that the cluster aware workflows will run against.  The agent that manages the virtual node will be the one that manages the class instances discovered by your management pack.

    ·         The preliminary discoveries which detect instances of the role (clustered or stand-alone) must be targeted at the Microsoft.Windows.Server class from the Microsoft.Windows.Library MP.

    o   The discoveries will not work correctly if they are targeted at the specialized Windows Server and Operating System classes included in the Windows Server Base OS MP, as those objects are excluded from being discovered on Failover Cluster virtual computers.

    o   Given that discoveries targeted at Microsoft.Windows.Server are run on all Windows Servers, the preliminary discovery should be as basic as is possible.  More complex discoveries can then be targeted at the classes discovered by the preliminary discoveries.

    Option 1: When Cluster install is optional – use dynamic name determination

    Two examples of products that have cluster-aware management packs are SQL 2005 and Exchange.  These MPs determine whether the agent is looking at a MSCS cluster virtual node by making discovery logic that is based in part on the special ‘IsVirtualNode” property of the server class.  This is done via a parameter passed in as a part of the discovery to its discovery data source module.  This parameter gets its value from the server property via the following reference:

    $Target/Property[Type="Windows!Microsoft.Windows.Server.Computer"]/IsVirtualNode$

    At runtime, this setting value comes from the server computer class instance, which has a IsVirtualNode property. The MP only has to target a windows server computer in the discovery workflow to be able to access this value[2].  In the following abbreviated example, we see the discovery rule creating and passing a parameter to a discovery data source module.  This IsVirtualNode property is automatically set to the value “true” by Operations Manager when it discovers a cluster virtual node.  For physical servers, the value will always be set to the value “false”.

    Let’s look at an example of a discovery that makes use of this property (this is from the SQL 2005 management pack)

    <Discovery ID="Microsoft.SQLServer.2005.AnalysisServicesDiscoveryRule.Server" Enabled="true" Target="Windows!Microsoft.Windows.Server.Computer" ConfirmDelivery="false" Remotable="true" Priority="Normal">

       <Category>Discovery</Category>

       <DiscoveryTypes>

       </DiscoveryTypes>

       <DataSource ID="DS" TypeID="Microsoft.SQLServer.2005.AnalysisServicesDiscovery">

           <IntervalSeconds>14400</IntervalSeconds>

           <SyncTime />

    <ComputerID>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]

    /PrincipalName$</ComputerID>

    <ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]

    /NetworkName$</ComputerName>

    <ComputerNETBIOSName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]

    /NetbiosComputerName$</ComputerNETBIOSName>

    <IsVirtualNode>$Target/Property[Type="Windows!Microsoft.Windows.Server.Computer"]

    /IsVirtualNode$</IsVirtualNode>

    <TimeoutSeconds>300</TimeoutSeconds>

       </DataSource>

    </Discovery>

    Example 1:  Illustration of a discovery that passes the IsVirtualNode property to its data source module.

    The ‘IsVirtualNode’ property gets a value from the base Microsoft.Windows.Server.Computer that is defined in the ops manager library classes.  The value of this parameter will be the string “true” or “false”, depending on whether the server is the virtual node in a cluster or not.  Also, note that the discovery has to have the Remotable attribute set to true – this is because the agent has to remotely discover the elements on the virtual node.  The API calls will be passed through to the underlying active computer – but the context will be the virtual.  This means that your discovery will run three times on a cluster with two nodes - the two physical nodes (which should not discover your application types) and the virtual node (which should).  If your discovery module returns class data when run on the physical node, you will have trouble with inactive nodes generating alerts when they should not, possible counter missing alerts if the counters you use are dynamic, etc.   The goal is to only monitor the clustered elements of your application from the agent that is chosen to manage the virtual node.

    In the data source module, the value of this configuration parameter will be examined to see if its value is “true”.  When it is, it means that the discovery script is being called by an agent that is managing a virtual node in the cluster.  The Management Pack author must choose whether or not to make their discovery logic place the class instance being discovered on the agent that manages the virtual node, or on the physical node[3].  Deciding which classes in a management pack get placed on the agent managing the physical or virtual nodes takes knowledge of the application components being modeled.  A rule of thumb that helps make the determination can be characterized in questions listed below:

    ·         If the class represents the logical application from a “service availability” perspective and should not be managed separately on the underlying physical nodes in a cluster, only discover them when the IsVirtualNode value is “true”.

    ·         If the class represents a characteristic of the application that needs to impact the view of physical server health or those class instances are not cluster managed, only discover them when IsVirtualNode value is “false”

    ·         If the application does not do anything to support MSCS clustering, then only discover the classes when “IsVirtualNode” is false.

    o   Note:  This implies that all discoveries should consider being aware of the IsVirtualNode setting so that an application that happens to be running on a clustered computer resource is not discovered by the agent managing the virtual node in the cluster.

    The data source module will nearly always be a script.  In that script the flow of the logic will follow the pattern in the following pseudo code.

    Create a discovery data payload

    If you find the application elements that could be discovered on this computer Then

    If the instance of this application elements on this computer are part of a clustered instance (by looking at the application config) Then

    If the node that the agent is looking at is a VirtualNode Then

    Create a class instance representing this node

    Set the key properties for this class instance

    Set the key properties for the parent of this class instance (if a sub-class in a hierarchy)

    Add this class instance to the discovery data payload

    Else

    Do not discover the node (e.g. skip this one because while a part of a clustered node, this computer is not the virtual instance)

    End If

    Else

    We have discovered a non-clustered instance of an operations class for this application

    Create a class instance representing this node

    Set the key properties for this class instance

    Set the key properties for the parent of this class instance (if a sub-class in a hierarchy)

    Add this new class instance to the discovery data payload

    End If

    Else

    Do not discover the node (nothing to do because the application was not found on this computer at all)

    End If

    Return the discovery payload

    Code Snippet 1

    By following this logical path in your discovery data source module script, your discovery will work on both clustered and non-clustered instances of your application.  Your application configuration has to be able to distinguish a clustered version of your application from a non-clustered version, and your discovery should pass in the IsVirtualNode parameter discussed earlier.  The “do not discover” sections in this pseudocode example are there for clarity – you don’t have to write code that does nothing J

    Topical Tip

    When doing discovery in a clustered environment, try to avoid making the discovered values have text in their property settings that reflect whether the item is on a real or virtual node of a MSCS cluster.  Since you should not be discovering then clustered elements on the physical clusters, you won’t have the opportunity to use these properties.

    Note:  you can find the SQL examples in readable form here: http://sharepoint/sites/mpbestpactices/Shared%20Documents/OpsMgr2007Sp1-RTMMPs.zip

    Option 2:  Target your discoveries at Windows.Cluster.VirtualServer

    If you know that the product being managed will always be installed on a cluster (E.g your product is not allowed to be installed on a non-clustered configuration, then another option you have is to simply make your discoveries target the Microsoft.Windows.Cluster.VirtualServer class from the Microsoft.Windows.Cluster.Library MP.  This will only run your discovery workflow logic the virtual nodes in clusters.

    The key thing you need to do is specialize the root monitoring classes from VirtualServer and then target your discovery logic at this same type.  This will make Operations Manager run the discovery logic only on the virtual node in the MSCS cluster.  This type (VirtualServer) is defined and discovered automatically from a clustering library that is always imported (Microsoft.Windows.Cluster.Library).

    In addition, you must also take into account the advice from above related to not using local references, since the workflows in the MP will always be run remotely.

    You may not need a data source discovery script module with this kind of script.  If the component that is the class type that can be discovered are all always only installed on a MSCS computing cluster, the presence of a simple registry check should be enough[4].  The VirtualServer base class and target mean the discovery only runs on the agent that remotely probes the virtual computer.

     



    [1] Note:  The alias “Windows!” shown in this sample is defined by the MP author.  Each MP author can override the alias that is used to reference system library references, so in your own MP, this alias may change.

    [2] The discovery does not need to have a target value that is the Server.Computer level.  Instead, the parameter will be available if you only have a reference back to the hosting server computer.  E.g. $Target/Host/Property[Type=”Windows!Microsoft.Windows.Server.Computer”]/IsVirtualNode$

    [3] For clarity – the discovery will run on both physical nodes, and again on the agent managing the active node – this is how the virtual node is managed.  Since you want the service availability viewpoint, the agent context managing the virtual node is the one where your workflows need to be run.

    [4] Remember though, that the registry key has to be discovered remotely.  Ops manager should be able to manage this however because the agentless configuration is already capable of managing registry probes on remote agent managed computers.

     

     


    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    Friday, April 2, 2010 4:11 PM

All replies

  • The virtual node derives from windows.server.computer, which derives from windows.computer so your discovery runs for both the physical and virtual node, that's why you are getting multiple alerts.

    Since clusters run on servers, you should probably target windows.server.computer. You then need to check the IsVirtualNode property of the computer in your discovery to determine whether your discovery is running on the physical or virtual node.

    Assuming you only care about the virtual node, your discovery should then only discover something when isvirtualnode is true. However, this means that the app you're monitoring needs to be cluster aware, so that the monitoring will work against the virtual node. If not, consider only discovering when you'r running on the physical node. Then your app should only be discovered on the physical node.

    Ensure the discovery and other workflows are remotable (since it will run on the virtual node by the physical node owning the cluster)

    Here is a SQL example

    <Discovery ID="Microsoft.SQLServer.2005.AnalysisServicesDiscoveryRule.Server" Enabled="true" Target="Windows!Microsoft.Windows.Server.Computer" ConfirmDelivery="false" Remotable="true" Priority="Normal">

       <Category>Discovery</Category>

       <DiscoveryTypes>

       </DiscoveryTypes>

       <DataSource ID="DS" TypeID="Microsoft.SQLServer.2005.AnalysisServicesDiscovery">

           <IntervalSeconds>14400</IntervalSeconds>

           <SyncTime />

    <ComputerID>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]

    /PrincipalName$</ComputerID>

    <ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]

    /NetworkName$</ComputerName>

    <ComputerNETBIOSName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]

    /NetbiosComputerName$</ComputerNETBIOSName>

    <IsVirtualNode>$Target/Property[Type="Windows!Microsoft.Windows.Server.Computer"]

    /IsVirtualNode$</IsVirtualNode>

    <TimeoutSeconds>300</TimeoutSeconds>

       </DataSource>

    </Discovery>

     

     

     

     


    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    • Proposed as answer by Vivian Xing Monday, April 5, 2010 7:10 AM
    Thursday, April 1, 2010 12:27 AM
  • Thanks a lot Ake for your guidance. Is it possible to do cluster aware discovery through Auth console? I used to create discovery and rules through auth console only. In that case can i select "Registry filtered" for this clustered aware discovery. Sorry if this question is very immature...
    Friday, April 2, 2010 3:35 PM
  • Clustering is tricky, your choices depend on whether your application is cluster aware. Pasting in a document that explains some of this.

    Note that from an infrastructure side, the way OM does cluster monitoring is that the agent on the active node does monitoring on behalf of the virtual server. That's why agent proxy is required and also why your workflows need to be remotable. Upon failover, the new active node does monitoring. Another thing to consider is that there is an override if the customer implements multiple network names for a resource group, by default we only discover one.

    Take a deep breath, here's the doc.

     

    When you develop a management pack for a cluster aware application or product, you need to take special steps to help the OpsMgr health service to make the right decisions for discoveries, tasks, monitors and rules to run correctly against monitoring classes that represent the operating components in cluster aware applications.  To do this, you take advantage of the IsVirtualNode property on the Windows.Server.Computer class from the Microsoft.Windows.Library management pack.  This property is provide to allow MP authors to create management packs that are MSCS cluster aware by implementing special discovery logic so that your monitoring logic only “activates” the monitoring required on the virtual node and not on either of the physical nodes that make up a cluster.  The management pack author has to choose to check for whether the application is in a clustered state, and then only “discover” the application components on the virtual node of the cluster.

    Often, MP authors read this first paragraph and conclude that becoming cluster aware is something they can do in the management pack.  Most of them fail.  The reason is that to be cluster aware, the application itself has to provide two critical pieces of information that are impossible for the MP author to manufacture.  These two items are:

    ·         AppInstalledInClusteredConfiguration:  This flag, which is just a variable name for illustrative purposes, indicates that the application MSI has dropped the bits for the app in a clustered configuration.

    ·         ClusteredApplicationItemIsOnActiveNode:  this flag, also illustrative, is used to tell anyone interested that the particular clustered element (via clustered resource group) is on the currently active node in the cluster.

    When these two items are not discernible in the discovery scripts in a management pack, it will not be possible to successfully make the MP be cluster aware.  If the app installer doesn’t leave a breadcrumb that indicates that the app is in a clustered configuration, and if the running application does not provide a way to tell if a particular node is the currently active node, then the best the MP author can do is make sure the app ignores clusters by making sure the “isVirtual” flag on the computer class is blank.

    For example, the newest SQL server MP added support for SQL clusters. This was made possible because SQL provides special table entries to reflect that the server is in an MSCS cluster, and also provides details that name the active instance.  This enabled the MP to be written to determine that the SQL instance is clustered and helped the MP discovery discern which node was active.

    Assuming that the above cluster awareness is provided by the application installer and the running application logic, you can the successfully make the MP be aware of clusters. 

    One way to do this is to add a special parameter to your discovery logic, and another is by deriving your monitoring nodes (classes) from Microsoft.Windows.Cluster.VirtualServer.  Both of these options are explored in the sections below.  But first, let’s look at the considerations from a conceptual perspective.

    Node 1

    Node 2

    Virtual Node

     

     

     

     


    Figure 1:  Conceptual cluster view

    Figure 1 shows a diagram of a hypothetical MSCS cluster.  There are two agent managed computers (node 1, node 2) and a virtual node that is the logical address of the cluster that is used to provide the high availability behavior that MSCS enables.  Typically, the applications that use the clustered resource direct calls to the virtual node, and not the physicals since this makes the cluster status (one active, one inactive or active/active invisible to the upstream (calling) application elements.

    When SCOM is monitoring a MSCS cluster, there are three computers being managed.  Two of them are the physical nodes (typically an agent-managed computer), and one virtual node. The virtual node is a computer from the Ops Manager perspective – but since it does not really exist, it is always configured in an “agentless” configuration.

    Note:  Since Ops Manager must manage the virtual node in agentless configuration, all discovery and monitoring rules (and monitors, etc) in a cluster aware MP must be marked for “allow proxy” and for “remotable” behaviors.  The “allow proxy” setting will allow Ops Manager to see the events and counters on the real from the virtual managed instance; the “remotable” will allow agentless managed configuration.

    The first trick to making a management pack for a clustered application is to make sure that the operation components (as represented by classes defined in the management pack) are only discovered on the virtual node and not discovered on the physical nodes.  This approach lets the cluster aware application be monitored from a service level perspective and allows the MP author to not have to keep track of which is the active or inactive nodes – you are monitoring the clustered components – which are projections of the active physical node.

    Operations manager provides a property on Microsoft.Windows.Server.Computer base class that is useful for determining whether the agent is seeing the virtual node or a physical node.  The agent runs workflows – and runs them in the context of the node that it is examining.  The property named “isVirtualNode” is used in the discovery rule for your MP to limit discovery of the clustered elements of your product to only the virtual node.  Since there are always at least three agent invocations to worry about (one for each physical node, and the remote monitoring of the virtual node), you must only discover the classes that represent the clustered application components on the agent context that is managing the virtual node.

    The second consideration to making a management pack work in an clustered environment is to write all scripts in a way that prevents them from using local system resources.  Since the agent that manages the virtual node is always remote, the workflows that it runs will also be remotely running.  For the script writer, this means avoiding things like local path names, registry keys or other resources that would normally be accessible locally.  Instead, they must always connect remotely (WMI, for instance) and be able to know the remote reference that lets you connect to the right computer – the virtual.

    A third consideration involves event based workflows (e.g. rules and monitors that utilize events).  If the software logs events under the name of the virtual node instead of the physical node, the event parameters need to take this into account.  For example if you are passing a computer name into a workflow as a configuration parameter, you need to use a reference that looks like

    <ComputerName>

    $Target/Host/Property[Type=Windows!Microsoft.Windows.Computer”]/NetworkName$>

    </ComputerName>[1]

     instead of

     <Computername>.</ComputerName>

    Other factors to plan for when supporting clustered configurations is that the OM infrastructure itself has to be configured to support the cluster.  The Management Pack Guide that helps your customers be successful with the MP should point out the following:

    ·         Agents on the cluster physical nodes – these need to be installed on all physical cluster nodes.

    ·         All agents on these nodes need to be configured to “allow agent proxying”

    ·         When the agents are correctly configured on the physical node, the virtual node will automatically be discovered and listed in the “agentless managed” view in the administration section of the Ops Manager console.

    ·         This agentless managed computer is the one that the cluster aware workflows will run against.  The agent that manages the virtual node will be the one that manages the class instances discovered by your management pack.

    ·         The preliminary discoveries which detect instances of the role (clustered or stand-alone) must be targeted at the Microsoft.Windows.Server class from the Microsoft.Windows.Library MP.

    o   The discoveries will not work correctly if they are targeted at the specialized Windows Server and Operating System classes included in the Windows Server Base OS MP, as those objects are excluded from being discovered on Failover Cluster virtual computers.

    o   Given that discoveries targeted at Microsoft.Windows.Server are run on all Windows Servers, the preliminary discovery should be as basic as is possible.  More complex discoveries can then be targeted at the classes discovered by the preliminary discoveries.

    Option 1: When Cluster install is optional – use dynamic name determination

    Two examples of products that have cluster-aware management packs are SQL 2005 and Exchange.  These MPs determine whether the agent is looking at a MSCS cluster virtual node by making discovery logic that is based in part on the special ‘IsVirtualNode” property of the server class.  This is done via a parameter passed in as a part of the discovery to its discovery data source module.  This parameter gets its value from the server property via the following reference:

    $Target/Property[Type="Windows!Microsoft.Windows.Server.Computer"]/IsVirtualNode$

    At runtime, this setting value comes from the server computer class instance, which has a IsVirtualNode property. The MP only has to target a windows server computer in the discovery workflow to be able to access this value[2].  In the following abbreviated example, we see the discovery rule creating and passing a parameter to a discovery data source module.  This IsVirtualNode property is automatically set to the value “true” by Operations Manager when it discovers a cluster virtual node.  For physical servers, the value will always be set to the value “false”.

    Let’s look at an example of a discovery that makes use of this property (this is from the SQL 2005 management pack)

    <Discovery ID="Microsoft.SQLServer.2005.AnalysisServicesDiscoveryRule.Server" Enabled="true" Target="Windows!Microsoft.Windows.Server.Computer" ConfirmDelivery="false" Remotable="true" Priority="Normal">

       <Category>Discovery</Category>

       <DiscoveryTypes>

       </DiscoveryTypes>

       <DataSource ID="DS" TypeID="Microsoft.SQLServer.2005.AnalysisServicesDiscovery">

           <IntervalSeconds>14400</IntervalSeconds>

           <SyncTime />

    <ComputerID>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]

    /PrincipalName$</ComputerID>

    <ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]

    /NetworkName$</ComputerName>

    <ComputerNETBIOSName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]

    /NetbiosComputerName$</ComputerNETBIOSName>

    <IsVirtualNode>$Target/Property[Type="Windows!Microsoft.Windows.Server.Computer"]

    /IsVirtualNode$</IsVirtualNode>

    <TimeoutSeconds>300</TimeoutSeconds>

       </DataSource>

    </Discovery>

    Example 1:  Illustration of a discovery that passes the IsVirtualNode property to its data source module.

    The ‘IsVirtualNode’ property gets a value from the base Microsoft.Windows.Server.Computer that is defined in the ops manager library classes.  The value of this parameter will be the string “true” or “false”, depending on whether the server is the virtual node in a cluster or not.  Also, note that the discovery has to have the Remotable attribute set to true – this is because the agent has to remotely discover the elements on the virtual node.  The API calls will be passed through to the underlying active computer – but the context will be the virtual.  This means that your discovery will run three times on a cluster with two nodes - the two physical nodes (which should not discover your application types) and the virtual node (which should).  If your discovery module returns class data when run on the physical node, you will have trouble with inactive nodes generating alerts when they should not, possible counter missing alerts if the counters you use are dynamic, etc.   The goal is to only monitor the clustered elements of your application from the agent that is chosen to manage the virtual node.

    In the data source module, the value of this configuration parameter will be examined to see if its value is “true”.  When it is, it means that the discovery script is being called by an agent that is managing a virtual node in the cluster.  The Management Pack author must choose whether or not to make their discovery logic place the class instance being discovered on the agent that manages the virtual node, or on the physical node[3].  Deciding which classes in a management pack get placed on the agent managing the physical or virtual nodes takes knowledge of the application components being modeled.  A rule of thumb that helps make the determination can be characterized in questions listed below:

    ·         If the class represents the logical application from a “service availability” perspective and should not be managed separately on the underlying physical nodes in a cluster, only discover them when the IsVirtualNode value is “true”.

    ·         If the class represents a characteristic of the application that needs to impact the view of physical server health or those class instances are not cluster managed, only discover them when IsVirtualNode value is “false”

    ·         If the application does not do anything to support MSCS clustering, then only discover the classes when “IsVirtualNode” is false.

    o   Note:  This implies that all discoveries should consider being aware of the IsVirtualNode setting so that an application that happens to be running on a clustered computer resource is not discovered by the agent managing the virtual node in the cluster.

    The data source module will nearly always be a script.  In that script the flow of the logic will follow the pattern in the following pseudo code.

    Create a discovery data payload

    If you find the application elements that could be discovered on this computer Then

    If the instance of this application elements on this computer are part of a clustered instance (by looking at the application config) Then

    If the node that the agent is looking at is a VirtualNode Then

    Create a class instance representing this node

    Set the key properties for this class instance

    Set the key properties for the parent of this class instance (if a sub-class in a hierarchy)

    Add this class instance to the discovery data payload

    Else

    Do not discover the node (e.g. skip this one because while a part of a clustered node, this computer is not the virtual instance)

    End If

    Else

    We have discovered a non-clustered instance of an operations class for this application

    Create a class instance representing this node

    Set the key properties for this class instance

    Set the key properties for the parent of this class instance (if a sub-class in a hierarchy)

    Add this new class instance to the discovery data payload

    End If

    Else

    Do not discover the node (nothing to do because the application was not found on this computer at all)

    End If

    Return the discovery payload

    Code Snippet 1

    By following this logical path in your discovery data source module script, your discovery will work on both clustered and non-clustered instances of your application.  Your application configuration has to be able to distinguish a clustered version of your application from a non-clustered version, and your discovery should pass in the IsVirtualNode parameter discussed earlier.  The “do not discover” sections in this pseudocode example are there for clarity – you don’t have to write code that does nothing J

    Topical Tip

    When doing discovery in a clustered environment, try to avoid making the discovered values have text in their property settings that reflect whether the item is on a real or virtual node of a MSCS cluster.  Since you should not be discovering then clustered elements on the physical clusters, you won’t have the opportunity to use these properties.

    Note:  you can find the SQL examples in readable form here: http://sharepoint/sites/mpbestpactices/Shared%20Documents/OpsMgr2007Sp1-RTMMPs.zip

    Option 2:  Target your discoveries at Windows.Cluster.VirtualServer

    If you know that the product being managed will always be installed on a cluster (E.g your product is not allowed to be installed on a non-clustered configuration, then another option you have is to simply make your discoveries target the Microsoft.Windows.Cluster.VirtualServer class from the Microsoft.Windows.Cluster.Library MP.  This will only run your discovery workflow logic the virtual nodes in clusters.

    The key thing you need to do is specialize the root monitoring classes from VirtualServer and then target your discovery logic at this same type.  This will make Operations Manager run the discovery logic only on the virtual node in the MSCS cluster.  This type (VirtualServer) is defined and discovered automatically from a clustering library that is always imported (Microsoft.Windows.Cluster.Library).

    In addition, you must also take into account the advice from above related to not using local references, since the workflows in the MP will always be run remotely.

    You may not need a data source discovery script module with this kind of script.  If the component that is the class type that can be discovered are all always only installed on a MSCS computing cluster, the presence of a simple registry check should be enough[4].  The VirtualServer base class and target mean the discovery only runs on the agent that remotely probes the virtual computer.

     



    [1] Note:  The alias “Windows!” shown in this sample is defined by the MP author.  Each MP author can override the alias that is used to reference system library references, so in your own MP, this alias may change.

    [2] The discovery does not need to have a target value that is the Server.Computer level.  Instead, the parameter will be available if you only have a reference back to the hosting server computer.  E.g. $Target/Host/Property[Type=”Windows!Microsoft.Windows.Server.Computer”]/IsVirtualNode$

    [3] For clarity – the discovery will run on both physical nodes, and again on the agent managing the active node – this is how the virtual node is managed.  Since you want the service availability viewpoint, the agent context managing the virtual node is the one where your workflows need to be run.

    [4] Remember though, that the registry key has to be discovered remotely.  Ops manager should be able to manage this however because the agentless configuration is already capable of managing registry probes on remote agent managed computers.

     

     


    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    Friday, April 2, 2010 4:11 PM
  • Also to add to that, you should be able to accomplish this using the Authoring Console. However, there is no wizard, template, or other guidance to help with it.


    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    Friday, April 2, 2010 6:49 PM
  • Thanks a lot Ake and Marcin. Initially it was not working out. Then today i read the above doc slowly (i need more patience) and created the MP accordingly. Now i am able to discover my cluster servers.

    Thanks for your time and post.

     

    Wednesday, April 7, 2010 5:59 PM
  • Would you be able to share the xml?  I've read the doc several times and I cannot get it to discovery anything when trying to use the IsVirtualNode property.
    Layne
    Wednesday, April 7, 2010 8:37 PM
  • Hi Layne,

    My approach didn't work when i created the rules for the class. I am still searching, if you find anything, Please share the xml with me.

    Thanks.

    Monday, May 17, 2010 6:23 PM