Planeación de la capacidad para SharePoint Server 2010

Artículo
03/03/2017

Se aplica a: SharePoint Server 2010

Última modificación del tema: 2016-11-30

En este artículo se describe cómo planear la capacidad de un conjunto o granja de servidores de Microsoft SharePoint Server 2010. Cuando tenga una apreciación y comprensión adecuadas de la planeación y administración de la capacidad, podrá aplicar sus conocimientos para realizar el ajuste de tamaño del sistema. Se entiende por ajuste de tamaño el proceso de elegir y configurar de manera adecuada la arquitectura de datos, la topología lógica y física, y el hardware para una plataforma de solución. Deben tenerse en cuenta varias consideraciones sobre administración y uso de la capacidad a la hora de determinar las opciones de hardware y de configuración más apropiadas.

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

En este artículo se describen los pasos que se deben seguir para la administración eficaz de la capacidad de un entorno. Cada paso requiere cierta información para su correcta ejecución e incluye un conjunto de entregas que se usarán en el paso siguiente. En las tablas que siguen se describen los requisitos y objetivos correspondientes a cada paso.

En este artículo:

Paso 1: Modelo
Paso 2: Diseño
Paso 3: Piloto, prueba y optimización
Paso 4: Implementación
Paso 5: Supervisión y mantenimiento

Paso 1: Modelo

Para crear un modelo de un entorno basado en SharePoint Server 2010, es necesario empezar con un análisis de las soluciones existentes y estimar la demanda y los objetivos previstos para la implementación que se desea configurar. Primero, debe recopilar información acerca de la base de usuarios, los requisitos de datos, la latencia y los objetivos de rendimiento, y documentar las características de SharePoint Server que desea implementar. En esta sección aprenderá qué datos debe recopilar, cómo recopilarlos y cómo se pueden usar en los pasos siguientes.

Determinación de la carga de trabajo y el conjunto de datos previstos

Para calcular correctamente el tamaño de una implementación de SharePoint Server 2010 debe analizar y conocer las características de demanda que se espera que la solución pueda controlar. Para conocer la demanda, debe poder describir las características de la carga de trabajo, como el número de usuarios y las operaciones que se usan con más frecuencia, así como las características del conjunto de datos, como el tamaño y la distribución del contenido.

Esta sección le ayudará a conocer algunos de los datos métricos y parámetros específicos que deberá recopilar y los mecanismos que puede usar para hacerlo.

Carga de trabajo

La carga de trabajo describe la demanda que el sistema deberá atender, la base de usuarios y las características de uso. En la tabla siguiente se proporcionan algunos datos métricos esenciales que resultan útiles para determinar la carga de trabajo. Puede usar esta tabla para registrar estos datos métricos a medida que los recopila.

Características de la carga de trabajo	Valor
Promedio de RPS por día
Promedio de RPS en horas pico
Número total de usuarios únicos por día
Promedio de usuarios simultáneos por día
Pico de usuarios simultáneos en horas pico
Número total de solicitudes por día
Distribución de carga de trabajo prevista	Número de solicitudes por día
Explorador web: rastreo de búsqueda
Explorador web: interacción general de colaboración
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/servicios web personalizados)

Usuarios simultáneos: es más común medir la simultaneidad de las operaciones que se ejecutan en la granja de servidores, como el número de usuarios distintos que generan solicitudes en una cantidad de tiempo determinada. Los datos métricos esenciales son el promedio diario y la cantidad de usuarios simultáneos con carga pico.
Solicitudes por segundo (RPS): RPS es un indicador que se usa comúnmente para describir la demanda en la granja de servidores expresada según el número de solicitudes que la granja de servidores procesa por segundo, sin distinguir entre el tipo o el tamaño de las solicitudes. La base de usuarios de cada organización genera la carga del sistema a una velocidad que depende de las características de uso únicas de la organización. Vea la sección Glosario en Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 para obtener más información acerca de este término.
Total de solicitudes diarias: el total de solicitudes diarias es un buen indicador de la carga general que deberá administrar el sistema. De manera habitual, se miden todas las solicitudes, salvo las solicitudes de protocolo de enlace de autenticación (estado HTTP 401), durante un período de 24 horas.
Total de usuarios diarios: el total de usuarios es otro indicador clave de la carga general que el sistema deberá administrar. Esta medida es el número real de usuarios únicos en un período de 24 horas y 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 posibles es de 100.000 empleados, una cantidad de 15.000 usuarios diarios significa que la carga puede aumentar considerablemente con el tiempo a medida que aumenta la adopción de usuarios.
Distribución de la carga de trabajo: conocer la distribución de las solicitudes en función de las aplicaciones cliente que interactúan con la granja de servidores puede ayudar a predecir la tendencia y los cambios de carga después de migrar a SharePoint Server 2010. A medida que los usuarios realicen la transición a versiones de clientes más recientes, como Office 2010, y comiencen a usar los nuevos modelos de carga y las nuevas capacidades, se estima que las RPS y el total de solicitudes aumentarán. Se puede describir el número de usuarios distintos que usan cada cliente en un período de un día y la cantidad total de solicitudes que el cliente o la característica genera en el servidor en cada caso.

Por ejemplo, el gráfico siguiente muestra una instantánea de un entorno interno real de Microsoft para una solución social típica. En este ejemplo, se puede ver que la mayor parte de la carga se genera por el rastreador de búsqueda y el uso típico de los exploradores web por parte de los usuarios finales. También se puede observar que la nueva característica de Outlook Social Connector introduce una carga considerable (6,2% de las solicitudes).

Distribución de carga de solicitudes diaria típica

Estimación de la carga de trabajo de producción

Para calcular el rendimiento que la granja de servidores tendrá que mantener, calcule primero la combinación de transacciones que se usarán en la granja de servidores. Céntrese en analizar las transacciones más frecuentes que el sistema tendrá que atender y en determinar con qué frecuencia se usarán y cuántos usuarios las usarán. Esto le ayudará a validar más adelante si la granja de servidores puede mantener dicha carga en pruebas de preproducción.

En el siguiente diagrama se describe la relación entre la carga de trabajo y la carga del sistema:

Capacidad: diagrama de carga de trabajo

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

Identifique las interacciones de los usuarios, como por ejemplo, páginas web que suelen visitar, descargas y cargas de archivos, vistas y ediciones de Office Web Application en el explorador, interacciones de co-autoría, sincronizaciones de sitios de SharePoint Workspace, conexiones sociales de Outlook, sincronización de RSS (en Outlook o en otros visores), difusiones de PowerPoint, blocs de notas compartidos de OneNote, libros compartidos de Servicios de Excel, aplicaciones compartidas de Servicios de Access, etc. Vea la sección sobre servicios y características del artículo Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 para obtener más información. Céntrese en identificar las interacciones que pueden ser únicas para la implementación y determine el impacto previsto de dicha carga; por ejemplo, un uso considerable de formularios de InfoPath, cálculos de Servicios de Excel y soluciones dedicadas similares.
Identifique operaciones del sistema, como rastreos incrementales de búsqueda, copias de seguridad diarias, trabajos del temporizador de sincronización de perfiles, procesamiento de Web Analytics, registro de trabajos del temporizador, etc.
Calcule el número total de usuarios por día que estima que usarán cada capacidad, derive la cantidad estimada de usuarios simultáneos y de solicitudes de alto nivel por segundo. Deberá plantear algunos supuestos, como la simultaneidad presente y el factor RPS por usuarios simultáneos, que difiere entre las distintas capacidades. Se recomienda usar la tabla de carga de trabajo incluida anteriormente en esta sección para realizar los cálculos. Es importante que se fije en las horas pico, en lugar del rendimiento promedio. Si planea la actividad pico, podrá ajustar correctamente el tamaño de la solución basada en SharePoint Server 2010.

Si dispone de una solución de Office SharePoint Server 2007, puede extraer los archivos de registro de IIS o recurrir a otras herramientas de supervisión web que tenga para entender mejor algunos de los comportamientos previstos de la solución existente. También puede ver las instrucciones que se proporcionan en la sección siguiente para obtener más detalles. Si no va a migrar de una solución existente, debe rellenar la tabla con estimaciones aproximadas. En los pasos posteriores deberá validar los supuestos planteados y optimizar el sistema.

Análisis de los registros de IIS de SharePoint Server 2010

Para obtener datos métricos esenciales acerca de una implementación de SharePoint Server 2010 existente, como cuántos usuarios están activos, con qué intensidad usan el sistema, qué tipo de solicitudes entran y de qué tipo de clientes proceden, es necesario extraer datos de los registros de ULS e IIS. Una de las formas más sencillas de obtener este tipo de datos consiste en usar Log Parser, una eficaz herramienta que se puede descargar de forma gratuita a través de Microsoft. Log Parser puede leer y escribir en una serie de formatos de texto y binarios, incluidos todos los formatos IIS.

Para obtener más información acerca de cómo analizar el uso de SharePoint Server 2010 con Log Parser, lea el tema sobre el análisis de uso de Productos y Tecnologías de Microsoft SharePoint (https://www.microsoft.com/downloads/en/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e\&displaylang=en\&tm).

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

Conjunto de datos

El conjunto de datos describe el volumen de contenido almacenado en el sistema y cómo puede distribuirse en el almacén de datos. En la tabla siguiente se proporcionan algunos datos métricos esenciales que resultan útiles para determinar el conjunto de datos. Puede usar esta tabla para registrar estos datos métricos a medida que los recopila.

Objeto	Valor
Tamaño de la base de datos (en GB)
Número de bases de datos de contenido
Número de colecciones de sitios
Número de aplicaciones web
Número de sitios
Tamaño de índice de búsqueda (número de elementos)
Número de documentos
Número de listas
Tamaño promedio de los sitios
Sitio de mayor tamaño
Número de perfiles de usuario

Tamaño del contenido: es importante conocer el tamaño del contenido que calcula que se almacenará en el sistema SharePoint Server 2010 para planear y diseñar la arquitectura del almacenamiento de sistema y también para ajustar correctamente el tamaño de la solución de búsqueda que va a rastrear e indizar este contenido. El tamaño del contenido se describe en el espacio total en disco. Si va a migrar contenido de una implementación existente, puede que le resulte sencillo identificar el tamaño total que moverá; durante la planeación, debería dejar espacio para el crecimiento a lo largo del tiempo en función de la tendencia prevista.
Número total de documentos: aparte del tamaño del cuerpo de datos, es importante realizar un seguimiento del número total de elementos. El sistema reacciona de forma diferente si 100 GB de datos se compone de 50 archivos de 2 GB cada uno, en lugar de 100.000 archivos de 1 KB cada uno. En las implementaciones de gran tamaño, cuanto menor esfuerzo haya en un solo elemento, documento o área de documentos, mejor será el rendimiento. El contenido que está muy distribuido, como varios archivos pequeños en muchos sitios y la colección de sitios, es más fácil de atender que una única biblioteca de documentos de gran tamaño con archivos muy grandes.
Tamaño máximo de la colección de sitios: es importante identificar cuál es la unidad más grande de contenido que se va a almacenar en SharePoint Server 2010; normalmente no se puede dividir esa unidad de contenido debido a una necesidad de la organización. El tamaño promedio de todas las colecciones de sitios y el número total estimado de colecciones de sitios son indicadores adicionales que le ayudarán a identificar cuál es la arquitectura de datos preferida.
Características de datos de aplicaciones de servicio: además de analizar las necesidades de almacenamiento del almacén de contenido, deber analizar y calcular los tamaños de otros almacenes de SharePoint Server 2010, incluidos:
Tamaño total del índice de búsqueda
El tamaño total de base de datos de perfiles en función del número de usuarios en el almacén de perfiles
El tamaño total de la base de datos social en función del número esperado de etiquetas, compañeros de trabajo y actividades
El tamaño del repositorio de metadatos
El tamaño de la base de datos de uso
El tamaño de la base de datos de Web Analytics

Para obtener más información acerca de cómo calcular los tamaños de las bases de datos, vea Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010).

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

Mediante el Paso 1: Modelo se puede lograr conocer bien los objetivos de rendimiento y confiabilidad más adecuados para las necesidades de la organización. Una solución de SharePoint Server que esté diseñada adecuadamente debe ser capaz de lograr un tiempo de actividad del 99,99% con una capacidad de respuesta del servidor de fracciones de segundos.

Los indicadores que se usan para describir el rendimiento y la confiabilidad de la granja de servidores incluyen, entre otros:

Disponibilidad del servidor: normalmente, se describe en función del porcentaje de tiempo de actividad general del sistema. Se debe realizar un seguimiento del tiempo de inactividad inesperado y comparar la disponibilidad general con el objetivo de la organización que se ha establecido. Los objetivos se describen normalmente mediante una serie de "nueves" (por ejemplo, 99%, 99,9%, 99,99%).
Capacidad de respuesta del servidor: el tiempo que tarda la granja de servidores en atender las solicitudes es un buen indicador para realizar un seguimiento del estado de la granja de servidores. Este indicador se denomina normalmente latencia del servidor y es habitual usar el promedio o la mediana (percentil de 50) de latencia de las solicitudes diarias que se atienden. Normalmente, los objetivos se describen en fracciones de segundo o en segundos. Tenga en cuenta que si la organización tiene como objetivo atender páginas de SharePoint Server 2010 en menos de dos segundos, el objetivo del servidor debe ser de fracciones de segundo para dar tiempo a la página a que obtenga acceso al cliente a través de la red y para que se represente en el explorador. También, en general, los tiempos de respuesta del servidor más largos indican que la granja de servidores está en mal estado, ya que esto normalmente afecta al rendimiento y rara vez las RPS pueden mantener el rendimiento si se dedica más de un segundo en el servidor para la mayoría de las solicitudes.
Picos del servidor: otro indicador de latencia del servidor adecuado del que vale la pena realizar un seguimiento es el comportamiento del 5% más lento de todas las solicitudes. Las solicitudes más lentas son normalmente las solicitudes que llegan al sistema cuando este se encuentra sometido a una carga más alta o, con más frecuencia, las solicitudes que se ven afectadas por la 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 bajo control las solicitudes más lentas. En este caso, el objetivo es similar a la capacidad de respuesta del servidor, pero para lograr una respuesta de fracciones de segundo en picos del servidor, deberá incluir en el sistema una gran cantidad de 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 en la topología de la granja de servidores. Los indicadores que se usan con más frecuencia para realizar un seguimiento son el uso porcentual de CPU y la memoria disponible; sin embargo, hay varios contadores adicionales que pueden ayudar a identificar un sistema que no está en buen estado; puede encontrar más detalles en el Paso 5: Supervisión y mantenimiento.

Paso 2: Diseño

Una vez que se han recopilado algunos datos o cálculos sobre la solución, puede continuar con el paso siguiente que consiste en diseñar una propuesta de arquitectura que pueda mantener la demanda prevista según sus cálculos.

Al finalizar este paso, deberá tener un diseño para la topología física y otro para la topología lógica, así que seguramente podrá proseguir con las compras necesarias.

Las especificaciones de hardware y el número de máquinas que incluya en el diseño están estrechamente relacionados. Para administrar una carga específica se puede elegir entre varias soluciones para implementarlas. Es habitual usar un conjunto pequeño de máquinas eficaces (incremento de la escalabilidad vertical) o bien un conjunto mayor de máquinas más pequeñas (incremento de la escalabilidad horizontal). Cada solución tiene sus ventajas e inconvenientes en cuanto a capacidad, redundancia, eficacia, costo, espacio y otras consideraciones.

Se recomienda que para iniciar este paso determine la arquitectura y la topología. Decida cómo tiene previsto diseñar las diferentes granjas de servidores y los distintos servicios en cada granja y, a continuación, elija las especificaciones de hardware para cada uno de los servidores del diseño. Para realizar este proceso, también puede identificar las especificaciones de hardware que espera implementar (muchas organizaciones están limitadas a un determinado estándar de la compañía) y, a continuación, definir la arquitectura y la topología.

Use la siguiente tabla para registrar los parámetros de diseño. Los datos que se incluyen son datos de ejemplo y no deben usarse para calcular el tamaño de la granja de servidores, ya que están diseñados para mostrar cómo usar esta tabla con sus propios datos.

Rol	Tipo (estándar o virtual)	Número de máquinas	Procedimientos	RAM	E/S por segundo necesaria	Tamaño de disco SO + registro	Unidad de datos
Servidores web	Virtual	4	4 núcleos	8	N/A	400 GB	N/A
Servidor de bases de datos de contenido	Estándar	1 clúster	4 procesadores de núcleo cuádruple a 2,33 (GHz)	48	2k	400 GB	20 discos de 300 GB a 15.000 RPM
Servidores de aplicaciones	Virtual	4	4 núcleos	16	N/A	400 GB	N/A
Servidor web de destino de rastreo de búsqueda	Virtual	1	4 núcleos	8	N/A	400 GB	N/A
Servidor de consultas de búsqueda	Estándar	2	2 procesadores de núcleo cuádruple a 2,33 (GHz)	32	N/A	400 GB	500 GB
Servidor de rastreador de búsqueda	Estándar	2	2 procesadores de núcleo cuádruple a 2,33 (GHz)	16	400	400 GB	N/A
Servidor de bases de datos de rastreo de búsqueda	Estándar	1 clúster	4 procesadores de núcleo cuádruple a 2,33 (GHz)	48	4 k (optimizado para lectura)	100 GB	16 discos de 150 GB a 15.000 RPM
Base de datos de almacén de propiedades de búsqueda + Servidor de bases de datos de administración	Estándar	1 clúster	4 procesadores de núcleo cuádruple a 2,33 (GHz)	48	2 k (optimizado para escritura)	100 GB	16 discos de 150 GB a 15.000 RPM

Determinación de la arquitectura inicial

En esta sección se describe cómo seleccionar una arquitectura inicial.

Cuando implemente SharePoint Server 2010, puede elegir entre una amplia gama de topologías para implementar la solución. Puede implementar un solo servidor o incrementar la escalabilidad horizontal de muchos servidores a una granja de servidores de SharePoint Server con servidores de bases de datos en clúster o reflejados y servidores de aplicaciones discretos para varios servicios. Después, puede seleccionar las configuraciones de hardware en función de los requisitos de cada uno de los roles, según sus necesidades de capacidad, disponibilidad y redundancia.

Comience por revisar las diferentes arquitecturas de referencia y determine la estructura de la granja de servidores. Decida si debe dividir la solución en varias granjas de servidores, o federar algunos servicios, como la búsqueda, en una granja de servidores dedicada. Vea la sección sobre arquitectura de referencia en Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 para obtener más información.

Casos prácticos técnicos de SharePoint Server 2010

Las directrices de administración de la capacidad de SharePoint Server 2010 contienen una serie de casos prácticos técnicos de los entornos de producción existentes que presentan una descripción detallada de los entornos de producción actuales basados en SharePoint Server. Más adelante se publicarán más casos prácticos técnicos para que sirvan de referencia sobre cómo diseñar un entorno basado en SharePoint Server con fines específicos.

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

En estos documentos se proporciona la información siguiente para cada caso práctico documentado:

Especificaciones, como hardware, topología de la 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 del contenido, las características del contenido y la distribución del contenido;
Mantenimiento y rendimiento, incluido un conjunto de indicadores registrados que describen las características de confiabilidad y rendimiento de la granja de servidores.

Para obtener más información, descargue los documentos relevantes de la página sobre casos prácticos técnicos de rendimiento y capacidad (https://technet.microsoft.com/es-es/library/cc261716.aspx).

Selección del hardware

La selección de las especificaciones adecuadas para las máquinas de la granja de servidores es un paso esencial para garantizar la confiabilidad y el rendimiento adecuados de la implementación. Unas de las consideraciones clave es que debe realizar la planeación teniendo en cuenta el pico de carga y las horas pico; es decir, cuando la granja de servidores está funcionando en condiciones de carga media, debería haber suficientes recursos disponibles para controlar la máxima demanda esperada y, al mismo tiempo, cumplir con los objetivos de latencia y rendimiento.

Las características principales del hardware de capacidad y rendimiento de los servidores reflejan cuatro categorías principales: potencia de procesamiento, rendimiento del disco, capacidad de la red y capacidades de memoria de un sistema.

Otro aspecto que se debe tener en cuenta es el uso de máquinas virtualizadas. Una granja de servidores de SharePoint Server se puede implementar mediante máquinas virtuales. Aunque no se haya comprobado que esto proporcione más beneficios de rendimiento, sí proporciona beneficios de capacidad de administración. Por lo general, no se recomienda la virtualización de equipos basados en SQL Server, pero puede haber ciertos beneficios en la virtualización de los niveles de servidores web y servidores de aplicaciones. Para obtener más información, vea el tema sobre la planeación de la virtualización (https://technet.microsoft.com/es-es/library/ff607968.aspx).

Instrucciones para la selección del hardware

Elección de procesadores

SharePoint Server 2010 solo está disponible para procesadores de 64 bits. Normalmente, un número mayor de procesadores le permitirá atender una mayor demanda.

En SharePoint Server 2010, a medida que se agregan más núcleos (hemos probado hasta 24 núcleos) se incrementará la escalabilidad de los servidores web individuales; cuantos más núcleos tenga el servidor, más carga podrá mantener, considerando que todas las demás características sean las mismas. En grandes implementaciones de SharePoint Server, se recomienda asignar varios servidores web de 4 núcleos (que se pueden virtualizar) o menos servidores web más eficaces (de 8, 16 ó 24 núcleos).

Los requisitos de capacidad del procesador de los servidores de aplicaciones varían según el rol del servidor y los servicios que ejecuta. Algunas características de SharePoint Server exigen mayor potencia de procesamiento que otras. Por ejemplo, el servicio de búsqueda de SharePoint es sumamente dependiente de la capacidad de procesamiento del servidor de aplicaciones. Para obtener más información acerca de los requisitos de recursos de las características y servicios de SharePoint Server, vea el tema sobre servicios y características del artículo Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010.

Los requisitos de capacidad de procesador para SQL Server también dependen de las bases de datos de servicio que hospeda un equipo basado en SQL Server. Para obtener más información acerca del comportamiento típico y los requisitos de cada base de datos, vea Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010).

Elección de la memoria

Los servidores requieren distintas cantidades de memoria, según la función de servidor y su rol. Por ejemplo, los servidores que ejecutan los componentes de rastreo de búsqueda procesan datos con más rapidez si tienen una gran cantidad de memoria debido a que los documentos se leen en la memoria para su procesamiento. Los servidores web que aprovechan muchas de las características de almacenamiento en caché de SharePoint Server 2010 pueden requerir más memoria también.

En general, los requisitos de memoria del servidor web dependen considerablemente del número de grupos de aplicaciones habilitadas 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 de producción, se recomienda asignar al menos 8 GB de RAM a cada servidor web y 16 GB en el caso de servidores con más tráfico o implementaciones con varios grupos de aplicaciones configurados para su aislamiento.

Los requisitos de memoria de los servidores de aplicaciones también son diferentes; algunas características de SharePoint Server requieren más memoria en el nivel de aplicaciones que otras. En la mayoría de las implementaciones de SharePoint Server en producción se recomienda asignar al menos 8 GB de RAM a cada servidor de aplicaciones; los servidores de aplicaciones de 16 GB, 32 GB y 64 GB son comunes cuando se habilitan muchos servicios de aplicaciones en el mismo servidor, o cuando se habilitan servicios que dependen en gran medida de la memoria, como el Servicio de cálculo de Excel y el Servicio de búsqueda de SharePoint Server.

Los requisitos de memoria de los servidores de bases de datos son muy dependientes de los tamaños de las bases de datos. Para obtener más información acerca de la elección de la memoria para los equipos basados en SQL Server, vea Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010).

Elección de las redes

Además del beneficio que ofrecen a los usuarios los clientes que tienen acceso rápido a los datos a través de la red, una granja de servidores distribuida debe tener acceso rápido para la comunicación entre servidores, especialmente al distribuir los servicios entre varios servidores o al federar algunos de los servicios a otras granjas de servidores. Hay un tráfico considerable en una granja de servidores en el nivel de los servidores web, el nivel de los servidores de aplicaciones y el nivel de los servidores de bases de datos, y la red puede convertirse fácilmente en un cuello de botella en determinadas situaciones, por ejemplo al trabajar con archivos muy grandes o con cargas muy altas.

Los servidores web y los servidores de aplicaciones deben configurarse con al menos dos tarjetas de interfaz de red (NIC): una NIC para controlar el tráfico de usuarios finales y la otra para controlar la comunicación entre servidores. La latencia de red entre los servidores puede tener un impacto significativo en el rendimiento, por lo que 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 base de datos de la aplicación de servicio deben estar lo más cerca posible del servidor de aplicaciones de consumo también. La red entre los servidores de la granja de servidores debe tener al menos de 1 Gbps de ancho de banda.

Elección de los discos y el almacenamiento

La administración de discos no consiste solamente en proporcionar espacio suficiente para los datos. Debe evaluar la demanda y el crecimiento continuo y asegurarse de que la arquitectura de almacenamiento no ralentiza 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 permitir el crecimiento futuro. Además, en la mayoría de los entornos de producción, la velocidad de disco (E/S por segundo) es crucial para proporcionar suficiente rendimiento para satisfacer las exigencias de almacenamiento de los servidores. Debe estimar la cantidad de tráfico (E/S por segundo) que requerirán las bases de datos principales en la implementación y asignar suficientes discos para satisfacer ese tráfico.

Para obtener más información acerca de cómo elegir los discos para los servidores de bases de datos, vea Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010).

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

Paso 3: Piloto, prueba y optimización

La fase de pruebas y optimización es un componente esencial de la administración eficaz de la capacidad. Debe probar las arquitecturas nuevas antes de implementarlas en producción y llevar a cabo pruebas de aceptación junto con los siguientes procedimientos recomendados de supervisión para garantizar que las arquitecturas que diseñe alcancen los objetivos de rendimiento y capacidad. Esto permite identificar y optimizar los posibles cuellos de botella antes de que afecten a los usuarios en una implementación real. Si realiza una actualización de un entorno de Office SharePoint Server 2007 y planea realizar modificaciones en la arquitectura, o si está calculando la carga de usuarios de las nuevas características de SharePoint Server, es especialmente importante realizar pruebas para garantizar que el nuevo entorno basado en SharePoint Server cumpla con los objetivos de rendimiento y capacidad.

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

Estos son los pasos secundarios recomendados que se deben seguir para la preproducción:

Cree el entorno de prueba de modo que imite la arquitectura inicial que diseñó en el Paso 2: diseño.
Llene el almacenamiento con el conjunto de datos o con la parte del conjunto de datos que identificó en el Paso 1: Modelo.
Fuerce el sistema con una carga sintética que represente la carga de trabajo que identificó en el Paso 1: Modelo.
Ejecute pruebas, analice los resultados y optimice la arquitectura.
Implemente la arquitectura optimizada en el centro de datos y lleve a cabo una prueba piloto con un grupo más pequeño de usuarios.
Analice los resultados de la prueba piloto, identifique los posibles cuellos de botella y optimice la arquitectura. Vuelva a realizar la prueba si es necesario.
Realice la implementación en el entorno de producción.

Prueba

Las pruebas son un factor esencial para determinar si el diseño del sistema es capaz de admitir la carga de trabajo y las características de uso. Vea Pruebas de rendimiento para SharePoint Server 2010 para obtener más información acerca de cómo probar la implementación de SharePoint Server 2010.

Creación de un plan de pruebas
Creación del entorno de prueba
Creación de pruebas y herramientas

Implementación del entorno piloto

Antes de implementar SharePoint Server 2010 en un entorno de producción, es importante que implemente primero un entorno piloto y pruebe minuciosamente la granja de servidores para asegurarse de que puede cumplir con los objetivos de capacidad y rendimiento para la carga máxima esperada. En primer lugar, se recomienda probar el entorno piloto con una carga sintética, especialmente en las implementaciones de gran tamaño, y, a continuación, someterlo al esfuerzo de un pequeño conjunto de usuarios activos y contenido en directo. La ventaja de analizar un entorno piloto con un pequeño grupo de usuarios en directo es la oportunidad de validar algunos de los supuestos planteados acerca de las características de uso y el crecimiento del contenido antes de usarlo plenamente en el entorno de producción.

Optimización

Si no puede cumplir con los objetivos de rendimiento y capacidad mediante el incremento de la escalabilidad del hardware de la granja de servidores o cambios en la topología, es posible que deba revisar la solución. Por ejemplo, si sus requisitos iniciales fueron para una sola granja de servidores para colaboración, búsqueda y social, es posible que deba federar algunos de los servicios, como búsqueda, a una granja de servidores de servicios dedicados, o dividir la carga de trabajo entre más granjas de servidores. Una alternativa consiste en implementar una granja de servidores dedicada para la actividad social y otra para la colaboración en equipo.

Paso 4: Implementación

Una vez que haya ejecutado la ronda final de pruebas y comprobado que la arquitectura que se ha seleccionado puede alcanzar los objetivos de rendimiento y capacidad que estableció en el Paso 1: Modelo, puede implementar el entorno basado en SharePoint Server 2010 en un entorno de producción.

La estrategia de implementación apropiada variará en función del entorno y la situación. Si bien por lo general la implementación de SharePoint Server está fuera del alcance de este documento, el ejercicio de planeación de la capacidad puede plantear ciertas actividades sugeridas. A continuación se describen algunos ejemplos:

Implementación de una nueva granja de servidores de SharePoint Server: el ejercicio de planeación de la capacidad debería haber guiado y confirmado los planes para el diseño y la implementación de SharePoint Server 2010. En este caso, la implementación será la primera implementación amplia de SharePoint Server 2010. Habrá que mover o volver a generar los servidores y servicios que se usaron durante los ejercicios de planeación de la capacidad en el entorno de producción. Este es el escenario más sencillo ya que no es necesario realizar actualizaciones ni modificaciones en una granja de servidores existente.
Actualización de una granja de servidores de Office SharePoint Server 2007 a SharePoint Server 2010: el ejercicio de planeación de la capacidad debería haber validado el diseño de una granja de servidores capaz de satisfacer las demandas existentes e incrementar la escalabilidad vertical para satisfacer la creciente demanda y el uso de una granja de servidores de SharePoint Server 2010. Parte del ejercicio de planeación de la capacidad debería haber incluido migraciones de prueba para validar el tiempo que llevará el proceso de actualización, si es necesario modificar o reemplazar código personalizado, si las herramientas de terceros necesitan actualizarse, etc. Al finalizar la planeación de la capacidad, debería tener un diseño validado y una idea de cuánto tiempo llevará la actualización, así como un plan para implementar el proceso de actualización de forma óptima, por ejemplo, una actualización en contexto, o la migración de las bases de datos de contenido a una nueva granja de servidores. Si realiza una actualización en contexto, durante la planeación de la capacidad es posible que haya descubierto que necesitará hardware adicional o actualizado y que deberá tener en cuenta el tiempo de inactividad. Parte del resultado del ejercicio de planeación debería ser una lista de los cambios de hardware necesarios y un plan detallado para la implementación de los cambios de hardware en la granja de servidores. Una vez implementada la plataforma de hardware que se validó durante la planeación de la capacidad, puede continuar con el proceso de actualización a SharePoint Server 2010.
Mejora del rendimiento de una granja de servidores de SharePoint Server 2010 existente: el ejercicio de planeación de la capacidad debería haberle ayudado a identificar los cuellos de botella de la implementación actual, diseñar formas de reducir o eliminar dichos cuellos de botellas y validar una implementación mejorada que cubra sus necesidades empresariales de servicios de SharePoint Server. Se han mostrado distintas formas de resolver los problemas de rendimiento, desde algo tan simple como reasignar los servicios entre el hardware existente, actualizar el hardware existente o agregar hardware adicional y agregarle servicios adicionales. Los diferentes enfoques deben probarse y validarse durante el ejercicio de planeación de la capacidad y, a continuación, debe formularse un plan de implementación según los resultados de las pruebas.

Paso 5: Supervisión y mantenimiento

Para mantener el rendimiento del sistema, debe supervisar el servidor para identificar los posibles cuellos de botella. Para poder supervisarlo de forma eficaz, debe conocer los indicadores clave que indican si una parte específica de la granja de servidores requiere atención y saber cómo interpretar dichos indicadores. Si comprueba que la granja de servidores está funcionando fuera de los objetivos que ha definido, puede ajustarla al agregar o quitar recursos de hardware, modificar la topología o cambiar la forma en que se almacenan los datos.

Vea Supervisión y mantenimiento de SharePoint Server 2010 para obtener una lista de las opciones de configuración que se pueden modificar para supervisar el entorno en sus primeras etapas, lo que le ayudará a determinar si es necesario realizar cambios. Tenga en cuenta que al aumentar las capacidades de supervisión, se verá afectada la cantidad de espacio en disco que requiere la base de datos de uso. Una vez que el entorno sea estable y esta supervisión detallada ya no sea necesaria, se aconseja revertir la configuración a los valores predeterminados.

Para obtener más información acerca de cómo supervisar el estado y solucionar problemas usando las herramientas de seguimiento de estado integradas en la interfaz de Administración central de SharePoint Server, lea los siguientes temas:

Seguimiento de estado (SharePoint Server 2010)

Solución de problemas (https://technet.microsoft.com/es-es/library/ee748639.aspx)