Servidores en la topología de resistencia de sitios metropolitana
Última modificación del tema: 2011-10-18
La topología de resistencia de sitios metropolitana puede incluir diferentes tipos de funciones de servidor de esta manera:
Grupo de servidores front-end
Este grupo de servidores hospeda a todos los usuarios de Lync Server. Cada sitio, norte y sur, contiene cuatro servidores front-end configurados idénticamente. La base de datos back-end se implementa como dos nodos de clúster geográficamente dispersos de SQL Server 2008 activos/pasivos, que se ejecutan en servicio de clúster de conmutación por error de Windows Server 2008 R2. Se requiere replicación de datos síncrona entre los dos servidores de base de datos back-end.
En nuestra topología de prueba, el servidor de mediación se instaló con el servidor front-end. También se admiten las topologías con servidor de mediación independiente.
Nuestra topología de prueba utilizó equilibrio de carga de DNS para equilibrar el tráfico de SIP del grupo, con equilibradores de carga de hardware implementados para el tráfico de HTTP.
Las topologías que usan solamente los equilibradores de carga de hardware para equilibrar todos los tipos de tráfico también se admiten para resistencia de sitios.
Grupo de conferencias A/V
Se implementó un grupo de servidores de conferencia A/V con cuatro servidores de conferencia A/V, dos en cada sitio.
Grupo de servidores de director
Se implementó un solo grupo de directores con cuatro directores, dos en cada sitio.
Grupo de servidores perimetrales
Los servidores perimetrales ejecutaron todos los servicios (servicio perimetral de acceso, servicio perimetral de conferencia A/V, y servicio perimetral de conferencia web), pero los probamos únicamente para situaciones de usuarios remotos. La conectividad de federación y MI pública queda fuera del alcance de este documento.
Se recomienda un equilibrio de carga de DNS para su grupo de servidores perimetrales, pero también se admite el uso de equilibradores de carga de hardware. La interfaz perimetral interna y la interfaz perimetral externa deben usar el mismo tipo de equilibrio de carga. No puede usar el equilibrio de carga de DNS en una interfaz perimetral y el equilibrio de carga de hardware en la otra interfaz perimetral. Si se utilizan equilibradores de carga de hardware para el grupo de servidores perimetrales, el equilibrador de carga de hardware en un sitio sirve como el equilibrador de carga principal y responde a solicitudes con dirección de virtual del servicio perimetral correspondiente. Si el equilibrador de carga de hardware principal no está disponible, el equilibrador de carga de hardware secundario del sitio tomará el control. Cada sitio tiene su propia subred IP; las redes perimetrales no se expandieron a lo ancho de los sitios norte y sur.
Servidores de Conversaciones en grupo
Cada sitio hospeda tanto un servicio de canal como un servicio de búsqueda, pero estos servicios pueden estar activos solamente en un sitio por vez. El servicio de canal y el servicio de búsqueda en el otro sitio deben estar detenidos o deshabilitados. En el caso de una conmutación por error del sitio, se requiere una intervención manual para iniciar estos servicios en el sitio de conmutación por error.
Cada sitio también hospeda un servidor de cumplimiento, pero solo uno de estos servidores puede estar activo por vez. En el caso de una conmutación por error y conmutación por recuperación del sitio, se requiere una intervención manual para restaurar el servicio. Para obtener más información, consulte Copia de seguridad del servidor de cumplimiento en la documentación sobre operaciones.
Se implementó la base de datos back-end de Conversaciones en grupo como dos nodos de clúster dispersos geográficamente de SQL Server 2008 activo/pasivo ejecutándose por sobre clústeres de conmutación por error de Windows Server 2008 R2. La replicación de datos entre los dos servidores de base de datos back-end debe ser síncrona. Una única instancia de base de datos se utiliza para tanto para Conversaciones en grupo como para datos de cumplimiento.
Servidor de supervisión y servidor de archivado
Para servidor de supervisión y servidor de archivado, se recomienda una implementación en caliente y en espera. Implementar estas funciones de servidor en ambos sitios, en un solo servidor en cada sitio. Solo uno de estos servidores está activo, y los grupos en su implementación están todos asociados con ese servidor activo. El otro servidor está implementado e instalado, pero no está asociado con ningún grupo.
Si el servidor principal no está disponible, se debe usar Topology Builder para asociar los grupos de forma manual con el servidor en espera, que luego pasa a ser el servidor principal.
Clúster de servidor de archivos
Se implementó un servidor de archivos como recurso de clúster disperso geográficamente de dos nodos mediante clúster de conmutación por error de Windows Server 2008 R2. Se solicitó replicación de datos síncrona. Toda función de Lync Server que requiere recurso compartido de archivos y está dividido en dos sitios debe usar este clúster de recurso compartido de archivos. Se trata de las opciones siguientes:
Ubicación del contenido de la reunión
Ubicación de los metadatos de la reunión
Ubicación de archivo de reuniones
Almacén de archivos del servidor de libreta de direcciones
Almacén de datos de aplicaciones
Almacén de datos de actualización de cliente
Repositorio de archivos de cumplimiento de conversación en grupo
Ubicación de archivos de carga de conversación en grupo
Proxy inverso
Se implementa un servidor de proxy inverso en cada sitio. En nuestra topología de prueba, estos servidores ejecutaron Microsoft Forefront Threat Management Gateway. Cada uno de estos servidores se ejecutó independientemente uno de otro. Se implementó un equilibrador de carga de hardware en cada sitio.