locked
ENTSSO configuration on SQL Cluster RRS feed

  • Question

  • Hi,

    Need your suggestion.

    We have 2 SQL Servers and 2 SQL Instances(one for messagebox and other for rest BizTalk Databases). Instance 1 is Active in SQL 1 and Passive in SQL 2, Instance 2 Active in SQL 2 and Passive in SQL 1.

    We are planned to install ENTSSO inSQL 1 &2(1 as primary) and SSO will be cluster( Meaning SSO service i up in one SQL server & in other SSO will in stopped state). Will this approach work?? since SSO is not running other instance, will it have any impact??  

    Also What is the best practice for Configuring ENTSSO out of below:-

    1) On SQL Cluster? 
    2) Move out to some other Server with Less Configuration Or
    3) On Biztalk Server(4 BizTalk nodes available)

    Regards,
    Ravoof

    Sunday, December 6, 2015 7:52 AM

Answers

  • There are very specific instructions on how to cluster the Master Secret Server: https://msdn.microsoft.com/en-us/library/aa561823.aspx?f=255&MSPPError=-2147217396

    Some key points that are not obvious:

    1. The point is to cluster the Master Secret Server, not just the ESSO Server.  ESSO will also be running on the BizTalk Host Computers.
    2. The MSS should be clustered with the SQL Server Instance that runs the SSODB database.
    3. You install the Master Secret Server components from the BizTalk setup media on both SQL nodes.  Do not install them on the BizTalk computers.
    4. ESSO, MSS or not, has nothing to do with the MessageBox so that's not really an issue.
    5. You do not have an Active/Active cluster.  What you have are two Active/Passive clusters that cross failover.
    • Marked as answer by Angie Xu Wednesday, December 16, 2015 2:40 AM
    Sunday, December 6, 2015 8:09 PM
    Moderator

All replies

  • In your scenario it would be a better option to go with a clustered SSO on the SQL Cluster (1). Refer to https://msdn.microsoft.com/en-us/library/aa561823.aspx on how to cluster the SSO (primary). Additionally specific to your scenario, cluster it in the second SQL Instance (the rest of the BizTalk Databases).

    You may want to also have a look at creating specific MSDTC mappings for each of your resource groups. If you create a MSDTC resource specific to each SQL Instance then you'd need to specify MSDTC mapping for the clustered SSO for it to work. Refer to https://technet.microsoft.com/en-us/library/cc742483(v=ws.10).aspx

    Regards.

    Sunday, December 6, 2015 3:13 PM
  • Thanks For your response.

    A quick question, if SSODB instance is running\Active in Server2(where as msgbox instance in Active in Server1), is it not required to make ENTSSO Service also running in Server2??Is it ok, if ENTSSO service running in Server1 and SSODB instance is active in Server2?

    Sunday, December 6, 2015 6:53 PM
  • There are very specific instructions on how to cluster the Master Secret Server: https://msdn.microsoft.com/en-us/library/aa561823.aspx?f=255&MSPPError=-2147217396

    Some key points that are not obvious:

    1. The point is to cluster the Master Secret Server, not just the ESSO Server.  ESSO will also be running on the BizTalk Host Computers.
    2. The MSS should be clustered with the SQL Server Instance that runs the SSODB database.
    3. You install the Master Secret Server components from the BizTalk setup media on both SQL nodes.  Do not install them on the BizTalk computers.
    4. ESSO, MSS or not, has nothing to do with the MessageBox so that's not really an issue.
    5. You do not have an Active/Active cluster.  What you have are two Active/Passive clusters that cross failover.
    • Marked as answer by Angie Xu Wednesday, December 16, 2015 2:40 AM
    Sunday, December 6, 2015 8:09 PM
    Moderator
  • There is no restriction on where you wish to cluster SSO. Remember that you can setup a separate cluster ONLY for the purposes of clustering the SSO. This would however require a separate set of BizTalk Licenses. However should you choose to cluster the SSO on the SQL then you do not need to have separate BizTalk licenses.

    That having said, it is all about how you work out the MSDTC instances involved in a multi-instance SQL cluster. When dealing with multiple instances on the cluster, it is better to have separate MSDTC instances (one MSDTC per SQL Named Instance). When you do this, you need to explicitly associate the MSDTC instance with the SQL Instance. The second link in my previous post will help you do that (or you can bing for msdtc -tmMapping<Set/View/Clear>)

    So hosting the SSO Service on the same instance as the SSODB will make it simpler, you can choose to complicate it with creating a separate resource group to host the SSO Service and create a specific MSDTC instance to ensure proper working.

    Regards.

    Monday, December 7, 2015 5:16 AM