Diseñar una granja de servidores de SharePoint Server en Azure
SE APLICA A:
2013 
2016 2019 Subscription Edition SharePoint en Microsoft 365
En este artículo se proporciona información general sobre la compatibilidad con granjas de servidores de SharePoint Server en los servicios de infraestructura de Azure y un proceso paso a paso, recomendaciones y procedimientos recomendados para diseñar el entorno de Azure, incluidos los recursos de red, almacenamiento y proceso.
Granjas de servidores de SharePoint Server en servicios de infraestructura de Azure
La ejecución de granjas de servidores de SharePoint Server en cualquier entorno de infraestructura como servicio (IaaS) puede aprovechar lo siguiente:
Capacidad a petición y la posibilidad de escalar máquinas virtuales (elasticidad)
Externalización parcial
Ubicaciones adicionales con una inversión mínima
Reducción de costos
Estos son los escenarios en los que las granjas de servidores de SharePoint tienen que ejecutarse desde un entorno de IaaS:
Granja de servidores de desarrollo y pruebas, piloto o prueba de concepto
Infraestructura híbrida
Recuperación ante desastres
Granja de servidores de producción
Compatibilidad de SharePoint Server en Azure
Microsoft admite los siguientes escenarios de implementación de SharePoint Server en máquinas virtuales (VM) iaas de Azure:
Las granjas de servidores que no sean de producción, como las usadas para entornos de desarrollo y pruebas o como prueba de concepto
Como destino de recuperación ante desastres mediante el trasvase de registros, grupos de disponibilidad AlwaysOn de SQL Server o Azure Site Recovery
Granjas de servidores de producción que usen almacenamiento premium de Azure para servidores que ejecuten el rol de búsqueda
Las granjas de servidores de producción que ejecuten SharePoint 2013 también son compatibles. SharePoint 2010 ya no se incluye en el soporte estándar, pero se puede instalar en VM de Azure para probar y validar escenarios de migración.
Al igual que con otras cargas de trabajo de Microsoft, la concesión de licencias se administra con Licensing Mobility por Software Assurance. Para obtener más información, consulte Licencias de productos de servidor de Microsoft para su uso en entornos virtuales.
Proceso de diseño de granjas de servidores de SharePoint Server en Azure
El entorno de los servicios de infraestructura de Azure es distinto de los centros de datos locales y es necesario realizar un planeamiento adicional. En el siguiente proceso de diseño se indican los pasos para determinar los elementos siguientes de la infraestructura de Azure:
Grupos de recursos
Conectividad
Almacenamiento
Identidad
Seguridad
Máquinas virtuales
Cada paso incluye procedimientos recomendados y recomendaciones específicas de los requisitos de las granjas de servidores de SharePoint Server.
Al final del proceso de diseño, habrá determinado el conjunto de componentes de los servicios de infraestructura de Azure que están listos para la granja de servidores de SharePoint Server.
Sugerencia
El proceso se basa en Diseñar servicios de infraestructura de Azure para hospedar una aplicación LOB de varios niveles.
Paso 1: Grupos de recursos
Los grupos de recursos son contenedores para varios elementos de Azure que se pueden administrar de forma conjunta. Por ejemplo, puede crear listas de control de acceso que solo permitan a cuentas de usuario específicas modificar el conjunto de elementos de un grupo de recursos.
Puede colocar todos los recursos de la granja de servidores de SharePoint Server en el mismo grupo de recursos, pero esto no se recomienda para las implementaciones de producción. En su lugar, le recomendamos que use diferentes grupos de recursos para:
Infraestructura y componentes de red
Por ejemplo, un grupo de recursos llamado Networking_RG que contiene la red virtual (VNET), grupos de seguridad de red y equilibradores de carga.
Los roles separados de la granja de servidores de SharePoint
Por ejemplo, use grupos de recursos independientes para el front-end, la búsqueda, la aplicación, la caché distribuida, los datos y los roles combinados de una granja de servidores de SharePoint Server típica. En cada grupo de recursos independiente, coloque los conjuntos de disponibilidad, las interfaces de red y las máquinas virtuales de ese rol.
Para los grupos de recursos, rellene la tabla siguiente antes de crearlo y use tantas filas como sea necesario.
| Nombre del grupo de recursos | Ubicación de Azure (región) |
|---|---|
Paso 2: Conectividad
En la conectividad se incluye:
Acceso a los servidores que se ejecutan en la granja de servidores de SharePoint Server, tanto para la administración como para los recursos de la granja, desde la intranet e Internet.
Acceso para los servidores de la granja de servidores entre sí, a la intranet y a Internet.
En los elementos de conectividad se incluyen redes virtuales (VNET), las subredes dentro de VNET, el Sistema de nombres de dominio (DNS) para el registro y la resolución de nombres, la distribución del tráfico y el direccionamiento de máquinas virtuales.
VNET
El contenedor necesario para las máquinas virtuales en los servicios de infraestructura de Azure es la VNET de Azure. Hay dos tipos de VNET:
Solo de nube
No tiene conexión a una red local. Use este tipo de red virtual cuando implemente una granja de SharePoint accesible desde Internet que use un bosque de Windows Server Active Directory (AD) independiente.
Entre locales
Tiene una conexión a una red local y es necesario que tenga asignada un espacio de direcciones único desde la intranet. Use este tipo de red virtual cuando implemente una granja de SharePoint basada en intranet que use un bosque local de Windows Server AD.
Aunque se puede colocar las VM de un rol de servidor de una granja de servidores de SharePoint en diferentes VNET, no lo recomendamos en absoluto, ya que el tráfico de red entre las VM tendría que realizar entre VNET a VNET o con una conexión de emparejamiento de VNET. Le recomendamos que coloque todos los servidores de una granja de servidores en una única VNET.
Al crear la red virtual, debe asignarle un espacio de direcciones, que puede constar de uno o varios bloques de enrutamiento de Inter-Domain sin clase (CIDR) (también conocidos como prefijos de red). Esto es similar a asignar un espacio de direcciones a un nuevo centro de datos que contendrá varias subredes y cargas de trabajo de TI. El espacio de direcciones de seleccione dependerá del tipo de VNET:
Solo de nube
Puede tener cualquier espacio de direcciones del espacio de direcciones IPv4 privado (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), siempre que no se superponga con los espacios de direcciones de otras VNET interconectadas.
Entre locales
Tiene que ser un espacio de direcciones único y que no se superponga del espacio de direcciones de la intranet, en el que se pueden incluir espacios de direcciones públicos y privados.
Para la VNET, rellene la tabla siguiente.
| Nombre de VNET | Tipo de VNET | Nombre del grupo de recursos | Espacio de direcciones |
|---|---|---|---|
Coloque la VNET en el grupo de recursos para componentes de redes o infraestructura.
Puede usar una VNET existente que hospede cargas de trabajo de TI en máquinas virtuales de Azure, o bien puede crear una VNET.
Subredes
Al igual que con las subredes del centro de datos, las subredes de una VNET de Azure son divisiones lógicas del espacio de direcciones IPv4 para agrupar y separar los nodos de la red y su tráfico. Azure admite tres tipos de subredes:
Hospedaje de VM (obligatorio)
Hospeda las VM de una carga de trabajo de TI. Un ejemplo son todos los servidores que ejecutan el servicio de caché distribuida de una granja de servidores de SharePoint Server.
Puerta de enlace
Hospeda las puertas de enlace de Azure para una conexión VPN entre locales o entre redes VNET. Esta subred debe denominarse "GatewaySubnet".
Administración (recomendado)
Hospeda dos o más VM que ofrecen conexiones de Escritorio remoto a los servidores de la VNET y admite funciones de administración de redes.
Al igual que con los centros de datos locales, en Azure le recomendamos usar una subred de hospedaje de VM separada para cada conjunto de VM que ofrezca el mismo rol de servidor para la granja de servidores. Con subredes separadas, puede usar los grupos de seguridad de red de Azure para definir el tráfico permitido de entrada y salida y realizar un aislamiento de la subred.
El espacio de direcciones de cada subred tiene que ser una parte del espacio de direcciones de la VNET expresado como un único bloque de CIDR, también conocido como prefijo de red. Use un espacio de direcciones suficiente para adaptarse al conjunto de servidores previsto que ejecutarán ese rol de servidor común.
| Número de servidores | Longitud el prefijo de red |
|---|---|
| 1-3 |
/29 |
| 4-11 |
/28 |
| 12-27 |
/27 |
| 18-59 |
/26 |
Para GatewaySubnet, le recomendamos que use una longitud de prefijo de red de /27 y que la asigne desde la última parte del espacio de direcciones de la VNET. Para obtener más información, consulte Cálculo del espacio de direcciones de subred de puerta de enlace para redes virtuales de Azure.
Para la subred desde la VNET, rellene la tabla siguiente antes de crearlas y use tantas filas como sea necesario.
| Nombre de la subred | Espacio de direcciones |
|---|---|
| GatewaySubnet (si es necesario) | |
DNS
Todas las VM de una VNET de Azure tienen asignado de forma predeterminada un conjunto de servidores DNS para realizar el registro la resolución de nombres. Para invalidar esto, asigne servidores DNS a interfaces de red de VM individuales.
Para una granja de servidores de SharePoint Server en Azure que usa Microsoft Entra Domain Services, asigne las direcciones IP del servicio como servidores DNS.
Para una granja de servidores de SharePoint Server en Azure que contiene un conjunto de controladores de dominio de Windows Server AD que también actúan como servidores DNS, asigne las direcciones IP de los controladores de dominio como servidores DNS. Para una VNET entre locales, se necesitan dos conjuntos de servidores DNS:
Un conjunto de servidores DNS en la red local que las VM del controlador de dominio usarán al unirse al dominio y al promoverse a controladores de dominio.
Cuando las VM se conviertan en servidores DNS, restablezca los servidores DNS a las direcciones IP de los controladores de dominio.
Para las direcciones IP en servidor DNS que tiene que asignar a la VNET, rellene la tabla siguiente y use tantas filas como sea necesario.
| Direcciones IP del servidor DNS |
|---|
Distribución del tráfico
En las granjas de servidores de SharePoint de producción típicas se usan equilibradores de carga para distribuir el tráfico entre los servidores de un rol común. En los servicios de infraestructura de Azure se incluye un equilibrador de carga integrado que se puede usar de las formas siguientes:
Accesible desde Internet: se usa con una dirección IP pública para distribuir el tráfico de Internet entrante a las VM que pertenezcan a un conjunto de carga equilibrada.
Interno: se usa con una dirección IP de una subred en la VNET para distribuir el tráfico de Internet entrante a las VM que pertenezcan a un conjunto de carga equilibrada.
Estas son las recomendaciones para usar equilibradores de carga de Azure en una granja de servidores de SharePoint Server 2016 en Azure:
Use Azure Load Balancer o un dispositivo de red de equilibrador de carga para los servidores front-end. Si la granja de servidores de SharePoint se diseñó para que sea accesible desde Internet, use un equilibrador de carga accesible desde Internet.
Use un Azure Load Balancer interno o un dispositivo de red de equilibrador de carga para el conjunto de servidores que ejecuten aplicaciones y para el clúster de SQL Server (con la dirección IP del agente de escucha).
Cree los equilibradores de carga de Azure o los dispositivos de red del equilibrador de carga en el grupo de recursos de redes o infraestructura.
Aumente el tiempo de espera de la conexión inactiva para controlar las conexiones de larga duración de los clientes de SharePoint con el comando Set-AzureLoadBalancedEndpoint -IdleTimeoutInMinutes 15 de Azure PowerShell.
El sondeo de mantenimiento de la VM puede ser un mensaje HTTP GET o un mensaje de petición eco ICMP (ping), excepto si el dispositivo de red de equilibrio de carga funciona en el nivel 4, en cuyo caso es necesario usar un mensaje HTTP GET.
Para los equilibradores de carga de Azure, rellene la tabla siguiente antes de crearlos y use tantas filas como sea necesario.
| Nombre de equilibrador de carga | Finalidad | Tipo (accesible desde Internet o interno) |
|---|---|---|
Direcciones estáticas
Puede asignar direcciones IP estáticas a las interfaces de red de la VM desde el espacio de direcciones de la subred disponible. Si usa un Azure Load Balancer interno para distribuir el tráfico entre los servidores de un rol común, asigne al equilibrador de carga una dirección IP estática de la subred que contenga los miembros del conjunto de carga equilibrada.
Para una granja de servidores de SharePoint Server en Azure, Microsoft recomienda asignar una dirección IP estática para cada servidor que ejecuta SQL Server o SharePoint Server.
Para direcciones IP estáticas, rellene la tabla siguiente y use tantas filas como sea necesario.
| Nombre del equilibrador de carga o VM | Dirección IP estática |
|---|---|
Direcciones IP públicas
Una dirección IP pública le permite obtener acceso a un equilibrador de carga o VM desde Internet. Para reducir el área expuesta a ataques malintencionados, Microsoft le recomienda que use direcciones IP públicas solo en los casos siguientes:
Para VM de administración en una red solo de nube.
La VM de administración es la VM desde donde iniciará conexiones a Escritorio remoto para administrar de forma remota el resto de las VM de la VNET. No se necesitan direcciones IP públicas para cada VM.
Para un equilibrador de carga accesible desde Internet para granjas de servidores accesibles externamente.
La dirección IP pública permite obtener acceso a los servidores en el rol front-end de la granja de servidores.
Para las direcciones IP públicas, rellene la tabla siguiente y use tantas filas como sea necesario.
| Nombre del equilibrador de carga o VM |
|---|
Azure asigna direcciones IP públicas en el momento en que se solicitan para la VM o el equilibrador de carga.
Paso 3: Almacenamiento
Los recursos de almacenamiento para las VM en Azure, que incluyen los discos que utiliza cada VM, son discos administrados.
Azure admite tipos de almacenamiento estándar y premium. Para estar en una configuración compatible, debe usar Premium Storage para los servidores que ejecutan SharePoint Server que hospedan el rol de búsqueda. Microsoft recomienda usar Premium Storage para todas las máquinas virtuales que ejecutan SQL Server o Servidores de SharePoint. Otras VM de la granja de servidores, como controladores de dominio y las VM en la subred de administración, pueden usar almacenamiento estándar.
Paso 4: Identidad
SharePoint Server requiere la pertenencia al dominio de Windows Server AD. Por lo tanto, una granja de servidores de SharePoint Server en Azure debe tener acceso a un dominio de Windows Server AD con máquinas virtuales que actúan como controladores de dominio o con Microsoft Entra Domain Services.
Al usar máquinas virtuales que actúan como controladores de dominio:
Para una granja de servidores solo de Internet en una VNET solo de nube, cree un bosque de Windows Server AD independiente que tenga como mínimo dos VM para garantizar la disponibilidad.
Para una granja de servidores de intranet en una VNET entre locales, puede usar controladores de dominio locales. Pero Microsoft le recomienda que use como mínimo dos controladores de dominio de réplica para el bosque de Windows Server AD local en la VNET que contenga la granja de servidores de SharePoint.
Paso 5: Seguridad
Use los elementos siguientes de Azure para garantizar la seguridad de los servidores de la granja de servidores de SharePoint:
Para VNET solo de nube, use una VM de administración para conexiones de Escritorio remoto y asigne la única dirección IP pública a la VM de administración. Las VM de administración son opcionales para VNET entre locales, ya que las VM de la granja de servidores de SharePoint son accesibles directamente desde la intranet.
Use grupos de seguridad de red basados en subredes para el aislamiento de subredes. Los grupos de seguridad de red y, después, las reglas que definen el tráfico permitido de la subred (saliente y entrante). Coloque los grupos de seguridad de red en el grupo de recursos para componentes de redes o infraestructura.
Para los grupos de seguridad de red, rellene la tabla siguiente antes de crearlos y use tantas filas como sea necesario.
| Nombre de grupo de seguridad de red | Nombre de la subred | Reglas |
|---|---|---|
Paso 6: Máquinas virtuales
Siga este procedimiento para las máquinas virtuales de la granja de servidores de SharePoint:
Cree un conjunto de disponibilidad para cada conjunto de VM en un rol común y coloque todas las VM con el mismo rol de servidor.
Cree el conjunto de disponibilidad en el grupo de recursos para el rol de servidor.
Use, como mínimo, dos VM por cada rol de servidor.
Si usa grupos de disponibilidad AlwaysOn de SQL Server y planea usar solo dos servidores SQL Server, también debe usar un servidor de nodo minoritario para el clúster.
Coloque las interfaces de red y las VM en el grupo de recursos para el rol de servidor.
Estos son los tamaños mínimos recomendados de las VM:
Controladores de dominio de Windows Server AD: Standard_D2
Servidores SQL Server: Standard_DS4
Servidor de nodos de minoría: Standard_D2
Servidores de SharePoint: Standard_DS4
Direcciones para interfaces de red:
Use direcciones IP privadas estáticas para todas las interfaces de máquinas virtuales que son controladores de dominio o que ejecutan SharePoint Server o SQL Server.
Use una dirección IP pública solo para las VM de administración.
Use una dirección IP pública para el equilibrador de carga accesible desde Internet de los servidores front-end si la granja de servidores está expuesta Internet.
En cada VM de Azure se incluye un disco del sistema operativo. Puede agregar discos adicionales al crear la VM o puede agregarlos posteriormente. Use la tabla siguiente para conocer el mínimo de discos adicionales para las VM en una granja de servidores de SharePoint.
| Tipo de servidor | Discos adicionales |
|---|---|
| Controladores de dominio de Windows Server AD |
Un disco adicional de 40 GB para almacenar información de Windows Server AD |
| Servidores SQL Server |
Tres discos adicionales de 1 TB para datos, registros y datos temporales |
| Servidores de búsqueda o aplicaciones |
Un disco adicional de 100 GB para registros, un disco adicional de 200 GB para el índice de búsqueda |
| Servidores front-end o de caché distribuida |
Un disco adicional de 100 GB para registros |
Para los conjuntos de disponibilidad, rellene la tabla siguiente antes de crearlos y use tantas filas como sea necesario.
| Nombre del conjunto de disponibilidad | Rol de la granja de servidores de SharePoint | Grupo de recursos |
|---|---|---|
Para las interfaces de red de las VM, rellene la tabla siguiente antes de crearlas y use tantas filas como sea necesario.
| Nombre de la interfaz de red | Grupo de recursos | Nombre de la subred | Dirección IP estática | Instancia del equilibrador de carga (si es necesario) |
|---|---|---|---|---|
Para las VM, rellene la tabla siguiente antes de crearlas y use tantas filas como sea necesario.
| Nombre de la VM | Finalidad | Tamaño | Conjunto de disponibilidad | Grupo de recursos | Nombre de la interfaz de red |
|---|---|---|---|---|---|
Pasos siguientes
Si está listo para crear una configuración de prueba de concepto o desarrollo o prueba de una granja de servidores de SharePoint Server de intranet en Azure, consulte Intranet SharePoint Server en el entorno de desarrollo y pruebas de Azure.
Si está listo para implementar una granja de servidores de SharePoint Server lista para producción y alta disponibilidad en Azure, consulte Implementación de SharePoint Server con grupos de disponibilidad AlwaysOn de SQL Server en Azure.
Vea también
Conceptos
SharePoint 2013 y SharePoint 2016
Instalación y configuración de SharePoint Server 2016