Alta disponibilidad y administración del grupo de servidores front-end
Obtenga información sobre la administración de grupos front-end en Skype Empresarial Server, incluida la administración de grupos, la pérdida de quórum y los pasos especiales para los grupos con solo dos servidores front-end.
En Skype Empresarial Server, la arquitectura de los grupos front-end usa un modelo de sistemas distribuidos, con los datos de cada usuario mantenidos en hasta tres servidores front-end del grupo. Le recomendamos que todos los grupos front-end Enterprise Edition incluyan al menos tres servidores front-end.
Nota
Skype Empresarial Server 2019 no admite Enterprise Edition grupos front-end con dos servidores front-end y no permitirá que la topología se publique en ese escenario.
Planear la administración de grupos de servidores front-end
Skype Empresarial Server utiliza un modelo de sistemas distribuidos basado en Windows Fabric. En este modelo, los datos importantes para cada usuario y conferencia se almacenan en tres servidores front-end de un grupo de servidores front-end. Estos tres servidores que almacenan un determinado conjunto de datos se denominanreplicas.
Con el modelo distribuido para los grupos de servidores front-end, es necesario ejecutar ciertos números de servidores de un grupo para que funcionen. Hay dos modos de pérdida para un grupo.
Pérdida de cuórum en el grupo de enrutamiento, provocada por una cantidad insuficiente de servidores de réplicas para un determinado grupo de enrutamiento. Un grupo de enrutamiento es un conjunto de usuarios hospedados en el grupo. Cada grupo de enrutamiento tiene tres réplicas en el grupo: una principal y dos secundarias.
Pérdida de cuórum en el grupo de servidores, que ocurre cuando no hay una cantidad suficiente de servidores semilla en ejecución en el grupo.
Pérdida de cuórum en el grupo de enrutamiento
La primera vez que inicia un nuevo grupo de servidores front-end, es fundamental que el 85 % de los servidores estén en funcionamiento, tal como se muestra en la tabla siguiente. Si hay menos servidores en ejecución, es posible que los servicios queden interrumpidos en el estado de inicio y que el grupo no se inicie.
| Cantidad total de servidores en el grupo |
Cantidad de servidores que necesitan estar en ejecución para que el grupo se inicie por primera vez |
|---|---|
| 2 |
1 |
| 3 |
3 |
| 4 |
3 |
| 5 |
4 |
| 6 |
5 |
| 7 |
5 |
| 8 |
6 |
| 9 |
7 |
| 10 |
8 |
| 11 |
9 |
| 12 |
10 |
| 16 para Skype Empresarial Server 2019 |
12 |
Cada vez subsiguiente que se inicie el grupo, es preciso iniciar el 85 % de los servidores (tal como se muestra en la tabla anterior). Si este número de servidores no se puede iniciar (pero se pueden iniciar suficientes servidores para que no se encuentre en pérdida de quórum de nivel de grupo), puede usar el Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery cmdlet para permitir que el grupo se recupere de esta pérdida de quórum de nivel de grupo de enrutamiento y realice el progreso. Para obtener más información sobre cómo usar este cmdlet, vea Reset-CsPoolRegistrarState.
Nota
En los grupos de servidores con una cantidad par de servidores, Skype Empresarial Server usa la base de datos SQL principal como testigo. En un grupo como este, si apaga la base de datos principal, cambia a la copia reflejada y apaga una cantidad suficiente de servidores front-end para que no haya los suficientes en ejecución de acuerdo con la tabla anterior, todo el grupo de servidores quedará inactivo. Para obtener más información, vea Testigo de creación de reflejo de base de datos.
Pérdida de cuórum en el grupo de servidores
Para que un grupo de servidores front-end funcione en absoluto, no puede estar en pérdida de quórum a nivel de grupo. Si la cantidad de servidores en ejecución está por debajo del nivel de funcionamiento (tal como se muestra en la tabla siguiente), los servidores restantes del grupo detendrán todos los servicios de Skype Empresarial Server. Tenga en cuenta que los números de la tabla siguiente suponen que los servidores back-end del grupo se están ejecutando.
| Número total de servidores front-end del grupo |
Cantidad de servidores que es preciso que estén en ejecución para que el grupo funcione |
|---|---|
| 2 |
1 |
| 3-4 |
2 cualesquiera |
| 5-6 |
3 cualesquiera |
| 7 |
4 cualesquiera |
| 8-9 |
4 cualesquiera de los primeros 7 servidores |
| 10-12 |
5 cualesquiera de los primeros 9 servidores |
| 12-16 de Skype Empresarial Server 2019 |
Cualquiera de los 7 primeros 12 servidores |
En la tabla anterior, los "primeros servidores" son los servidores que se crearon primero, cronológicamente, cuando se inició el grupo por primera vez. Para determinar estos servidores, puede usar el Get-CsComputer cmdlet con la -PoolFqdn opción. Este cmdlet le mostrará los servidores en el orden en el que aparecen en la topología; los que se encuentran en la parte superior de la lista son los primeros servidores.
Importante
El número máximo de servidores front-end se ha aumentado a 16 en Skype Empresarial Server 2019
Pasos adicionales para comprobar si los grupos de servidores son funcionales
Es necesario tener en cuenta algunos otros factores a fin de asegurarse de que los grupos de servidores front-end sigan siendo funcionales.
Al mover usuarios al grupo por primera vez, asegúrese de que se estén ejecutando al menos tres de los servidores front-end.
Si establece una relación de emparejamiento entre este grupo de servidores y otro con fines de recuperación ante desastres, después de establecer dicha relación, necesitará asegurarse de que este grupo tiene tres servidores front-end ejecutándose simultáneamente en algún momento para sincronizar correctamente los datos con el servidor de copia de seguridad. Para obtener más información sobre el emparejamiento de grupos y las características de recuperación ante desastres, consulte Planear la alta disponibilidad y la recuperación ante desastres en Skype Empresarial Server.
Grupos de servidores front-end con dos servidores front-end
No se recomienda implementar un grupo de servidores front-end que contenga solo dos servidores front-end. Este grupo pequeño no ofrecerá una solución de alta disponibilidad sólida como lo haría un grupo más grande y requerirá más atención en su administración. Además, si el servidor back-end de un grupo de dos servidores se desintegó, todo el grupo en sí probablemente pronto también bajaría. Si desea implementar solo uno o dos servidores que ejecuten Skype Empresarial Server, le recomendamos que los implemente como servidores Standard Edition.
Si alguna vez necesita implementar un grupo con dos servidores front-end, siga estas instrucciones:
Si uno de los dos servidores front-end se apaga, intente hacer una copia de seguridad del servidor con errores tan pronto como pueda. Del mismo modo, si necesita actualizar uno de los dos servidores, vuelva a ponerlo en línea tan pronto como termine la actualización.
Si, por algún motivo, necesita detener los dos servidores en algún momento, realice lo siguiente cuando termine el tiempo de inactividad del grupo:
El procedimiento recomendado es reiniciar ambos servidores front-end al mismo tiempo.
Si no se pueden reiniciar los dos servidores al mismo tiempo, será necesario ponerlos en funcionamiento nuevamente en el orden inverso al orden en que se detuvieron.
Si no puede volver a mostrarlas en ese orden, use el siguiente cmdlet antes de realizar una copia de seguridad del grupo:
Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery -PoolFQDN <FQDN>
Cambios y errores de configuración en el grupo de servidores front-end
Si se produce un error en un servidor front-end y no es probable que se sustituya durante unos días, quite el servidor de la topología. Cuando el nuevo servidor front-end esté disponible, agréguelo a la topología.
Siempre que realice un cambio de configuración en un grupo de servidores front-end, como agregar o quitar servidores, es preciso seguir estas instrucciones:
Después de publicar una topología nueva, necesita reiniciar cada uno de los servidores front-end del grupo. Reinícielos de uno en uno.
Si todo el grupo se ha desactivado durante el cambio de configuración, ejecute el siguiente cmdlet después de publicar la nueva topología:
Reset-CsPoolRegistrarState -PoolFQDN <PoolFQDN> -ResetType ServiceReset