Planeación de arquitectura de hardware en Project Server 2010
Se aplica a: Project Server 2010
Última modificación del tema: 2015-03-09
El rendimiento de Microsoft Project Server 2010 depende de muchos factores. Entre otros: el número de usuarios; el tipo, la complejidad y la frecuencia de las operaciones de los usuarios; el número de devoluciones (postbacks) en una operación; y el rendimiento de las conexiones de datos. Deben considerarse detenidamente los factores que se tratan en esta sección al planear la arquitectura del hardware. Project Server puede implementarse y configurarse de varias maneras. Así, no hay una forma sencilla para calcular cuántos usuarios pueden ser admitidos por un número determinado de servidores. Por lo tanto, realice las pruebas pertinentes en su propio entorno antes de implementar Project Server 2010 en un entorno de producción.
Este artículo contiene información sobre los límites de rendimiento y capacidad probados de Microsoft Project Server 2010, el entorno de prueba y los resultados de las pruebas y facilita directrices sobre rendimientos aceptables. Use la información de este artículo para calcular los objetivos de rendimiento de Project Server.
En el momento de planear la capacidad de Microsoft Project Server 2010, tenga en cuenta las variables que pueden incidir en el rendimiento de una implementación de Project Server.
Dado el potente conjunto de funcionalidades que proporciona Project Server, implementaciones que pueden parecer similares cuando se describen en general, puede que tengan características de rendimiento significativamente diferentes en la realidad. No es suficiente fundamentar las necesidades solo en el número de proyectos o el número de usuarios que tendrá el sistema. La estrategia relativa al rendimiento de la implementación de Project Server requiere un enfoque holístico y más matizado. Por ejemplo, las cargas de trabajo —y, consecuentemente, las necesidades de hardware— diferirán en función de las siguientes variables:
Factor | Características |
---|---|
Proyectos |
|
Usuarios |
|
Patrones de uso |
|
Existen muchas otras variables que pueden incidir en un entorno determinado y cada una de ellas puede afectar al rendimiento en distintas áreas. Algunos resultados de pruebas y recomendaciones de este artículo pueden estar relacionados con características u operaciones de usuario que no se den en su entorno y, por consiguiente, no serán de utilidad en su aplicación particular. Solo mediante la realización de pruebas podrá obtener los datos precisos para su entorno.
Otras variables para tener en cuenta:
Simultaneidad de usuarios: la carga de usuarios simultáneos es, con frecuencia, un factor importante al definir los requisitos de capacidad. Tal vez tenga pocos usuarios en el sistema, pero puede que estos operen con el servidor simultáneamente durante períodos de tráfico "pico". Por ejemplo, una organización cuyos usuarios deban enviar sus estados o partes de horas actualizados en el mismo momento de la semana sufrirá posiblemente una disminución sustancial del rendimiento durante dicho periodo. Si experimenta periodos con tráfico muy intenso, no descarte agregar recursos adicionales a la tipología recomendada para su conjunto de datos.
Repartición de roles de usuario: la distribución de usuarios entre administradores, administradores de cartera, jefes de proyecto e integrantes de grupo afectará al rendimiento de la implementación en cuanto que cada tipo de usuario obtiene acceso a un volumen de datos diferente. Los usuarios de las distintas categorías de seguridad se diferencian por cuántos proyectos y recursos pueden ver. Los administradores, por ejemplo, pueden ver todos los proyectos del servidor cuando cargan el Centro de proyectos y todos los recursos cuando cargan el Centro de recursos. Por contra, los jefes de proyecto sólo pueden ver sus propios proyectos. En consecuencia, estos usuarios percibirán un menor rendimiento. Si es posible, limite el número de proyectos, tareas o recursos mostrados en una vista determinada asignando los filtros adecuados en las vistas que defina en Configuración del servidor>Administración de vistas.
Distribución global de usuarios
Problemas, riesgos y entregas: si se presentan varios de estos elementos, puede aumentar la carga en SQL Server. En particular, la carga posiblemente aumente cuando el usuario ve estos elementos o interactúa con ellos en el sitio de Project. Si usa con mucha frecuencia estos elementos, le convendría asignar recursos adicionales a la implementación de SQL Server para mantener un nivel elevado de rendimiento. Puesto que estos artefactos y la funcionalidad del sitio de Project son sitios y listas de SharePoint, consulte la documentación relativa al escalado de los sitios y listas de SharePoint.
Calendarios: se pueden definir calendarios personalizados para los proyectos, las tareas y los recursos, que afectan en gran medida al motor de programación, ya que aumentan el uso de la CPU en los servidores de aplicaciones y de bases de datos.
Conjuntos de datos típicos
Los conjuntos de datos descritos en esta sección se caracterizan por las variables que se enumeran y explican en la tabla siguiente. Puede que estas variables no representen todos los factores que inciden en el rendimiento de Project Server (esto es, no representan la combinación de características que suele usar en su implementación). No obstante, recogen gran parte de la información importante a la hora de determinar la capacidad adecuada para cada uno.
Entidad | Descripción/notas | Pequeño | Mediano | Grande | |
---|---|---|---|---|---|
1 |
Proyectos |
100 |
5.000 |
20.000 |
|
1 |
Tareas |
17.125 |
856.250 |
3.425.000 |
|
1 |
Promedio de tareas por proyecto |
171,25 |
171,25 |
171,25 |
|
2 |
Historial de transacciones de tareas |
El número de veces que un estado se suele enviar y aprobar para una tarea determinada |
10 |
100 |
1.000 |
1 |
Asignaciones |
22.263 |
1.113.125 |
4.500.000 |
|
1 |
Promedio de asignaciones por tarea |
1,3 |
1,3 |
1,3 |
|
2/3 |
Aprobaciones |
Actualizaciones pendientes por jefe |
50 |
600 |
3.000 |
Usuarios |
1.000 |
10.000 |
50.000 |
||
Campos personalizados |
Proyecto (fórmula) |
3 |
20 |
25 |
|
Campos personalizados |
Proyecto (manual) |
2 |
40 |
50 |
|
Campos personalizados |
Tarea (fórmula) |
Los campos de fórmula de tarea suelen usar la mayor parte de la cuota de rendimiento porque deben calcularse para cada tarea. |
6 |
12 |
15 |
Campos personalizados |
Tarea (manual) |
4 |
8 |
10 |
|
Campos personalizados |
Aplicación de asignación |
50% |
50% |
50% |
|
Campos personalizados |
Recurso |
10 |
20 |
25 |
|
Campos personalizados |
Buscar campos personalizados de tabla |
2 |
15 |
100 |
|
1 |
Partes de horas (anual) |
Cuantos más partes de hora use, más solicitudes de recursos se enviarán a SQL Server |
52.000 |
780.000 |
8.320.000 |
1 |
Líneas de partes de horas |
5 |
10 |
10 |
Recomendaciones de hardware
Las secciones siguientes proporcionan recomendaciones generales sobre el rendimiento y la capacidad. Le servirán para identificar una topología inicial adecuada para sus requisitos y decidir si debe incrementar la escalabilidad horizontal o vertical de dicha topología inicial.
En este artículo, se hace referencia a los tres roles que se instalan en Windows Server: rol de servidor front-end web, rol de servidor de aplicaciones y rol de servidor de base de datos (SQL). Todos ellos forman parte de una implementación de Project Server 2010 completa. Los servidores front-end web actúan de interfaz para los usuarios que obtienen acceso a Project Server. El servidor de aplicaciones se ocupa de las solicitudes enviadas a la capa de datos de Project Server e implementa la lógica de negocios de Project Server 2010. Por último, la capa de base de datos es el origen de datos, que aloja las bases de datos de Project Server 2010. En las implementaciones pequeñas, los roles de servidor front-end web, de aplicaciones y de bases de datos pueden combinarse en el mismo equipo físico. En las implementaciones más grandes, puede resultar necesario repartirlos en distintos equipos, aunque varios equipos físicos desempeñen el mismo rol.
Recomendaciones de hardware para conjuntos de datos pequeños
En esta sección, se propone una topología recomendada para cada uno de los distintos tamaños de conjuntos de datos —pequeño, mediano y grande— clasificados en la sección "Conjuntos de datos típicos". Las topologías recomendadas para cada conjunto de datos deberían de ser suficiente para obtener un rendimiento aceptable con la mayoría de los patrones de uso de estos tamaños de conjuntos de datos. Con todo, debería tener en cuenta las recomendaciones específicas ofrecidas en el resto de este artículo para averiguar si debe ampliar la topología recomendada para su conjunto de datos aproximado. En general, debe observar las métricas de rendimiento de su topología y aumentarla en consecuencia, si no está de acuerdo con las características de rendimiento.
Tenga en cuenta que Project Server 2010 usa más recursos (procesador, RAM y disco duro) porque coexiste con SharePoint Server 2010. Los requisitos guía de SharePoint Server 2010 son igualmente válidos para una instalación de Project Server 2010 con un conjunto de datos pequeño y un uso básico. No obstante, para patrones de uso más intensos y conjuntos de datos de mayor tamaño, se necesitarán más recursos de hardware. Para una implementación en un equipo independiente con un conjunto de datos pequeño, 16 GB de RAM serán suficientes para garantizar un alto nivel de rendimiento percibido. A partir de esta cifra, es recomendable, si es posible, separar el servidor de bases de datos de las capas de aplicaciones y front-end web colocando las bases de datos en un equipo dedicado donde se ejecute SQL Server.
En la tabla siguiente, se enumeran las especificaciones de un único servidor con instalaciones de base de datos integradas e instalaciones de granjas de servidores con un servidor o varios servidores en la granja.
Servidor front-end web/de aplicaciones
Componente | Recomendado |
---|---|
Procesador |
64 bits, cuatro núcleos, 2,5 gigahercios (GHz) por núcleo como mínimo |
RAM |
4 GB para uso de desarrolladores o evaluación, 8 GB para instalación de granja de un único servidor o de varios servidores para uso en entorno de producción |
Disco duro |
80 GB |
SQL Server
Componente | Recomendado |
---|---|
Procesador |
64 bits, cuatro núcleos, 2,5 GHz como mínimo por núcleo (si su conjunto de datos es mucho mayor que un conjunto de datos mediano, se recomiendan ocho núcleos). |
RAM |
4 GB para uso de desarrolladores o evaluación, 8 GB para instalación de granja de un único servidor o de varios servidores para uso en entorno de producción |
Disco duro |
80 GB |
Recomendaciones de hardware para conjunto de datos mediano
Si tiene que procesar una carga mayor, puede incrementar la escalabilidad horizontal o vertical de los requisitos mínimos especificados para los conjuntos mediados. Las topologías incrementadas tratan consideraciones sobre cómo procesar cargas de usuario o de datos mayores.
Como recomendación general, para poder procesar una carga adicional de usuarios o de datos, debe disponer de equipos suficientes para agregar a su topología servidores front-end web y de aplicaciones. Las especificaciones de hardware de sus servidores front-end web y de aplicaciones serán prácticamente las mismas. Una topología 4 × 2 × 1 debería de ser suficiente para dar respuesta a las necesidades de la mayoría de los conjuntos de datos medianos y patrones de uso. El incremento de la escalabilidad horizontal de los servidores front-end web y de aplicaciones agregará más carga a su implementación de SQL Server, lo cual se debe compensar agregando más recursos de memoria y CPU. La especificación siguiente de SQL Server debe poder dar respuesta a los requisitos de rendimiento de la mayoría de los conjuntos de datos medianos. El mejor modo de identificar si la topología diseñada se adapta a sus requisitos de rendimiento es configurar un entorno de ensayo para probar la topología y supervisar las características de rendimiento.
Servidor front-end web
Componente | Recomendado |
---|---|
Procesador |
64 bits, cuatro núcleos, 2,5 GHz como mínimo por núcleo |
RAM |
4 GB para uso de desarrolladores o evaluación, 8 GB para instalación de granja de un único servidor o de varios servidores para uso en entorno de producción |
Disco duro |
80 GB |
Servidor de aplicaciones
Componente | Recomendado |
---|---|
Procesador |
64 bits, cuatro núcleos, 2,5 GHz como mínimo por núcleo |
RAM |
4 GB para uso de desarrolladores o evaluación, 8 GB para instalación de granja de un único servidor o de varios servidores para uso en entorno de producción |
Disco duro |
80 GB |
SQL Server
Componente | Recomendado |
---|---|
Procesador |
64 bits, ocho núcleos, 2,5 GHz como mínimo por núcleo. Si su conjunto de datos es mucho mayor que el conjunto de datos mediano, se aconseja el uso de ocho núcleos. |
RAM |
32 GB |
Disco duro |
160 GB |
Recomendaciones de hardware para conjunto de datos grande
En conjuntos de datos grandes, la carga de datos es el cuello de botella más importante para el rendimiento.
Generalmente, como mínimo para los conjuntos de datos grandes, será conveniente utilizar una topología 4 × 2 × 1. Las características de hardware de los servidores front-end web y de aplicaciones pueden ser las mismas que las recomendadas para los conjuntos de datos pequeños y medianos. No obstante, dado que la instalación de SQL Server será el cuello de botella, podría detectar que esto limita su capacidad de incrementar la escalabilidad horizontal a otros servidores front-end web y de aplicaciones. Si detecta que la carga de datos es su cuello de botella, podría detectar que los servidores front-end y de aplicaciones adicionales no representan un aumento en el rendimiento.
En los conjuntos de datos grandes, si la instación de SharePoint Server 2010 con la que coexiste Project Server 2010 está siendo objeto de un uso intensivo de (es decir, no se usa esa implementación de SharePoint Server 2010 específicamente para la funcionalidad Project Server 2010), se recomienda separar las cuatro bases de datos de Project Server 2010 de las bases de datos de contenido de SharePoint Server 2010 y colocarlas en su propia instalación dedicada de SQL Server.
Dado que el rendimiento de los datos será el cuello de botella, deberá invertir en recursos adicionales en la capa de SQL Server de su topología. Puede “incrementar la escalabilidad vertical” de la instalación de SQL Server agregando recursos de RAM, CPU y disco duro. En las secciones siguientes, se enumeran las especificaciones mínimas y recomendadas para la capa de SQL Server de una topología de conjunto de datos grande.
Requisitos mínimos de SQL Server
Componente | Recomendados |
---|---|
Procesador |
64 bits, ocho núcleos, 2,5 GHz como mínimo por núcleo. Si su conjunto de datos es mucho mayor que el conjunto de datos mediano, se aconseja el uso de ocho núcleos. |
RAM |
32 GB |
Disco duro |
250 GB |
Requisitos recomendados de SQL Server
Componente | Recomendados |
---|---|
Procesador |
64 bits, ocho núcleos, 2,5 GHz como mínimo por núcleo. Si su conjunto de datos es mucho mayor que el conjunto de datos mediano, se aconseja el uso de ocho núcleos. |
RAM |
64 GB |
Disco duro |
300 GB como mínimo. Coloque la base de datos de informes en un servidor de bases de datos separado. Sería idóneo separar y establecer prioridades para los datos entre los discos. Coloque los archivos de datos y los registros de transacción de SQL Server 2008 en discos duros físicos separados. RAID 5 puede ser una solución equilibrada entre fiabilidad y rendimiento. |
Recomendaciones sobre virtualización
Project Server 2010 no se puede ejecutar en equipos virtualizados. La mayoría de los consejos ofrecidos para la virtualización de SharePoint Server 2010 es aplicable también a Project Server 2010. Hallará documentación sobre la virtualización de SharePoint Server 2010 en Planeación de la virtualization (SharePoint Server 2010). Además, puede consultar la guía de virtualización de Project Server 2007 para obtener información adicional sobre virtualización y Project Server 2010, puesto que la mayoría de las directrices siguen siendo aplicables. No obstante, como en cualquier situación en la que se use virtualización, es importante tener en cuenta la contención de los recursos del equipo físico entre los equipos virtualizados que se ejecutan en la misma instalación física.
Nota
No se recomienda ejecutar SQL Server en un equipo virtualizado. La competencia por los recursos en un equipo virtualizado puede disminuir sustancialmente el rendimiento del servidor. Si tiene que ejecutar SQL Server en un entorno virtualizado, se recomienda el uso de la siguiente configuración:
-
Adaptador de red:
-
Si usa la virtualización Hyper-V, debe usar el adaptador de red virtual en lugar del adaptador de red heredado.
-
-
Disco virtual:
-
Para el equipo virtual en el que está ejecutando SQL Server, se recomienda seleccionar la opción de “paso” para el tipo de disco (en lugar de dinámico o fijo). Si no es una opción, debe usar el tamaño de disco fijo en lugar de un disco virtual de tamaño dinámico.
-
Se recomienda seleccionar IDE sobre SCSI para la unidad de arranque.
-
Asigne suficiente espacio de disco duro para procesar el tamaño máximo previsto de las peticiones de registro de ULS y de conjunto de datos.
-
-
Memoria:
-
Debe asignar al equipo virtual que ejecuta SQL Server tanta memoria como realistamente se pueda, lo que debe ser comparable al volumen de memoria necesario o recomendado para los servidores físicos que prestan la misma función.
-
Al menos, deben reservarse 2 GB de memoria para el sistema operativo host.
-
La ejecución de servidores front-end web y de aplicaciones en entornos virtualizados, no suele ser tan perjudicial para el rendimiento como la ejecución de SQL Server en un entorno virtualizado.
Requisitos de la red
Para la mayoría de las implementaciones de Project Server, el ancho de banda de red no suele ser el cuello de botella del rendimiento. En la tabla siguiente, se enumeran las especificaciones recomendadas de los componentes de red. Mantener una baja latencia entre las capas de servidores de aplicaciones y SQL debe ser un objetivo general.
Componente | Conjunto de datos pequeño y mediano | Conjunto de datos grande |
---|---|---|
Número de tarjetas de interfaz de red |
1 |
2 |
Velocidad de tarjetas de interfaz de red (red) |
Las velocidades superiores a 100 mbps son aceptables |
1 GB/s |
Tipo de equilibrador de carga |
NLB o hardware; se aceptan ambos |
NLB o hardware; se aceptan ambos |