Alta disponibilidad de Back-End Server en Skype Empresarial Server

Obtenga información sobre las opciones de alta disponibilidad de Back-End Server compatibles con Skype Empresarial Server, incluidos los grupos de disponibilidad AlwaysOn, las instancias de clúster de conmutación por error AlwaysOn, la creación de reflejo de la base de datos y los clústeres de conmutación por error de SQL.

Tiene cuatro opciones para mejorar la alta disponibilidad de sus servidores back-end:

• Creación de reflejo de la base de datos

• Grupos de disponibilidad AlwaysOn

• Instancias de clúster de conmutación por error AlwaysOn (FCI)

• Clústeres de conmutación por error de SQL

El uso de una u otra solución es opcional, pero recomendamos mantener la continuidad empresarial de la organización. De lo contrario, el hecho de que un único servidor de bases de datos se apague podría provocar la pérdida de datos Skype Empresarial Server significativos.

Puede configurar la creación de reflejo de base de datos usando solo el Generador de topologías. Para los grupos de disponibilidad AlwaysOn, instancias de clúster de conmutación por error AlwaysOn o clústeres de conmutación por error de SQL, use SQL Server para crear la solución de alta disponibilidad y, después, puede usar el Generador de topologías para asociarlo a un grupo de servidores front-end.

Si utiliza back-end server de alta disponibilidad en un grupo de servidores front-end 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.

Creación de reflejo de la base de datos

Skype Empresarial Server admite la creación de reflejos con el software de base de datos siguiente:

• SQL Server 2019, tanto Enterprise Edition como Standard Edition

• SQL Server 2017, tanto Enterprise Edition como Standard Edition

• SQL Server 2016, tanto Enterprise Edition como Standard Edition

• SQL Server 2014, tanto Enterprise Edition como Standard Edition

• SQL Server 2012 SP2 y CU2, tanto Enterprise Edition como Standard Edition

La creación de reflejo asincrónico de base de datos no es compatible con la alta disponibilidad de Back-End Server en Skype Empresarial Server. En lo que resta de este documento, la creación de reflejo de la base de datos implica la creación de reflejo de la base de datos sincrónica, a menos que se indique lo contrario.

Al implementar la creación de reflejos de base de datos en un grupo de servidores front-end, se reflejan todas las bases de datos de Skype Empresarial Server del grupo, incluido el almacén de administración central (si se encuentra en este grupo), así como la base de datos de aplicaciones de 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 reflejo de la base de datos, 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 optar por implementar una creación de reflejo de la base de datos 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.

Instrucciones para planificar la creación de reflejo del servidor back-end

En general, la configuración de creación de reflejo de SQL entre los dos servidores back-end con un testigo requiere lo siguiente:

• La versión del servidor principal de SQL Server debe admitir la creación de reflejo de SQL.

• El servidor principal, el reflejo y el testigo (si se implementan) necesitan tener la misma versión de SQL Server.

• El servidor principal y el reflejo necesitan tener la misma edición de SQL Server. El testigo puede tener una edición diferente.

Para conocer los procedimientos recomendados de SQL en cuanto a qué versiones SQL son compatibles con un rol testigo, vea "Testigo de creación de reflejo de base de datos" en MSDN Library.

Para configurar la creación de reflejo del servidor, es necesario que primero configure los permisos de la base de datos de SQL correctamente. Para obtener más información, consulte "Configurar cuentas de inicio de sesión para creación de reflejo de base de datos o Grupos de disponibilidad AlwaysOn (SQL Server)".

Con la creación de reflejo de SQL, el modo de recuperación de base de datos siempre se establece en Completo, lo que significa que debe supervisar de cerca el tamaño del registro de transacciones y realizar copias de seguridad de los registros de transacciones de forma regular para evitar que se quede sin espacio en disco en los servidores back-end. La frecuencia de las copias de seguridad del registro de transacciones depende de la tasa de crecimiento del registro, que a su vez depende de las transacciones de base de datos en las que incurran las actividades del usuario en el grupo de servidores front-end. Le recomendamos que determine cuánto crecimiento del registro de transacciones se espera para su carga de trabajo de implementación de Lync para que pueda realizar la planeación en consecuencia. En los artículos siguientes se proporciona información adicional sobre la administración de registros y copias de seguridad sql:

Tiempo de recuperación de conmutación por error automática de servidor back-end con la creación de reflejo

Para la conmutación por error automática de servidores back-end con la creación de reflejos, el objetivo de ingeniería para el objetivo de tiempo de recuperación (RTO) es de 5 minutos. Debido a la creación de reflejos sincrónica, no prevemos pérdida de datos durante los errores en el servidor back-end, excepto en raras ocasiones, cuando tanto los servidores front-end como los servidores back-end dejan de funcionar simultáneamente mientras se mueven datos 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 de servidor back-end con la creación de reflejo

La experiencia del usuario durante un error depende de la naturaleza del error y de la topología.

Si usa la creación de reflejo de bases de datos y tiene un testigo configurado y se produce un error en la entidad principal, la conmutación por error del servidor back-end se produce de forma rápida y automática. 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.

Grupos de disponibilidad AlwaysOn e instancias de clústeres de conmutación por error AlwaysOn

Skype Empresarial Server admite grupos de disponibilidad AlwaysOn solo como activos/pasivos, no activos o activos.

Para usar grupos de disponibilidad AlwaysOn o instancias de clúster de conmutación por error AlwaysOn, primero debe usar SQL Server para configurar la solución de alta disponibilidad. Después, puede usar el Generador de topologías para asociarlo a un grupo de servidores front-end.

Skype Empresarial Server admite AlwaysOn con el software de base de datos siguiente:

• Enterprise Edition de SQL Server 2019

• SQL Server 2019 Standard Edition con limitaciones, consulta la nota que viene a continuación

• Enterprise Edition de SQL Server 2017

• SQL Server 2017 Standard Edition con limitaciones, consulta la nota que viene a continuación

• Enterprise Edition de SQL Server 2016

• SQL Server 2016 Standard Edition con limitaciones, consulta la nota que viene a continuación

• Enterprise Edition de SQL Server 2014

• Enterprise Edition de SQL Server 2012 SP2 y CU2

Para conocer los pasos para implementar grupos de disponibilidad AlwaysOn, vea Implementar un grupo de disponibilidad AlwaysOn en un servidor back-end en Skype Empresarial Server.

Clústeres de conmutación por error de SQL Server

Skype Empresarial Server admite SQL Server clústeres de conmutación por error con el software de base de datos siguiente:

• SQL Server 2019, tanto Enterprise Edition como Standard Edition

• SQL Server 2017, tanto Enterprise Edition como Standard Edition

• SQL Server 2016, tanto Enterprise Edition como Standard Edition

• SQL Server 2014, tanto Enterprise Edition como Standard Edition

• SQL Server 2012 SP2 y CU2, tanto Enterprise Edition como Standard Edition

Para usar la agrupación de clústeres de conmutación por error de SQL, primero debe configurar el clúster de SQL Server antes de implementar el grupo de servidores front-end. Para conocer los procedimientos recomendados y las instrucciones de configuración para clústeres de conmutación por error en SQL Server 2012, consulte https://technet.microsoft.com/library/hh231721.aspx.

Para usar la agrupación de clústeres de conmutación por error de SQL, primero debe configurar el clúster de SQL Server antes de implementar el grupo de servidores front-end. Para conocer los procedimientos recomendados y las instrucciones de configuración para clústeres de conmutación por error en SQL Server 2014 y 2016, consulte https://technet.microsoft.com/library/hh231721.aspx. Para los clústeres de conmutación por error en SQL Server 2008, consulte https://technet.microsoft.com/library/ms189134(v=sql.105).aspx.

Al instalar SQL Server, es preciso instalar también SQL Server Management Studio para administrar las ubicaciones de la base de datos y de los archivos de registro. SQL Server Management Studio se instala como un componente opcional al instalar SQL Server.