Welcome!

XML Authors: David Weinberger, Jason Bloomberg, Michael Nir, David Smith, PR.com Newswire

Blog Feed Post

Lync 2013 Persistent Chat HA\DR Deep Dive Pt. 2

In part 1 of this blog we discussed the architecture and design of Lync 2013 pChat HA\DR components. Now we will discuss how this design behaves with various failures within a Lync infrastructure. These different failure scenarios are based off our Disaster Recovery diagram from part 1 (Figure 1). We will cover the following failure scenarios:

  1. Lync Front End Pool failure
  2. Complete Site Failure
  3. pChat Pool failure
  4. Site Recovery

 

Scenario 1A: Lync FE Pool failure (Figure 1)

Figure 1: EEPool1 fails in East Datacenter

In this scenario our Front End Pool (EEPool1) in the East Datacenter has a complete failure. In order for users to get reconnected to pChat1 we will need to failover our paired pool from the East Datacenter to the West Datacenter. This will allow EEPool2 to route pChat connections to our pChat pool. This scenario would have the same failover steps regardless of if all pChat servers are active in oncdatacenter or split between the two (discussed in part 1).

  1. Failover the pool from EEPool1 to EEPool2
    Invoke-CsPoolFailOver –PoolFqdn “eepool1.domain.com” –DisasterMode2

1 The same steps will be performed regardless of whether all of the pChat servers are active in a single datacenter or they are active in both datacenters.

2 The –DisasterMode parameter is used with the Invoke-CsPoolFailOver cmdlet because our Pool has completely failed.

Once the failover is complete users can reconnect and all pChat functionality will be restored.

 

Scenario 1B: Lync FE Pool failback

Once our Front End Pool (EEPool1) in the East Datacenter comes back online and all services are restored we need to perform a failback.

  1. Invoke-CsPoolFailback -PoolFQDN "eepool1.domain.com" –Verbose

 

Scenario 2A: Complete Site failure (Figure 2)

Figure 2: Entire East Datacenter failure – all services in this Datacenter are down (FE, pChat, SQL, File Store, Edge)

Next, we look at a complete Lync site failure. This encompasses all Lync services including FE, pChat, SQL, File Store, and Edge. In order to restore all User services, including pChat, we will need to activate all these services in the secondary datacenter. In order to shorten this blog a little there are links to the edge failover process at end.

  1. Failover Pool from EEPool1 to EEPool2
    1. Invoke-CsPoolFailOver –PoolFqdn “eepool1.domain.com” –DisasterMode2
  2. Prepare pChat Backup DB, Commit TLogs, and bring DB online
    1. Remove log shipping from the Persistent Chat Server Backup Log Shipping database
      1. Using SQL Server Management Studio, connect to the database instance where the Persistent Chat Server backup MGC database is located
      2. Open a query window to the master database
      3. Drop Log shipping  - exec sp_delete_log_shipping_secondary_database mgc
    2. Copy any uncopied backup files from the backup share to the copy destination folder of the backup server.
    3. Apply any unapplied transaction log backups in sequence to the secondary database
      1. "How to: Apply a Transaction Log Backup (Transact-SQL)" at http://go.microsoft.com/fwlink/p/?linkid=247428
    4. Bring the backup MGC database online. Using the query window that was opened in step 2a, end all connections to the MGC database, if there are any:
      1. \exec sp_who2 to identify connections to the mgc database.
      2. \kill <spid> to end these connections.
    5. Bring the database online
      1. \restore database mgc with recoverSet pChat Pool state as failed over - after this is completed the MGC backup DB will now serve as the primary database.
  3. Set pChat Pool state as failed over - after this is completed the MGC backup DB will now serve as the primary database.
    1. Set-CsPersistentChatState -Identity “PersistentChatServer:pchatpool1.domain.com” –PoolState FailedOver
    2. Use the Get-CSPersistentChatState to verify it is marked as “Failed Over”
  4. Set the pChat Active servers in the secondary datacenter (West datacenter in our example) – at this point we want to make sure all the pChat servers in the secondary datacenter are active
    1. Set-CsPersistentChatActiveServer –Identity “global” –ActiveServers @{Add="pchatserver6.domain.com"}1
  5. (Optional but recommended) – use the Install-CsMirrorDatabase cmdlet to establish a High Availability mirror for the backup database that now serves as the primary database.

1 Add all pChat servers (using FQDN) in secondary datacenter (West datacenter) separated by commas in between quoted servers names.

Once the failover is complete users can reconnect and all pChat functionality will be restored using services from the secondary (paired) datacenter.

 

 Scenario 2B: Complete Site failback

 Once the East datacenter comes back online and all services come online we need to perform a failback.

  1. First lets failback our pool to the Primary datacenter (East Datacenter)
    1. Invoke-CsPoolFailback -PoolFqdn “eepool1.domain.com”
  2. Clear all servers from the Persistent Chat Server Active Server list
    1. Set-CsPersistentChatActiveServer (no switches)
  3. If you enabled DB mirroring on the backup DB in the secondary datacenter disable mirroring
    1. Using SQL Server Management Studio, connect to the backup MGC instance.
    2. Right-click the MGC database, point to Tasks, and then select Mirror.
    3. Click Remove Mirroring, and then select OK.
  4. Back up the MGC database so that it can be restored to the new primary database
    1. Using SQL Server Management Studio, connect to the backup MGC instance.
    2. Right-click the MGC database, point to Tasks, and then click Back Up. The Back up Database dialog box appears.
    3. In Backup type, select Full.
    4. For Backup component, click Database.
    5. Either accept the default backup set name suggested in Name, or enter a different name for the backup set.
    6. <Optional> In Description, enter a description of the backup set.
    7. Remove the default backup location from the destination list.
    8. Add a file to the list by using the path to the share location that you established for log shipping. This path is available to the primary database and to the backup database.
    9. Click OK to close the dialog box and begin the backup process.
  5. Restore the primary database by using the backup database created in the previous step.
    1. Using SQL Server Management Studio, connect to the primary MGC instance.
    2. Right-click the MGC database, point to Tasks, point to Restore, and then click Database. The Restore Database dialog box appears.
    3. Select From Device.
    4. Click the browse button, which opens the Specify Backup dialog box. In Backup media, select File. Click Add, select the backup file that you created in step 3, and then click OK.
    5. In Select the backup sets to restore, select the backup.
    6. Click Options in the Select a page pane.
    7. In Restore options, select Overwrite the existing database.
    8. In Recovery State, select Leave the database ready to use.
    9. Click OK to begin the restoration process.
  6. Set pChat Pool state as Normal -
    1. Set-CsPersistentChatState –Identity “PersistentChatServer:pchatpool1.domain.com” –PoolState Normal
    2. Use the Get-CSPersistentChatState to verify it is marked as “Normal”
  7. Set the pChat Active servers to what they were prior to failover.
    1. Set-CsPersistentChatActiveServer –Identity “global” –ActiveServers @{Add=”pchatserver6.domain.com”}1
  8. pChat clients should now reconnect to the Active pChat servers
  9. Setup Log shipping again to the secondary datacenter for DR purposes
    1. Follow steps here - http://technet.microsoft.com/en-us/library/jj204653.aspx

1 Add all pChat servers (using FQDN) that were active before failover separated by commas

 

Scenario 3A: pChat Pool Server failure (Figure 3)

Figure 3: pChat Pool failure in East Datacenter

The third failure scenario that we will explore is a pChat Pool Server failure in which all active pChat servers are located in the East Datacenter1. We will need to failover all pChat services to the secondary datacenter. Once we complete the failover of the pChat services, EEPool1 will route pChat traffic to the pChat servers located in the secondary datacenter.

  1. Prepare pChat Backup DB, Commit TLogs, and bring DB online – in order to accomplish these tasks follow step 2 from Scenario 2A from the complete site failure above.
  2. Set pChat Pool state as failed over – after this is completed the MGC backup DB will now serve as the primary database.
    1. Set-CsPersistentChatState –Identity “PersistentChatServer:pchatpool1.domain.com” –PoolState FailedOver
    2. Use the Get-CSPersistentChatState to verify it is marked as “Failed Over”
  3. Set the pChat Active servers in secondary datacenter – at this point we want to make sure all the pChat servers in the secondary datacenter are active.
    1. Set-CsPersistentChatActiveServer –Identity “global” –ActiveServers @{Add=”pchatserver6.domain.com”}2

1 In this scenario if we have active pChat servers split between the datacenters pChat functionality would continue to work. For optimal performance you would still want to follow the steps above in order to failover the backend pChat DB. This should be done during off hours so that production user impact is minimized.

2 Add all pChat servers (using FQDN) in secondary datacenter (West datacenter) separated by commas in between quoted server names.

Once the failover is complete EEPool1 will reconnect the users to the pChat servers located in the secondary (paired) datacenter.

 

Scenario 3B: pChat Pool Server failback

Once the pChat servers in the East datacenter come back online we should failback1. This should be done during off hours so that production user impact is minimized.

  1. Failback to Primary DB with current data – in order to accomplish this follow steps 2-5 from Scenario 2B from the complete site failback above.
  2. Set pChat Pool state as Normal
    1. Set-CsPersistentChatState –Identity “PersistentChatServer:pchatpool1.domain.com” –PoolState Normal
    2. Use the Get-CSPersistentChatState to verify it is marked as “Normal”
  3. Set the pChat Active servers -
    1. Set-CsPersistentChatActiveServer –Identity “global” –ActiveServers @{Add=”pchatserver1.domain.com”}2
  4. pChat clients should now reconnect to the Active pChat servers
  5. Setup Log shipping again to the secondary datacenter for DR purposes
    1. Follow steps here - http://technet.microsoft.com/en-us/library/jj204653.aspx

1 The pChat services will continue to function in this failed over state ever after the pChat servers in the East Datacenter come back online. The reason we want to failback is so that we are in the same production state we were prior to the pChat server failures in the East Datacenter. This will ensure we are in a "Normal" state instead of "Failed Over".

2 Add all pChat servers (using FQDN) that should become active separated by commas in between quoted server names.

 

Scenario 4A: pChat SQL Data Loss

The final failure scenario includes the loss of data from the backend SQL pChat DB (MGC) or User error (deletion). This database includes the pChat room content, principals, and access permissions for the pChat rooms. The pChat data can be backed up in one of the following two ways:

  1. SQL Server DB Backup – backups to SQL databases is usually a standard process for most organizations.
  2. Export-CsPersistentChatData cmdlet – this cmdlet will export all of the pChat data into a .zip file which will contain multiple .xml files (Figure 4)

Figure 4: Export-CsPersistentChatData cmdlet & ZIP file contents

Data that is created by using SQL Server backup requires significantly more disk space—possibly 20 times more—than that created by Export-CsPersistentChatData, but SQL Server backup is more likely to be a procedure that administrators are familiar with. The export in Figure 4 utilizing the Export-CsPersistentChatData cmdlet totaled 150 KB vs. a 4 MB SQL backup.

 

Scenario 4B: pChat SQL Data Recovery

In order to restore the data that we backed up above you can perform the steps below.

  1. If you used SQL Server backup procedures, you must use SQL Server restore procedures.
  2. If you used the Export-CsPersistentChatData cmdlet to back up Persistent Chat data, then you must use the Import-CsPersistentChatData cmdlet to restore the data.

Hopefully this helps everyone understand what process they will need to perform based on their specific failure.

Edge Failover Process - http://technet.microsoft.com/en-us/library/jj721897.aspx

                                             http://technet.microsoft.com/en-us/library/jj688023.aspx

 

 

Read the original blog entry...

More Stories By Richard Schwendiman

My name is Richard Schwendiman and I am currently working for Microsoft as a (PFE) Premier Field Engineer specializing in both Exchange and Lync. I have been working as an IT Consultant for 13+ years focusing on a wide array of Infrastructure technologies. These technologies include Messaging, UC, Networking, Platforms, Active Directory, Virtualization, etc... I am currently certified as an MCSE (Microsoft Certified Systems Engineer), MCSE Messaging 2013, MCSE Communications 2013, MCSA 2012, MCITP Enterprise Messaging, MCTS-Lync, CCNA (Cisco Certified Network Associate), Commvault, CCNP (Cisco Certified Network Professional), and JNCIA-ER (Juniper Enterprise Routing). I am hoping that through this blog I can bring knowledge from the field and keep everyone informed about our ever changing Industry. Please feel free to email me any questions, comments, or concerns pertaining to this blog or any technology related things. Thanks and look forward to providing some good content. http://blogs.technet.com/b/rischwen/