Lync Front End Server Disaster Recovery

Lync Front End Server disaster recovery is at the core of disaster recovery in Lync Server 2013. As mentioned earlier, Lync Front End Servers provide disaster recovery first through backup registrar functionality. This enables users to immediately fail over to a secondary pool for basic registration and inbound and outbound voice routing.

In the event of a prolonged outage, administrators can leverage pool pairing to provide presence and conferencing services to users. Lync Server pool pairing uses Windows Fabric to synchronize data across multiple Lync Front End pools. In the event of a failure, the administrator can invoke a pool failover, which will result in the import of presence and conferencing data to the secondary pool database.

Backup Registrar Relationship Details

Lync Server 2013 backup registrar relationships must always be a 1:1 configuration and will always be reciprocal. This means that if Pool 1 is the backup for Pool 2, then Pool 2 must be the backup for Pool 1. Additionally, neither can be the backup for any other Front End pool. The exception to this rule is that each Front End pool can also be the backup registrar for any number of Survivable Branch Appliances, or Survivable Branch Servers.

Pool Pairing Relationship Details

When planning for pool pairing, the following items should be considered:

• Consider the distance between the datacenters—Although there is no limit on the distance between two datacenters that contain paired pools, keep in mind that depending on the connectivity between sites, data replication might take longer, resulting in a longer RPO. Additionally, it is important to not have two datacenters in close proximity to each other in the event of a natural disaster.

• Pool types must match—Enterprise Edition pools can be paired only with other Enterprise Edition pools. Similarly, Standard Edition pools must be paired only with other Standard Edition pools.

• Physical and virtual must match—Physical pools can be paired only with other physical pools. Similarly, virtual pools can be paired only with other virtual pools.

• Consider capacity—Each pool in the pair should have the capacity to serve all users from both pools in the event of a disaster. This is very important when planning server capacity in a multisite scenario.

These best practices are recommended to avoid providing an insufficient disaster recovery design.

Note

Topology Builder will not prevent an administrator from configuring two pools in an unsupported matter. However, it is absolutely critical to deploy solutions in a supported configuration, and as such, Microsoft’s recommendations should always be followed.

RTO and RPO for Lync Pool Pairing

Microsoft has engineered Lync pool pairing to provide a recovery time objective of 15 minutes. Administrators must manually initiate the failover as part of a disaster recovery procedure. Fifteen minutes is the time it takes for the procedure to complete—it does not account for the time it takes to identify the disaster and make a decision for failover. When an administrator initiates a pool failover, the data must be imported to the new pool. The time it takes for the failover to complete results in the engineered RTO of 15 minutes.

For Lync pool pairing, the recovery point objective is also 15 minutes. This means that up to 15 minutes’ worth of data could be lost due to replication latency of the Lync Backup Service.

The RTO and RPO numbers are based off of a pool with 40,000 concurrent users, and 200,000 users enabled on the pool.

Central Management Store Recovery

The Central Management Store (CMS) is responsible for all configuration data in the Lync Server 2013 environment. The CMS runs on one active Front End pool in the environment, and subsequently one active SQL backend. When pool pairing is configured on a pool that is hosting the CMS, a backup CMS database is configured on the backup pool, and the CMS services are also installed on that pool. CMS data is also replicated by the Lync Backup Service to the standby pool. When initiating a pool failover involving the CMS, the administrator must first execute a CMS failover.

The engineering target for RPO and RTO of the CMS is 5 minutes. CMS data is not as large as presence and conferencing data; as such, the replication latency and import time are reduced when compared to Front End pool RPO/RTO.

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

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