Editar

Ejecución de una granja de servidores de SharePoint Server 2016 de alta disponibilidad en Azure

Azure ExpressRoute
Azure Managed Disks
Azure Virtual Machines
Azure Virtual Network
Azure VPN Gateway

Esta arquitectura de referencia muestra procedimientos de demostrada eficacia para implementar una granja de servidores de SharePoint Server 2016 de alta disponibilidad en Azure, mediante la topología MinRole y los grupos de disponibilidad AlwaysOn de SQL Server. La granja de servidores de SharePoint se implementa en una red virtual protegida sin puntos de conexión accesibles desde Internet ni presencia en esta red.

Architecture

Architecture diagram that shows a highly available SharePoint Server 2016 farm in Azure.

Descargue un archivo Visio de esta arquitectura.

Esta arquitectura se basa en la que se muestra en [Run Windows VMs for an N-tier application][windows-n-tier]. Implementa una granja de servidores de SharePoint Server 2016 con alta disponibilidad dentro de una red virtual (VNet) de Azure. Esta arquitectura es adecuada para un entorno de pruebas o producción, una infraestructura híbrida de SharePoint con Microsoft 365 o como base para un escenario de recuperación ante desastres.

Componentes

  • Los grupos de recursos son contenedores que contienen recursos de Azure relacionados. Un grupo de recursos se usa para los servidores de SharePoint y otro grupo de recursos para los componentes de infraestructura que son independientes de las máquinas virtuales (VM), como la red virtual y los equilibradores de carga.

  • Azure Virtual Network es el bloque de creación fundamental para las redes privadas en Azure. Las máquinas virtuales se implementan en una red virtual con un espacio de direcciones de intranet único. La red virtual se subdivide además en subredes.

  • Las máquinas virtuales son recursos informáticos a petición y escalables disponibles con Azure. Las máquinas virtuales se implementan en la red virtual y se les asignan direcciones IP estáticas privadas a todas ellas. Se recomiendan las direcciones IP estáticas para las máquinas virtuales que ejecutan SQL Server y SharePoint Server 2016, a fin de evitar problemas con el almacenamiento en caché de direcciones IP y los cambios de direcciones después de un reinicio.

  • Los conjuntos de disponibilidad son agrupaciones lógicas de máquinas virtuales. Coloque las máquinas virtuales de cada rol de SharePoint en conjuntos de disponibilidad independientes y aprovisione al menos dos máquinas virtuales para cada rol. Esta configuración hace que las máquinas virtuales sean aptas para un Acuerdo de Nivel de Servicio mayor.

  • Azure Load Balancer distribuye el tráfico de solicitudes de SharePoint desde la red local hasta los servidores web front-end de la granja de servidores de SharePoint. Esta solución usa un equilibrador de carga interno. Alternativa para el tráfico HTTP, se puede usar Azure Application Gateway.

  • Los grupos de seguridad de red filtran el tráfico en una red virtual de Azure. Para cada subred que contiene máquinas virtuales, se crea un grupo de seguridad de red. Use grupos de seguridad de red para restringir el tráfico en una red virtual, a fin de aislar las subredes.

  • Azure ExpressRoute o una VPN de sitio a sitio, como Azure VPN Gateway, proporciona una conexión entre la red local y la red virtual de Azure. Para más información, consulte Connect an on-premises network to Azure (Conexión de una red local a Azure).

  • Los controladores de dominio de Windows Server Active Directory (AD) autentican a los usuarios dentro de un dominio. Los controladores de dominio de esta arquitectura de referencia se ejecutan en la red virtual de Azure y tienen una relación de confianza con el bosque de Windows Server AD local. Las solicitudes web de cliente de los recursos de la granja de servidores de SharePoint se autentican en la red virtual en lugar de enviarse ese tráfico de autenticación a la red local a través de la conexión de puerta de enlace. En DNS, se crean registros A o CNAME de intranet para que los usuarios de intranet puedan resolver el nombre de la granja de servidores de SharePoint en la dirección IP privada del equilibrador de carga interno.

    SharePoint Server 2016 también admite el uso de Microsoft Entra Domain Services. Microsoft Entra Domain Services proporciona servicios de dominio administrados para que no necesite implementar ni administrar controladores de dominio en Azure.

  • Los grupos de disponibilidad Always On de SQL Server ofrecen una solución de alta disponibilidad y recuperación ante desastres. Se recomiendan para obtener alta disponibilidad de la base de datos SQL Server. Se usan dos máquinas virtuales para SQL Server. Una de ellas contiene la réplica de base de datos principal y la otra la réplica secundaria.

  • Una máquina virtual de mayoría de nodos permite que el clúster de conmutación por error establezca un cuórum. Para más información, consulte Descripción de las configuraciones de cuórum en un clúster de conmutación por error.

  • SharePoint Server proporciona una plataforma para el acceso compartido. Los servidores de SharePoint desempeñan funciones de front-end web, almacenamiento en caché, aplicación y búsqueda.

  • Un jumpbox, que también se denomina host bastión, es una máquina virtual segura en la red que los administradores usan para conectarse a otras máquinas virtuales. El jumpbox tiene un grupo de seguridad de red que permite el tráfico remoto solo desde IP públicas que se encuentren en una lista segura. El grupo de seguridad de red debe permitir el tráfico de Escritorio remoto (RDP).

Recomendaciones

Los requisitos pueden diferir de los de la arquitectura que se describe aquí. Use estas recomendaciones como punto de partida.

Recomendaciones para grupos de recursos

Se recomienda separar los grupos de recursos de acuerdo con el rol del servidor y tener un grupo de recursos independiente para los componentes de infraestructura que sean recursos globales. En esta arquitectura, los recursos de SharePoint forman un grupo, mientras que SQL Server y otros recursos de utilidad forman otro.

Recomendaciones para red virtual y subred

Use una subred para cada rol de SharePoint, más una subred para la puerta de enlace y otra para el jumpbox.

La subred de puerta de enlace debe tener el nombre GatewaySubnet. Asigne el espacio de direcciones de subred de puerta de enlace desde la última parte del espacio de direcciones de red virtual. Para más información, consulte la sección Connect an on-premises network to Azure using a VPN gateway (Conexión de una red local a Azure mediante una puerta de enlace de VPN).

Recomendaciones de VM

Esta arquitectura requiere un mínimo de 44 núcleos:

  • 8 servidores de SharePoint en Standard_DS3_v2 (4 núcleos cada uno) = 32 núcleos
  • 2 controladores de dominio de Active Directory en Standard_DS1_v2 (1 núcleo cada uno) = 2 núcleos
  • 2 máquinas virtuales de SQL Server en Standard_DS3_v2 = 8 núcleos
  • 1 mayoría de nodos en Standard_DS1_v2 = 1 núcleo
  • 1 servidor de administración en Standard_DS1_v2 = 1 núcleo

Para todos los roles de SharePoint, excepto indexador de búsqueda, se recomienda usar el tamaño de máquina virtual Standard_DS3_v2. El indexador de búsqueda debe tener como mínimo el tamaño Standard_DS13_v2. Para más información, consulte Requisitos de hardware y software para SharePoint Server 2016. Para las VM con SQL Server, se recomienda un mínimo de 4 núcleos y 8 GB de RAM. Para más información, consulte Almacenamiento y configuración y planeamiento de capacidad de SQL Server (SharePoint Server).

Recomendaciones del grupo de seguridad de red

Se recomienda tener un grupo de seguridad de red para cada subred que contenga máquinas virtuales, a fin de permitir el aislamiento de la subred. Si quiere configurar el aislamiento de la subred, agregue reglas del grupo de seguridad de red que definan el tráfico entrante o saliente permitido o denegado para cada subred. Para más información, consulte Filtrado del tráfico de red con grupos de seguridad de red.

Si asigna un grupo de seguridad de red a la subred de puerta de enlace, la puerta de enlace dejará de funcionar.

Recomendaciones para almacenamiento

La configuración del almacenamiento de las máquinas virtuales de la granja de servidores debe coincidir con los procedimientos recomendados usados en las implementaciones locales. Los servidores de SharePoint deben tener un disco aparte para los registros. Los servidores de SharePoint que hospedan roles de índice de búsqueda requieren espacio en disco adicional para que se almacene el índice de búsqueda. En SQL Server, el procedimiento habitual consiste en separar datos y registros. Agregue más discos para el almacenamiento de copia de seguridad de base de datos y use un disco independiente para tempdb.

Para lograr la máxima confiabilidad, se recomienda usar Azure Managed Disks. Los discos administrados garantizan que los discos de las máquinas virtuales de un conjunto de disponibilidad estén aislados, con el fin de evitar únicos puntos de error.

Use discos administrados Premium en todas las máquinas virtuales de SQL Server y SharePoint. Puede usar discos administrados Estándar para el servidor de mayoría de nodos, los controladores de dominio y el servidor de administración.

Recomendaciones para el servidor de SharePoint

Antes de configurar la granja de servidores de SharePoint, asegúrese de que tiene una cuenta de servicio de Windows Server Active Directory por cada servicio. Para esta arquitectura se necesita, como mínimo, las siguientes cuentas de nivel de dominio para aislar los privilegios por rol:

  • Cuenta de servicio de SQL Server
  • Cuenta de usuario de instalación
  • Cuenta de granja de servidores
  • Cuenta de Search Service
  • Cuenta de acceso al contenido
  • Cuentas de grupo de aplicaciones web
  • Cuentas de grupo de aplicaciones de servicio
  • Cuenta de superusuario de caché
  • Cuenta de lector avanzado de caché

Para satisfacer el requisito de compatibilidad con el rendimiento del disco de 200 MB por segundo como mínimo, asegúrese de planear la arquitectura de búsqueda. Consulte Planear la arquitectura de búsqueda empresarial en SharePoint Server 2013. Además, siga las directrices descritas en Procedimientos recomendados para el rastreo en SharePoint Server 2016.

Asimismo, almacene los datos del componente de búsqueda en un volumen de almacenamiento independiente o en una partición con alto rendimiento. Para reducir la carga y mejorar el rendimiento, configure las cuentas de usuario de caché de objeto, que son necesarias en esta arquitectura. Divida los archivos del sistema operativo Windows Server, los archivos de programa de SharePoint Server 2016 y los registros de diagnóstico en tres volúmenes de almacenamiento independientes o particiones con un rendimiento normal.

Para más información sobre estas recomendaciones, consulte Cuentas de servicio y administrativas de implementación inicial en SharePoint Server 2016.

Cargas de trabajo híbridas

Esta arquitectura de referencia implementa una granja de servidores de SharePoint Server 2016 que se puede usar como entorno híbrido de SharePoint, es decir, ampliar SharePoint Server 2016 a SharePoint Online. Si tiene Office Online Server, consulte Compatibilidad de Office Web Apps y Office Online Server en Azure.

Las aplicaciones de servicio predeterminadas de esta solución están diseñadas para admitir cargas de trabajo híbridas. Todas las cargas de trabajo híbridas de SharePoint Server 2016 y Microsoft 365 se pueden implementar en esta granja de servidores sin cambios en la infraestructura de SharePoint, con una excepción: la aplicación híbrida de nube de Search Service no se debe implementar en servidores que hospeden una topología de búsqueda existente. Por lo tanto, es necesario agregar a la granja una o varias máquinas virtuales basadas en roles de búsqueda para admitir este escenario híbrido.

Grupos de disponibilidad Always On de SQL Server

En esta arquitectura se usan VM con SQL Server porque SharePoint Server 2016 no puede usar Azure SQL Database. Para lograr una alta disponibilidad en SQL Server, se recomienda usar grupos de disponibilidad Always On, que especifican un conjunto de bases de datos que conmutan por error juntas, lo que hace que tengan una alta capacidad de disponibilidad y recuperación. Para más información, consulte Crear el grupo de disponibilidad y agregar las bases de datos de SharePoint.

También se recomienda agregar una dirección IP de escucha al clúster, que es la dirección IP privada del equilibrador de carga interno para las VM con SQL Server.

Para conocer los tamaños de máquina virtual recomendados y otras recomendaciones sobre rendimiento para SQL Server en Azure, consulte Procedimientos recomendados para SQL Server en Azure Virtual Machines. Además, siga las recomendaciones de Procedimientos recomendados para SQL Server en una granja de servidores de SharePoint 2016.

Se recomienda que el servidor de mayoría de nodos resida en un equipo independiente de los asociados de replicación. El servidor permite que el servidor asociado de replicación secundaria en una sesión en modo de alta seguridad reconozca si debe iniciar una conmutación por error automática. A diferencia de los dos asociados, los servidores de mayoría de nodos no atienden la base de datos, sino que admiten la conmutación por error automática.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Escalabilidad

Para escalar verticalmente los servidores existentes, cambie el tamaño de la máquina virtual.

Con la funcionalidad MinRoles de SharePoint Server 2016, puede escalar horizontalmente los servidores según el rol del servidor y también quitar servidores de un rol. Cuando agregue servidores a un rol, puede especificar cualquiera de los roles únicos o uno de los roles combinados. Sin embargo, si agrega servidores al rol de búsqueda, también debe reconfigurar la topología de búsqueda mediante PowerShell. Además, puede convertir roles mediante MinRoles. Para más información, consulte Administración de una granja de servidores de MinRole en SharePoint Server 2016.

SharePoint Server 2016 no admite el uso de Virtual Machine Scale Sets para el escalado automático.

Disponibilidad

Esta arquitectura de referencia admite alta disponibilidad dentro de una región de Azure, ya que cada rol tiene al menos dos máquinas virtuales implementadas en un conjunto de disponibilidad.

Para protegerse frente a un error regional, cree una granja de servidores de recuperación ante desastres independiente en una región distinta de Azure. Los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO) determinarán los requisitos de instalación. Para más información, consulte Seleccionar una estrategia de recuperación ante desastres para SharePoint 2016. La región secundaria debe ser una región emparejada con la región primaria. En el caso de una interrupción amplia, tiene prioridad la recuperación de una región de cada pareja. Para más información, consulte Continuidad empresarial y recuperación ante desastres (BCDR): Regiones emparejadas de Azure.

Facilidad de uso

Para operar y mantener servidores, granjas de servidores y sitios, siga los procedimientos recomendados para las operaciones de SharePoint. Para más información, consulte Operaciones para SharePoint Server 2016.

Las tareas que debe tener en cuenta al administrar SQL Server en un entorno de SharePoint pueden diferir de aquellas que se suelen considerar para una aplicación de base de datos. Un procedimiento recomendado es realizar una copia de seguridad semanal completa de todas las bases de datos SQL con copias de seguridad incrementales durante la noche. Realice copia de seguridad de los registros de transacciones cada 15 minutos. Otro procedimiento consiste en implementar tareas de mantenimiento de SQL Server en las bases de datos y deshabilitar las integradas de SharePoint. Para más información, consulte Almacenamiento y configuración y planeamiento de capacidad de SQL Server.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

Las cuentas de servicio a nivel de dominio utilizadas para ejecutar SharePoint Server 2016 requieren controladores de dominio de Windows Server AD o Microsoft Entra Domain Services para los procesos de autenticación y unión al dominio. No obstante, para ampliar la infraestructura de identidad de Windows Server AD ya implantada en la intranet, esta arquitectura concreta emplea dos controladores de dominio de réplica de Windows Server AD de un bosque existente de Windows Server AD local.

Además, siempre es conveniente planear la protección de seguridad. Otras recomendaciones son:

  • Agregar reglas a los grupos de seguridad de red para aislar las subredes y los roles.
  • No asignar direcciones IP públicas a las máquinas virtuales.
  • Para la detección de intrusiones y el análisis de cargas útiles, considere la posibilidad de usar una aplicación virtual de red delante de los servidores web front-end en lugar de un equilibrador de carga interno de Azure.
  • Como opción, use directivas IPsec para el cifrado del tráfico de texto no cifrado entre servidores. Si también va a realizar el aislamiento de la subred, actualice las reglas del grupo de seguridad de red para permitir el tráfico IPsec.
  • Instalar agentes antimalware para las máquinas virtuales.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

Puede usar la calculadora de precios de Azure para calcular los costos. Estos son algunos de los factores que optimizan el costo de esta arquitectura.

Active Directory Domain Services

Considere la posibilidad de que Active Directory Domain Services sea un servicio compartido que lo consuman varias cargas de trabajo para reducir costos. Para obtener más información, vea Precios de Active Directory Domain Services.

VPN Gateway

El modelo de facturación se basa en el periodo de tiempo en que la puerta de enlace está aprovisionada y disponible. Vea Precios de VPN Gateway.

Todo el tráfico de entrada es gratis. Todo el tráfico de salida se factura. Al tráfico de salida de la VPN se le aplican los costos de ancho de banda de Internet.

Virtual Network

Virtual Network es gratis. A cada suscripción se le permite crear un máximo de 50 redes virtuales en todas las regiones. Todo el tráfico que se origina dentro de los límites de una red virtual es gratis. Por consiguiente, la comunicación entre dos máquinas virtuales de la misma red virtual es gratis.

Esta arquitectura se basa en la que se implementa en [Run Windows VMs for an N-tier application][windows-n-tier].

Para más información, consulte la sección acerca de los costos del artículo sobre elmarco de buena arquitectura de Microsoft Azure.

DevOps

Considere la posibilidad de usar grupos de recursos independientes para entornos de producción, desarrollo y pruebas. Los grupos de recursos independientes facilitan la administración de implementaciones, la eliminación de implementaciones de prueba y la asignación de derechos de acceso. En general, coloque los recursos que tienen el mismo ciclo de vida en el mismo grupo de recursos. Use el nivel Desarrollador para los entornos de desarrollo y pruebas. Para minimizar los costos durante la preproducción, implemente una réplica del entorno de producción, ejecute las pruebas y, a continuación, apáguela.

Use las plantillas de Azure Resource Manager o las plantillas de Azure Bicep para definir la infraestructura. En ambos casos, siga la práctica de infraestructura como código (IaC) para implementar los recursos. Para automatizar la implementación de la infraestructura, puede usar Azure DevOps Services u otras soluciones de CI/CD. El proceso de implementación también es idempotente, es decir, se puede repetir para generar los mismos resultados. Azure Pipelines forma parte de Azure DevOps Services y ejecuta compilaciones, pruebas e implementaciones automatizadas.

Estructure las plantillas de implementación según los criterios de carga de trabajo, identifique unidades únicas de trabajo e inclúyalas en su propia plantilla. En este escenario, se identifican y aíslan en sus propias plantillas un mínimo de siete cargas de trabajo: la red virtual de Azure y la puerta de enlace de VPN, el jumpbox de administración, los controladores de dominio de AD y las máquinas virtuales de SQL Server, el clúster de conmutación por error y el grupo de disponibilidad, y las restantes máquinas virtuales, el nodo principal de SharePoint, la caché de SharePoint y las reglas del grupo de seguridad de red. El aislamiento de la carga de trabajo facilita la asociación de recursos específicos de la carga de trabajo a un equipo para que este pueda administrar todos los aspectos de esos recursos de forma independiente. Este aislamiento permite que DevOps realice la integración continua y la entrega continua (CI/CD). Esta configuración también permite el almacenamiento provisional de las cargas de trabajo, lo que significa realizar las implementaciones en varias fases y ejecutar validaciones en todas las fases antes de pasar a la siguiente. De este modo, puede enviar actualizaciones a los entornos de producción de una manera muy controlada y minimizar los problemas de implementación imprevistos.

Considere la posibilidad de usar Azure Monitor para analizar y optimizar el rendimiento de la infraestructura, así como supervisar y diagnosticar problemas de red sin iniciar sesión en las máquinas virtuales.

Para más información, consulte la sección DevOps en Marco de buena arquitectura de Microsoft Azure.

Pasos siguientes

Para más información sobre las partes individuales de la arquitectura de la solución, consulte los temas siguientes: