Topologías y componentes para los servidores front-end, la mensajería instantánea y la presencia en Lync Server 2013

  • Artículo

 

Última modificación del tema: 2014-10-24

Los únicos componentes necesarios para la mensajería instantánea (MI) y la presencia son:

  • Los servidores front-end o los servidores Standard Edition de su organización. Las capacidades de presencia y de mensajería instantánea (MI) siempre se encuentran habilitadas en estos servidores.

  • Un equilibrador de carga, si se dispone de un grupo de servidores front-end Enterprise Edition. Para obtener más información, vea Requisitos de equilibrio de carga para Lync Server 2013.

Planeamiento de la implementación de grupos de servidores front-end

En Lync Server 2013, la arquitectura del grupo de servidores front-end ha cambiado y estos cambios afectan a la forma en que debe planear y mantener los grupos de servidores front-end.

Le recomendamos que todos los grupos front-end Enterprise Edition incluyan al menos tres servidores front-end. En Lync Server, la arquitectura de los grupos front-end usa un modelo de sistemas distribuidos, con los datos de cada usuario mantenidos en tres servidores front-end del grupo. Para obtener más información sobre esta nueva arquitectura, vea Cambios de topología en Lync Server 2013.

Si no desea implementar tres servidores front-end Enterprise Edition y desea una recuperación ante desastres, le recomendamos que use Lync Server Standard Edition y cree dos grupos con una relación de copia de seguridad emparejada. Esto proporcionará una solución de recuperación ante desastres con solo dos servidores. Para obtener más información, sobre topologías y características de alta disponibilidad y recuperación ante desastres, consulte Planeamiento de alta disponibilidad y recuperación ante desastres en Lync Server 2013.

Planificación de la gestión de grupos front-end

Para los grupos front-end, siga las instrucciones de esta sección.

Garantizar que los grupos sean funcionales

Con el nuevo modelo distribuido para grupos front-end, determinados números de servidores de un grupo deben ejecutarse para que funcione el grupo. 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 una agregación de un conjunto de usuarios alojados 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

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 no se puede iniciar esta cantidad de servidores (pero se puede iniciar una cantidad de servidores suficiente para que no haya pérdida de cuórum en el grupo de servidores), puede usar el cmdlet Reset-CsPoolRegistrarState –ResetType QuorumLossRecovery para permitir que el grupo se recupere de esta pérdida de cuórum en el grupo de enrutamiento y pueda progresar. Para obtener más información sobre cómo usar este cmdlet, vea Reset-CsPoolRegistrarState.

Nota

Como Lync Server usa la base de datos SQL principal como testigo, si cierra la base de datos principal y cambia a la copia reflejada, y cierra suficientes servidores front-end para que no haya suficientes ejecutándose según la tabla anterior, todo el grupo desaparecerá. 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 el número de servidores que se ejecutan es inferior al nivel funcional que se muestra en la tabla siguiente, los servidores restantes del grupo de servidores detendrán todos los servicios de Lync 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

En la tabla anterior, los "primeros servidores" son los servidores que aparecieron primero, en orden cronológico, cuando se inició el grupo por primera vez. Para determinar estos servidores, puede usar el cmdlet Get-CsComputer con la opción –PoolFqdn . 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.

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. Si alguna vez necesita implementar un grupo de este tipo, 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>

Pasos adicionales para asegurarse de que los grupos 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 y otro grupo con fines de recuperación ante desastres, después de establecer esa relación debe estar seguro de que este grupo tiene tres servidores front-end ejecutándose simultáneamente en algún momento para sincronizar correctamente los datos con el grupo de copia de seguridad. Para obtener más información sobre las características de emparejamiento y recuperación ante desastres de un grupo, vea Planear la alta disponibilidad y la recuperación ante desastres en Lync Server 2013.

Mejora de la confiabilidad de las actualizaciones de las piscinas

Cuando necesite actualizar o aplicar revisiones a los servidores de un grupo de servidores front-end, siga el flujo de trabajo que se muestra en Actualizar o actualizar servidores front-end en Lync Server 2013 y las siguientes directrices:

  • Al pasar de un dominio de actualización a otro para actualizaciones (siguiendo el flujo de trabajo en Actualizar o actualizar servidores front-end en Lync Server 2013), usará el cmdlet Get-CsPoolUpgradeReadinessState y comprobará si hay estado Ready. Agregar una espera de 20 minutos entre cada dominio de actualización después de que llegue a "Ready" hará que las actualizaciones sean más confiables. Si no está listo durante estos 20 minutos, reinicia el temporizador de 20 minutos. Además, puede ejecutar el cmdlet Get-CsPoolFabricState antes y después de iniciar el intervalo de 20 minutos y asegurarse de que no haya cambios en las primarias y secundarias de los grupos de enrutamiento.

  • No pase al siguiente dominio de actualización si alguno de los servidores del último dominio de actualización con revisiones se bloquea o no se reinicia. Esto también se aplica si ninguno de los servidores de una actualización no se puede iniciar. Ejecute Get-CsPoolFabricState para asegurarse de que todos los grupos de enrutamiento tienen un primario y al menos un secundario; esto confirmará si todos los usuarios tienen servicio.

  • Si algunos usuarios tienen servicio y otros no, ejecute Get-CsPoolFabricState con la opción –Verbose para comprobar si hay grupos de enrutamiento que faltan réplicas. No reinicie todo el grupo como primer paso de solución de problemas. Para obtener más información sobre este cmdlet, vea Get-CsPoolFabricState.

  • Asegúrate de que todas las instancias de las ventanas Visor de eventos o Monitor de rendimiento estén cerradas para las instalaciones o desinstalaciones de windows fabric.

Cambiar la configuración de un grupo de servidores front-end

Siempre que agregue servidores front-end a un grupo o los quite del grupo y, a continuación, publique la nueva topología, siga estas instrucciones:

  • Una vez publicada la nueva topología, debe reiniciar cada servidor 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

Si se produce un error en un servidor front-end y es poco probable que se reemplace durante unos días o más, quite el servidor de la topología. Agregue el nuevo servidor front-end a la topología cuando vuelva a estar disponible.