Pianificazione della capacità per SharePoint Server 2010

Articolo
03/05/2017

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

In questo articolo viene descritto come pianificare la capacità di una farm di Microsoft SharePoint Server 2010. Dopo aver valutato e acquisto familiarità con la pianificazione e la gestione della capacità, è possibile applicare le nozioni acquisite al dimensionamento del sistema. Per dimensionamento si intende la selezione e la configurazione dell'architettura di dati, della topologia logica e fisica e dei componenti hardware appropriati per la piattaforma di una soluzione. È necessario tenere conto di alcune considerazioni sulla gestione e l'utilizzo della capacità che influiscono sulla determinazione dei componenti hardware e delle opzioni di configurazione più appropriati.

Prima di leggere questo articolo, vedere Panoramica del dimensionamento e della gestione della capacità per SharePoint Server 2010.

In questo articolo vengono descritte le operazioni da eseguire per una gestione efficace della capacità di un ambiente. Per la corretta esecuzione di ogni passaggio sono necessarie alcune informazioni. Ogni passaggio restituisce una serie di risultati finali che verranno utilizzati al passaggio successivo. I requisiti e i risultati finali di ogni passaggio sono evidenziati in tabelle.

Contenuto dell'articolo:

Passaggio 1: modellare
Passaggio 2: progettare
Passaggio 3: eseguire la distribuzione pilota, i test e l'ottimizzazione
Passaggio 4: distribuire
Passaggio 5: monitorare e gestire

Passaggio 1: modellare

La modellazione di un ambiente basato su SharePoint Server 2010 inizia con l'analisi delle soluzioni esistenti e con la valutazione dei requisiti previsti e degli obiettivi della distribuzione di cui si sta pianificando la configurazione. Per iniziare è necessario raccogliere informazioni sulla base di utenti, i requisiti per i dati, nonché gli obiettivi di latenza e velocità effettiva e quindi documentare le caratteristiche di SharePoint Server che si desidera distribuire. Utilizzare questa sezione per ottenere informazioni sui dati che devono essere raccolti, sulla modalità con cui raccoglierli e sul relativo utilizzo nei passaggi successivi.

Informazioni sul carico di lavoro e il set di dati previsti

Per un dimensionamento appropriato di un'implementazione di SharePoint Server 2010 è necessario studiare e conoscere le caratteristiche dei requisiti che verranno presumibilmente gestite dalla soluzione. Per conoscere i requisiti, è necessario essere in grado di descrivere sia le caratteristiche del carico di lavoro, ad esempio il numero di utenti e le operazioni utilizzate con maggiore frequenza, che le caratteristiche del set di dati, ad esempio le dimensioni e la distribuzione del contenuto.

Questa sezione è utile per conoscere alcuni parametri e metriche specifici di cui è consigliabile raccogliere i valori, nonché i meccanismi in base a quali raccogliere questi dati.

Carico di lavoro

Il carico di lavoro descrive i requisiti che dovranno essere soddisfatti dal sistema, la base di utenti e le caratteristiche di utilizzo. Nella tabella riportata di seguito vengono elencate alcune metriche chiave utili per determinare il carico di lavoro. È possibile utilizzare questa tabella per prendere nota dei valori di queste metriche durante la raccolta dei dati.

Caratteristiche del carico di lavoro	Valore
Media di richieste al secondo giornaliere
Media di richieste al secondo nelle ore di punta
Numero totale di utenti univoci al giorno
Media giornalieri utenti simultanei
Picco utenti simultanei nelle ore di punta
Numero totale di richieste al giorno
Distribuzione del carico di lavoro previsto	N. di richieste al giorno
Web Browser - Ricerca per indicizzazione
Web Browser - Interazione collaborazione generale
Web Browser - Interazione social networking
Web Browser - Interazione generale
Web Browser - Office Web Apps
Client di Office
Client OneNote
SharePoint Workspace
Sincronizzazione RSS di Outlook
Outlook Social Connector
Altre interazioni (applicazioni personalizzate/servizi Web)

Utenti simultanei. La procedura più comune per misurare la concorrenza delle operazioni eseguite nella server farm consiste nel calcolare il numero di singoli utenti che generano richieste in un determinato intervallo di tempo. Le metriche chiave sono rappresentate dalla media giornaliera e dal carico di utenti simultanei nelle ore di punta.
Richieste al secondo (RPS). RPS è un indicatore comune utilizzato per descrivere la domanda per la server farm espressa nel numero di richieste elaborate dalla farm al secondo, senza tuttavia differenziare i tipi o le dimensioni delle richieste. La base di utenti di ogni organizzazione genera un carico sul sistema con una frequenza che dipende dalle caratteristiche di utilizzo univoche dell'organizzazione. Per ulteriori informazioni su questo termine, vedere la sezione Glossario in Panoramica del dimensionamento e della gestione della capacità per SharePoint Server 2010.
Totale richieste giornaliere. Il totale delle richieste giornaliere è un buon indicatore del carico globale che dovrà essere gestito dal sistema. È procedura comune misurare tutte le richieste tranne le richieste di handshake dell'autenticazione (stato HTTP 401) per un periodo di 24 ore.
Totale utenti giornalieri. Il totale degli utenti è un altro indicatore chiave del carico globale che dovrà essere gestito dal sistema. Questa misura corrisponde al numero effettivo di utenti univoci in un periodo di 24 ore e non al numero totale di dipendenti dell'organizzazione.

Nota

Il numero totale di utenti giornalieri può indicare il potenziale di crescita del carico della farm. Se ad esempio il numero di utenti potenziali è 100.000 dipendenti, un risultato di 15.000 utenti giornalieri indica che il carico può crescere in modo significativo nel tempo con l'aumento dell'adozione della tecnologia da parte degli utenti.
Distribuzione del carico di lavoro. La conoscenza della distribuzione delle richieste basate sulle applicazioni client che interagiscono con la farm consente di prevedere i cambiamenti di tendenza e di carico dopo la migrazione a SharePoint Server 2010. Con l'adozione da parte degli utenti di versioni client più recenti, ad esempio Office 2010, e l'utilizzo delle nuove funzionalità e dei nuovi modelli di carico, è previsto un aumento delle richieste al secondo e delle richieste totali. Per ogni client è possibile descrivere il numero di singoli utenti che lo utilizzeranno in un determinato intervallo di tempo del giorno e la quantità di richieste totali generate dal client o dalle funzionalità sul server.

Nel grafico seguente ad esempio viene mostrato uno snapshot di un ambiente Microsoft interno attivo che gestisce una soluzione di social networking tipica. In questo esempio è possibile osservare come la maggior parte del carico sia generata dal crawler di ricerca e dall'esplorazione Web dell'utente finale. È inoltre possibile osservare il carico significativo introdotto dalla nuova caratteristica Outlook Social Connector (6,2% delle richieste).

Distribuzione tipica del carico giornaliero delle richieste

Valutazione del carico di lavoro della produzione

Per calcolare la velocità effettiva richiesta che deve poter essere sostenuta dalla farm, valutare inizialmente la combinazione di transazioni che verranno utilizzate nella farm. Analizzare innanzitutto le transazioni utilizzate più frequentemente che verranno gestite dal sistema, valutando la frequenza con cui verranno utilizzate e da parte di quanti utenti. In questo modo sarà possibile verificare successivamente se la farm è in grado di sostenere questo carico nel testing di pre-produzione.

Nella figura seguente viene illustrata la relazione tra carico di lavoro e carico del sistema:

Capacità - Diagramma carico di lavoro

Per calcolare il carico di lavoro previsto, raccogliere le informazioni seguenti:

Identificare le interazioni degli utenti, ad esempio le esplorazioni tipiche di pagine Web, i download e i caricamenti di file, le visualizzazioni e le modifiche di Office Web Apps nel browser, le interazioni di creazione condivisa, le sincronizzazioni di siti di SharePoint Workspace, gli utilizzi di Outlook Social Connector, la sincronizzazione RSS (in Outlook o in altri visualizzatori), le trasmissioni di PowerPoint e l'utilizzo di blocchi appunti condivisi di OneNote, di cartelle di lavoro condivise di Excel Services, di applicazioni condivise di Access Services e così via. Per ulteriori informazioni, vedere la sezione Servizi e caratteristiche nell'articolo Panoramica del dimensionamento e della gestione della capacità per SharePoint Server 2010. Concentrarsi sull'identificazione delle interazioni univoche per la distribuzione desiderata e individuare l'impatto previsto di tale carico. Possono essere esempi significativi l'utilizzo di InfoPath Forms, Servizi di calcolo Excel e soluzioni dedicate simili.
Identificare le operazioni del sistema, ad esempio le ricerche per indicizzazione incrementali, i backup giornalieri, i processi timer di sincronizzazione dei profili, l'elaborazione di Web Analytics, la registrazione dei processi timer e così via.
Calcolare il numero totale di utenti giornalieri che presumibilmente utilizzeranno ogni funzionalità, dedurre il numero di utenti simultanei previsti e le richieste al secondo di livello elevato. Sarà necessario suggerire alcune ipotesi, ad esempio la concorrenza attuale e il fattore di RPS per utenti simultanei, variabile a seconda delle funzionalità. Per i calcoli è consigliabile utilizzare la tabella relativa al carico di lavoro riportata più indietro in questa sezione. È importante concentrarsi sulle ore di punta anziché sulla velocità effettiva media. Una pianificazione basata sulle attività di punta consente di dimensionare in modo appropriato la propria soluzione basata su SharePoint Server 2010.

Se si dispone di una soluzione di Office SharePoint Server 2007 esistente, è possibile eseguire il data mining dei file di registro IIS o esaminare altri strumenti di monitoraggio Web di cui si dispone per conoscere meglio alcuni dei comportamenti previsti sulla base della soluzione esistente. In alternativa, vedere le istruzioni nella sezione riportata di seguito per ottenere ulteriori informazioni. Se non si esegue la migrazione da una soluzione esistente, è consigliabile completare la tabella con calcoli approssimativi. Nei passaggi successivi sarà necessario convalidare le ipotesi suggerite e ottimizzare il sistema.

Analisi dei registri IIS in SharePoint Server 2010

Per individuare le metriche chiave relative a una distribuzione di SharePoint Server 2010 esistente, ad esempio il numero di utenti attivi, il carico di utilizzo del sistema, i tipi di richieste in ingresso e i tipi di client da cui provengono le richieste, è necessario estrarre i dati dai registri ULS e IIS. Uno dei modi più semplici per acquisire questi dati consiste nell'utilizzare Log Parser, un potente strumento disponibile gratuitamente per il download da Microsoft. Log Parser consente di leggere e scrivere in numerosi formati di testo e binari, inclusi tutti i formati IIS.

Per informazioni dettagliate su come analizzare l'utilizzo di SharePoint Server 2010 tramite lo strumento Log Parser, vedere Analisi di utilizzo di Prodotti e tecnologie Microsoft SharePoint (le informazioni potrebbero essere in lingua inglese) (https://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e\&displaylang=it-it).

È possibile scaricare Log Parser 2.2 all'indirizzo https://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07&displaylang=it-it (le informazioni potrebbero essere in lingua inglese).

Set di dati

Il set di dati descrive il volume di contenuto archiviato nel sistema e il modo in cui può essere distribuito nell'archivio dati. Nella tabella riportata di seguito vengono elencate alcune metriche chiave utili per determinare il set di dati. È possibile utilizzare questa tabella per prendere nota dei valori di queste metriche durante la raccolta dei dati.

Oggetto	Valore
Dimensioni database (in GB)
Numero di database del contenuto
Numero di raccolte siti
Numero di applicazioni Web
Numero di siti
Dimensioni dell'indice di ricerca (numero di elementi)
Numero di documenti
Numero di elenchi
Dimensione media dei siti
Dimensione massima dei siti
Numero di profili utente

Dimensioni del contenuto. È importante conoscere le dimensioni del contenuto che si prevede di archiviare nel sistema SharePoint Server 2010 per pianificare e definire l'architettura della memoria di sistema e per dimensionare correttamente la soluzione di ricerca che eseguirà la ricerca per indicizzazione e l'indicizzazione del contenuto. Le dimensioni del contenuto sono descritte in termini di spazio su disco totale. Se si esegue la migrazione del contenuto da una distribuzione esistente, è più semplice identificare le dimensioni totali che verranno spostate. Durante la pianificazione, è consigliabile lasciare spazio per l'espansione del contenuto nel tempo in base alla tendenza prevista.
Numero totale di documenti. Oltre alle dimensioni del corpo dei dati, è importante tenere traccia del numero totale di elementi. Il sistema risponde in modo diverso a seconda che 100 GB di dati siano costituiti da 50 file di 2 GB ognuno o da 100.000 file di 1 KB ognuno. Nelle distribuzioni di grandi dimensioni minore è il carico a cui viene sottoposto un singolo elemento, un documento o un'area di documenti, migliori saranno le prestazioni. Il contenuto distribuito su larga scala, ad esempio più file piccoli su numerosi siti e raccolte siti, risulta più semplice da gestire rispetto a una singola raccolta documenti contenente file di grandi dimensioni.
Dimensione massima delle raccolte siti. È importante identificare l'unità di contenuto più estesa che verrà archiviata in SharePoint Server 2010. Questo in genere è un requisito aziendale che garantisce che tale unità di contenuto non venga suddivisa. La dimensione media di tutte le raccolte siti e il numero totale stimato di raccolte siti sono ulteriori indicatori che consentiranno di identificare l'architettura di dati ottimale.
Caratteristiche dei dati delle applicazioni di servizio. Oltre ad analizzare i requisiti di memoria per l'archivio contenuto, è consigliabile analizzare e calcolare le dimensioni di altri archivi di SharePoint Server 2010, tra cui:
Dimensioni totali dell'indice di ricerca
Dimensioni totali del database dei profili in base al numero di utenti nell'archivio dei profili
Dimensioni totali del database di social networking in base al numero previsto di tag, colleghi e attività
Dimensioni dell'archivio dei metadati
Dimensioni del database servizio di utilizzo
Dimensioni del database di Web Analytics

Per ulteriori informazioni su come calcolare le dimensioni dei database, vedere Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server 2010).

Impostazione delle prestazioni della farm e degli obiettivi di affidabilità

Uno dei risultati finali del Passaggio 1: modellare è una buona conoscenza degli obiettivi di prestazioni e affidabilità adatti alle esigenze dell'organizzazione. Una soluzione di SharePoint Server progettata correttamente dovrebbe essere in grado di raggiungere un tempo di attività con "quattro nove" (99,99%) e con tempi di risposta del server inferiori al secondo.

Gli indicatori utilizzati per descrivere le prestazioni e l'affidabilità della farm possono includere:

Disponibilità del server. Viene descritta generalmente indicando la percentuale di tempo di attività globale del sistema. È consigliabile tenere traccia di tempi di inattività non previsti e confrontare la disponibilità globale con l'obiettivo aziendale definito. Gli obiettivi vengono descritti in genere con un numero di nove, ad esempio 99%, 99,9%, 99,99%.
Tempi di risposta del server. Il tempo impiegato dalla farm per gestire le richieste è un buon indicatore per monitorare lo stato della farm. Questo indicatore è denominato in genere latenza sul lato server. Viene utilizzata generalmente la latenza media o mediana (cinquantesimo percentile) delle richieste giornaliere gestite. Gli obiettivi vengono descritti solitamente in termini di tempi inferiori al secondo o in termini di secondi. Si noti che se un obiettivo dell'organizzazione è gestire le pagine di SharePoint Server 2010 in meno di due secondi, l'obiettivo sul lato server dovrà soddisfare tempi inferiori al secondo per consentire alla pagina di raggiungere il client sulla rete ed essere sottoposta a rendering nel browser. Tempi di risposta del server più lunghi in genere indicano una farm con stato non integro. Questa situazione infatti ha impatto sulla velocità effettiva e le richieste al secondo riescono raramente a soddisfare i requisiti se il server utilizza più di un secondo per la maggior parte delle richieste.
Sovraccarico del server. Un altro ottimo indicatore della latenza sul lato server che è consigliabile rilevare è il comportamento del 5% di tutte le richieste più lento. Le richieste più lente in genere sono quelle che raggiungono il sistema nel momento di carico maggiore oppure, più comunemente, quelle su cui ha effetto un'attività con frequenza ridotta che si verifica quando gli utenti interagiscono con il sistema. In un sistema integro vengono controllate anche le richieste più lente. L'obiettivo in questo caso è simile a quello per i tempi di risposta del server, ma per ottenere tempi di risposta inferiori al secondo in caso di sovraccarico del server sarà necessario creare il sistema con numerose risorse dedicate alla gestione delle situazioni di sovraccarico.
Utilizzo delle risorse di sistema. Altri indicatori comuni utilizzati per monitorare lo stato del sistema sono rappresentati da una raccolta di contatori del sistema che indicano lo stato di ogni server della topologia di farm. Gli indicatori di questo tipo utilizzati con maggiore frequenza sono rappresentati dalla percentuale di utilizzo della CPU e dalla memoria disponibile. Esistono tuttavia molti altri contatori che consentono di individuare un sistema con stato non integro. Per ulteriori informazioni, vedere la sezione Passaggio 5: monitorare e gestire.

Passaggio 2: progettare

Dopo aver raccolto alcuni fatti o stime per la soluzione da creare, si è pronti per procedere con il passaggio successivo, ovvero la progettazione di un proposta di architettura che in base alle proprie previsioni dovrebbe essere in grado di soddisfare i requisiti.

Al termine di questo passaggio si disporrà di una progettazione della topologia fisica e di un layout della topologia logica, in modo da poter procedere con tutti gli ordini di acquisto necessari.

Le specifiche hardware e il numero di computer definiti nel layout sono strettamente correlati. Per gestire un carico specifico, è possibile scegliere di distribuire diverse soluzioni. È procedura comune utilizzare un insieme ridotto di computer potenti (scalabilità verticale) o un insieme più ampio di computer più piccoli (scalabilità orizzontale). Ogni soluzione prevede vantaggi e svantaggi relativamente alla capacità, alla ridondanza, alla potenza, ai costi, allo spazio e ad altri tipi di considerazioni.

Per iniziare questo passaggio è consigliabile determinare l'architettura e la topologia. Definire il layout previsto per le diverse farm e i diversi servizi di ogni farm e quindi selezionare le specifiche hardware per ognuno dei singoli server della struttura. È inoltre possibile eseguire questo processo identificando le specifiche hardware che devono essere distribuite (molte organizzazioni sono vincolate da alcuni standard aziendali) e quindi definire l'architettura e la topologia.

Utilizzare la tabella riportata di seguito per prendere nota dei parametri di progettazione. I dati inclusi sono di esempio e non devono essere utilizzati per il dimensionamento della propria farm. Vengono indicati esclusivamente per illustrare l'utilizzo della tabella per i propri dati.

Ruolo	Tipo (standard o virtuale)	Numero di computer	Processori	RAM	Operazioni di I/O al secondo richieste	Dimensioni disco sistema operativo + registro	Unità dati
Server Web	Virtuale	4	4 processori core	8	N/D	400 GB	N/D
Server di database del contenuto	Standard	1 cluster	4 quad core 2.33 (GHz)	48	2000	400 GB	20 dischi da 300 GB @ 15000 richieste al minuto
Server applicazioni	Virtuale	4	4 processori core	16	N/D	400 GB	N/D
Server Web di destinazione della ricerca per indicizzazione	Virtuale	1	4 processori core	8	N/D	400 GB	N/D
Server di query di ricerca	Standard	2	2 quad core 2.33 (GHz)	32	N/D	400 GB	500 GB
Server crawler di ricerca	Standard	2	2 quad core 2.33 (GHz)	16	400	400 GB	N/D
Server di database di ricerca per indicizzazione	Standard	1 cluster	4 quad core 2.33 (GHz)	48	4000 (ottimizzazione per la lettura)	100 GB	16 dischi da 150 GB @ 15000 richieste al minuto
Database di archiviazione delle proprietà di ricerca + Server di database di amministrazione	Standard	1 cluster	4 quad core 2.33 (GHz)	48	2000 (ottimizzazione per la scrittura)	100 GB	16 dischi da 150 GB @ 15000 richieste al minuto

Determinare l'architettura di partenza

In questa sezione viene descritto come selezionare un'architettura di partenza.

Quando si distribuisce SharePoint Server 2010, è possibile scegliere tra un'ampia gamma di topologie per implementare la soluzione. È possibile distribuire un singolo server o implementare la scalabilità orizzontale di più server in una farm di SharePoint Server con server di database in cluster o con mirroring e server applicazioni discreti per diversi servizi. Le configurazioni hardware verranno selezionate successivamente in base ai requisiti di ogni ruolo, a seconda delle esigenze di capacità, disponibilità e ridondanza.

Esaminare le diverse architetture di riferimento e definire la struttura della farm, decidere se si desidera suddividere la soluzione su più farm o attuare la federazione di alcuni servizi, ad esempio il servizio di ricerca, in una farm dedicata. Per ulteriori informazioni, vedere la sezione Architetture di riferimento in Panoramica del dimensionamento e della gestione della capacità per SharePoint Server 2010.

Case study tecnici di SharePoint Server 2010

Le informazioni sulla gestione della capacità di SharePoint Server 2010 includono numerosi case study tecnici relativi ad ambienti di produzione esistenti con una descrizione dettagliata di ambienti di produzione esistenti basati su SharePoint Server. Verranno pubblicati nel tempo ulteriori case study tecnici. È possibile utilizzare questi case study come riferimento per la progettazione di un ambiente basato su SharePoint Server per scopi specifici.

Questi case study possono essere utilizzati come riferimento durante la progettazione dell'architettura delle soluzioni di SharePoint Server, soprattutto se si ritiene che la descrizione di questi elementi chiave di differenziazione specifici della distribuzione sia simile ai requisiti e agli obiettivi della soluzione di cui si sta definendo l'architettura.

In questi documenti vengono descritte le informazioni seguenti per ogni case study documentato:

Specifiche, ad esempio componenti hardware, topologia della farm e configurazione
Carico di lavoro, inclusi la base di utenti e le caratteristiche di utilizzo
Set di dati, inclusi le dimensioni, le caratteristiche e la distribuzione del contenuto
Stato e prestazioni, incluso un insieme di indicatori registrati che descrivono l'affidabilità e le caratteristiche delle prestazioni della farm

Per ulteriori informazioni, scaricare i documenti pertinenti dalla pagina Case study tecnici su prestazioni e capacità (https://technet.microsoft.com/it-it/library/cc261716(Office.14).aspx).

Selezionare i componenti hardware

La selezione delle specifiche appropriate per i computer della farm è un passaggio fondamentale per garantire affidabilità e prestazioni ottimali della distribuzione. Un concetto chiave di cui tenere conto è l'indicazione di effettuare la pianificazione in base ai carichi di picco e alle ore di punta. In altre parole, quando la farm funziona in condizioni di carico medio, devono essere disponibili risorse sufficienti per gestire la massima domanda prevista continuando a soddisfare gli obiettivi di latenza e velocità effettiva.

Le caratteristiche hardware di capacità e prestazioni di base dei server riflettono quattro categorie principali: potenza di elaborazione, prestazioni del disco, capacità di rete e capacità di memoria di un sistema.

Un altro elemento di cui tenere conto è l'utilizzo di macchine virtuali. È possibile distribuire una farm di SharePoint Server utilizzando macchine virtuali. Sebbene non sia stato dimostrato alcun vantaggio a livello di prestazioni, la virtualizzazione offre benefici a livello di gestione. Non è consigliabile in genere virtualizzare computer basati su SQL Server, ma possono derivare alcuni vantaggi dalla virtualizzazione dei livelli di server Web e dei server applicazioni. Per ulteriori informazioni, vedere Pianificazione della virtualizzazione (https://technet.microsoft.com/it-it/library/ff607968(Office.14).aspx).

Linee guida per la scelta dei componenti hardware

Scelta dei processori

SharePoint Server 2010 è disponibile solo per processori a 64 bit. Un numero elevato di processori in genere consente di gestire una domanda più elevata.

In SharePoint Server 2010 viene implementata la scalabilità dei singoli server Web man mano che si aggiungono ulteriori processori core (sono stati testati fino a 24 processori core). Maggiore è il numero di processori core del server, maggiore sarà il carico che potrà essere sostenuto, pur equivalendosi quasi tutte le caratteristiche. In distribuzioni di SharePoint Server estese è consigliabile allocare più server Web (virtualizzabili) a 4 processori core o un numero inferiore di server Web più potenti (8-/16-/24 processori core).

I requisiti di capacità dei processori dei server applicazioni variano a seconda del ruolo del server e dei servizi eseguiti. Alcune caratteristiche di SharePoint Server richiedono una maggiore potenza di elaborazione di altre. Il servizio di ricerca di SharePoint ad esempio dipende in modo significativo dalla potenza di elaborazione del server applicazioni. Per ulteriori informazioni sui requisiti di risorse delle caratteristiche e dei servizi di SharePoint Server, vedere la sezione Servizi e caratteristiche più indietro in questo documento.

I requisiti di capacità dei processori di SQL Server dipendono inoltre dai database dei servizi ospitati da un computer basato su SQL Server. Per ulteriori informazioni sul comportamento e i requisiti tipici di ogni database, vedere Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server 2010).

Scelta della memoria

I server richiederanno quantità variabili di memoria, a seconda della funzione e del ruolo. I server che eseguono i componenti della ricerca per indicizzazione ad esempio elaboreranno i dati più rapidamente se dispongono di una quantità elevata di memoria, poiché per l'elaborazione i documenti vengono letti nella memoria. Anche i server Web che utilizzano molte delle caratteristiche di memorizzazione nella cache di SharePoint Server 2010 possono richiedere molta memoria.

I requisiti di memoria dei server Web in genere dipendono in modo significativo dal numero di pool di applicazioni abilitati nella farm e dal numero di richieste simultanee gestite. Nella maggior parte delle distribuzioni di produzione di SharePoint Server è consigliabile allocare almeno 8 GB di RAM per ogni server Web, con 16 GB consigliati per server che gestiscono un traffico superiore o per distribuzioni con più pool di applicazioni configurati per l'isolamento.

Anche i requisiti di memoria dei server applicazioni sono variabili. Alcune caratteristiche di SharePoint Server presentano requisiti di memoria superiori a livello di applicazione rispetto ad altre. Nella maggior parte delle distribuzioni di produzione di SharePoint Server è consigliabile allocare almeno 8 GB di RAM per ogni server applicazioni. Server applicazioni da 16 GB, 32 GB e 64 GB sono comuni in scenari in cui sono abilitati molti servizi di applicazioni nello stesso server o in cui sono abilitati servizi che dipendono in modo significativo dalla memoria, ad esempio Servizi di calcolo Excel e il servizio di ricerca di SharePoint Server.

I requisiti di memoria dei server di database sono strettamente correlati alle dimensioni dei database. Per ulteriori informazioni sulla scelta della memoria per i computer basati su SQL Server, vedere Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server 2010).

Scelta delle reti

Oltre ai vantaggi per gli utenti se i client dispongono di un rapido accesso ai dati sulla rete, una farm distribuita deve disporre inoltre di un accesso rapido alle comunicazioni tra server, soprattutto se si distribuiscono servizi tra più server o si attua la federazione di alcuni dei servizi in altre farm. Il traffico scambiato in una farm a livello dei server Web, dei server applicazioni e dei server di database è elevato e pertanto la rete può trasformarsi facilmente in un collo di bottiglia in alcune condizioni, ad esempio in presenza di file di grandi dimensioni o di carichi molto elevati.

I server Web e i server applicazioni devono essere configurati con almeno due schede di interfaccia di rete, una per la gestione del traffico dell'utente finale e l'altra per la gestione delle comunicazioni tra server. Poiché la latenza di rete tra i server può produrre un impatto significativo sulle prestazioni, è importante mantenere una latenza inferiore a 1 millisecondo tra il server Web e i computer SQL Server che ospitano i database del contenuto. I computer SQL Server che ospitano il database di ogni applicazione di servizio inoltre devono essere il più vicino possibile al server applicazioni che lo utilizza. La rete tra i server della farm deve avere una larghezza di banda minima di 1 Gbps.

Scelta dei dischi e dello spazio di archiviazione

La gestione dei dischi non si limita a fornire spazio adeguato per i dati. È necessario valutare la richiesta crescente di spazio e l'aumento dei dati offrendo un'architettura dello spazio di archiviazione che non rallenti il sistema. Verificare sempre di disporre di almeno il 30% di capacità aggiuntiva in ogni disco, oltre alla stima dei requisiti massimi per i dati, in modo da lasciare spazio per un'espansione futura. Nella maggior parte degli ambienti di produzione inoltre la velocità dei dischi (operazioni di I/O al secondo) è fondamentale per fornire una velocità effettiva sufficiente per soddisfare le richieste di spazio di archiviazione sui server. È necessario calcolare la quantità di traffico (operazioni di I/O al secondo) richiesta dai database principali nella distribuzione e allocare dischi sufficienti per soddisfare tale richiesta.

Per informazioni su come scegliere i dischi per i server di database, vedere Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server 2010).

Anche i server Web e i server applicazioni prevedono requisiti di spazio di archiviazione. Nella maggior parte degli ambienti di produzione è consigliabile allocare almeno 200 GB di spazio su disco per il sistema operativo e i dati temporanei e 150 GB di spazio su disco per i registri.

Passaggio 3: eseguire la distribuzione pilota, i test e l'ottimizzazione

La fase di testing e ottimizzazione è un aspetto fondamentale di una gestione efficace della capacità. È consigliabile testare le nuove architetture prima di distribuirle in un ambiente di produzione, nonché eseguire test di accettazione insieme alle procedure consigliate di monitoraggio seguenti per accertarsi che le architetture progettate soddisfino i requisiti di prestazioni e capacità. In questo modo è possibile individuare e ottimizzare potenziali colli di bottiglia prima che creino problemi per gli utenti in una distribuzione attiva. Se si esegue l'aggiornamento da un ambiente Office SharePoint Server 2007 e si prevede di apportare modifiche all'architettura o si desidera effettuare una valutazione del carico utente per le nuove caratteristiche di SharePoint Server, è particolarmente importante eseguire i test per verificare che il nuovo ambiente basato su SharePoint Server soddisfi i requisiti di prestazioni e capacità.

Dopo aver testato l'ambiente, è possibile analizzare i risultati dei test per determinare le modifiche che devono essere apportate per raggiungere gli obiettivi di prestazioni e capacità definiti nel Passaggio 1: modellare.

Per la fase di pre-produzione è consigliabile eseguire i passaggi secondari seguenti:

Creare l'ambiente di testing che simula l'architettura iniziale progettata nel Passaggio 2: progettare.
Popolare lo spazio di archiviazione con il set di dati o parte di esso secondo quanto definito nelPassaggio 1: modellare.
Sollecitare il sistema con un carico sintetico che rappresenta il carico di lavoro identificato nel Passaggio 1: modellare.
Eseguire i test, analizzare i risultati e ottimizzare l'architettura.
Distribuire l'architettura ottimizzata nel data center e implementare una distribuzione pilota con un insieme ridotto di utenti.
Analizzare i risultati della distribuzione pilota, individuare potenziali colli di bottiglia e ottimizzare l'architettura. Rieseguire i test, se necessario.
Effettuare la distribuzione nell'ambiente di produzione.

Eseguire i test

I test rappresentano un aspetto importante per stabilire la capacità della struttura del sistema di supportare il carico di lavoro e le caratteristiche di utilizzo. Per informazioni dettagliate sui test della distribuzione di SharePoint Server 2010, vedere Esecuzione dei test delle prestazioni di SharePoint Server 2010.

Creare un piano di test
Creare l'ambiente di testing
Creare test e strumenti

Distribuire l'ambiente pilota

Prima di distribuire SharePoint Server 2010 in un ambiente di produzione, è importante distribuire un ambiente pilota e verificare accuratamente la farm per accertarsi che soddisfi i requisiti di capacità e prestazioni per il carico di picco previsto. È consigliabile testare innanzitutto l'ambiente pilota con un carico sintetico, soprattutto per distribuzioni estese, e quindi sollecitarlo con un insieme limitato di utenti e contenuto attivi. L'analisi di un ambiente pilota con un insieme ridotto di utenti attivi offre il vantaggio di convalidare alcune delle ipotesi sulla caratteristiche di utilizzo e sull'aumento del contenuto prima di passare definitivamente all'ambiente di produzione.

Ottimizzare

Se non è possibile soddisfare i requisiti di capacità e prestazioni implementando la scalabilità dei componenti hardware della farm o apportando modifiche alla topologia, è opportuno valutare la possibilità di riesaminare la soluzione. Se ad esempio i requisiti iniziali sono relativi a una singola farm per la collaborazione, la ricerca e il social networking, potrebbe essere necessario attuare la federazione di alcuni dei servizi, ad esempio il servizio di ricerca, in una farm di servizi dedicati oppure suddividere il carico di lavoro tra più farm. Un'alternativa consiste nel distribuire una farm dedicata per il social networking e un'altra per la collaborazione di team.

Passaggio 4: distribuire

Dopo aver eseguito l'ultima serie di test e aver verificato che l'architettura selezionata è in grado di soddisfare i requisiti di prestazioni e capacità definiti nel Passaggio 1: modellare, è possibile distribuire l'ambiente basato su SharePoint Server 2010 nell'ambiente di produzione.

La strategia di implementazione appropriata dipenderà dall'ambiente e dalla situazione. Sebbene la distribuzione di SharePoint Server in generale non rientri nell'ambito di questo documento, alcune attività suggerite derivano dalla sperimentazione della pianificazione della capacità. Vengono riportati di seguito alcuni esempi:

Distribuzione di una nuova farm di SharePoint Server: la sperimentazione della pianificazione della capacità dovrebbe aver definito e verificato i piani per la progettazione e la distribuzione di SharePoint Server 2010. In questo caso, l'implementazione sarà costituita inizialmente da una distribuzione di SharePoint Server 2010 su larga scala. Richiederà lo spostamento o la ricreazione di server e servizi utilizzati durante la sperimentazione della pianificazione della capacità in un ambiente di produzione. Questo è lo scenario più immediato, poiché non sono previsti aggiornamenti o modifiche necessarie per una farm esistente.
Aggiornamento di una farm di Office SharePoint Server 2007 a SharePoint Server 2010: la sperimentazione della pianificazione della capacità dovrebbe aver convalidato la pianificazione di una farm in grado di soddisfare requisiti esistenti e di implementare la scalabilità verticale per soddisfare un aumento dei requisiti e dell'utilizzo di una farm di SharePoint Server 2010. Parte della sperimentazione della pianificazione della capacità dovrebbe aver incluso migrazioni di prova per convalidare la durata del processo di aggiornamento, l'eventuale necessità di modificare o sostituire il codice personalizzato, l'esigenza di aggiornare strumenti di terze parti e così via. Al termine della pianificazione della capacità, l'utente dovrebbe disporre di una struttura convalidata, conoscere il tempo necessario per l'aggiornamento e disporre di un piano per l'esecuzione ottimale del processo di aggiornamento, ad esempio un aggiornamento sul posto o la migrazione di database del contenuto in una nuova farm. Se si esegue un aggiornamento sul posto, è possibile che durante la pianificazione della capacità sia stata rilevata la necessità di aggiungere o aggiornare i componenti hardware e di prendere in considerazione eventuali tempi di inattività. Parte dell'output della sperimentazione della pianificazione dovrebbe essere un elenco delle modifiche hardware necessarie e un piano dettagliato per la distribuzione di tali modifiche innanzitutto nella farm. Dopo aver realizzato la piattaforma hardware convalidata durante la pianificazione della capacità, è possibile proseguire con il processo di aggiornamento a SharePoint Server 2010.
Miglioramento delle prestazioni di una farm di SharePoint Server 2010 esistente: la sperimentazione della pianificazione della capacità dovrebbe aver consentito di individuare i colli di bottiglia nell'implementazione corrente, determinare come ridurre o eliminare tali colli di bottiglia e convalidare un'implementazione migliorata in grado di soddisfare i requisiti aziendali per i servizi di SharePoint Server. È possibile procedere in diversi modi per risolvere i problemi di prestazioni, dalla semplice riallocazione dei servizi nei componenti hardware esistenti, all'aggiornamento dei componenti hardware esistenti o all'aggiunta di altri componenti hardware e ulteriori servizi correlati. I diversi approcci devono essere testati e convalidati durante la sperimentazione della pianificazione della capacità, per poi formulare un piano di distribuzione in base ai risultati dei test.

Passaggio 5: monitorare e gestire

Per gestire le prestazioni del sistema, è necessario monitorare il server per individuare potenziali colli di bottiglia. Per poter eseguire un monitoraggio efficace, è necessario conoscere gli indicatori chiave che segnaleranno se una parte specifica della farm richiede attenzione, nonché essere in grado di interpretare tali indicatori. Se si rileva che la farm non soddisfa i requisiti definiti, è possibile modificarla aggiungendo o rimuovendo risorse hardware oppure modificando la topologia o la modalità di archiviazione dei dati.

Per un elenco delle impostazioni che è possibile modificare per monitorare l'ambiente a partire dalle fasi iniziali e per determinare se è necessario apportare eventuali modifiche, vedere Monitoraggio e manutenzione di SharePoint Server 2010. Considerare che il potenziamento delle funzionalità di monitoraggio avrà effetto sullo spazio su disco richiesto dal database servizio di utilizzo. Nel momento in cui l'ambiente è stabile e non è più necessario eseguire un monitoraggio dettagliato, è possibile ripristinare i valori predefiniti delle impostazioni.

Per ulteriori informazioni sul monitoraggio dello stato e sulla risoluzione dei problemi tramite gli strumenti di monitoraggio dello stato incorporati nell'interfaccia di Amministrazione centrale SharePoint Server, vedere gli articoli seguenti:

Health monitoring (SharePoint Server 2010)

Risoluzione dei problemi (https://technet.microsoft.com/it-it/library/ee748639(office.14).aspx)