Planeación de capacidad para SharePoint Server 2013

Artículo
03/08/2023

SE APLICA A: yes-img-13 2013 no-img-16 2016 no-img-19 2019 no-img-se Subscription Edition no-img-sop SharePoint en Microsoft 365

En este artículo se describe cómo planear la capacidad de una granja de servidores de SharePoint Server 2013. Cuando comprenda bien la administración y planeación de la capacidad, puede aplicar sus conocimientos para dimensionar el sistema. Dimensionar es el término usado para describir la selección y configuración de una arquitectura de datos, una topología lógica y física, y el hardware apropiados para la plataforma de una solución. Hay una variedad de consideraciones de uso y administración de capacidad que afectan a cómo debe determinar las opciones de hardware y configuración más adecuadas.

Antes de leer este artículo, debe leer Información general sobre el ajuste de tamaño y la administración de la capacidad de SharePoint Server 2013.

Importante

Alguna información y algunos valores de este artículo se basan en resultados de pruebas y otra información relacionada con Productos de SharePoint 2010 y pueden no representar los valores finales para SharePoint Server 2013.

En este artículo se describen los pasos que debe seguir para realizar una administración eficaz de la capacidad de su entorno. Cada paso requiere cierta información para la ejecución correcta y tiene un conjunto de entregas que usará en el paso siguiente. En las tablas se describen estos requisitos y los resultados para cada paso.

Paso 1: modelar

El modelado del entorno basado en SharePoint Server 2013 comienza con el análisis de las soluciones existentes y la estimación de la demanda y los destinos esperados para la implementación que planea configurar. Empiece recopilando información sobre la base de usuarios, los requisitos de datos, los destinos de latencia y rendimiento, y documente las características de SharePoint Server 2013 que desea implementar. Use esta sección para comprender qué datos debe recopilar, cómo recopilarlos y cómo usarlos en pasos posteriores.

Comprender la carga de trabajo esperada y el conjunto de datos

Para el correcto dimensionamiento de una implementación de SharePoint Server 2013 es necesario estudiar y comprender las características de la demanda que prevé que su solución administre. Comprender la demanda requiere que pueda describir las características de la carga de trabajo, como el número de usuarios y las operaciones más usadas, y las características del conjunto de datos, como el tamaño de contenido y la distribución de contenido.

Esta sección puede ayudarle a entender algunas de las métricas y parámetros específicos que debe recopilar, y los mecanismos usados para recopilarlos.

Carga de trabajo

La carga de trabajo describe la demanda a la que el sistema debe hacer frente, la base de usuarios y las características de uso. La tabla siguiente proporciona algunas métricas clave que son útiles para determinar la carga de trabajo. Puede utilizar esta tabla para registrar estas métricas durante su recopilación.

Características de la carga de trabajo	Valor
Promedio diario de RPS
Promedio de RPS en horas pico
Número total de usuarios únicos por día
Promedio diario de usuarios simultáneos
Número máximo de usuarios simultáneos en horas pico
Número total de solicitudes por día
Distribución prevista de la carga de trabajo
No. de solicitudes por día
Explorador web: rastreo de búsqueda
Explorador web: interacción de colaboración general
Explorador web: interacción social
Explorador web: interacción general
Explorador Web: Office Web Apps
Clientes de Office
Cliente de OneNote
SharePoint Workspace
Sincronización de RSS de Outlook
Outlook Social Connector
Otras interacciones (aplicaciones personalizadas/servicios web)

Usuarios simultáneos : es más común medir la simultaneidad de las operaciones ejecutadas en la granja de servidores como el número de usuarios distintos que generan solicitudes en un período de tiempo determinado. Las métricas clave son el promedio diario y los usuarios simultáneos en una carga pico.
Solicitudes por segundo (RPS): RPS es un indicador usado habitualmente para describir la demanda en la granja de servidores, expresado como el número de solicitudes que la granja de servidores procesa por segundo, pero sin diferenciar el tipo o el tamaño de las solicitudes. La base de usuarios de cada organización genera una carga del sistema con una velocidad que depende de las características de uso únicas de la organización. Para obtener más información, vea Glosario.
Total de solicitudes diarias: el número total de solicitudes diarias es un buen indicador de la carga general que el sistema tendrá que administrar. Es más común medir todas las solicitudes excepto las solicitudes de protocolo de enlace de autenticación (estado HTTP 401) durante un período de 24 horas.
Total de usuarios diarios: el número total de usuarios es otro indicador clave de la carga general que el sistema tendrá que administrar. Esta medida es el número real de usuarios únicos en un período de 24 horas, no el número total de empleados de la organización.

Nota:

El número total de usuarios diarios puede indicar el potencial de crecimiento de la carga en la granja de servidores. Por ejemplo, si el número de usuarios potenciales es 100.000 empleados, 15.000 usuarios diarios indica que la carga puede crecer considerablemente con el tiempo cuando aumente la adopción por parte de los usuarios.
Distribución de cargas de trabajo : comprender la distribución de las solicitudes en función de las aplicaciones del cliente que interactúan con la granja de servidores puede ayudar a predecir la tendencia esperada y los cambios de carga después de migrar a SharePoint Server 2013. A medida que los usuarios realizan la transición a versiones de cliente más recientes, como Office 2013, y comienzan a usar las nuevas funcionalidades, se espera que aumenten los nuevos patrones de carga, RPS y solicitudes totales. Para cada cliente, podemos describir el número de usuarios distintos que lo usan en un período de tiempo de un día y el número total de solicitudes que el cliente o la característica genera en el servidor.

Por ejemplo, el siguiente gráfico muestra una instantánea de un entorno dinámico interno de Microsoft que actúa como una solución social típica. En este ejemplo, puede ver que la mayor parte de la carga la genera el rastreador de búsqueda y la exploración web típica del usuario final. También puede observar que hay una carga significativa introducida por la característica Outlook Social Connector (6,2 por ciento de las solicitudes).

Calcular la carga de trabajo de producción

Para calcular la capacidad de proceso necesaria que su granja de servidores debe poder mantener, comience por calcular la combinación de transacciones que se usará en su granja de servidores. Céntrese en analizar las transacciones usadas con más frecuencia que el sistema atenderá y entienda la frecuencia con la que se usarán y el número de usuarios. Esta comprensión le ayudará más adelante cuando valide si la granja de servidores puede mantener dichas cargas en las pruebas de preproducción.

El siguiente diagrama describe la relación entre la carga de trabajo y la carga en el sistema:

Capacidad: diagrama de carga de trabajo

Para calcular la carga de trabajo prevista, recopile la siguiente información:

Identificar las interacciones del usuario. Por ejemplo:
- Busca la página web.
- Descargas y cargas de archivos.
- Vistas y modificaciones de la aplicación web de Office en el explorador.
- Interacciones del coautor.
- Sincronizaciones del sitio del área de trabajo de SharePoint.
- Outlook Social Connections.
- Sincronización RSS (en Outlook u otros visores).
- Difusiones de PowerPoint.
- Cuadernos compartidos de OneNote.
- Libros compartidos de Excel Service.
- Aplicaciones compartidas del servicio access
Para obtener más información, consulte Servicios y características. Céntrese en la identificación de las interacciones que pueden ser únicas para la implementación. Reconocer el impacto esperado de estas cargas. Por ejemplo, un uso significativo de Forms de InfoPath, cálculos de servicios de Excel y soluciones dedicadas similares.
Identifique las operaciones del sistema tales como rastreos de búsqueda incrementales, copias de seguridad diarias, trabajos del temporizador de sincronización del perfil, procesamiento de Web Analytics, trabajos de temporizador de registro y otros.
Calcule los siguientes elementos:
- Número total de usuarios por día que se espera que usen cada funcionalidad.
- Derive los usuarios simultáneos estimados y las solicitudes de alto nivel por segundo.
Harás algunas suposiciones. Por ejemplo:
- Simultaneidad presente.
- El factor de RPS por usuario simultáneo que es diferente en todas las funcionalidades
Use la tabla de cargas de trabajo anteriormente en esta sección para las estimaciones. Es importante centrarse en las horas punta, en lugar de en el rendimiento medio. Planear la actividad máxima permite ajustar correctamente el tamaño de la solución basada en SharePoint Server 2013.

Si tiene una solución de Office SharePoint Server 2007 existente, puede extraer los archivos de registro de IIS o buscar otras herramientas de supervisión web que tenga que comprender mejor algunos de los comportamientos esperados de la solución existente. De lo contrario, consulte las instrucciones de la sección siguiente para obtener más información. Si no va a migrar desde una solución existente, debe rellenar la tabla con estimaciones aproximadas. En los pasos posteriores, deberá validar las suposiciones y ajustar el sistema.

Analizar los registros de IIS de SharePoint Server 2013

Tendrá que extraer datos de los registros ULS e IIS para detectar métricas clave sobre una implementación existente de SharePoint Server 2013. Por ejemplo:

Cuántos usuarios están activos.
Cuánto usan el sistema.
¿Qué tipo de solicitudes están llegando?
De qué tipo de clientes se originan las solicitudes.

Una de las maneras más fáciles de encontrar estos datos es usar Log Parser, una herramienta eficaz disponible gratuitamente para su descarga desde Microsoft. Log Parser puede leer y escribir en muchos formatos de texto y binarios, incluidos todos los formatos de IIS.

Puede descargar Log Parser 2.2 en (https://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07).

Conjunto de datos

El conjunto de datos describe el volumen de contenido almacenado en el sistema y cómo se puede distribuir en el almacén de datos. La tabla siguiente proporciona algunas métricas clave que son útiles para determinar el conjunto de datos. Puede utilizar esta tabla para registrar estas métricas durante su recopilación.

Objeto	Valor
Tamaño de base de datos (en GB)
Número de bases de datos de contenido
Número de colecciones de sitio
Número de aplicaciones web
Número de sitios
Tamaño del índice de búsqueda (n.º de elementos)
Número de documentos
Número de listas
Tamaño promedio de los sitios
Tamaño máximo de sitio
Número de perfiles de usuario

Tamaño del contenido: comprender el tamaño del contenido que espera almacenar en el sistema SharePoint Server 2013 es importante para planear y diseñar la arquitectura del almacenamiento del sistema, así como para dimensionar correctamente la solución de búsqueda que rastreará e indizará este contenido. El tamaño del contenido se expresa en espacio total en disco. Si va a migrar contenido desde una implementación existente, es posible que le resulte sencillo identificar el tamaño total de contenido que se va a mover. Durante el planeamiento, debe dejar espacio para el crecimiento a lo largo del tiempo.
Número total de documentos: aparte del tamaño del corpus de datos, es importante realizar un seguimiento del número total de elementos. El sistema reacciona de forma diferente si 100 GB de datos están compuestos por 50 archivos de 2 GB en lugar de 100.000 archivos de 1 KB cada uno. En implementaciones grandes, cuanto menos estrés haya en un solo elemento, documento o área de documentos, mejor será el rendimiento. El contenido ampliamente distribuido, como varios archivos más pequeños en muchos sitios y colecciones de sitios, es más fácil de atender que una sola biblioteca de documentos grande con archivos grandes.
Tamaño máximo de la colección de sitios: es importante identificar cuál es la unidad de contenido más grande que almacenará en SharePoint Server 2013; normalmente es una necesidad de la organización que impide dividir esa unidad de contenido. El tamaño medio de todas las colecciones de sitios y el número total estimado de colecciones de sitios son otros indicadores que le ayudarán a identificar la arquitectura de datos preferida.
Características de datos de las aplicaciones de servicio : además de analizar las necesidades de almacenamiento del almacén de contenido, debe analizar y calcular los tamaños de otros almacenes de SharePoint Server 2013, entre los que se incluyen:
Tamaño total del índice de búsqueda
Tamaño total de la base de datos de perfil en función del número de usuarios en el almacén de perfiles
Tamaño total de la base de datos social en función del número esperado de etiquetas, compañeros y actividades
El tamaño del almacén de metadatos
El tamaño de la base de datos de uso
El tamaño de la base de datos de Web Analytics

Ajuste de los objetivos de rendimiento y confiabilidad de la granja de servidores

Uno de los resultados del Paso 1: modelar es una buena comprensión de los objetivos de rendimiento y confiabilidad que mejor se ajustan a las necesidades de su organización. Una solución de SharePoint Server 2013 diseñada correctamente debe ser capaz de lograr "cuatro nueves" (99,99 %) de tiempo de actividad con capacidad de respuesta del servidor de subsegundos.

Los indicadores utilizados para describir el rendimiento y la confiabilidad de la granja de servidores son, entre otros:

Disponibilidad del servidor: se describe según el porcentaje de tiempo de actividad general del sistema. Debe realizar un seguimiento de los tiempos de inactividad no previstos y comparar la disponibilidad general con el objetivo establecido para la organización. Los objetivos se describen con frecuencia en un número de nueves (es decir, 99 %, 99,9 %, 99,99 %)
Capacidad de respuesta del servidor: el tiempo que tarda la granja en atender solicitudes es un buen indicador para realizar un seguimiento del estado de la granja de servidores. Este indicador se denomina latencia del lado servidor. Los Tt suelen usar la latencia media o media (percentil 50) de las solicitudes diarias que se atienden. Los destinos se describen normalmente en segundos o fracciones de segundos. Si el destino es servir páginas en menos de dos segundos, el objetivo del lado servidor debe estar en fracciones de segundo. Este mayor rendimiento permite que la página llegue al cliente y se represente en el explorador. Además, los tiempos de respuesta del servidor más largos suelen ser una indicación de una granja de servidores en mal estado. RpS rara vez puede mantenerse al día si gasta más de un segundo en el servidor para la mayoría de las solicitudes.
Spikiness del servidor: otro buen indicador de latencia del lado servidor que vale la pena realizar un seguimiento es el comportamiento del 5 % más lento de todas las solicitudes. Las solicitudes más lentas suelen ser las solicitudes que afectan al sistema cuando está bajo una carga mayor o, más comúnmente, las solicitudes que se ven afectadas por una actividad menos frecuente que se produce mientras los usuarios interactúan con el sistema; un sistema en buen estado es aquel que también tiene las solicitudes más lentas bajo control. El destino aquí es similar a La capacidad de respuesta del servidor, pero para lograr una respuesta de subsegundos en la spikiness del servidor, tendrá que compilar el sistema con numerosos recursos de reserva para controlar los picos de carga.
Uso de recursos del sistema: otros indicadores comunes que se usan para realizar un seguimiento del estado del sistema son una colección de contadores del sistema que indican el estado de cada servidor de la topología de la granja de servidores. Los indicadores usados con más frecuencia para realizar el seguimiento son % uso de CPU y memoria disponible; sin embargo, hay varios contadores más que pueden ayudar a identificar un sistema incorrecto; Puede encontrar más detalles en Paso 5: Supervisión y mantenimiento.

Paso 2: diseñar

Ahora que ha terminado de recopilar algunos hechos o estimaciones sobre la solución que necesita entregar, está listo para comenzar el siguiente paso de diseño de una arquitectura propuesta que prediga podrá mantener la demanda esperada.

Al final de este paso, tendrá un diseño para la topología física y una distribución para la topología lógica, por lo que podrá continuar con los pedidos de compras necesarios.

Las especificaciones de hardware y el número de máquinas que se diseñarán están estrechamente relacionadas, para controlar una carga específica hay varias soluciones que puede optar por implementar. Es habitual usar un pequeño conjunto de máquinas seguras (escalar verticalmente) o un conjunto más grande de máquinas más pequeñas (escalar horizontalmente); cada solución tiene sus ventajas y desventajas cuando se trata de capacidad, redundancia, potencia, costo, espacio y otras consideraciones.

Le recomendamos que comience este paso determinando la arquitectura y la topología. Defina cómo planea establecer las distintas granjas de servidores y los distintos servicios de cada granja de servidores y, a continuación, elija las especificaciones de hardware para cada uno de los servidores individuales del diseño. También puede ejecutar este proceso identificando las especificaciones de hardware que se espera que implemente (muchas organizaciones están restringidas a un determinado estándar de empresa) y, a continuación, defina la arquitectura y la topología.

Use la tabla siguiente para registrar los parámetros de diseño. Los datos incluidos son datos de ejemplo y no se usan para ajustar el tamaño de la granja de servidores. Está pensado para mostrar cómo usar esta tabla para sus propios datos.

Role	Tipo (estándar o virtual)	N.º de máquinas	Procesadores	RAM	IOPS necesaria	Tamaño de disco SO+registro	Unidad de datos
Servidores web	Virtual	4	4 núcleos	8	N/D	400 GB	N/D
Servidor de base de datos de contenido	Estándar	1 clúster	4 procesadores de cuatro núcleos a 2,33 (GHz)	48	2 k	400 GB	20 discos de 300 GB a 15.000 r.p.m.
Servidores de aplicaciones	Virtual	4	4 núcleos	16	N/D	400 GB	N/D
Servidor web de destino de rastreo de búsqueda	Virtual	1	4 núcleos	8	N/D	400 GB	N/D
Servidor de consultas de búsqueda	Estándar	2	2 procesadores de cuatro núcleos a 2,33 (GHz)	32	N/D	400 GB	500 GB
Servidor de rastreador de búsqueda	Estándar	2	2 procesadores de cuatro núcleos a 2,33 (GHz)	16	400	400 GB	N/D
Servidor de base de datos de rastreo de búsqueda	Estándar	1 clúster	4 procesadores de cuatro núcleos a 2,33 (GHz)	48	4k (optimizado para lectura)	100 GB	16 discos de 150 GB a 15 K RPM
Base de datos del almacén de propiedades de búsqueda + servidor de bases de datos de administración	Estándar	1 clúster	4 procesadores de cuatro núcleos a 2,33 (GHz)	48	2k (ajustado para escritura)	100 GB	16 discos de 150 GB a 15 K RPM

Determine la arquitectura de punto de inicio

En esta sección se describe cómo seleccionar una arquitectura de punto de inicio.

Al implementar SharePoint Server 2013, puede elegir entre una variedad de topologías para implementar la solución; puede implementar un único servidor o escalar horizontalmente muchos servidores en una granja de servidores de SharePoint Server 2013 con servidores de base de datos en clúster o reflejados y servidores de aplicaciones discretos para varios servicios. Más adelante, seleccione las configuraciones de hardware en función de los requisitos de cada uno de los roles, en función de sus necesidades de capacidad, disponibilidad y redundancia.

Para empezar, revise las distintas arquitecturas de referencia y determine la estructura de la granja de servidores, decida si debe dividir la solución entre varias granjas de servidores o federar algunos servicios, como la búsqueda, en una granja dedicada. Para obtener más información, consulte Arquitecturas de referencia.

Casos prácticos técnicos de SharePoint Server 2010

La guía de administración de capacidad para SharePoint Server 2013 incluye muchos casos prácticos técnicos de entornos de producción existentes que presentan una descripción detallada de los entornos de producción existentes basados en SharePoint Server 2013. Los casos prácticos técnicos específicos de SharePoint Server 2013 se publicarán a medida que estén disponibles; los casos prácticos existentes de SharePoint Server 2010 pueden servir como referencia sobre cómo diseñar un entorno basado en SharePoint Server 2013 para fines específicos.

Puede usar estos casos prácticos como referencia al diseñar la arquitectura de las soluciones de SharePoint Server 2013, especialmente si encuentra la descripción de estos diferenciadores clave específicos de implementación similares a las demandas y los destinos de la solución que está diseñando.

Estos documentos describen la siguiente información para cada caso práctico documentado:

Especificaciones, como hardware, topología de granja de servidores y configuración;
Carga de trabajo, incluida la base de usuarios y las características de uso.
Conjunto de datos, incluidos los tamaños de contenido, las características de contenido y la distribución de contenido
Estado y rendimiento, incluido un conjunto de indicadores registrados que describen las características de confiabilidad y rendimiento del conjunto de servidores.

Para obtener más información, descargue los documentos correspondientes de la página Casos prácticos técnicos de rendimiento y capacidad (SharePoint Server 2010).

Seleccione el hardware

Seleccionar las especificaciones correctas para los equipos de la granja de servidores es un paso crucial para garantizar la correcta confiabilidad y rendimiento de su implementación. Un concepto clave que hay que olvidar es que debe planear para cargas pico y horas pico; en otras palabras, cuando su granja de servidores esté funcionando bajo condiciones de carga promedio, debe haber suficientes recursos disponibles para administrar la mayor demanda prevista manteniendo al mismo tiempo los objetivos de latencia y capacidad de proceso.

Las principales características de hardware en cuanto a capacidad y rendimiento se dividen en cuatro categorías principales: capacidad de procesamiento, rendimiento del disco, capacidad de red y capacidad de memoria de un sistema.

Otra cosa a tener en cuenta es el uso de máquinas virtualizadas. Una granja de servidores de SharePoint Server 2013 se puede implementar mediante máquinas virtuales. Aunque no se ha encontrado que la virtualización agregue ninguna ventaja de rendimiento, proporciona ventajas de administración. No se recomienda virtualizar equipos basados en SQL Server, pero puede haber ciertas ventajas en la virtualización de los niveles de servidor web y servidor de aplicaciones. Para obtener más información, vea Planeamiento de virtualización (/previous-versions/office/sharepoint-server-2010/ff607968(v=office.14)).

Para obtener más información sobre los requisitos de hardware, vea Requisitos de hardware y software para SharePoint Server 2016.

Instrucciones para la selección de hardware

Elección de los procesadores

SharePoint Server 2013 solo está disponible para procesadores de 64 bits. En general, más procesadores permiten atender una mayor demanda.

En SharePoint Server 2013, los servidores web individuales se escalarán verticalmente a medida que agregue más núcleos. Cuantos más núcleos tenga el servidor más carga puede mantener, si todas las demás condiciones son iguales. En implementaciones grandes de SharePoint Server 2013, se recomienda asignar varios servidores web de 4 núcleos (que se pueden virtualizar) o menos servidores web más seguros (8/16-/24 núcleos).

Los requisitos de capacidad del procesador de los servidores de aplicaciones varían en función del rol del servidor y de los servicios en ejecución. Algunas características de SharePoint Server 2013 requieren mayor potencia de procesamiento que otras. Por ejemplo, el servicio de búsqueda de SharePoint depende mucho de la capacidad de procesamiento del servidor de aplicaciones.

Los requisitos de capacidad de los procesadores para SQL Server también dependen de las bases de datos de servicio que hospede un equipo basado en SQL Server.

Elección de memoria

Los servidores requerirán cantidades variables de memoria según la función y el rol del servidor. Por ejemplo, los servidores que ejecutan componentes de rastreo de búsqueda procesarán los datos más rápidamente si tienen más memoria, porque los documentos se leen en la memoria para su procesamiento. Los servidores web que aprovechan las ventajas de muchas de las características de almacenamiento en caché de SharePoint Server 2013 pueden requerir también más memoria.

En general, los requisitos de memoria de los servidores web dependen mucho del número de grupos de aplicaciones habilitados en la granja de servidores, y del número de solicitudes simultáneas que se atienden. En la mayoría de las implementaciones de SharePoint Server 2013 de producción, se recomienda asignar al menos 8 GB de RAM en cada servidor web, con 16 GB recomendados para servidores que tienen mayor tráfico o implementaciones con varios grupos de aplicaciones configurados para el aislamiento.

Los requisitos de memoria de los servidores de aplicaciones también difieren; algunas características de SharePoint Server 2013 tienen mayores requisitos de memoria en el nivel de aplicación que otras. En la mayoría de las implementaciones de SharePoint Server 2013 de producción, se recomienda asignar al menos 8 GB de RAM en cada servidor de aplicaciones; Los servidores de aplicaciones de 16 GB, 32 GB y 64 GB son comunes cuando muchos servicios de aplicaciones están habilitados en el mismo servidor o cuando se habilitan los servicios que dependen en gran medida de la memoria, como Excel Calculation Service y SharePoint Server 2013 Search Service.

Los requisitos de memoria de los servidores de bases de datos dependen estrechamente del tamaño de las bases de datos. Para obtener más información sobre cómo elegir memoria para los equipos basados en SQL Server, vea Almacenamiento y SQL Server planeamiento y configuración de capacidad (SharePoint Server).

Elección de redes

Además de la ventaja que se ofrece a los usuarios, si los clientes tienen acceso rápido a los datos a través de la red, una granja distribuida debe tener acceso rápido para la comunicación entre servidores. Esto es especialmente cierto cuando se distribuyen servicios entre varios servidores o se federan servicios a otras granjas de servidores. Hay tráfico significativo en una granja de servidores a través del nivel de servidor web, el nivel de servidor de aplicaciones y el nivel de servidor de base de datos, y la red puede convertirse fácilmente en un cuello de botella en determinadas condiciones, como trabajar con archivos grandes o cargas altas.

Los servidores web y los servidores de aplicaciones deben configurarse para usar al menos dos tarjetas de interfaz de red (NIC): una para administrar el tráfico de los usuarios finales y otra para administrar la comunicación entre servidores. La latencia de red entre los servidores puede tener un efecto significativo sobre el rendimiento. Por lo tanto, es importante mantener menos de 1 milisegundo de latencia de red entre el servidor web y los equipos basados en SQL Server que hospedan las bases de datos de contenido. Los equipos basados en SQL Server que hospedan cada una de las bases de datos de aplicaciones de servicio debe estar lo más próximos posible al servidor de aplicaciones de consumo. La red entre los servidores de la granja debe tener un ancho de banda de al menos 1 Gbps.

Elección de discos y almacenamiento

La administración de discos no es simplemente una función de proporcionar suficiente espacio para los datos. Debe evaluar la demanda y el crecimiento en marcha, y asegurarse de que la arquitectura de almacenamiento no está ralentizando el sistema. Siempre debe asegurarse de que tiene al menos un 30 % de capacidad adicional en cada disco, por encima de la estimación de requisitos de datos más alta, para dejar espacio para el crecimiento futuro. Además, en la mayoría de entornos de producción, la velocidad del disco (IOps) es crucial para que la capacidad de proceso sea suficiente para satisfacer las demandas de almacenamiento de los servidores. Debe calcular la cantidad de tráfico (IOps) que requerirán las principales bases de datos de su implementación y asignar suficientes discos para satisfacer ese tráfico.

Para obtener más información sobre cómo elegir discos para servidores de bases de datos, vea Almacenamiento y SQL Server planeamiento y configuración de capacidad (SharePoint Server).

Los servidores web y de aplicaciones también tienen requisitos de almacenamiento. En la mayoría de los entornos de producción, recomendamos asignar al menos 200 GB de espacio en disco para el SO y los archivos temporales, y 150 GB de espacio en disco para los registros.

Paso 3: Piloto, Prueba y Optimización

La fase de prueba y optimización es un componente importante de la administración eficaz de la capacidad. Debe probar las nuevas arquitecturas antes de implementarlas en el entorno de producción, y debe realizar pruebas de aceptación con los siguientes procedimientos recomendados sobre supervisión, para asegurarse de que las arquitecturas que diseñe logran los objetivos de rendimiento y capacidad. Esto le permite identificar y optimizar posibles cuellos de botella antes de que afecten a los usuarios en una implementación en vivo. Si va a actualizar desde un entorno de Office SharePoint Server 2007 y planea realizar cambios en la arquitectura, o está estimando la carga del usuario de las nuevas características de SharePoint Server 2013, las pruebas son importantes para asegurarse de que el nuevo entorno basado en SharePoint Server 2013 cumplirá los objetivos de rendimiento y capacidad.

Una vez probado el entorno, puede analizar los resultados de las pruebas para determinar qué cambios deben realizarse para lograr los objetivos de rendimiento y capacidad que estableció en el Paso 1: modelar.

Estos son los pasos secundarios para la preproducción:

Cree el entorno de prueba que imita la arquitectura inicial que ha diseñado en el Paso 2: diseñar.
Rellenar el almacenamiento con el conjunto de datos o con una parte del conjunto de datos que ha identificado en el Paso 1: modelar.
Realizar una prueba de esfuerzo en el sistema con una carga sintética que represente la carga de trabajo que ha identificado en el Paso 1: modelar.
Ejecutar pruebas, analizar los resultados y optimizar la arquitectura.
Implemente la arquitectura optimizada en el centro de datos y aplique un piloto con un conjunto menor de usuarios.
Analice los resultados de piloto, identifique los posibles cuellos de botella y optimice la arquitectura. Vuelva a probar si es necesario.
Implementar en el entorno de producción.

Prueba

Las pruebas son un factor fundamental para establecer la capacidad del diseño del sistema para admitir las características de uso y carga de trabajo. Vea Pruebas de rendimiento para SharePoint Server 2013 para obtener información detallada sobre cómo probar su implementación de SharePoint Server 2013.

Crear un plan de pruebas
Crear el entorno de pruebas
Crear las pruebas y herramientas

Implementar el entorno piloto

Antes de implementar SharePoint Server 2013 en un entorno de producción, es importante que primero implemente un entorno piloto y pruebe exhaustivamente la granja de servidores para asegurarse de que puede cumplir los objetivos de capacidad y rendimiento para la carga máxima esperada. Se recomienda que el entorno piloto se pruebe por primera vez con carga sintética especialmente para implementaciones grandes y, a continuación, se estrese por un pequeño conjunto de usuarios activos y contenido en directo. Analizar un entorno piloto con un pequeño conjunto de usuarios activos permite validar algunas suposiciones realizadas acerca de las características de uso y el crecimiento del contenido antes de entrar de lleno en el entorno de producción.

Optimizar

Si no puede cumplir los objetivos de capacidad y rendimiento mediante el escalado del hardware de la granja de servidores o la realización de cambios en la topología, es posible que tenga que considerar la posibilidad de revisar la solución. Por ejemplo, si sus requisitos iniciales eran para una sola granja de servidores para tareas de colaboración, de búsquedas y sociales, quizás tenga que federar algunos servicios, como las búsquedas, en una granja de servicios dedicados, o repartir la carga de trabajo entre varias granjas más. Una alternativa es implementar una granja de servidores dedicada para tareas sociales y otra para la colaboración en grupo.

Paso 4: implementar

Una vez que haya ejecutado la ronda final de pruebas y confirmado que la arquitectura seleccionada puede lograr los objetivos de rendimiento y capacidad que estableció en Paso 1: Modelo, puede implementar el entorno basado en SharePoint Server 2013 en producción.

La estrategia de lanzamiento apropiada variará según el entorno y la situación. Aunque la implementación de SharePoint Server 2013 generalmente está fuera del ámbito de este documento, hay ciertas actividades sugeridas que pueden salir del ejercicio de planeamiento de la capacidad. Estos son algunos ejemplos:

Implementación de una nueva granja de servidores de SharePoint Server 2013: El ejercicio de planeamiento de capacidad debe tener planes guiados y confirmados para un diseño e implementación de SharePoint Server 2016. En este caso, el lanzamiento será la primera implementación amplia de SharePoint Server 2013. Será necesario mover o volver a crear en producción los servidores y servicios que se usaron durante los ejercicios de planeación de la capacidad. Este es el escenario más sencillo porque no se necesitan actualizaciones ni modificaciones en una granja de servidores existente.
Actualización de una granja de servidores de Office SharePoint Server 2007 a SharePoint Server 2013: El ejercicio de planeamiento de capacidad debe haber validado el diseño de una granja de servidores que pueda satisfacer las demandas existentes y escalar verticalmente para satisfacer el aumento de la demanda y el uso de una granja de servidores de SharePoint Server 2013. Parte del ejercicio de planeamiento de capacidad debería haber incluido migraciones de prueba para validar cuánto tiempo tardará el proceso de actualización, si se debe modificar o reemplazar cualquier código personalizado, si se deben actualizar las herramientas de terceros, etc. Al finalizar el planeamiento de la capacidad, debe tener un diseño validado y comprender cuánto tiempo se tardará en actualizarse, y un plan para ver la mejor manera de trabajar a través del proceso de actualización, por ejemplo, una actualización local o la migración de bases de datos de contenido a una nueva granja de servidores. Si está realizando una actualización local, es posible que durante el planeamiento de la capacidad haya detectado que se necesitará hardware adicional o actualizado y consideraciones para el tiempo de inactividad. Parte de la salida del ejercicio de planeación debe ser una lista de los cambios de hardware necesarios y un plan detallado para implementar primero los cambios de hardware en la granja de servidores. Una vez que se haya implementado la plataforma de hardware que se validó durante el planeamiento de la capacidad, puede avanzar con el proceso de actualización a SharePoint Server 2013.
Mejora del rendimiento de una granja de servidores de SharePoint Server 2013 existente: El ejercicio de planeamiento de capacidad debería haberle ayudado a identificar los cuellos de botella en la implementación actual, planear formas de reducir o eliminar esos cuellos de botella y validar una implementación mejorada que cumpla los requisitos empresariales para los servicios de SharePoint Server 2013. Hay diferentes maneras en las que se podrían haber resuelto problemas de rendimiento, desde algo tan fácil como reasignar servicios en todo el hardware existente, actualizar el hardware existente o agregar más hardware y agregarle más servicios. Los diferentes enfoques deben probarse y validarse durante el ejercicio de planeación de la capacidad y, después, diseñarse un plan de implementación según los resultados de las pruebas.

Paso 5: supervisar y mantener

Para mantener el rendimiento del sistema, debe supervisar el servidor para identificar posibles cuellos de botella. Para poder realizar una supervisión eficaz, debe comprender los principales indicadores que le dirán si un componente específico de su granja de servidores requiere atención, y saber cómo interpretar esos indicadores. Si ve que su granja de servidores no está logrando los objetivos que ha definido, puede ajustarla agregando o quitando recursos de hardware, cambiando su topología o cambiando la manera de almacenar los datos.

Vea Supervisión y mantenimiento de SharePoint Server 2013 para obtener una lista de las opciones de configuración que puede cambiar para supervisar su entorno en estas fases tempranas, y que le ayudarán a determinar si se necesita realizar algún cambio. Recuerde que aumentar las funcionalidades de supervisión afectará a la cantidad de espacio en disco que necesitará la base de datos de uso. Una vez que el entorno es estable y esta supervisión detallada ya no es necesaria, es posible que desee revertir la configuración siguiente a su configuración predeterminada.

Para obtener más información sobre la supervisión de estado y la solución de problemas con las herramientas de supervisión de estado integradas en la interfaz de Administración central de SharePoint Server 2013, vea:

Supervisión y envío de informes de SharePoint Server 2016

Solución de problemas