CA Service Management

  • Private Community

  • 1.  SDM 14.1 Cluster

    Posted Apr 13, 2016 05:32 AM

    Hi Team,

    I am implementing CA SDM 14.1 Windows and SQL cluster environment. i have followed the following steps:

     

    1. Gave the ownership to node 1. Installed CA Service Desk Manager Primary Server Installation on Node 1 with database cluster name

    2. Verified the installation on  node 1

    3. Shutdown the services of CA SDM on node 1

    4. Gave the ownership to node 2

    5. Installed CA Service Desk Manager Primary Server Installation on Node 2 with database cluster name

    6. Verified the installation on node 2

     

    Now during test failover, i have given the ownership to node 1 again. I have tried to manually start the CA SDM services, but i am not able to start it. It is in starting state and giving me the error that windows service is not able to start.

     

    Kindly guide me

     

     

    Regards,

    PMO DCN



  • 2.  Re: SDM 14.1 Cluster

    Posted Apr 13, 2016 06:51 AM

    Failover clustering of the SDM application server under 14.x can be made to work but I'm not sure that CA would regard it as a supported configuration, although I have recently implemented it - with much help from colleagues - for a customer who had no budget for standing up additional VMs and load balancer and wanted to re-use the VMs from their previous r12.6 installation.  The Advanced Availability (AA) architecture has a number of advantages over Failover clustering.  I'd encourage you to review the AA architecture and only go down the failover path if you have no alternative.  If you're really stuck with it I can supply some notes on how to successfully install SDM 14.1.02 in a failover cluster, but I'd rather not encourage it.

     

    Regards,

    James



  • 3.  Re: SDM 14.1 Cluster

    Posted Apr 13, 2016 08:38 AM

    Hi James and PMO DCN,

    From a support standpoint, we do NOT support the cluster itself, however you can install our products in a cluster environment.  Service Desk is what we call "cluster tolerant" but it is NOT "cluster aware" - meaning, we can be installed in a cluster environment, but we are not aware of the cluster and do not act based upon the status of cluster nodes.  Thus there is no automatic way of failing over seamlessly.  As for the SQL side, when you failover a SQL cluster, there will be a disconnection that occurs, which can affect Service Desk depending on  how long that takes to complete.  We have had some customers recently that made a switch to complete solid-state storage for their SQL clusters, and the failover takes mere fractions of a second, and they are able to do it without affecing the product at all. In a traditional storage environment, many customers end up having to recycle service desk services to get the connection to the db re-established.  Now, as for Advanced Availability (called AA as James mentioned) - it does offer high availability for the  application, but the best advantage of it in my opinion is the performance increase due to the fact that in an AA environment, each app server has its own virtual-database process, and its own db agents, allowing for much more efficient query returns from the db than the conventional architecture in which all db transactions are done through the primary server only.  So the AA architecture will cut out a lot of excess communication between servers, allowing for much better performance.  I agree with James that  clustering should really only be a last resort as it wont really offer you much in regards to high availability within the product itself.  Failing over the Service Desk application server wont be seemless, and will require manual intervention. 

    For info about the Advanced Availability architecture, take a look at the wiki site here: Installation Considerations - CA Service Management - 14.1 - CA Technologies Documentation

    Hope this helps,

    Jon Israel

    Principal Support Engineer

    CA Technologies



  • 4.  Re: SDM 14.1 Cluster

    Broadcom Employee
    Posted May 22, 2018 08:40 AM

    The latest update we got from product team as on today is that they have successfully tested Always On when failover occurs between MS SQL Servers on the same subnet.

     

    However, we don’t support Always On failover between MS SQL Servers on different subnets, because Microsoft doesn’t support it for SQL Server Native Client OLE DB.

     

    Unfortunately Microsoft doesn’t support MultiSubnetFailover=True for SQL Server Native Client OLE DB as per below document: 

    https://docs.microsoft.com/en-us/sql/integration-services/connection-manager/ole-db-connection-manager?view=sql-server-2017