Pianificare l'architettura hardware in Project Server 2010
Si applica a: Project Server 2010
Ultima modifica dell'argomento: 2015-03-09
Numerosi fattori possono avere un effetto significativo sulla velocità effettiva in Microsoft Project Server 2010. Questi fattori includono il numero di utenti, il tipo, la complessità e la frequenza delle operazioni utente, il numero di postback in un'operazione e le prestazioni della connessione dati. Considerare con attenzione i fattori discussi in questa sezione quando si pianifica l'architettura hardware. È possibile distribuire e configurare Project Server in molti modi diversi. Non esiste pertanto una soluzione semplice per stimare il numero di utenti che possono essere supportati da un determinato numero di server. È quindi necessario eseguire test nel proprio ambiente prima di distribuire Project Server 2010 in un ambiente di produzione.
In questo articolo vengono descritti i limiti di capacità e prestazioni testati per Microsoft Project Server 2010, vengono fornite informazioni sull'ambiente di test e sui risultati dei test e vengono indicate alcune linee guida per ottenere prestazioni accettabili. Utilizzare le informazioni in questo articolo per stimare gli obiettivi di velocità effettiva per Project Server.
Quando si pianifica la capacità per Microsoft Project Server 2010, prestare attenzione alle variabili che possono influire sulle prestazioni di una distribuzione di Project Server.
Poiché Project Server offre un'ampia gamma di funzionalità, distribuzioni che sembrano simili quando descritte a livello generale possono differire significativamente nelle prestazioni effettive. Non è sufficiente caratterizzare le richieste solo in base al numero di progetti o di utenti che saranno presenti nel sistema. Per valutare le prestazioni di una distribuzione di Project Server è necessario un approccio più sfaccettato e olistico. I carichi di lavoro, e conseguentemente le esigenze relative all'hardware, differiscono ad esempio in relazione alle variabili seguenti:
| Fattore | Caratteristiche |
|---|---|
Progetti |
|
Utenti |
|
Modelli di utilizzo |
|
Vi sono numerose variabili che, in aree diverse, possono influire sulle prestazioni in un determinato ambiente. Alcuni dei consigli e dei risultati dei test inclusi in questo articolo potrebbero essere correlati a caratteristiche o operazioni degli utenti che non riguardano l'ambiente in uso e pertanto non si applicano alla soluzione specifica. Per ottenere dati precisi relativi all'ambiente in uso, è in ogni caso fondamentale effettuare test accurati.
Di seguito sono elencate altre variabili da considerare:
Concorrenza degli utenti: il carico utente concorrente è spesso un fattore significativo per la definizione dei requisiti di capacità. Nel sistema potrebbe essere presente un numero minore di utenti, ma tali utenti potrebbero eseguire tutti transazioni con il server contemporaneamente durante i periodi di picco del traffico. In un'organizzazione, ad esempio, in cui tutti gli utenti inviano aggiornamenti delle schede attività o dello stato nello stesso momento della settimana, si noterà con ogni probabilità un sostanziale peggioramento delle prestazioni durante tali periodi. Se vi sono periodi di grande picco di utilizzo, pianificare l'aggiunta di ulteriori risorse alla topologia consigliata per il set di dati.
Suddivisione dei ruoli utente: la distribuzione degli utenti tra amministratori, amministratori di portfolio, project manager e membri del team influisce sulle prestazioni in quanto ogni tipo di utente dispone di accesso a una diversa quantità di dati. Gli utenti in categorie di sicurezza diverse possono differire relativamente al numero di progetti e risorse che possono visualizzare. Gli amministratori, ad esempio, possono visualizzare tutti i progetti nel server quando caricano il centro Progetti e tutte le risorse quando caricano il centro Risorse, mentre un project manager può visualizzare solo i suoi progetti. Di conseguenza, questi utenti sono soggetti a una diminuzione delle prestazioni percepite. Quando possibile, è consigliabile limitare il numero di progetti, attività o risorse presenti in una visualizzazione specifica definendo filtri appropriati nelle visualizzazioni in Impostazioni server > Gestisci visualizzazioni.
Distribuzione globale degli utenti
Problemi, rischi e risultati finali: un elevato numero di questi elementi può comportare carico aggiuntivo in SQL Server. In particolare, la visualizzazione di queste entità e l'interazione con esse nel sito di Project comporta con ogni probabilità la creazione di carico aggiuntivo. Se si utilizzano molto queste caratteristiche, potrebbe essere necessario allocare risorse aggiuntive per la distribuzione di SQL Server per garantire un elevato livello di prestazioni. Poiché questi elementi della struttura del sito e le funzionalità del sito di Project sono elenchi e siti di SharePoint, consultare la documentazione relativa alla scalabilità di elenchi e siti di SharePoint.
Calendari: è possibile definire calendari personalizzati per progetti, attività e risorse. Questi elementi hanno un'influenza notevole sul motore di programmazione, in quanto comportano un maggiore utilizzo della CPU nei server applicazioni e database.
Set di dati tipici
I set di dati descritti in questa sezione sono caratterizzati dalle variabili elencate e illustrate nella tabella seguente. Queste variabili potrebbero non comprendere tutti i fattori che influiscono sulle prestazioni di Project Server, ovvero potrebbero non comprendere la combinazione di caratteristiche utilizzate nella distribuzione, ma includono tuttavia molte informazioni significative per la determinazione della capacità appropriata.
| Entità | Descrizione/Note | Piccole dimensioni | Medie dimensioni | Grandi dimensioni | |
|---|---|---|---|---|---|
1 |
Progetti |
100 |
5.000 |
20.000 |
|
1 |
Attività |
17.125 |
856.250 |
3.425.000 |
|
1 |
Numero medio di attività per progetto |
171,25 |
171,25 |
171,25 |
|
2 |
Cronologia transazioni attività |
Numero di volte in cui lo stato viene inviato e approvato per una determinata attività |
10 |
100 |
1.000 |
1 |
Assegnazioni |
22.263 |
1.113.125 |
4.500.000 |
|
1 |
Numero medio di assegnazioni per attività |
1,3 |
1,3 |
1,3 |
|
2/3 |
Approvazioni |
Aggiornamenti in sospeso per manager |
50 |
600 |
3.000 |
Utenti |
1.000 |
10.000 |
50.000 |
||
Campi personalizzati |
Progetto (formula) |
3 |
20 |
25 |
|
Campi personalizzati |
Progetto (manuale) |
2 |
40 |
50 |
|
Campi personalizzati |
Attività (formula) |
I campi formula delle attività tendono a essere quelli con maggiore influenza sulle prestazioni in quanto devono essere calcolati per ogni attività. |
6 |
12 |
15 |
Campi personalizzati |
Attività (manuale) |
4 |
8 |
10 |
|
Campi personalizzati |
Riporto assegnazione |
50% |
50% |
50% |
|
Campi personalizzati |
Risorsa |
10 |
20 |
25 |
|
Campi personalizzati |
Campi personalizzati tabella di ricerca |
2 |
15 |
100 |
|
1 |
Schede attività (per anno) |
Maggiore è l'utilizzo delle schede attività, maggiore è la richiesta di risorse in SQL Server |
52.000 |
780.000 |
8.320.000 |
1 |
Righe delle schede attività |
5 |
10 |
10 |
Consigli per i componenti hardware
Nelle sezioni seguenti vengono indicati consigli di carattere generale sulle prestazioni e sulla capacità. Utilizzare questi consigli per identificare una topologia iniziale appropriata in base ai requisiti e stabilire se è necessario implementare la scalabilità orizzontale o verticale nella topologia iniziale.
In questo articolo viene fatto riferimento a tre diversi ruoli configurati in Windows Server: il ruolo del server Web front-end, il ruolo del server applicazioni e il ruolo del server (SQL) database. Questi rappresentano tutti i componenti di una distribuzione completa di Project Server 2010. I server Web front-end fungono da interfaccia per gli utenti che accedono a Project Server. Il server applicazioni provvede alla gestione delle richieste al livello dati di Project Server e all'implementazione della regola business di Project Server 2010. Il livello database, infine, corrisponde all'origine dati in cui sono presenti i database di Project Server 2010. Per le distribuzioni di piccole dimensioni, i ruoli del server Web front-end, del server applicazioni e del server database possono essere combinati nello stesso computer fisico. Per le distribuzioni di dimensioni maggiori, potrebbe essere necessario separare questi ruoli in computer distinti, anche con più computer fisici che ricoprono lo stesso ruolo.
Consigli per i componenti hardware per set di dati di piccole dimensioni
In questa sezione viene suggerita una topologia consigliata per ognuno dei set di dati di piccole, medie e grandi dimensioni descritti in precedenza nella sezione "Set di dati tipici". Le topologie consigliate per ogni set di dati dovrebbero essere sufficienti a garantire prestazioni ragionevoli con la maggior parte dei modelli di utilizzo per le dimensioni specifiche del set di dati. È tuttavia consigliabile prendere in considerazione i consigli specifici illustrati nella parte rimanente di questo articolo per determinare se è necessario espandere ulteriormente la topologia consigliata per il set di dati approssimativo. In generale, è consigliabile monitorare i livelli di prestazioni della topologia e ampliarla di conseguenza se non si è soddisfatti dei risultati.
Si noti che la coesistenza di Project Server 2010 con SharePoint Server 2010 comporta l'utilizzo di risorse aggiuntive (processore, RAM e disco rigido). I requisiti consigliati per SharePoint Server 2010 sono validi anche per un'installazione di Project Server 2010 con un set di dati di piccole dimensioni e un utilizzo poco intensivo. Per set di dati e modelli di utilizzo più sostanziali, sono necessarie ulteriori risorse hardware. Per una distribuzione in un computer autonomo, con un set di dati di piccole dimensioni, è consigliabile disporre di 16 GB di RAM per garantire un livello elevato di prestazioni percepite. Oltre a questo, se possibile, è consigliabile separare il server di database dai livelli applicazioni e Web front-end posizionando i database in un computer dedicato che esegue SQL Server.
Nella tabella seguente sono elencate le specifiche per installazioni a server singolo con database incorporato e per installazioni di server farm che includono un server singolo o più server nella farm.
Server applicazioni/Web front-end
| Componente | Risorse consigliate |
|---|---|
Processore |
64 bit, quad core, 2,5 gigahertz (GHz) minimi per core |
RAM |
4 GB per l'utilizzo a scopo di sviluppo o valutazione, 8 GB per le installazioni a server singolo e in farm con più server per l'utilizzo a scopo di produzione |
Disco rigido |
80 GB |
SQL Server
| Componente | Risorse consigliate |
|---|---|
Processore |
64 bit, quad core, 2,5 GHz minimi per core (se il set di dati è notevolmente più grande rispetto al set di dati di medie dimensioni, sono consigliabili otto core). |
RAM |
4 GB per l'utilizzo a scopo di sviluppo o valutazione, 8 GB per le installazioni a server singolo e in farm con più server per l'utilizzo a scopo di produzione |
Disco rigido |
80 GB |
Consigli per i componenti hardware per set di dati di medie dimensioni
Ai requisiti minimi specificati per i set di dati di medie dimensioni è possibile applicare scalabilità orizzontale e verticale per consentire la gestione di carichi aggiuntivi. Le topologie con scalabilità verticale e orizzontale prevedono alcune considerazioni sulla gestione di carichi utente e carichi di dati maggiori.
In generale, è consigliabile essere preparati alle gestione di carichi utente e carichi di dati aggiuntivi avendo a disposizione un numero sufficiente di computer per l'aggiunta di server Web front-end e server applicazioni alla topologia. Le specifiche hardware dei server Web front-end e dei server applicazioni possono rimanere in gran parte analoghe. Una topologia 4 × 2 × 1 dovrebbe essere sufficiente per la gestione delle esigenze della maggior parte dei set di dati e dei modelli di utilizzo di medie dimensioni. L'aggiunta di server applicazioni e server Web front-end comporterà un carico aggiuntivo nella distribuzione di SQL Server, che sarà necessario compensare tramite l'aggiunta di ulteriori risorse CPU e memoria. La specifica seguente per SQL Server dovrebbe consentire la gestione delle esigenze in termini di prestazioni per la maggior parte dei set di dati di medie dimensioni. Il modo migliore per identificare se la topologia progettata soddisfa le esigenze in termini di prestazioni consiste nel configurare un ambiente di gestione temporanea per testare la topologia e monitorare le prestazioni.
Server Web front-end
| Componente | Risorse consigliate |
|---|---|
Processore |
64 bit, quad core, 2,5 GHz minimi per core |
RAM |
4 GB per l'utilizzo a scopo di sviluppo o valutazione, 8 GB per le installazioni a server singolo e in farm con più server per l'utilizzo a scopo di produzione |
Disco rigido |
80 GB |
Server applicazioni
| Componente | Risorse consigliate |
|---|---|
Processore |
64 bit, quad core, 2,5 GHz minimi per core |
RAM |
4 GB per l'utilizzo a scopo di sviluppo o valutazione, 8 GB per le installazioni a server singolo e in farm con più server per l'utilizzo a scopo di produzione |
Disco rigido |
80 GB |
SQL Server
| Componente | Risorse consigliate |
|---|---|
Processore |
64 bit, otto core, 2,5 GHz minimi per core (se il set di dati è notevolmente più grande rispetto al set di dati di medie dimensioni, sono consigliabili otto core). |
RAM |
32 GB |
Disco rigido |
160 GB |
Consigli per i componenti hardware per set di dati di grandi dimensioni
Per i set di dati di grandi dimensioni, il carico di dati rappresenta il maggiore collo di bottiglia per le prestazioni.
In genere, per i set di dati di grandi dimensioni, è necessaria almeno una topologia 4 × 2 × 1. Le caratteristiche hardware dei server applicazioni e Web front-end possono in genere rimanere analoghe a quelle consigliate per i set di dati di piccole e medie dimensioni. Considerando tuttavia che l'installazione di SQL Server rappresenta il collo di bottiglia, questa potrebbe essere considerata una limitazione per l'aggiunta di ulteriori server applicazioni e Web front-end. Se si ritiene che il collo di bottiglia sia costituito dal carico di dati, l'aggiunta di server applicazioni e Web front-end potrebbe non comportare un miglioramento della velocità effettiva.
Per i set di dati di grandi dimensioni, se anche l'istanza di SharePoint Server 2010 con cui coesiste Project Server 2010 viene utilizzata in modo intensivo, ovvero se non si utilizza la distribuzione di SharePoint Server 2010 in modo specifico per le funzionalità di Project Server 2010, è consigliabile separare i quattro database di Project Server 2010 dal database del contenuto di SharePoint Server 2010, collocandoli in un'istanza dedicata di SQL Server.
Poiché il collo di bottiglia sarà rappresentato dalla velocità effettiva dei dati, è consigliabile investire in risorse aggiuntive al livello SQL Server della topologia. È possibile implementare la scalabilità verticale nell'installazione di SQL Server aggiungendo risorse in termini di RAM, CPU e disco rigido. Nelle sezioni seguenti vengono elencate le specifiche minime e consigliate per il livello SQL Server di una topologia con set di dati di grandi dimensioni.
Requisiti minimi per SQL Server
| Componente | Risorse consigliate |
|---|---|
Processore |
64 bit, otto core, 2,5 GHz minimi per core (se il set di dati è notevolmente più grande rispetto al set di dati di medie dimensioni, sono consigliabili otto core). |
RAM |
32 GB |
Disco rigido |
250 GB |
Requisiti consigliati per SQL Server
| Componente | Risorse consigliate |
|---|---|
Processore |
64 bit, otto core, 2,5 GHz minimi per core (se il set di dati è notevolmente più grande rispetto al set di dati di medie dimensioni, sono consigliabili otto core). |
RAM |
64 GB |
Disco rigido |
300 GB o superiore. Collocare il database delle relazioni in un server di database distinto. Idealmente, è consigliabile separare i dati e assegnarne le priorità tra dischi. Collocare i file di dati e i log delle transazioni di SQL Server 2008 in dischi rigidi fisici distinti. RAID 5 rappresenta un buon compromesso tra affidabilità e velocità effettiva. |
Consigli per la virtualizzazione
Project Server 2010 supporta l'esecuzione in macchine virtualizzate. La maggior parte dei consigli relativi alla virtualizzazione di SharePoint Server 2010 si applica anche a Project Server 2010. Per la documentazione relativa alla virtualizzazione in SharePoint Server 2010, vedere Pianificazione della virtualizzazione (SharePoint Server 2010). È inoltre possibile fare riferimento alla guida alla virtualizzazione di Project Server 2007 per ulteriori informazioni sulla virtualizzazione e su Project Server 2010, in quanto la maggior parte dei consigli è comunque appropriata. Come in ogni situazione in cui viene utilizzata la virtualizzazione, tuttavia, è importante considerare i conflitti per le risorse fisiche del computer tra le macchine virtualizzate in esecuzione nella stessa istanza fisica.
Nota
Non è consigliabile eseguire SQL Server in una macchina virtualizzata. Il conflitto per le risorse in una macchina virtualizzata può ridurre notevolmente le prestazioni del server. Se è necessario eseguire SQL Server in un ambiente virtualizzato, è consigliabile utilizzare le impostazioni seguenti:
-
Scheda di rete:
-
Se si utilizza la virtualizzazione Hyper-V, utilizzare la scheda di rete virtuale anziché la scheda di rete legacy.
-
-
Disco virtuale:
-
Per la macchina virtuale in cui è in esecuzione SQL Server, è consigliabile selezionare l'opzione pass-through per il tipo di disco (anziché dinamico o fisso). Se questo non è possibile, utilizzare un disco con dimensione fissa anziché un disco virtuale ridimensionato dinamicamente.
-
È consigliabile selezionare IDE su SCSI per l'unità di avvio.
-
Allocare spazio sufficiente sul disco rigido per gestire le dimensioni massime previste del set di dati e le richieste di registrazione ULS.
-
-
Memoria:
-
Allocare la massima quantità di memoria possibile alla macchina virtuale in cui è in esecuzione SQL Server. Questa quantità deve essere paragonabile alla quantità di memoria richiesta/consigliata per i server fisici che adempiono alla stessa funzione.
-
Riservare almeno 2 GB di memoria per il sistema operativo host.
-
L'esecuzione di server applicazioni e Web front-end in ambienti virtualizzati non è in genere pregiudizievole per le prestazioni di esecuzione di SQL Server in un ambiente virtualizzato.
Requisiti di rete
Per la maggior parte delle distribuzioni di Project Server, la larghezza di banda tende a non rappresentare un collo di bottiglia per le prestazioni. Nella tabella seguente sono elencate le specifiche consigliate per i componenti di rete. L'obiettivo generale deve essere quello di mantenere una bassa latenza tra il livello applicazioni e il livello SQL Server.
| Componente | Set di dati di piccole e medie dimensioni | Set di dati di grandi dimensioni |
|---|---|---|
Numero di schede di interfaccia di rete (NIC) |
1 |
2 |
Velocità schede NIC (rete) |
Qualsiasi velocità superiore a 100 mbps è adeguata |
1 GB/s |
Tipo di servizio di bilanciamento del carico |
Bilanciamento carico di rete (NLB) o hardware, entrambi sono accettabili |
Bilanciamento carico di rete (NLB) o hardware, entrambi sono accettabili |