Planejar a arquitetura de hardware no Project Server 2010
Aplica-se a: Project Server 2010
Tópico modificado em: 2015-03-09
Muitos fatores podem ter um efeito importante na taxa de transferência do Microsoft Project Server 2010. Esses fatores incluem o número de usuários; o tipo, a complexidade e a frequência de operações de usuário; o número de postbacks em uma operação e o desempenho das conexões de dados. Considere cuidadosamente os fatores discutidos nesta seção quando planejar sua arquitetura de hardware. O Project Server pode ser implantado e configurado de várias maneiras. Como resultado, não há uma maneira fácil de estimar quantos usuários poderão ter suporte de um determinado número de servidores. Dessa forma, conduza testes em seu próprio ambiente antes de implantar o Project Server 2010 em um ambiente de produção.
Este artigo descreve o desempenho e os limites de capacidade testados do Microsoft Project Server 2010, fornece informações sobre o ambiente de teste e os resultados do teste e oferece diretrizes para um desempenho aceitável. Use as informações neste artigo para estimar as metas de taxa de transferência para o Project Server.
Ao realizar o planejamento de capacidade para o Microsoft Project Server 2010, conheça as variáveis que podem afetar o desempenho de uma implantação do Project Server.
Devido ao farto conjunto de funcionalidades fornecido pelo Project Server, uma implantação parecida ao ser descrita em um nível superior pode diferir consideravelmente com relação às características de desempenho real. Não basta caracterizar suas demandas apenas pelo número de projetos ou pelo número de usuários que você terá no sistema. Pensar no desempenho de sua implantação do Project Server exige uma abordagem mais sutil e holística. Por exemplo, cargas de trabalho, e subsequentemente suas necessidades de hardware, serão diferentes com relação às seguintes variáveis:
| Fator | Características |
|---|---|
Projetos |
|
Usuários |
|
Padrões de uso |
|
Há muitas outras variáveis que podem afetar o desempenho em um determinado ambiente, cada uma dessas variáveis pode afetar o desempenho em áreas diferentes. Alguns dos resultados de teste e recomendações neste artigo podem estar relacionados aos recursos ou operações do usuário que não existem em seu ambiente e, portanto, não se aplicam à sua solução. Apenas o teste completo pode fornecer dados exatos relacionados ao seu próprio ambiente.
Outras variáveis a serem consideradas:
Simultaneidade de usuários: frequentemente, a carga de usuários simultâneos é um fator considerável na definição dos requisitos de capacidade. Talvez você tenha menos usuários no sistema, mas todos eles podem realizar transações com o servidor simultaneamente durante o "pico" de seus períodos de tráfego. Por exemplo, uma organização na qual todos os usuários enviam atualizações de status/folha de horas no mesmo período da semana provavelmente perceberá uma diminuição considerável no desempenho durante esses períodos. Se você tiver períodos de alta utilização, planeje adicionar outros recursos à topologia recomendada para seu conjunto de dados.
Divisão de funções do usuário: A distribuição de seus usuários entre Administradores, Administradores de portfólio, Gerentes de projeto e Membros da equipe afetará o desempenho de sua implantação na medida em que cada tipo de usuário tem acesso a uma quantidade diferente de dados. Os usuários em categorias de segurança diferentes podem variar de acordo com a quantidade de projetos e recursos que eles podem ver. Os Administradores, por exemplo, conseguem ver todos os projetos no servidor quando carregam a Central de Projetos e todos os recursos quando carregam a Central de Recursos. Em comparação, um Gerente de projetos verá apenas seus próprios projetos. O resultado é que esses usuários estão sujeitos a um desempenho reduzido. Quando possível, sugerimos a limitação do número de projetos, tarefas ou recursos exibidos em uma determinada visualização, definindo filtros apropriados nas visualizações definidas em Configurações do servidor>Gerenciar modos de exibição.
Distribuição global de usuários
Problemas, riscos e resultados finais: Ter uma quantidade maior dessas entidades pode sobrecarregar seu SQL Server. Em particular, é a ação de visualizar e interagir com essas entidades no site do Project que provavelmente cria a carga adicional. Se você usa muito esses recursos, convém alocar recursos adicionais à sua implantação do SQL Server a fim de manter um desempenho de alto nível. Pelo fato de esses artefatos e a funcionalidade de site do Project serem sites e listas do SharePoint, consulte a documentação sobre como expandir os sites e listas do SharePoint.
Calendários: é possível definir calendários personalizados para projetos, tarefas e recursos. Eles afetam bastante o mecanismo de agendamento, causando um uso elevado da CPU nos servidores de aplicativo e de banco de dados.
Conjuntos de dados típicos
Os conjuntos de dados descritos nesta seção são caracterizados pelas variáveis listadas e explicadas na tabela abaixo. Talvez essas variáveis não capturem todos os fatores que afetam o desempenho do Project Server (ou seja, não capturam a combinação de recursos que você tende a usar em sua implantação). No entanto, elas capturam grande parte das informações significativas para determinar a capacidade apropriada.
| Entidade | Descrição/Notas | Pequena | Média | Grande | |
|---|---|---|---|---|---|
1 |
Projetos |
100 |
5000 |
20000 |
|
1 |
Tarefas |
17125 |
856250 |
3425000 |
|
1 |
Média de tarefas por projeto |
171,25 |
171,25 |
171,25 |
|
2 |
Histórico de transação de tarefas |
O número de vezes que o status tende a ser enviado e aprovado para qualquer tarefa fornecida |
10 |
100 |
1000 |
1 |
Atribuições |
22263 |
1113125 |
4500000 |
|
1 |
Média de atribuições por tarefa |
1,3 |
1,3 |
1,3 |
|
2/3 |
Aprovações |
Atualizações pendentes por gerente |
50 |
600 |
3000 |
Usuários |
1000 |
10000 |
50000 |
||
Campos personalizados |
Projeto (Fórmula) |
3 |
20 |
25 |
|
Campos personalizados |
Projeto (Manual) |
2 |
40 |
50 |
|
Campos personalizados |
Tarefa (Fórmula) |
Os campos de fórmula da tarefa costumam afetar mais o desempenho, pois precisam ser computados para cada tarefa. |
6 |
12 |
15 |
Campos personalizados |
Tarefa (Manual) |
4 |
8 |
10 |
|
Campos personalizados |
Implementação de atribuição |
50% |
50% |
50% |
|
Campos personalizados |
Recurso |
10 |
20 |
25 |
|
Campos personalizados |
Campos personalizados da tabela de pesquisa |
2 |
15 |
100 |
|
1 |
Folhas de hora (por ano) |
Quanto mais você usa Folhas de hora, mais demandas por recurso são colocadas sobre o SQL Server |
52000 |
780000 |
8.320.000 |
1 |
Linhas da folha de hora |
5 |
10 |
10 |
Recomendações de hardware
As seções a seguir fornecem recomendações gerais de desempenho e de capacidade. Use essas recomendações para identificar uma topologia inicial adequada para seus requisitos e para decidir se você precisa realizar a escalabilidade horizontal ou vertical da topologia inicial.
Durante todo este artigo, nos referimos a três funções diferentes configuradas no Windows Server: a função de Servidor Web Front-End, a função de Servidor de Aplicativos e a função de Servidor de Banco de Dados (SQL). Todas elas são componentes de uma implantação completa do Project Server 2010. Os Servidores Web Front-End agem como a interface para os usuários acessarem o Project Server. O Servidor de Aplicativos lida com as solicitações para as camadas de dados do Project Server e implementa a lógica de negócios do Project Server 2010. Por fim, a camada de banco de dados é a fonte de dados, hospedando os bancos de dados do Project Server 2010. Para implantações pequenas, as funções de Servidor Web Front-End, Servidor de Aplicativos e Servidor de Banco de dados podem ser combinadas no mesmo computador físico. Para implantações maiores, talvez seja necessário separá-las em computadores diferentes, com até mesmo vários computadores físicos agindo na mesma função.
Recomendações de hardware para conjunto de dados pequenos
Esta seção sugere uma topologia recomendada para um dos tamanhos de conjunto de dados, pequeno, médio e grande, caracterizados anteriormente na seção "Conjuntos de dados típicos". As topologias recomendadas para cada conjunto de dados devem ser suficientes para a obtenção de um desempenho razoável com a maioria dos padrões de uso nesses tamanhos de conjunto de dados. No entanto, incentivamos que você leve em consideração as recomendações específicas fornecidas durante todo o resto deste artigo para determinar se você precisa expandir além da topologia recomendada para seu conjunto de dados aproximado. Em geral, você deve monitorar as métricas de desempenho de sua topologia e escalá-la de adequadamente, caso não esteja satisfeito com as características do desempenho.
Observe que como o Project Server 2010 coexiste com o SharePoint Server 2010, ele usa recursos adicionais (processador, RAM e disco rígido). Os requisitos especificados para o SharePoint Server 2010 também são válidos para uma instalação do Project Server 2010 com um pequeno conjunto de dados e pouco uso. No entanto, para obter conjuntos de dados e padrões de uso mais substanciais, outros recursos de hardware são exigidos. Para implantação em um computador autônomo, com um pequeno conjunto de dados, aconselhamos 16 GB de RAM para assegurar um alto nível de desempenho percebido. Além disso, se possível, recomendamos a separação de seu Servidor de banco de dados das camadas de Aplicativo e Web Front-End colocando seus bancos de dados em um computador dedicado e com o SQL Server em execução.
A tabela abaixo lista as especificações para um único servidor com instalações de banco de dados integradas e instalações de farm de servidores que incluem um único servidor ou múltiplos servidores no farm.
Servidor Web Front-end/de Aplicativos
| Componente | Recomendado |
|---|---|
Processador |
64 bits, quatro-core, 2.5 gigahertz (GHz) no mínimo por core |
RAM |
4 GB para uso de desenvolvedor ou de avaliação, 8 GB para instalação de um farm com um único servidor ou com múltiplos servidores para uso de produção |
Disco rígido |
80 GB |
SQL Server
| Componente | Recomendado |
|---|---|
Processador |
64 bits, quatro-core, 2.5 GHz no mínimo por core. (Se o tamanho de seu conjunto de dados for consideravelmente maior do que o conjunto de dados médio, oito cores será o recomendado.) |
RAM |
4 GB para uso de desenvolvedor ou de avaliação, 8 GB para instalação de um farm de servidor único e de múltiplos servidores para uso de produção |
Disco rígido |
80 GB |
Recomendações de hardware para conjunto de dados médio
Os requisitos mínimos especificados para conjuntos médios podem ser escalados horizontal e verticalmente a fim de lidar com a carga adicional. As topologias escaladas vertical e horizontalmente discutem as considerações sobre como lidar com a carga de usuário e a carga de dados cada vez maiores.
Como uma receita geral, você deve se preparar para lidar com a carga de usuário e a carga de dados adicionais tendo computadores suficientes para adicionar servidores Web Front-End e Servidores de aplicativo à sua topologia. As especificações de hardware de seus servidores Web Front-End e Servidores de aplicativo podem permanecer em grande parte as mesmas. Uma topologia 4 × 2 × 1 deve ser suficiente para lidar com as necessidades da maioria dos conjuntos de dados médio e os padrões de uso. A escala horizontal de seus Servidores de aplicativo e Web Front-End acrescentará mais carga à sua implantação do SQL Server e você deverá compensá-la adicionando mais memória e recursos de CPU. A seguinte especificação de SQL Server deve ser capaz de lidar com as necessidades de desempenho da maioria dos conjuntos de dados médio. A melhor maneira de identificar se a topologia projetada por você satisfaz suas necessidades de desempenho é definir um ambiente de preparo para testar sua topologia e monitorar as características do desempenho.
Servidor Web front-end
| Componente | Recomendado |
|---|---|
Processador |
64 bits, quatro-core, 2.5 GHz no mínimo por core |
RAM |
4 GB para uso de desenvolvedor ou de avaliação, 8 GB para instalação de um farm de servidor único e de múltiplos servidores para uso de produção |
Disco rígido |
80 GB |
Servidor de aplicativos
| Componente | Recomendado |
|---|---|
Processador |
64 bits, quatro-core, 2.5 GHz no mínimo por core |
RAM |
4 GB para uso de desenvolvedor ou de avaliação, 8 GB para instalação de um farm de servidor único e de múltiplos servidores para uso de produção |
Disco rígido |
80 GB |
SQL Server
| Componente | Recomendado |
|---|---|
Processador |
64 bits, oito-core, 2.5 GHz no mínimo por core. (Se o tamanho de seu conjunto de dados for consideravelmente maior do que o conjunto de dados médio, oito cores será o recomendado.) |
RAM |
32 GB |
Disco rígido |
160 GB |
Recomendações de hardware para conjunto de dados grande
Para conjuntos de dados grandes, a carga de dados é o afunilamento de desempenho mais substancial.
Geralmente, considerando o mínimo para conjuntos de dados grandes, convém usar uma topologia 4 × 2 × 1. Geralmente, as características de hardware dos Servidores Web Front-End e de aplicativo podem permanecer as mesmas que as recomendadas para os conjuntos de dados pequenos e médios. No entanto, como a instalação do SQL Server será o afunilamento, talvez você perceba que isso restringe sua habilidade de escalar horizontalmente para Servidores adicionais Web Front-End e de aplicativo. Se você perceber que a carga de dados é seu afunilamento, talvez você perceba também que Servidores adicionais Web Front-End e de aplicativo não produzem um aprimoramento na taxa de transferência.
Para conjuntos de dados grandes, se a instância do SharePoint Server 2010 com a qual o Project Server 2010 está coexistindo também estiver sendo bastante utilizada (ou seja, você não estiver usando essa implantação do SharePoint Server 2010 especificamente para a funcionalidade do Project Server 2010), recomendamos a separação dos quatro bancos de dados do Project Server 2010 dos bancos de dados de conteúdo do SharePoint Server 2010, colocando-os em sua própria instância do SQL Server.
Pelo fato de a taxa de transferência de dados ser o afunilamento, você deve investir em recursos adicionais na camada do SQL Server de sua topologia. É possível “escalar verticalmente” sua instalação do SQL Server adicionando recursos de RAM, CPU e de disco rígido. Nas seções a seguir, listamos as especificações mínimas e recomendadas para a camada do SQL Server e de uma topologia de conjunto de dados grande.
Requisitos mínimos do SQL Server
| Componente | Recomendado |
|---|---|
Processador |
64 bits, oito-core, 2.5 GHz no mínimo por core. (Se o tamanho de seu conjunto de dados for consideravelmente maior do que o conjunto de dados médio, oito cores será o recomendado.) |
RAM |
32 GB |
Disco rígido |
250 GB |
Requisitos recomendados do SQL Server
| Componente | Recomendado |
|---|---|
Processador |
64 bits, oito-core, 2.5 GHz no mínimo por core. (Se o tamanho de seu conjunto de dados for consideravelmente maior do que o conjunto de dados médio, oito cores será o recomendado.) |
RAM |
64 GB |
Disco rígido |
300 GB ou mais. Coloque seu banco de dados de relatório em um servidor de banco de dados separado. Da maneira ideal, você deve preparar e priorizar dados entre discos. Coloque seus arquivos de dados e seus logs de transação do SQL Server 2008 em discos rígidos físicos separados. O RAID 5 deve fornecer um equilíbrio adequado entre confiabilidade e taxa de transferência. |
Recomendações de virtualização
O Project Server 2010 não suporta a execução em máquinas virtualizadas. A maioria das orientações fornecidas para virtualização do SharePoint Server 2010 também se aplica ao Project Server 2010. Para obter a documentação sobre virtualização no SharePoint Server 2010, consulte Planejamento da virtualização (SharePoint Server 2010). Consulte também o Guia de virtualização do Project Server 2007 para obter informações adicionais sobre a virtualização e o Project Server 2010, uma vez que grande parte dessa orientação ainda é aplicável. No entanto, assim como ocorre em qualquer situação na qual a virtualização é aplicada, é importante considerar a contenção de recursos do computador físico entre as máquinas virtualizadas em execução na mesma instância física.
Observação
Não recomendamos a execução do SQL Server em uma máquina virtualizada. A competição por recursos em uma máquina virtualizada pode diminuir consideravelmente o desempenho do servidor. Se você precisar executar o SQL Server em um ambiente virtualizado, recomendamos o uso das seguintes configurações:
-
Adaptador de rede:
-
Se você estiver usando a virtualização do Hyper-V, use o adaptador de rede virtual em vez do adaptador de rede herdado.
-
-
Disco virtual:
-
Para a máquina virtual na qual você está executando o SQL Server, recomendamos a seleção da opção de “passagem” para o tipo de disco (em vez de dinâmico ou fixo). Se essa não for uma opção, use um tamanho de disco fixo em vez de um disco virtual com tamanho dinâmico.
-
Recomendamos a seleção de IDE em vez de SCSI para sua unidade de inicialização
-
Aloque espaço suficiente no disco rígido para lidar com o tamanho máximo esperado de seu conjunto de dados e demandas de registro em log do ULS.
-
-
Memória:
-
Aloque o máximo possível de memória à máquina virtual que está executando o SQL. Isso deve ser comparável à quantidade de memória necessária/recomendada para servidores físicos ate atendem à mesma função.
-
No mínimo 2 GB de memória devem ser reservados para o Sistema operacional host.
-
A execução de Servidores Web Front-End ou de aplicativo em ambientes virtualizados costuma não prejudicar o desempenho da execução do SQL Server em um ambiente virtualizado.
Requisitos de rede
Para a maioria das implantações do Project Server, a largura de banda não costuma ser o afunilamento do desempenho. A tabela abaixo lista as especificações recomendadas de componentes de rede. Um objetivo geral deve ser manter uma latência baixa entre as camadas de Aplicativo e do SQL Server.
| Componente | Conjuntos de dados pequeno e médio | Conjuntos de dados grandes |
|---|---|---|
Número de NICs |
1 |
2 |
Velocidade do #NIC (Rede) |
Qualquer velocidade superior a 100mbps deve funcionar bem |
1 GB/s |
Tipo de balanceador de carga |
NLB ou hardware; ambos são aceitáveis |
NLB ou hardware; ambos são aceitáveis |