locked
BizTalk Server Disaster Recovery Test Case Scenarios RRS feed

  • Question

  • 1.what are the test case scenarios  to be execute to process of DR Testing(please list out ?

    2.our primary site production server have 2 BTS and clustered SQL(active/passive) config.so to implement DR Site do i need to go for same two biztalk server (or) 1 single BTS server with 1 SQL Server is enough?(Because some budget issue with customer)

    3Once logshipping is done and verified the DR working, how to switch back to Primary Site?

    Could you please respond for above Q's?

    Tuesday, January 13, 2015 9:00 PM

Answers

    1. DR test case scenarios:

    We have followed two approaches depends on client.

    Approach 1: Sample Smoke testing:

    During DR testing, we will have set of smoke test to test the general health of the server and its different applications and BizTalk artifacts. This smoke testing would cover at least one test case for each application installed. And also ensure these smoke test cases cover all the BizTalk artifacts like adapters, host instances, IIS etc.

    Approach 2: Run DR server as primary site during test for a specified period.

    Some clients prefer to use this approach as this gives more confidence on their DR setup. Here we would switch the DR server as primary site and run the BizTalk processing in DR for a day (or for few hours sometimes). In this case since this DR test, we at least have main primary sit to fall back due to any issue, so we could confidently run the actual production processing for a specified period of time. This approach would give high level of confidence that our DR server was tested to handle the production processing when there is real issue of main site failure. Obviously this would not give 100% assurance and we could not cover all the possible cases during the specified period (like peak period), but would give better confidence compared to other standard testing approaches.

    2) Server Requirement:

    In ideal world or correct approach is to have same setup as primary site in DR. But in many cases it would not be possible. In those cases lesser availability of server is okay but obvious risk has to be understood. And in your case, I don’t think the server infrastructure in massive. So I don’t except that having exact replica of server infrastructure would have major impact on budget. I personally would not take trade off on saving smaller money in my budget to having risk free DR environment. If the server infrastructure is really high I could consider saving money on lesser server, but in yours it should not be an issue.

    3) Switch back to Primary Site:

    It depends on what test approach you choose in you DR testing. If you just apply smoke test approach where you would not do really world messaging in DR testing, then you don’t need to restore the log shipping back to your primary site. But if you allow any actual production data processing during your DR site testing, you need to continue do backup in your DR during your testing and restore the log shipping from DR to primary site when you switch back.

    Regards,

    M.R.Ashwin Prabhu


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    • Marked as answer by Angie Xu Monday, January 19, 2015 2:20 AM
    Tuesday, January 13, 2015 10:49 PM
  • Coming to your other questions:

    4) Yes, if you have let any production/live messages to be processed by DR’s BizTalk databases, then you need to use the log-shipping from DR and restore in primary site’s databases again which you switch back from DR to live.

    5) I believe the MSDN reference you’re mentioning here is http://msdn.microsoft.com/en-us/library/gg634436%28v=bts.70%29.aspx. This article from MSDN is just to prepare the DR server just as runtime/processing server and keep using the production (or primary site’s) databases.

    A robust DR solution, should also consider both processing BizTalk server and its databases. Normally we keep processing servers and its related database servers close to each other (in different servers obviously) , what if the whole area where your primary server located is flooded. In this case you need to rely on DR server for both processing and also for databases.

    In the case where your “primary BizTalk processing sever and primary BizTalk database server” are separate to your “DR BizTalk processing sever and DR BizTalk database server”, and once you have allowed any production message to be processed by DR servers, when you switch back you need to restore the DR server log-shipping data which would restore the synchronisation between you BizTalk databases.

    In the case where your “DR BizTalk processing sever uses primary BizTalk database servers”: You don’t need to restore the log shipping when you switch back to “primary BizTalk processing sever and primary BizTalk database server”

    Regards,

    M.R.Ashwin Prabhu


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    • Marked as answer by Angie Xu Monday, January 19, 2015 2:21 AM
    Wednesday, January 14, 2015 5:18 PM

All replies

    1. DR test case scenarios:

    We have followed two approaches depends on client.

    Approach 1: Sample Smoke testing:

    During DR testing, we will have set of smoke test to test the general health of the server and its different applications and BizTalk artifacts. This smoke testing would cover at least one test case for each application installed. And also ensure these smoke test cases cover all the BizTalk artifacts like adapters, host instances, IIS etc.

    Approach 2: Run DR server as primary site during test for a specified period.

    Some clients prefer to use this approach as this gives more confidence on their DR setup. Here we would switch the DR server as primary site and run the BizTalk processing in DR for a day (or for few hours sometimes). In this case since this DR test, we at least have main primary sit to fall back due to any issue, so we could confidently run the actual production processing for a specified period of time. This approach would give high level of confidence that our DR server was tested to handle the production processing when there is real issue of main site failure. Obviously this would not give 100% assurance and we could not cover all the possible cases during the specified period (like peak period), but would give better confidence compared to other standard testing approaches.

    2) Server Requirement:

    In ideal world or correct approach is to have same setup as primary site in DR. But in many cases it would not be possible. In those cases lesser availability of server is okay but obvious risk has to be understood. And in your case, I don’t think the server infrastructure in massive. So I don’t except that having exact replica of server infrastructure would have major impact on budget. I personally would not take trade off on saving smaller money in my budget to having risk free DR environment. If the server infrastructure is really high I could consider saving money on lesser server, but in yours it should not be an issue.

    3) Switch back to Primary Site:

    It depends on what test approach you choose in you DR testing. If you just apply smoke test approach where you would not do really world messaging in DR testing, then you don’t need to restore the log shipping back to your primary site. But if you allow any actual production data processing during your DR site testing, you need to continue do backup in your DR during your testing and restore the log shipping from DR to primary site when you switch back.

    Regards,

    M.R.Ashwin Prabhu


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    • Marked as answer by Angie Xu Monday, January 19, 2015 2:20 AM
    Tuesday, January 13, 2015 10:49 PM
  • Thank you very much for in details explanation.

    Few more Queries:

    4.if i choose approach-2 test case scenario ,once DR Server is up and got the confidence then if i want to move back to primary Site means I have to do the log-shipping from DR to Primary again(same procedure steps)?

    5.As per MSDN,Configure these BizTalk Server run-time servers using the BizTalk Configuration Wizard to join them to the production BizTalk group.

      Here the question is Production BizTalk group is binded with PROD SQL Server Cluster Server.So when we join DR Servers to PROD Group it means we are connecting DR servers to PROD SQL Server Cluster DB right.

    what about DR SQL DB then.if we are mapping DR servers to PROD SQL then why log shipping required?

    it might be silly Questions.Sorry for that.i am having little bit confusion on this DR concept in BTS

    Wednesday, January 14, 2015 12:12 AM
  • This post might be helpful too.

    Regards,
    Bali
    MCTS: BizTalk Server 2010,BizTalk Server 2006 and WCF
    My Blog:dpsbali-biztalkweblog
    -----------------------------------------------------
    Mark As Answer or Vote As Helpful if this helps.

    Wednesday, January 14, 2015 10:46 AM
  • Coming to your other questions:

    4) Yes, if you have let any production/live messages to be processed by DR’s BizTalk databases, then you need to use the log-shipping from DR and restore in primary site’s databases again which you switch back from DR to live.

    5) I believe the MSDN reference you’re mentioning here is http://msdn.microsoft.com/en-us/library/gg634436%28v=bts.70%29.aspx. This article from MSDN is just to prepare the DR server just as runtime/processing server and keep using the production (or primary site’s) databases.

    A robust DR solution, should also consider both processing BizTalk server and its databases. Normally we keep processing servers and its related database servers close to each other (in different servers obviously) , what if the whole area where your primary server located is flooded. In this case you need to rely on DR server for both processing and also for databases.

    In the case where your “primary BizTalk processing sever and primary BizTalk database server” are separate to your “DR BizTalk processing sever and DR BizTalk database server”, and once you have allowed any production message to be processed by DR servers, when you switch back you need to restore the DR server log-shipping data which would restore the synchronisation between you BizTalk databases.

    In the case where your “DR BizTalk processing sever uses primary BizTalk database servers”: You don’t need to restore the log shipping when you switch back to “primary BizTalk processing sever and primary BizTalk database server”

    Regards,

    M.R.Ashwin Prabhu


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    • Marked as answer by Angie Xu Monday, January 19, 2015 2:21 AM
    Wednesday, January 14, 2015 5:18 PM
  • Did you read all of the MSDN documentation?  It does explain the process pretty clearly.

    However, there are a couple of 'architectural' considerations as well.

    First, do you really need full Log Shipping DR?  If all the transactions are transient, meaning no long running Orchestrations and such, you may be able to stand up the DR site as a completely separate Group.  This depends entirely on your applications and business continuity requirements.

    Second, is the other site just DR or is it really an 'alternate' site?  I have one site where they do a planned move to the alternate site every few weeks.  All the Log Shipping bits are fully configured on both sides.


    Wednesday, January 14, 2015 8:57 PM
    Moderator
  • Hi below are the steps which you can follow,

    a.    Both servers should be at the same patch level
    b.    Both servers can communicate to each other over the network
    c.    Both servers can perform MSDTC communication (use DtcPing tool to check)  :Note It is required for transactional integrity across the farm build
    d.    Both servers have the same location for MDF and LDF files
    •    It is recommended that back-up and transaction-log files should be written to a highly-available?
    UNC share, which is accessible to both the servers and have ample space available.

    •    Make sure that Backup BizTalk Server job is configured properly and working fine.
    Configuring Log Shipping:

    [Refer Configuring LogShipping for detailed information]
    •    Run the following two SQL scripts on the Destination SQL Server to create the infrastructure for Log Shipping:
    a.    LogShipping_Destination_Schema.sql
    b.    LogShipping_Destination_Logic.sql
    •    Execute bts_ConfigureBizTalkLogShipping
    exec bts_ConfigureBizTalkLogShipping @nvcDescription = '<MyLogShippingSolution>',
    @nvcMgmtDatabaseName = '<BizTalkServerManagementDatabaseName>',
    @nvcMgmtServerName = '<BizTalkServerManagementDatabaseServer>',
    @SourceServerName = null, -- null indicates that this destination server restores all databases
    @fLinkServers = 1 -- 1 automatically links the server to the management database
    •    Make sure the following two jobs are up and running:
    a.    BTS Log Shipping Get Backup History
    b.    BTS Server Log Shipping Restore Databases (WITH NORECOVERY)
     And that the following job is disabled:
    a.    BTS Log Shipping Restore To Mark (WITH RECOVERY)
    Your Log Shipping is configured now and you should see BizTalk DBs in restoring state on the DR site
    Update “SampleUpdateInfo.xml” on the BizTalk Server so that all database server information is updated with DR SQL server details.
    Recovering from failure:
    •    Disable following jobs on the Destination SQL Server:
    a.    BTS Log Shipping Get Backup History
    b.    BTS Server Log Shipping Restore Databases
    •    Enable following job on the Destination SQL Server:
    a.    BTS Log Shipping Restore To Mark
    Once this job is completed, go to the next step for pointing the BizTalk server to the newly restored BizTalk DB.
    •     Run the following command on BizTalk Server:
    a.    cscript UpdateDatabase.vbs SampleUpdateInfo.xml (Any one BizTalk Server in group)
    b.    cscript UpdateRegistry.vbs SampleUpdateInfo.xml (All BizTalk Server in group)
    •    Restart all the BizTalk related services on BizTalk Server
    •    Point BizTalk Administration Console to the new SQL Server: After you run UpdateRegistry.vbs BizTalk Administration Console will point to new SQL server, However if you are not seeing this then Right Click on BizTalk Administration Console, Connect to Existing Group and select new SQL server on which the databases were restored.
    How to reconfigure Destination Database server for LogShipping:
    •    Run stored procedure master.dbo.bts_LogShippingClean, to clean up destination SQL server . After running this the whole database for which we are doing LogShipping will be deleted.
    •    Delete jobs manually which were created previously to perform LogShipping
    •    Run the following two SQL scripts on the Destination SQL Server to create the infrastructure for Log Shipping:
    a.    LogShipping_Destination_Schema.sql
    b.    LogShipping_Destination_Logic.sql
    Note: This will clean everything from the DR DB site
    •    Execute bts_ConfigureBizTalkLogShipping. After executing this you will observer the jobs are recreated again and will be in the ‘running state”. Once you wait
    a while, you will see all BizTalk databases appearing under database with state as (restoring).

    http://social.technet.microsoft.com/wiki/contents/articles/7702.aspects-of-backup-for-biztalk-databases.aspx

    Thanks

    Abhishek

    Thursday, January 15, 2015 5:46 AM