Problem with the discovery of clustered SQL Server Analysis Services objects

Respondida Problem with the discovery of clustered SQL Server Analysis Services objects

  • viernes, 27 de abril de 2012 19:24
     
     

    Hello,

    I was wondering if others may be experiencing the same issue with the SQL Server MP.

    It would appear that the SQL Server MP does not handle the discovery of the Analysis Services objects when they are in a clustered configuration.  For each instance of the service, an instance/object is currently being created for:

    • Each node of the cluster; and
    • Each virtual server name hosted by the hosting node, despite the fact that they are in different resource groups; and
    • The virtual server name representing the cluster itself

    Note that this is quite different than the discovery of the DB Engine objects, where only one instance is instantiated/discovered.  Furthermore, this instance is, as expected, associated with the corresponding virtual server name in the same resource group.

    Since the “Alert only if service startup type is automatic” option is currently enabled for the SQL Server Analysis Services Windows Service monitor, we essentially have no monitoring of the service for any of our clustered instances (with Startup Type = “Manual”).  If we disable the option, it will raise alerts for the object instances on the other nodes in the cluster (and possibly the cluster virtual server name), since it is stopped there.

    Does anyone have a solution to this problem?

    Larry

    P.S. Though we are using an old version of the MP (v6.0.6648.0), I have confirmed the same behavior in our pre-production environment, where I am testing the latest version of the MP (v6.3.173.0).

Todas las respuestas

  • viernes, 27 de abril de 2012 19:36
     
     

    One more thing...

    Note that the same behavior occurs with the instances of the non-clustered Integration Services objects, where an instance/object is currently being created for:

    • Each node of the cluster; and

    Note that this discovery is normal as it is a non-clustered object on each node of the cluster.

    • Each virtual server name hosted by the hosting node; and
    • The virtual server name representing the cluster itself

    It is possible that the Reporting Services class suffers from the same problem, though I have not confirmed as we haven't installed it in any of our clusters.

  • lunes, 30 de abril de 2012 18:21
     
     

    One last thing...

    I have just confirmed the very same behaviour with teh Reporting Services class.

  • martes, 01 de mayo de 2012 0:27
     
     

    Here is an explination of the problem and a fix:

    http://blogs.technet.com/b/jimmyharper/archive/2009/02/21/no-alert-from-sql-mp-when-clustered-services-go-down.aspx

    Let me know if this solves your problems.  If it does, maybe we can look into how we might do this dynamically (so we aren't stuck creating overrides each time a new SQL cluster comes onboard).

  • lunes, 07 de mayo de 2012 20:41
     
     

    It does "solve" the problem for the DB Engine instances, as each instance is discovered once and associated with the virtual server name (i.e. in the same resource group).  I say "solve", as ideally, the monitor should have an override disabling the "Alert only if startup type is automatic" against clustered DB Engine instances.

    Another bigger problem lies in the fact that multiple instances of the Aalysis Services, Integration Services, and Reporting Services are being instantiated for each instance of the servive.  Specifically, one is being created for each of the following:

    • Each node in the cluster, both passive and active (ex.: PPD-HQ-N16 & PPD-HQ-N17); and
    • The cluster virtual server itself (ex.: PPD-HQ-C11); and
    • Each virtual server (ex.: PPD-HQ-S09, PPD-HQ-S10, and PPD-HQ-S11DA);

    Note that if discovery would be working as expected (i.e. as is the case with the discovery of the SQL Server 200x Database Engine class), we would only see a single instance discovered.  Furthermore, it would be associated with the virtual server hosted by the same resource group hosting the AS resource.  In our case, that would be PPD-HQ-S11DA.

    As such, if I were to create the same override as described in the Corrective Action - DB Engine section above, the health state of the instances running on each of the following servers would fall to critical, as the service is not running on any of the passive nodes:

    • The passive node(s) in the cluster; and
    • Any other virtual servers currently hosted on any of the above passive node(s) (including the cluster virtual server, PPD-HQ-C11).

    Please note that we are seeing this behavior in our Production environment, which is running v6.0.6648.0 of the Microsoft SQL Server MP, as well as in our Pre-Production environment, which is running a recently upgraded v6.3.173.0 of the same MP.

    Larry

  • jueves, 31 de mayo de 2012 14:55
     
     Respondida

    Muppet news flash!!!

    Please note that I managed to successfully deploy a “work around” for the Integration Services (IS) and Reporting Services (RS) classes by:

    1) creating an override disabling the IS & RS discoveries for Windows Server objects whose “Is Virtual Node = True” (using a group of course);

    2) running the Remove-DisabledMonitoringObject PoSH cmdlet

    3) creating an identical override as with the DB Engine class, disabling the service monitor's "Check Startup Type" parameter.

    I have a ticket open with Microsoft on the above issue, who have confirmed the bugs, and are currently working on a rewrite of most of the discovery capabilities supplied with the MP, not just for AS but to globally improve the clustering interactions.

    Thanks,


    Larry

    • Marcado como respuesta larry.leblanc jueves, 31 de mayo de 2012 14:56
    •  
  • viernes, 01 de junio de 2012 17:58
     
     

    Please note that I have yet to find a workable solution for the Analysis Services (AS) class.  Hopefully this will be corrected in the next version of the MP.

    Larry