Alta disponibilidad de Back-End Server en Lync Server 2013
Última modificación del tema: 2013-08-12
Para garantizar una alta disponibilidad de los servidores back-end, puede usar la creación de reflejos sql sincrónicas o la agrupación en clústeres sql. El uso de una de estas soluciones es opcional, pero se recomienda para mantener la continuidad empresarial de su organización. La creación de reflejo asincrónico de SQL no es compatible con la alta disponibilidad de Back-End Server en Lync Server 2013. En el resto de este documento, la creación de reflejo SQL significa creación de reflejo sql síncrono, a menos que se indique lo contrario explícitamente.
Puede configurar fácilmente la creación de reflejos de SQL con el Generador de topologías. Los clústeres de conmutación por error de SQL deben configurarse desde SQL Server.
Si utiliza la creación de reflejos de SQL o la agrupación de clústeres SQL en un grupo que está emparejado con otro grupo de servidores front-end para la recuperación ante desastres, debe usar la misma solución de alta disponibilidad back-end en ambos grupos. No debe emparejar un grupo mediante la creación de reflejos de SQL con un grupo que use clústeres de SQL.
Al implementar la creación de reflejos de SQL, todas las bases de datos de Lync Server del grupo se reflejan, incluido el almacén de administración central, si se encuentra en este grupo, así como la base de datos de aplicaciones del grupo de respuesta y la base de datos de aplicaciones de estacionamiento de llamadas, si esas aplicaciones se están ejecutando en el grupo.
Con la creación de reflejos de SQL, no es necesario usar el almacenamiento compartido para los servidores. Cada servidor guarda su copia de la base de datos en un almacenamiento local.
Puede implementar la creación de reflejos de SQL con o sin un testigo. Recomendamos usar un testigo, porque esto permite que la conmutación por error del servidor back-end sea automática. De lo contrario, un administrador tendrá que invocar manualmente la conmutación por error. Tenga en cuenta que, incluso si se implementa un testigo, un administrador puede invocar manualmente la conmutación por error del servidor back-end, si fuera necesario.
Si usa un testigo, puede usar un único testigo para varios pares de servidores back-end. No existe una correspondencia estricta uno a uno entre testigos y pares de servidores back-end. Las implementaciones en las que se emplea un único testigo para varios pares de servidores back-end no son tan resistentes como las topologías con un testigo independiente para cada par de servidor back-end.
Para obtener más información sobre la compatibilidad con clústeres de SQL, vea Soporte de software de base de datos en Lync Server 2013. Para obtener más información sobre cómo implementar clústeres SQL, consulte Configurar clústeres de SQL Server para Lync Server 2013.
Tiempo de recuperación para la conmutación por error automática del servidor back-end con creación de reflejo de SQL
Para la conmutación por error back-end automática con creación de reflejo de SQL, el objetivo de ingeniería para el tiempo de recuperación objetivo (RTO) es de 5 minutos. Debido a la creación de reflejos sincrónicos de SQL, no anticipamos la pérdida de datos durante los errores del servidor back-end excepto en raras ocasiones cuando los servidores front-end y el servidor back-end bajan simultáneamente mientras los datos se mueven entre los servidores. El objetivo de ingeniería para el objetivo de punto de recuperación (RPO) es de 5 minutos.
Experiencia del usuario durante un error del servidor back-end con creación de reflejo de SQL
La experiencia del usuario durante un error depende de la naturaleza del error y de la topología.
Si utiliza la creación de reflejo de SQL y tiene un testigo configurado, y se produce un error en la entidad de seguridad, la conmutación por error del servidor back-end se realiza de forma automática y rápida. Los usuarios activos no tendrían que notar muchas interrupciones en sus sesiones en curso.
Si no hay ningún testigo configurado, tomará algún tiempo que el administrador invoque manualmente la conmutación por error. Durante ese tiempo, los usuarios activos probablemente lo notarán. Continuarán con sus sesiones normalmente durante unos 30 minutos. Si el elemento principal sigue sin restaurarse o un administrador no ha conmutado por error a la copia de seguridad, los usuarios cambian al modo de resistencia, lo que significa que no pueden realizar tareas que requieran un cambio persistente en Lync Server (por ejemplo, agregar un contacto).
Si tanto el servidor back-end principal como el de reflejo fallan o si se produce un error en uno de esos servidores y el testigo, el servidor back-end dejará de estar disponible (incluso si se trata del principal que sigue funcionando). En este caso, los usuarios activos se cambian al modo de resistencia después de algún tiempo.