Persistent Chat Disaster Recovery

With Lync Server 2013, the disaster recovery mechanism for Persistent Chat has become more in line with the rest of the product when compared to Lync Server 2010. Unlike Lync Server Front End pools, Persistent Chat pools cannot be paired to provide disaster recovery. Persistent Chat pools require introducing a stretched pool configuration to provide disaster recovery.

Providing disaster recovery to Persistent Chat pools will require the following configurations:

Primary SQL Servers—Persistent Chat will rely on a stretched pool configuration. SQL Servers should be located in the same physical datacenter as the Persistent Chat Front Ends to provide normal operations. For high-availability purposes, it is recommended that this be a SQL mirror, with a third SQL Server configured as a witness for automatic failover.

SQL Log Shipping—Providing disaster recovery to the Persistent Chat backend is done through SQL log shipping. This must be manually configured by administrators, and will perform transaction backups to the secondary datacenter.

Primary File Share—SQL Log Shipping requires a file share to be created and designated for SQL transaction logs. The share must have read and write privileges to all SQL Server services that are running Persistent Chat services in both datacenters.

Secondary File Share—A secondary file share must be designated to receive SQL transaction logs. This can be located on the secondary SQL Server.

Secondary SQL Server—In the datacenter designated for disaster recovery, a secondary SQL Server should be designated. SQL log shipping will be used to back up all SQL data to the secondary datacenter.

The configuration options covered in the following subsections are available when Persistent Chat is being deployed with disaster recovery available.

Stretched Persistent Chat Pool in Low-Bandwidth and High-Latency Scenarios

Persistent Chat pools can contain up to eight servers. However, only four servers can be active at once. In a scenario in which the connectivity between two datacenters is not efficient, placing four servers in each datacenter in an active/standby configuration is ideal. The requirements outlined in the preceding section, “Persistent Chat Disaster Recovery,” outline the resources required to complete this configuration. See Figure 15.3 for an example of this design.

Image

Figure 15.3. Stretched Persistent Chat pool in low-bandwidth and high-latency scenarios.

The following statements are true in this configuration:

• Site A and Site B both contain a Front End Server pool, servicing a subset of users. Each site shares Persistent Chat Pool A for Persistent Chat.

• Site A contains four active Persistent Chat servers; all users in Site A and Site B will connect to those servers for access to Persistent Chat Pool A.

• SQL Log Shipping is configured between SQL1 and SQL3. Every transaction will be shipped to SQL3, and in the event of a disaster, data can be restored.

• Site B contains four standby Persistent Chat servers. In the event of a disaster, these servers can be marked as active and serve users from Site A and Site B.

Stretched Persistent Chat Pool in High-Bandwidth and Low-Latency Scenarios

When bandwidth and latency are efficient, it is possible to split the Persistent Chat pool in an active/active configuration across two datacenters. Requirements discussed in earlier sections apply. However, in this configuration two servers in each datacenter are designated as active. See Figure 15.4 for an example of this design.

Image

Figure 15.4. Stretched Persistent Chat pool in high-bandwidth and low-latency scenarios.

The following statements are true in this configuration:

• Site A and Site B both contain a Front End Server pool, servicing a subset of users. Each site shares Persistent Chat Pool A for Persistent Chat.

• Site A and Site B both contain two active Persistent Chat Front End Servers. DNS load balancing will be used to distribute traffic across the pool to all four active servers. Users in Site A and Site B will connect to any active server, including in the other datacenter.

• SQL Log Shipping is configured between SQL1 and SQL3. Every transaction will be shipped to SQL3, and in the event of a disaster, data can be restored.

• Site A and Site B will contain two standby Persistent Chat Servers each. In the event of a disaster, the standby servers can be activated to maintain capacity. All users will connect to the active datacenter in that scenario.

The process for configuring Persistent Chat disaster recovery, as well as initiating a failover, are covered in the “Executing Disaster Recovery Procedures” section.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset