Calcolare i requisiti di prestazioni e capacità per ambienti di collaborazione di reparto (SharePoint Server 2013)

SI APPLICA A:2013 2016 2019 Subscription Edition SharePoint in Microsoft 365

Questo articolo descrive le linee guida sulla pianificazione delle prestazioni e della capacità per una soluzione di collaborazione divisionale basata su SharePoint Server 2013. Sono incluse le informazioni seguenti:

• Specifiche dell'ambiente di laboratorio di test, ad esempio hardware, topologia della farm e configurazione

• Set di dati e carico di lavoro della farm di test che hanno generato il carico di test

• Risultati dei test e analisi che dimostrano e spiegano le tendenze in termini di velocità effettiva, latenza e requisiti hardware sotto carico in punti specifici dell'implementazione della scalabilità.

Usare le informazioni di questo articolo per identificare le caratteristiche dello scenario, in condizioni normali e nei picchi di carico, oltre che per valutare le variazioni nelle tendenze delle prestazioni quando il numero dei server della farm viene incrementato mediante scalabilità orizzontale. Questo articolo può anche rivelarsi utile per stimare un punto di partenza appropriato per l'architettura pianificata e per individuare i fattori da considerare per sviluppare un piano che consenta di mantenere livelli accettabili di prestazioni durante i picchi di carico.

Introduzione

Questo articolo illustra come aumentare le prestazioni dei server in una soluzione di collaborazione divisionale di SharePoint Server 2013. Una soluzione di collaborazione divisionale è una distribuzione di SharePoint Server 2013 con meno computer coinvolti nelle attività di collaborazione rispetto a una soluzione di collaborazione aziendale. Questo articolo presuppone che una divisione sia un'organizzazione all'interno di un'azienda che ha da 1.000 a 10.000 dipendenti.

Scenari diversi prevedono requisiti diversi. Pertanto, integrare queste indicazioni con test aggiuntivi sull'hardware e nell'ambiente specifico. Se la progettazione e i carichi di lavoro pianificati sono simili all'ambiente descritto in questo articolo, è possibile trarre conclusioni sulle prestazioni prevedibili dopo aver implementato la scalabilità orizzontale e verticale dell'ambiente.

Con la consultazione dell'articolo sarà possibile acquisire informazioni sugli aspetti seguenti:

• Specifiche, che comprendono hardware, topologia e configurazione

• Carico di lavoro, che comprende un'analisi della richiesta per la farm, il numero degli utenti e le caratteristiche di utilizzo

• Set di dati, ad esempio le dimensioni del database e i tipi di contenuto

• Risultati dei test e analisi per implementare la scalabilità orizzontale dei server Web

Prima di leggere questo articolo, leggere gli articoli seguenti per assicurarsi di comprendere i concetti chiave alla base della gestione della capacità in Limiti e limiti software per SharePoint 2013SharePoint Server 2013.

• Informazioni sulla pianificazione di prestazioni e capacità per SharePoint Server 2013

• Stimare i requisiti di prestazioni e capacità per ambienti di collaborazione su Intranet aziendale (SharePoint Server 2013)

Glossario

L'elenco seguente contiene le definizioni dei principali termini usati in questo articolo.

• RPS: Richieste al secondo. RPS è il numero di richieste ricevute da una farm o da un server in un secondo. Questa è una misurazione comune del carico dei server e delle farm.

  Nota

  Le richieste sono diverse dai caricamenti di pagina. Una pagina contiene diversi componenti, ognuno dei quali crea una o più richieste quando viene caricata in un browser. Il caricamento di una singola pagina crea quindi diverse richieste. In genere, i controlli e gli eventi di autenticazione che usano risorse poco significative non vengono conteggiati nelle misurazioni delle richieste al secondo.

• Area verde: rappresenta un set definito di caratteristiche di carico in condizioni operative normali, fino ai carichi di picco giornalieri previsti. Una farm che opera in questo ambito deve essere in grado di supportare tempi di risposta e latenza che rientrano in parametri accettabili.

  Si tratta dello stato in cui il server può soddisfare il set di criteri seguente:

  • La latenza sul lato server per almeno il 75% delle richieste è inferiore a 1 secondo.

  • Tutti i server della farm mantengono una media di utilizzo della CPU inferiore al 60%.

    Nota

    L'ambiente lab non ha eseguito una ricerca per indicizzazione attiva. Il server di database è stato quindi mantenuto vicino al 50% di utilizzo della CPU o inferiore per riservare il 10% per il carico di ricerca per indicizzazione. Si presuppone che SQL Server Resource Governor venga usato nell'ambiente di produzione per limitare il carico di ricerca per indicizzazione al 10% della CPU.

  • La percentuale di errori è inferiore allo 0,01%.

• Zona rossa (max): La zona rossa rappresenta un set definito di caratteristiche di carico in condizioni operative di picco. Nell'area rossa la farm ha un tasso molto elevato di richieste di risorse temporanee che può sostenere soltanto per periodi limitati prima che si verifichino errori e altri problemi di prestazioni e affidabilità.

  Si tratta dello stato in cui il server può soddisfare il set di criteri seguente per un periodo limitato:

  • La funzionalità di limitazione delle richieste HTTP è abilitata, ma non vengono restituiti errori 503 (server occupato).

  • La frequenza degli errori è minore di 0. 1%.

  • La latenza sul lato server è inferiore a 3 secondi per almeno il 75% delle richieste.

  • Tutti i server della farm (esclusi i server di database) mantengono una media di utilizzo della CPU approssimativamente inferiore al 90%.

  • La media di utilizzo della CPU dei server di database è approssimativamente inferiore al 50%, pertanto viene riservato un ampio margine di sovraccarico in relazione al carico di ricerca per indicizzazione.

• AxBxC (notazione grafo): Numero di server Web, server applicazioni e server di database rispettivamente in una farm. Ad esempio, 10x1x1 significa che questo ambiente ha 10 server Web, 1 server applicazioni e 1 server di database.

• MDF e LDF: File fisici di SQL Server. Per altre informazioni, vedere Architettura di file e filegroup.

Panoramica

In questa sezione viene fornita una panoramica dell'approccio di implementazione della scalabilità e la metodologia di test utilizzati.

Approccio per l'implementazione della scalabilità

Questa sezione descrive l'approccio adottato per implementare la scalabilità orizzontale nell'ambiente di laboratorio. Con questo approccio sarà possibile individuare la configurazione ottimale per specifici carichi di lavoro:

• Implementando la scalabilità orizzontale, è stato incrementato fino a quattro il numero dei server Web in uso. In ogni server viene eseguito il servizio cache distribuita.

• È stato aggiunto un server dedicato in cui viene eseguito il servizio cache distribuita.

• È stato disabilitato il servizio cache distribuita nei server Web.

• Sempre implementando la scalabilità orizzontale, il numero dei server Web è stato incrementato al massimo per l'ambito dei test.

Note su metodologia e test

Poiché questo articolo contiene i risultati di un ambiente di laboratorio di test, è stato possibile controllare determinati fattori per mostrare aspetti specifici delle prestazioni per questo carico di lavoro. Inoltre, alcuni elementi dell'ambiente di produzione, riportati nell'elenco seguente, sono stati esclusi dall'ambiente di laboratorio per semplificare il sovraccarico dei test.

• Tra un'esecuzione e l'altra dei test, è stata modificata una sola variabile alla volta per semplificare il confronto dei risultati.

• I server di database non facevano parte di un cluster perché la ridondanza non era necessaria ai fini di questi test.

• La ricerca per indicizzazione non è stata eseguita durante i test. Naturalmente, potrebbe essere in esecuzione in un ambiente di produzione. Per tenere conto di questo, è stato ridotto l'utilizzo della CPU di SQL Server nelle definizioni di "zona verde" e "zona rossa" per supportare le risorse che una ricerca per indicizzazione in genere usava durante i test.

Specifiche

Questa sezione fornisce i dettagli su hardware, software, topologia e configurazione dell'ambiente di laboratorio.

Hardware

Le sezioni seguenti descrivo l'hardware usato nell'ambiente di laboratorio di test.

Host Hyper-V

Per i test sono stati usati sei host Hyper-V configurati in modo identico. In ogni host vengono eseguite da una a due macchine virtuali.

Server Web e server applicazioni virtuali

La farm di test usa otto server Web virtuali. È stato inoltre usato un server virtuale dedicato che esegue il servizio cache distribuita.

Server di database

Nei test viene usato un server di database fisico ed è stata eseguita l'istanza di SQL Server predefinita che archivia i database di SharePoint. In questo articolo non si tiene traccia del database di registrazione.

Nell'ambiente lab la registrazione è stata vincolata e il database di registrazione è stato archiviato in un'istanza separata di SQL Server.

Topologia

Il diagramma seguente mostra la topologia dell'ambiente di laboratorio di test.

Configurazione

La tabella seguente mostra le modifiche significative apportate alla configurazione del server di database nell'ambiente di laboratorio. Queste modifiche consentono di ottenere prestazioni di test ottimali e relazioni ben definite tra parametri di test e risultati. Si noti che l'impostazione MAXDOP è necessaria per SharePoint Server 2013. Le altre modifiche delle impostazioni si applicano solo all'ambiente di laboratorio di test e potrebbero non influire sull'ambiente di produzione.

Carico di lavoro

Questa sezione illustra i test di laboratorio eseguiti su SharePoint Server 2013. I dettagli dei test sono tipici di un ambiente di collaborazione tra divisioni.

Set di dati

Il set di dati usato nell'ambiente di laboratorio di test rappresenta un tipico ambiente di collaborazione tra divisioni. Contiene raccolte siti, siti, elenchi, raccolte, tipi di file e dimensioni di file di vario tipo.

Risultati e analisi

I risultati seguenti sono ordinati in base all'approccio adottato per l'implementazione della scalabilità dell'ambiente, descritto nella sezione Panoramica.

Scalabilità orizzontale dei server Web

Le sezioni seguenti descrivono i risultati dei test ottenuti incrementando il numero di server Web dell'ambiente di laboratorio di test con la scalabilità orizzontale.

Metodologia di test

• Aggiungere server Web con le stesse specifiche hardware ed eseguire di nuovo il test senza apportare modifiche alla farm o ai parametri di test.

• Misurare il numero di richieste al secondo, la latenza e l'utilizzo delle risorse in ogni server della farm di test.

Analisi

I risultati dei test sono i seguenti:

• Nell'ambiente il numero di server Web è stato incrementato fino a dieci per ogni server di database. L'aumento della velocità effettiva è stato relativamente lineare.

• Anche fino al numero massimo di dieci server Web testati, l'aggiunta di altri server di database non ha determinato un aumento della velocità effettiva. Il collo di bottiglia in generale riguardava le risorse dei server Web.

• La latenza media nell'area verde è stata quasi constante per l'intera durata del test. Il numero di server Web e la velocità effettiva non hanno influito sulla latenza di quest'area. I dati sulla latenza dell'area rossa indicano una linea di tendenza prevista. La latenza è molto elevata in un singolo server Web. Una curva tra 2 e 8 server Web rimane tranquillamente entro i criteri dell'area rossa.

  Nota

  La latenza può variare leggermente quando si sposta il servizio cache distribuita dai server Web di una farm in un server dedicato a tale cache. Questo può accadere perché il traffico della cache distribuita, che precedentemente era interno a ogni server Web, inizia ad attraversare la rete. Verificare le prestazioni dopo aver implementato la scalabilità orizzontale nel proprio ambiente per stabilire se tale effetto negativo è significativo. Tenere presente che la latenza nell'ambiente di test è aumentata leggermente dopo la migrazione del servizio cache distribuita in un server dedicato. La latenza è diminuita man mano che sono stati aggiunti server Web, in quanto la latenza aggiunta nominale è stata compensata da una riduzione del carico di elaborazione e memoria nei server Web. > Per altre informazioni sulla pianificazione della capacità della cache distribuita, vedere Pianificare i feed e il servizio Cache distribuita in SharePoint Server.

• A causa dei miglioramenti apportati alla memorizzazione nella cache e alle caratteristiche di utilizzo del database in SharePoint Server 2013, il carico medio sul livello del server di database è basso. Durante i test, è stato rilevato che non era necessario implementare la scalabilità orizzontale per i server di database.

• I miglioramenti delle prestazioni ottenuti con l'aggiunta di server Web virtuali dipendono in parte dalle risorse hardware dell'host e dall'utilizzo delle risorse degli altri computer virtuali in esecuzione nello stesso host. I server virtuali richiedono altre strategie di pianificazione e gestione specifiche della virtualizzazione.

  Per altre informazioni sulla pianificazione delle prestazioni e della capacità di Hyper-V, vedere Requisiti di virtualizzazione Hyper-V per SharePoint 2013 e Usare le configurazioni consigliate per le macchine virtuali e l'ambiente Hyper-V di SharePoint 2013.

Risultati, grafici e diagrammi

L'asse X dei grafici seguenti indica la variazione nel numero di server Web nella farm. La scala inizia con un server Web virtuale e un server di database fisico (1x1). Il massimo è rappresentato da otto server Web virtuali, un server virtuale dedicato alla cache distribuita (aggiunto in quattro server Web) e un server di database fisico (8x1x1).

1. Richieste al secondo (RPS)

Nel grafico riportato di seguito viene mostrato come l'implementazione della scalabilità orizzontale influisca sui valori RPS di riferimento.

2. Latenza

Il grafico seguente mostra gli effetti della scalabilità orizzontale sulla latenza. La latenza nell'area verde rimane quasi costante, mentre quella nell'area rossa presenta incrementi che rientrano nei limiti accettabili.

3. Utilizzo del processore e della memoria dei server Web

Il grafico seguente mostra gli effetti della scalabilità orizzontale sull'utilizzo medio di processori e memoria nei server Web. Nell'area verde l'utilizzo di processori e l'utilizzo medio di memoria rimangono relativamente costanti con l'aumento del numero di richieste al secondo.

La tendenza dell'utilizzo di processori nell'area rossa è discendente. Questa tendenza verso il basso riflette il fatto che la domanda media del processore del server Web in corrispondenza del carico massimo diminuisce gradualmente con l'aumento del numero di server.

4. SQL operazioni di I/O server al secondo e utilizzo del processore

I grafici seguenti mostrano la variazione del numero medio di operazioni IOPs su disco (in totale e di lettura/scrittura) e dei valori di utilizzo dei processori quando viene implementata la scalabilità orizzontale dei server Web. Per misurare i valori di IOPs sono stati usati i contatori delle prestazioni seguenti:

• Disco fisico: Letture disco/sec

• Disco fisico: Scritture disco/sec

Per i valori di ogni contatore nel corso del test viene calcolata la media, quindi le medie vengono sommate per produrre il numero totale di IOPs.

Nei grafici di questa sezione, i dati riguardanti le operazioni IOPs e l'utilizzo dei processori dei server di database presentano una flessione con sei server Web front-end, mentre il numero di richieste al secondo continua ad aumentare. Questa variazione si riflette anche sull'utilizzo dei processori dei server Web mostrati nel grafico precedente.

Questo dimostra che il livello di scalabilità della farm ha raggiunto il punto di massima pressione sulle risorse dei server della farm con il set di dati e il carico di riferimento. Per far fronte al carico della farm, è necessario un utilizzo medio minore delle risorse dei server.

Da questa tendenza è possibile concludere quanto segue:

• Se il carico di test fosse stato aumentato in corrispondenza del sesto server Web sulla scala, sarebbe stato possibile raggiungere un numero di richieste al secondo più elevato mantenendo una curva piatta nell'utilizzo delle risorse dei server.

• Se il numero dei server Web fosse stato incrementato ulteriormente mantenendo lo stesso carico di test, il numero di richieste al secondo avrebbe continuato ad aumentare mentre la pressione sulle risorse dei server avrebbe continuato ad avere una tendenza discendente.

1. Operazioni di I/O totali di SQL Server

   Nel grafico riportato di seguito viene mostrato come l'implementazione della scalabilità orizzontale influisca sulle operazioni di I/O al secondo totali.

   

2. Operazioni di I/O al secondo di SQL Server suddivise in operazioni di lettura e scrittura

   Il grafico seguente mostra gli effetti della scalabilità orizzontale sul valore IOPs per le operazioni di lettura e scrittura al secondo.

   

3. Utilizzo del processore di SQL Server

   Il grafico seguente mostra come il ridimensionamento influisce sull'utilizzo del processore di SQL Server.

   

Vedere anche

Concetti

Pianificare le prestazioni di pianificazione in SharePoint Server 2013

Risultati dei testi delle prestazioni e della capacità e suggerimenti (SharePoint Server 2013)

Stimare i requisiti di prestazioni e capacità per ambienti di collaborazione su Intranet aziendale (SharePoint Server 2013)