Compartir a través de


Estimar los requisitos de capacidad y rendimiento de los entornos de colaboración entre departamentos (SharePoint Server 2013)

SE APLICA A:yes-img-132013 no-img-162016 no-img-192019 no-img-seSubscription Edition no-img-sopSharePoint en Microsoft 365

Este artículo sirve de orientación para planear el rendimiento y la capacidad de una solución de colaboración de división basada en SharePoint Server 2013. En él encontrará la siguiente información:

  • Especificaciones del entorno de pruebas, como el hardware, la topología de la granja de servidores y la configuración.

  • El conjunto de datos y la carga de trabajo de la granja de servidores que han generado la carga de prueba.

  • Análisis y resultados de pruebas que demuestran y explican las tendencias en cuanto a rendimiento, latencia y demanda de hardware bajo la carga en puntos de escala específicos.

Use la información de este artículo para comprender las características del escenario bajo cargas normales y máximas, y cómo las tendencias de rendimiento cambian cuando se escalan horizontalmente los servidores de la granja. Este artículo también le puede servir para calcular un punto de inicio adecuado para la arquitectura planeada y saber qué aspectos debe tener en cuenta al desarrollar un plan para mantener niveles aceptables de rendimiento bajo una carga máxima.

Introducción

En este artículo se explica cómo escalar horizontalmente los servidores en una solución de colaboración de división de SharePoint Server 2013. Una solución de colaboración de división es una implementación de SharePoint Server 2013 donde hay un menor número de equipos dedicados a actividades de colaboración que en un entorno de colaboración empresarial. En este artículo se entiende por división una organización dentro de una empresa con entre 1.000 y 10.000 empleados.

Diversos escenarios tendrán requisitos diferentes. Por lo tanto, complemente esta guía con pruebas adicionales en su propio hardware y en su propio entorno. Si el diseño planeado y la carga de trabajo son similares al entorno descrito en este artículo, puede extraer conclusiones sobre el rendimiento que se espera al escalar y reducir verticalmente el entorno.

Importante

Los resultados de las pruebas de este artículo se produjeron en un laboratorio de pruebas que usaba una carga de trabajo, un conjunto de datos y una arquitectura para simular un entorno de producción en condiciones muy controladas. Aunque hemos diseñado cuidadosamente estas pruebas, las características de rendimiento de un laboratorio de pruebas nunca son las mismas que el comportamiento de un entorno de producción. Estos resultados de pruebas no representan las características de rendimiento y capacidad de una granja de servidores de producción. En su lugar, los resultados de la prueba muestran las tendencias observadas en el rendimiento, la latencia y la demanda de hardware. Use el análisis de los datos observados para ayudarle a planear la capacidad y administrar su propia granja de servidores.

A medida que vaya avanzando en este artículo, obtendrá información sobre los siguientes aspectos:

  • Especificaciones, que engloban el hardware, la topología y la configuración

  • La carga de trabajo, que incluye un análisis de la demanda en la granja de servidores, el número de usuarios y las características de uso

  • El conjunto de datos, como el tamaño de las bases de datos y los tipos de contenido

  • Análisis y resultados de pruebas para escalar servidores web horizontalmente

Antes de leer este artículo, lea los siguientes artículos para asegurarse de que comprende los conceptos clave de la administración de capacidad en límites y límites de software para SharePoint 2013SharePoint Server 2013.

Glosario

La siguiente lista contiene definiciones de los términos clave que aparecen en este artículo.

  • RPS: solicitudes por segundo. RPS hace referencia al número de solicitudes que un servidor o granja de servidores recibe en un segundo. Se trata de una medida común de la carga de servidores y granjas de servidores.

    Nota:

    Las solicitudes difieren de las cargas de página. Una página contiene varios componentes, y cada uno de ellos crea una o más solicitudes cuando un explorador carga la página. Con una sola carga de página se crean varias solicitudes. Por lo general, los eventos y las comprobaciones de autenticación que usan recursos insignificantes no se tienen en cuentan en las mediciones de RPS.

  • Zona verde: la zona verde representa un conjunto definido de características de carga bajo condiciones de funcionamiento normales, hasta las cargas máximas diarias esperadas. Una granja de servidores que opera en este intervalo debería poder sostener tiempos de respuesta y latencia que se encuentren dentro de parámetros aceptables.

    Este es el estado en el que el servidor puede mantener el siguiente conjunto de criterios:

    • La latencia del servidor durante al menos el 75% de las solicitudes es inferior a un segundo.

    • Todos los servidores de la granja mantienen un uso medio de la CPU de menos del 60%.

      Nota:

      Nuestro entorno de laboratorio no ejecutó un rastreo de búsqueda activo. Por lo tanto, hemos mantenido el servidor de base de datos cerca del 50 % de uso de CPU o inferior para reservar el 10 % para la carga de rastreo de búsqueda. Esto supone que se usa el regulador de recursos de SQL Server en producción para limitar la carga de rastreo de búsqueda para el 10% de la CPU.

    • El porcentaje de errores es inferior al 0,01%.

  • Zona roja (máx.): la zona roja representa un conjunto definido de características de carga bajo condiciones de operación máxima. En la zona roja, la granja de servidores experimenta demandas muy elevadas de recursos transitorios que únicamente puede sostener durante períodos limitados antes de que se produzcan errores y otros problemas de rendimiento y fiabilidad.

    Este es el estado en el que el servidor puede mantener el siguiente conjunto de criterios para una duración limitada:

    • La característica de limitación de solicitudes HTTP está habilitada, pero no se han devuelto errores 503 (servidor ocupado).

    • La tasa de errores es menor que 0. 1%.

    • La latencia del servidor es inferior a tres segundos en al menos el 75% de las solicitudes.

    • Todos los servidores de la granja (excluyendo los servidores de base de datos) mantienen un uso medio de la CPU inferior al porcentaje aproximado del 90%.

    • El uso medio de la CPU del servidor de base de datos es inferior al porcentaje aproximado del 50%, lo cual permite que se reserve una sobrecarga suficiente para la carga de rastreo de búsqueda.

  • AxBxC (notación de gráfico): este es el número de servidores web, servidores de aplicaciones y servidores de base de datos respectivamente en una granja de servidores. Por ejemplo, 10x1x1 significa que este entorno tiene 10 servidores web, 1 servidor de aplicaciones y 1 servidor de base de datos.

  • MDF y LDF: archivos físicos de SQL Server. Para obtener más información, vea Arquitectura de archivos y grupos de archivos.

Información general

Esta sección ofrece información general de nuestro enfoque de escala y metodología de prueba.

Enfoque de escalado

En esta sección se describe el método que adoptamos para escalar nuestro entorno de pruebas. Dicho método le permitirá encontrar la mejor configuración para su carga de trabajo:

  • Escalamos horizontalmente los servidores web hasta que hubo cuatro servidores web en uso. Cada servidor ejecuta el servicio de caché distribuida.

  • Agregamos un servidor dedicado que ejecuta el servicio de caché distribuida.

  • Deshabilitamos el servicio de caché distribuido en los servidores web.

  • Escalamos horizontalmente más servidores web al número máximo para el ámbito de las pruebas.

Metodología y notas de pruebas

Dado que este artículo contiene los resultados de un entorno de pruebas, podríamos controlar determinados factores para mostrar aspectos específicos de rendimiento de esta carga. Además, algunos elementos del entorno de producción (incluidos en la siguiente lista) se excluyeron del entorno de pruebas para simplificar la sobrecarga de las pruebas.

Nota:

Se recomienda incluir estos elementos en entornos de producción.

  • Entre las ejecuciones de prueba, solo modificamos una variable cada vez para facilitar la comparación de resultados entre las ejecuciones de prueba.

  • Los servidores de base de datos no forman parte de un clúster, porque la redundancia no era necesaria para el propósito de estas pruebas.

  • El rastreo de búsqueda no se estaba ejecutando durante las pruebas. Por supuesto, puede que se esté ejecutando en un entorno de producción. Para tener esto en cuenta, hemos reducido el uso de CPU de SQL Server en nuestras definiciones de "Zona verde" y "Zona roja" para dar cabida a los recursos que un rastreo de búsqueda suele consumir durante las pruebas.

Especificaciones

En esta sección encontrará información detallada sobre el hardware, el software, la topología y la configuración de nuestro entorno de pruebas.

Hardware

En las siguientes secciones se describe el hardware que hemos usado en nuestro entorno de pruebas.

Importante

Hemos usado hosts de Hyper-V para virtualizar todos los servidores web y los servidores de aplicaciones de nuestro entorno de pruebas. Los servidores de base de datos no se virtualizaron. El hardware de host físico y el hardware virtual de máquina virtual se describen en esta sección por separado.

Hosts Hyper-V

En nuestras pruebas usamos seis hosts de Hyper-V configurados de forma idéntica. Cada host ejecuta entre una y dos máquinas virtuales.

Host Hardware Valor
Procesadores
2 procesadores de cuatro núcleos de 2,49 GHz
Memoria RAM
32 GB
Sistema operativo
Windows Server 2008 R2 SP1
Número de adaptadores de red
2
Velocidad del adaptador de red
1 Gigabit

Servidores web virtuales y servidores de aplicaciones

En nuestra granja de servidores de prueba se usan ocho servidores web virtuales. Asimismo, usamos un servidor virtual dedicado que ejecuta el servicio de caché distribuida.

Nota:

En los entornos de producción se suelen implementar servidores dedicados para ejecutar el servicio de caché distribuida en una configuración de alta disponibilidad. En nuestro entorno de pruebas hemos usado un servidor único dedicado para caché distribuida, porque la alta disponibilidad no es un factor importante.

Hardware de máquina virtual WFE1-8 y DC1
Procesadores
4 procesadores virtuales
RAM
12 GB
Sistema operativo
Windows Server 2008 R2 SP1
Tamaño de la unidad de SharePoint
100 GB
Número de adaptadores de red
2
Velocidad del adaptador de red
10 gigabits (tráfico entre hosts limitado para hospedar la velocidad del adaptador de red)
Autenticación
Windows NTLM
Tipo de equilibrador de carga
F5 Big IP
Servicios en ejecución local
WFE 1-8: servicios federados básicos. Esto abarca lo siguiente: temporizador de extensiones de SharePoint, servicio de seguimiento, Word Automation Services, Servicios de Excel y servicio de código en espacio aislado de Microsoft SharePoint Foundation.
DC1: servicio de caché distribuida.

Servidores de base de datos

En nuestras pruebas, usamos un servidor de base de datos físico y ejecutamos la instancia de SQL Server predeterminada que almacena las bases de datos de SharePoint. En este artículo no realizamos un seguimiento de la base de datos de registro.

Nota:

Si habilita los informes de uso, le aconsejamos que almacene la base de datos de registro en un número de unidad lógica (LUN) aparte. Las implementaciones grandes y algunas implementaciones medianas pueden requerir un servicio de base de datos de registro dedicado para adaptarse a la demanda en el procesador que genera un gran volumen de registro de eventos.

En nuestro entorno de pruebas, limitamos el registro y almacenamos la base de datos de registro en una instancia independiente de SQL Server.

Servidor de base de datos: instancia predeterminada SQL Server
Procesadores
4 procesadores de cuatro núcleos de 2,4 GHz
Memoria RAM
32 GB
Sistema operativo
Windows Server 2008 R2 SP1
Almacenamiento y geometría
Almacenamiento conectado directo (DAS)
1 volumen de sistema (RAID0, 1 eje, 300 GB)
2 volúmenes de datos de contenido (RAID0, 4 ejes, 450 GB cada uno)
2 volúmenes de registro de contenido (RAID0, 2 ejes, 450 GB cada uno)
1 volumen de datos temporales (RAID0, 2 ejes, 300 GB cada uno)
1 volumen de registro temporal (RAID0, 2 ejes, 300 GB cada uno)
Número de adaptadores de red
1
Velocidad del adaptador de red
1 Gigabit
Autenticación
Windows NTLM
Versión de software
SQL Server 2008 R2

Topología

El siguiente diagrama refleja la topología de nuestro entorno de pruebas.

La topología del laboratorio de pruebas tiene 4 VM de Hyper-V con 2 servidores web y 1 VM adicional como controlador de dominio. El servidor de BD físico ejecuta SQL Server 2008 R2 SP1 (1 volumen del sistema, 2 volúmenes de datos de contenido, 2 volúmenes de registro de contenido, 1 volumen de datos temporales, 1 volumen de registro temporal).

Configuración

En la siguiente tabla se indican los cambios de configuración significativos que llevamos a cabo en el servidor de base de datos de nuestro entorno de pruebas. Estos cambios de configuración permiten obtener un rendimiento de pruebas inmejorable y relaciones transparentes entre los resultados y los parámetros de prueba. Tenga presente que en SharePoint Server 2013 es necesario configurar el valor de MAXDOP. Los demás cambios de configuración son válidos únicamente en nuestro entorno de pruebas y posiblemente no afecten a su entorno de producción.

Opción Valor Notas
Colección de sitios
179 (en total en el entorno)
Las colecciones de sitios de nuestro entorno de pruebas usan la configuración predeterminada y la autenticación de notificaciones de Windows.
Almacenamiento en caché BLOB
Activado
El valor predeterminado es Desactivado. Si habilita el almacenamiento en caché BLOB, se disparará la eficacia del servidor, ya que se reducen las llamadas al servidor de base de datos para recursos de página estáticos que los exploradores pueden solicitar con frecuencia.
Grado máximo de paralelismo (MAXDOP)
1
Este parámetro se establece en las instancias de SQL Server que contienen bases de datos de contenido SharePoint Server 2013. El valor predeterminado es 0, que habilita SQL Server para determinar el grado máximo de paralelismo. SharePoint Server 2013 requiere MAXDOP para establecerse en 1 para las instancias de SQL Server que contienen bases de datos de SharePoint Server 2013.
Para obtener más información sobre cómo configurar los valores de MAXDOP para SQL Server 2008 R2, vea el grado máximo de la opción de paralelismo.
Para obtener información sobre cómo configurar los valores de MAXDOP para SQL Server 2012, vea Configurar la opción de configuración de servidor del grado de paralelismo máximo.

Carga de trabajo

En esta sección se detallan las pruebas que ejecutamos en SharePoint Server 2013. Los detalles de las pruebas son típicos de un entorno de colaboración de división.

Pruebas de laboratorio ejecutadas para la colaboración entre secciones en SharePoint Server 2013. Los detalles de las pruebas muestran las solicitudes realizadas en el servidor en nueve escenarios.

Conjunto de datos

El conjunto de datos que usamos en nuestro entorno de pruebas es el típico entorno de colaboración de división. Este conjunto de datos contiene varias colecciones de sitios, sitios, listas, bibliotecas, tamaños de archivo y tipos de archivos.

Características del conjunto de datos Valor
Tamaño de la base de datos (combinado)
174 GB
Tamaño de MDF
154 GB
Tamaño de LDF
20 GB
Tamaño de blob
152 GB
Número de bases de datos de contenido
2
Número de colecciones de sitio
179
Número de aplicaciones web
1
Número de sitios
1.471

Resultados y análisis

Los siguientes resultados se ordenan en función del enfoque de escalado descrito en la sección Información general .

Escalado horizontal de servidor web

En las siguientes secciones se describen los resultados de prueba que obtuvimos cuando escalamos horizontalmente el número de servidores web en nuestro entorno de pruebas.

Metodología de prueba

  • Agregar un servidor web que use las mismas especificaciones de hardware y volver a ejecutar la prueba sin cambios en la granja de servidores o los parámetros de prueba.

  • Medir el valor de RPS, la latencia y el uso de recursos en cada servidor de la granja de servidores de prueba.

Análisis

Nuestras pruebas arrojaron lo siguiente:

  • El entorno escaló a diez servidores web por servidor de base de datos. El aumento en el rendimiento fue relativamente lineal.

  • Incluso hasta la escala probada máxima de diez servidores web, la adición de más servidores de base de datos no aumentó el rendimiento. Por lo general, el cuello de botella se limitó a recursos de servidor web.

  • La latencia media en la zona verde fue casi constante durante toda la prueba. El número de servidores web y el rendimiento no afectaron a la latencia de la zona verde. Los datos de latencia de la zona verde muestran una línea de tendencia esperada. La latencia es muy elevada en un servidor web único. Una curva entre 2 y 8 servidores web permanece de manera cómoda dentro de los criterios de la zona roja.

    Nota:

    La latencia puede verse ligeramente afectada si se mueve el servicio de caché distribuida de los servidores web de una granja a un servidor dedicado a la caché distribuida. Esto puede ocurrir porque el tráfico de caché distribuida, que anteriormente era interno de cada servidor web, comienza a atravesar la red. Pruebe el rendimiento del escalado horizontal en su propio entorno para averiguar si esta desventaja es importante. Tenga en cuenta que la latencia en nuestro entorno de pruebas aumentó ligeramente cuando el servicio de caché distribuida se migró a un servidor dedicado. La latencia disminuyó con cada servidor web agregado conforme la latencia agregada nominal se desplazó por la carga de memoria y el procesamiento disminuido en los servidores web. > Para obtener más información sobre el planeamiento de la capacidad de caché distribuida, vea Planear fuentes y el servicio caché distribuida en SharePoint Server.

  • Gracias a las mejoras realizadas en las características de uso de base de datos y almacenamiento en caché en SharePoint Server 2013, la carga media de la capa del servidor de base de datos es baja. Durante nuestras pruebas, vimos que no era necesario escalar horizontalmente los servidores de base de datos.

  • Las mejoras en el rendimiento cuando se agregan servidores virtuales dependen en parte de los recursos de hardware de host y del uso de recursos de otros equipos virtuales que se ejecutan en el mismo host. Los servidores virtuales requieren estrategias de administración y planeación extra específicas de la virtualización.

    Para obtener más información sobre el rendimiento y el planeamiento de capacidad de Hyper-V, vea Requisitos de virtualización de Hyper-V para SharePoint 2013 y Usar configuraciones de procedimientos recomendados para las máquinas virtuales de SharePoint 2013 y el entorno de Hyper-V.

Nota:

Las conclusiones en esta sección son específicas del hardware de que se compone el entorno. El entorno podría haber logrado el mismo rendimiento si usara más servidores host de Hyper-V, pero menos potentes, o bien menos servidores host de Hyper-V, pero más potentes. Un aumento de los recursos de hardware del servidor de base de datos no afectaría en gran medida a los resultados.

Resultados y gráficos

El eje x de los siguientes gráficos señala el cambio en el número de servidores web de la granja de servidores. La escala empieza con un servidor web virtual y un servidor de base de datos físico (1x1). El máximo es ocho servidores web virtuales, un servidor de caché distribuida virtual, un servidor de caché distribuida virtual dedicado (agregado en cuatro servidores web) y un servidor de base de datos físico (8x1x1).

Nota:

Los gráficos de esta sección representan los valores medios de cada punto de datos durante la prueba. Todos los gráficos incluyen la línea base de RPS de las zonas verde y roja a fin de mostrar la relación entre RPS y factores como la latencia, el uso de recursos de servidor y el uso de disco de SQL Server.

1. RPS

El siguiente gráfico muestra de qué manera el escalado horizontal afecta a la línea base de RPS.

Ilustración de un gráfico que muestra el aumento de las solicitudes por segundo a medida que los servidores front-end web y los controladores de dominio se escalan horizontalmente.

2. Latencia

El siguiente gráfico muestra de qué manera el escalado horizontal afecta a la latencia. Observe que la latencia de la zona verde permanece plana en su mayor parte, mientras que la latencia de la zona roja muestra variaciones moderadas dentro de límites aceptables.

El escalado horizontal de servidores front-end web y controladores de dominio afecta la latencia. La zona verde permanece plana, mientras que la zona roja presenta variaciones.

3. Uso de memoria y procesador de servidor web

El siguiente gráfico muestra de qué manera el escalado horizontal afecta al uso medio de la memoria y el procesador en los servidores web. Observe que el uso medio de la memoria y el uso del procesador de la zona verde permanecen relativamente constantes a medida que el valor de RPS aumenta.

La tendencia de uso del procesador en la zona roja es hacia abajo. Esta tendencia a la baja refleja el hecho de que la demanda media del procesador del servidor web en la carga máxima disminuye gradualmente conforme aumenta el número de servidores.

Gráfico que muestra cómo el escalado horizontal de servidores front-end web afecta el uso de memoria y del procesador. La zona verde permanece constante a medida que aumentan en uso de memoria y las solicitudes por segundo. La zona roja presenta una reducción a medida que disminuye la demanda en el procesador del servidor web cuando se agregan servidores.

4. Uso del procesador y operaciones por segundo de E/S (IOP) de SQL Server

Los siguientes gráficos reflejan cómo el promedio de IOP de disco (tanto totales como de lectura/escritura) y los valores de uso del procesador cambian a medida que se escala horizontalmente el número de servidores web. Usamos los siguientes contadores de rendimiento para medir los valores de IOP:

  • PhysicalDisk: lecturas de disco/segundo

  • PhysicalDisk: escrituras de disco/segundo

Se realiza el promedio de los valores de cada contador durante la prueba y, a continuación, se suman para producir las IOP totales.

Nota:

Estos datos no se ven reflejados en este gráfico porque los datos relativos al uso de memoria de SQL Server no estaban disponibles cuando realizamos nuestras pruebas.

Importante

Estos resultados de pruebas de IOP no son representativos de un entorno de producción, ya que nuestro conjunto de datos era mucho menor que el de una granja de servidores de producción. Esto hizo posible que un porcentaje mayor de los datos se almacenara en caché en los servidores web de lo que sería posible en un entorno de producción. Como almacenamos en caché un porcentaje mayor de los datos en el servidor web, los resultados de IOP de esta sección son promedios calculados que se basan en datos de pruebas disponibles. La previsión es que nuestros resultados de IOP sean, por lo general, menores que las IOP de un entorno de producción. Una prueba exhaustiva de su propia granja de servidores en un entorno piloto puede arrojar resultados diferentes.

Tenga en cuenta que, en los gráficos de esta sección, tanto las IOP como el uso de procesador del servidor de base de datos muestran una caída en seis servidores web front-end, mientras que RPS continúa aumentando. Esta variación también se refleja en el uso de procesador de servidor web, como se aprecia en el gráfico anterior.

Esto muestra que la escala de la granja de servidores ha alcanzado un punto en el que se ha logrado la presión máxima en los recursos del servidor de la granja de servidores mediante el conjunto de datos y la carga de la línea base. Se requiere una utilización media inferior para admitir la carga en la granja de servidores.

De esta tendencia se pueden extraer las siguientes conclusiones:

  • Si hubiéramos aumentado la carga de prueba en el sexto punto de escala de servidor web, se podría haber logrado un mayor RPS y, al mismo tiempo, mantener una curva plana en el uso de recursos de servidor.

  • Si hubiéramos escalado aún más el número de servidores web horizontalmente y mantenido la misma carga de prueba, el valor de RPS habría seguido aumentando, a la vez que la presión en los recursos de servidor habría continuado una tendencia a la baja.

  1. IOP totales de SQL Server

    En el siguiente gráfico se muestra la manera en que el escalado afecta a las IOP totales.

    Gráfico que muestra el total de IOPS del servidor SQL para las zonas verde y roja. Ambas zonas aumentan hasta un máximo de 4 servidores front-end web, luego se nivelan y disminuyen a 8 servidores web.

  2. IOP de SQL Server desglosadas en operaciones de lectura y escritura

    El siguiente gráfico muestra de qué manera el escalado horizontal afecta a las IOP en las lecturas por segundo y las escrituras por segundo.

    Gráfico que muestra cómo el escalado horizontal de servidores front-end web afecta las IOPS en cuanto a lecturas y escrituras por segundo. Las lecturas y escrituras por segundo aumentan hasta 4 servidores front-end web, luego las lecturas por segundo disminuyen de forma gradual mientras que las escrituras por segundo siguen aumentando.

  3. Utilización del procesador de SQL Server

    El siguiente gráfico muestra de qué manera el escalado horizontal afecta al uso del procesador de SQL Server.

    Ilustración de un gráfico que muestra la tendencia en aumento del procesador SQL y de las lecturas por segundo a medida que se agregan servidores web.

Vea también

Conceptos

Planeamiento del rendimiento en SharePoint Server 2013

Resultados y recomendaciones de la prueba de rendimiento y capacidad (SharePoint Server 2013)

Estimar requisitos de capacidad y rendimiento para entornos de colaboración de Intranet empresarial (SharePoint Server 2013)