Pianificazione della capacità per SharePoint Server 2013

Articolo
03/08/2023

SI APPLICA A: yes-img-13 2013 no-img-16 2016 no-img-19 2019 no-img-se Subscription Edition no-img-sop SharePoint in Microsoft 365

Questo articolo descrive come pianificare la capacità di una farm di SharePoint Server 2013. Dopo avere 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 scelta e la configurazione dell'architettura di dati, della topologia logica e fisica e dei componenti hardware appropriati per la piattaforma di una soluzione. È disponibile una gamma di considerazioni sulla gestione della capacità e sull'utilizzo che influiscono sul modo in cui è necessario determinare le opzioni di configurazione e hardware più appropriate.

Prima di leggere questo articolo, è consigliabile leggere Panoramica della gestione della capacità e del ridimensionamento per SharePoint Server 2013.

Importante

Alcune informazioni e valori in questo articolo si basano sui risultati dei test e altre informazioni relative ai prodotti SharePoint 2010 e potrebbero non rappresentare i valori finali per SharePoint Server 2013.

In questo articolo vengono descritti i passaggi da eseguire per intraprendere una gestione efficace della capacità per l'ambiente. Ogni passaggio richiede determinate informazioni per l'esecuzione corretta e include un set di risultati finali che verranno usati nel passaggio successivo. Per ogni passaggio, questi requisiti e risultati finali sono descritti nelle tabelle.

Passaggio 1: modellazione

La modellazione dell'ambiente basato su SharePoint Server 2013 inizia con l'analisi delle soluzioni esistenti e la stima della domanda e degli obiettivi previsti per la distribuzione che si intende configurare. Per iniziare, raccogliere informazioni sulla base utenti, i requisiti dei dati, la latenza e le destinazioni di velocità effettiva e documentare le funzionalità di SharePoint Server 2013 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.

Comprensione del carico di lavoro e del set di dati previsti

Il ridimensionamento corretto di un'implementazione di SharePoint Server 2013 richiede lo studio e la comprensione delle caratteristiche della domanda che la soluzione deve gestire. Per comprendere la domanda è necessario essere in grado di descrivere sia le caratteristiche del carico di lavoro, ad esempio il numero di utenti e le operazioni usate più di frequente, sia le caratteristiche del set di dati, ad esempio le dimensioni del contenuto 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 ai quali è possibile raccogliere questi dati.

Carico di lavoro

Il carico di lavoro descrive la domanda a cui il sistema dovrà fare fronte, 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 tali 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 di utenti simultanei giornalieri
Picco di utenti simultanei nelle ore di punta
Numero totale di richieste al giorno
Distribuzione del carico di lavoro previsto
No. 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 : è più comune misurare la concorrenza delle operazioni eseguite nella server farm come numero di utenti distinti che generano richieste in un determinato intervallo di tempo. Le metriche chiave sono la media giornaliera e gli utenti simultanei al carico massimo.
Richieste al secondo ( RPS): RPS è un indicatore di uso comune usato per descrivere la domanda nella server farm espressa nel numero di richieste elaborate dalla farm al secondo, ma senza alcuna differenziazione tra il tipo o le dimensioni delle richieste. La base di utenti di ogni organizzazione genera il carico di sistema a una velocità che dipende dalle caratteristiche di utilizzo univoche dell'organizzazione. Per altre informazioni, vedere Glossario.
Richieste giornaliere totali : le richieste giornaliere totali sono un buon indicatore del carico complessivo che il sistema dovrà gestire. È più comune misurare tutte le richieste tranne le richieste di handshake di autenticazione (stato HTTP 401) in un periodo di 24 ore.
Utenti giornalieri totali : il totale degli utenti è un altro indicatore chiave del carico complessivo che il sistema dovrà gestire. Questa misurazione è il numero effettivo di utenti univoci in un periodo di 24 ore, non il numero totale di dipendenti nell'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 man mano che sempre più utenti adottano la tecnologia.
Distribuzione del carico di lavoro : comprendere la distribuzione delle richieste in base alle applicazioni del client che interagiscono con la farm può aiutare a stimare la tendenza prevista e caricare le modifiche dopo la migrazione a SharePoint Server 2013. Man mano che gli utenti passano a versioni client più recenti, ad esempio Office 2013, e iniziano a usare le nuove funzionalità, è previsto un aumento dei nuovi modelli di carico, RPS e richieste totali.As users transition to more recent client versions as Office 2013, and start using the new capabilities new load patterns, RPS, and total requests are expected to grow. Per ogni client, è possibile descrivere il numero di utenti distinti che lo usano in un intervallo di tempo di un giorno e il numero di richieste totali generate dal client o dalla funzionalità nel 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 notare che la maggior parte del carico viene generato dal crawler di ricerca e dalla tipica esplorazione Web dell'utente finale. È anche possibile osservare che la funzionalità Outlook Social Connector introduce un carico significativo (6,2% delle richieste).

Stima del carico di lavoro per la produzione

Per calcolare la velocità effettiva richiesta che deve poter essere sostenuta dalla farm, iniziare con la stima della combinazione di transazioni che verranno utilizzate nella farm. Concentrarsi sull'analisi delle transazioni usate più di frequente che il sistema gestirà e comprendere la frequenza con cui verranno usate e il numero di utenti. Questa comprensione consentirà di verificare in un secondo momento se la farm può sostenere tali carichi nei test di preproduzione.

Nel diagramma seguente viene illustrata la relazione tra carico di lavoro e carico del sistema:

Capacità - Diagramma carico di lavoro

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

Identificare le interazioni degli utenti. Ad esempio:
- Esplora la pagina Web.
- Download e caricamenti di file.
- Le visualizzazioni e le modifiche dell'applicazione Web di Office nel browser.
- Interazioni con autori.
- Sincronizzazioni del sito dell'area di lavoro di SharePoint.
- Connessioni di social networking di Outlook.
- Sincronizzazione RSS (in Outlook o in altri visualizzatori).
- Trasmissioni di PowerPoint.
- Blocchi appunti condivisi di OneNote.
- Cartelle di lavoro condivise del servizio Excel.
- Accedere alle applicazioni condivise del servizio
Per altre informazioni, vedere Servizi e funzionalità. Concentrarsi sull'identificazione delle interazioni che possono essere univoche per la distribuzione. Riconoscere l'impatto previsto di tali carichi. Ad esempio, uso significativo di moduli di InfoPath, calcoli del servizio 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.
Stimare gli elementi seguenti:
- Numero totale di utenti al giorno che si prevede utilizzino ogni funzionalità.
- Derivare gli utenti simultanei stimati e le richieste di alto livello al secondo.
Verranno fatte alcune ipotesi. Ad esempio:
- Concorrenza attuale.
- Fattore di RPS per utente simultaneo diverso tra le funzionalità
Usare la tabella del carico di lavoro precedente in questa sezione per le stime. È importante concentrarsi sulle ore di punta anziché sulla velocità effettiva media. La pianificazione dell'attività di picco consente di ridimensionare correttamente la soluzione basata su SharePoint Server 2013.

Se si dispone di una soluzione di Office SharePoint Server 2007 esistente, è possibile estrarre i file di log di IIS o cercare altri strumenti di monitoraggio Web per comprendere meglio alcuni dei comportamenti previsti dalla soluzione esistente. In caso contrario, vedere le istruzioni nella sezione seguente per altri dettagli. Se non si esegue la migrazione da una soluzione esistente, è necessario compilare la tabella usando stime approssimative. Nei passaggi successivi sarà necessario convalidare i presupposti e ottimizzare il sistema.

Analisi dei log IIS in SharePoint Server 2013

Sarà necessario estrarre dati dai log ULS e IIS per individuare le metriche chiave relative a una distribuzione di SharePoint Server 2013 esistente. Ad esempio:

Numero di utenti attivi.
Quanto usano il sistema.
Che tipo di richieste sono in arrivo.
Da quale tipo di client provengono le richieste.

Uno dei modi più semplici per trovare questi dati consiste nell'usare Log Parser, un potente strumento disponibile gratuitamente per il download da Microsoft. Il parser di log può leggere e scrivere in molti formati di testo e binari, inclusi tutti i formati IIS.

È possibile scaricare Log Parser 2.2 all'indirizzo https://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07.

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 : comprendere le dimensioni del contenuto che si prevede di archiviare nel sistema SharePoint Server 2013 è importante per pianificare e progettare l'archiviazione di sistema e anche per dimensionare correttamente la soluzione di ricerca che eseguirà la ricerca per indicizzazione e l'indicizzazione del contenuto. Le dimensioni del contenuto sono descritte nello spazio totale su disco. Se si esegue la migrazione del contenuto da una distribuzione esistente, potrebbe essere semplice identificare le dimensioni totali del contenuto da spostare. Durante la pianificazione, è consigliabile lasciare spazio alla crescita nel tempo in base al tempo.
Numero totale di documenti: oltre alle dimensioni del corpus di dati, è importante tenere traccia del numero complessivo di elementi. Il sistema reagisce in modo diverso se 100 GB di dati sono costituiti da 50 file da 2 GB ciascuno rispetto a 100.000 file di 1 KB ciascuno. Nelle distribuzioni di grandi dimensioni, meno stress si verifica su un singolo elemento, documento o area di documenti, le prestazioni migliori saranno. Il contenuto ampiamente distribuito, ad esempio più file più piccoli in molti siti e raccolte siti, è più semplice da gestire rispetto a una singola raccolta documenti di grandi dimensioni con file di grandi dimensioni.
Dimensioni massime della raccolta siti : è importante identificare qual è la più grande unità di contenuto che si archivierà in SharePoint Server 2013; in genere si tratta di un'esigenza organizzativa che impedisce di dividere l'unità di contenuto. Le dimensioni medie di tutte le raccolte siti e il numero totale stimato di raccolte siti sono altri indicatori che consentono di identificare l'architettura dei dati preferita.
Caratteristiche dei dati delle applicazioni di servizio : oltre ad analizzare le esigenze di archiviazione per l'archivio contenuto, è necessario analizzare e stimare le dimensioni di altri archivi di SharePoint Server 2013, tra cui:
Dimensioni totali dell'indice di ricerca
Dimensioni totali del database del profilo in base al numero di utenti nell'archivio profili
Dimensioni totali del database social in base al numero previsto di tag, colleghi e attività
Dimensioni dell'archivio dei metadati
Dimensioni del database del servizio di utilizzo
Dimensioni del database di Web Analytics

Impostazione dei target di prestazioni e affidabilità della farm

Uno dei risultati finali del Passaggio 1: modellazione è una buona comprensione dei target di prestazioni e affidabilità più adatti alle esigenze dell'organizzazione. Una soluzione di SharePoint Server 2013 progettata correttamente dovrebbe essere in grado di ottenere "quattro nove" (99,99%) di tempo di attività con velocità di risposta del server di sottosecondi.

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

Disponibilità del server: descritto in base alla percentuale del tempo di attività complessivo del sistema. È consigliabile tenere traccia di eventuali tempi di inattività imprevisti e confrontare la disponibilità complessiva con la destinazione dell'organizzazione impostata. Le destinazioni sono comunemente descritte da un numero di nove (ovvero, 99%, 99,9%, 99,99%)
Velocità di risposta del server: il tempo necessario alla farm per gestire le richieste è un buon indicatore per tenere traccia dell'integrità della farm. Questo indicatore è denominato latenza lato server. Tt usa comunemente la latenza media o mediano (il 50° percentile) delle richieste giornaliere servite. Le destinazioni sono comunemente descritte in secondi o frazioni di secondi. Se la destinazione deve servire le pagine in meno di due secondi, l'obiettivo sul lato server deve essere espresso in frazioni di secondo. Questo aumento delle prestazioni consente alla pagina di raggiungere il client e di eseguire il rendering nel browser. Inoltre, i tempi di risposta del server più lunghi sono in genere un'indicazione di una farm non integra. RPS può raramente tenere il passo se si spende più di un secondo nel server per la maggior parte delle richieste.
Spikiness del server: un altro indicatore di latenza lato server valido che vale la pena tenere traccia è il comportamento del 5% più lento di tutte le richieste. Le richieste più lente sono in genere le richieste che hanno raggiunto il sistema quando il carico è più elevato o ancora più comunemente, le richieste che sono interessate da attività meno frequenti che si verificano mentre gli utenti interagiscono con il sistema; anche un sistema integro ha le richieste più lente sotto controllo. La destinazione è simile alla velocità di risposta del server, ma per ottenere una risposta al secondo secondario in caso di spikiness del server, è necessario compilare il sistema con numerose risorse di riserva per gestire i picchi di carico.
Utilizzo delle risorse di sistema: altri indicatori comuni usati per tenere traccia dell'integrità del sistema sono una raccolta di contatori di sistema che indicano l'integrità di ogni server nella topologia della farm. Gli indicatori usati più di frequente da tenere traccia sono % utilizzo CPU e memoria disponibile; tuttavia, ci sono diversi altri contatori che possono aiutare a identificare un sistema non integro; Altri dettagli sono disponibili in Passaggio 5: Monitorare e gestire.

Passaggio 2: progettazione

Ora che hai finito di raccogliere alcuni fatti o stime sulla soluzione che devi fornire, sei pronto per iniziare il passaggio successivo della progettazione di un'architettura proposta che prevedi sarà in grado di sostenere la domanda prevista.

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 layout sono strettamente correlati, per gestire un carico specifico sono disponibili diverse soluzioni che è possibile scegliere di distribuire. È comune usare un piccolo set di macchine complesse (scalabilità orizzontale) o un set più grande di macchine più piccole (scalabilità orizzontale); ogni soluzione presenta i suoi vantaggi e svantaggi quando si tratta di capacità, ridondanza, alimentazione, costi, spazio e altre considerazioni.

Per iniziare questo passaggio, è consigliabile determinare l'architettura e la topologia. Definire il modo in cui si prevede di disporre le diverse farm e i diversi servizi in ogni farm, quindi selezionare le specifiche hardware per ognuno dei singoli server nella progettazione. È anche possibile eseguire questo processo identificando le specifiche hardware che si prevede di distribuire (molte organizzazioni sono vincolate a un determinato standard aziendale) 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 dati di esempio e non vengono usati per ridimensionare la farm. Ha lo scopo di illustrare come usare questa tabella per i propri dati.

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

Determinazione dell'architettura di partenza

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

Quando si distribuisce SharePoint Server 2013, è possibile scegliere tra una gamma di topologie per implementare la soluzione; È possibile distribuire un singolo server o aumentare il numero di server in una farm di SharePoint Server 2013 con server di database in cluster o con mirroring e server applicazioni discreti per vari servizi. In seguito si selezionano le configurazioni hardware in base ai requisiti di ognuno dei ruoli, in base alle esigenze di capacità, disponibilità e ridondanza.

Innanzitutto 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 altre informazioni, vedere Architetture di riferimento.

Case study tecnici di SharePoint Server 2010

Le linee guida per la gestione della capacità per SharePoint Server 2013 includono molti case study tecnici sugli ambienti di produzione esistenti che presentano una descrizione dettagliata degli ambienti di produzione esistenti basati su SharePoint Server 2013. I case study tecnici specifici di SharePoint Server 2013 saranno pubblicati man mano che diventano disponibili; i case study di SharePoint Server 2010 esistenti possono fungere da riferimento su come progettare un ambiente basato su SharePoint Server 2013 per scopi specifici.

È possibile usare questi case study come riferimento durante la progettazione dell'architettura delle soluzioni SharePoint Server 2013, soprattutto se si trova la descrizione di questi differenziatori chiave specifici della distribuzione simili alle richieste e agli obiettivi della soluzione che si sta progettando.

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

Specifiche, ad esempio hardware, topologia della farm e configurazione;
Carico di lavoro, inclusi la base di utenti e le caratteristiche di utilizzo
Set di dati, incluse le dimensioni dei contenuti, le caratteristiche del contenuto e la distribuzione del contenuto
Integrità e prestazioni, incluso un insieme di indicatori registrati che descrivono le caratteristiche di affidabilità e prestazioni della farm

Per ulteriori informazioni, scaricare i documenti pertinenti dalla pagina Performance and capacity technical case studies (SharePoint Server 2010).

Scelta dei componenti hardware

La scelta 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 altri termini, quando la farm funziona in condizioni di carico medio, devono essere disponibili risorse sufficienti per gestire la massima domanda prevista continuando a soddisfare i target 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 2013 usando macchine virtuali. Sebbene la virtualizzazione non sia stata trovata per aggiungere vantaggi in termini di prestazioni, offre vantaggi di gestibilità. La virtualizzazione di computer basati su SQL Server non è consigliata, ma potrebbero esserci alcuni vantaggi nella virtualizzazione dei livelli server Web e server applicazioni. Per altre informazioni, vedere Virtualization planning (/previous-versions/office/sharepoint-server-2010/ff607968(v=office.14)).

Per altre informazioni sui requisiti hardware, vedere Requisiti hardware e software per SharePoint Server 2016.

Linee guida per la scelta dei componenti hardware

Scelta dei processori

SharePoint Server 2013 è disponibile solo per processori a 64 bit. Un numero maggiore di processori in genere consente di fare fronte a una domanda più elevata.

In SharePoint Server 2013, i singoli server Web verranno ridimensionati man mano che si aggiungono altri core. Maggiore è il numero di core del server, maggiore sarà il carico che potrà essere sopportato, pur equivalendosi quasi tutte le altre caratteristiche. Nelle distribuzioni di SharePoint Server 2013 di grandi dimensioni è consigliabile allocare più server Web 4 core (che possono essere virtualizzati) o meno server Web più forti (8/16-/24 core).

I requisiti di capacità del processore dei server applicazioni variano a seconda del ruolo del server e dei servizi in esecuzione. Alcune funzionalità di SharePoint Server 2013 richiedono una maggiore potenza di elaborazione rispetto ad altre. Il servizio di ricerca di SharePoint ad esempio dipende in modo significativo dalla potenza di elaborazione del server applicazioni.

I requisiti di capacità del processore per SQL Server dipendono anche dai database del servizio ospitati da un computer basato su SQL Server.

Scelta della memoria

I server richiederanno quantità variabili di memoria, a seconda della funzione e del ruolo. I server che eseguono componenti di ricerca per indicizzazione ad esempio elaboreranno i dati più rapidamente se dispongono di una quantità elevata di memoria perché per l'elaborazione i documenti vengono letti nella memoria. I server Web che sfruttano molte delle funzionalità di memorizzazione nella cache di SharePoint Server 2013 possono richiedere anche più 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 SharePoint Server 2013 di produzione è consigliabile allocare almeno 8 GB di RAM in ogni server Web, con 16 GB consigliati per i server con traffico maggiore o distribuzioni con più pool di applicazioni configurati per l'isolamento.

Anche i requisiti di memoria dei server applicazioni differiscono; alcune funzionalità di SharePoint Server 2013 hanno requisiti di memoria maggiori nel livello applicazione rispetto ad altri. Nella maggior parte delle distribuzioni di SharePoint Server 2013 di produzione è consigliabile allocare almeno 8 GB di RAM in ogni server applicazioni; I server applicazioni da 16 GB, 32 GB e 64 GB sono comuni quando molti servizi applicazione sono abilitati nello stesso server o quando sono abilitati servizi che dipendono fortemente dalla memoria, ad esempio il servizio di calcolo Excel e il servizio di ricerca di SharePoint Server 2013.

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

Scelta delle reti

Oltre al vantaggio offerto agli utenti, se i client hanno accesso rapido ai dati tramite la rete, una farm distribuita deve avere accesso rapido per la comunicazione tra server. Ciò è particolarmente vero quando si distribuiscono i servizi tra più server o si federatano alcuni servizi ad altre farm. C'è traffico significativo in una farm attraverso il livello server Web, il livello server applicazione e il livello server di database e la rete può facilmente diventare un collo di bottiglia in determinate condizioni, ad esempio gestire file di grandi dimensioni o carichi elevati.

I server Web e i server applicazioni devono essere configurati per l'uso di almeno due schede di interfaccia di rete (NIC): una scheda di interfaccia di rete per gestire il traffico dell'utente finale e l'altra per gestire la comunicazione tra server. La latenza di rete tra server può avere un effetto significativo sulle prestazioni. È quindi importante mantenere meno di 1 millisecondo di latenza di rete tra il server Web e i computer basati su SQL Server che ospitano i database del contenuto. I computer basati su SQL Server che ospitano ogni database dell'applicazione di servizio devono essere il più vicino possibile anche al server applicazioni che utilizza. La rete tra server farm deve avere almeno 1 Gbps di larghezza di banda.

Scelta dei dischi e dello spazio di archiviazione

La gestione del disco non è semplicemente una funzione di fornire spazio sufficiente per i dati. È necessario valutare la domanda e la crescita in corso e assicurarsi che l'architettura di archiviazione non stia rallentando il sistema. È sempre necessario assicurarsi di avere almeno il 30% di capacità aggiuntiva su ogni disco, al di sopra della stima più elevata dei requisiti di dati, per lasciare spazio alla crescita 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 dei 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 altre informazioni su come scegliere i dischi per i server di database, vedere Pianificazione e configurazione della capacità di Archiviazione e SQL Server (SharePoint Server).

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 log.

Passaggio 3: Pilota, Test e Ottimizzazione

La fase di test e ottimizzazione è un componente importante della gestione efficace della capacità. È opportuno 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 target 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 di Office SharePoint Server 2007 e si prevede di apportare modifiche all'architettura o si stima il carico utente delle nuove funzionalità di SharePoint Server 2013, il test è importante per assicurarsi che il nuovo ambiente basato su SharePoint Server 2013 soddisfi gli obiettivi di prestazioni e capacità.

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

Di seguito sono riportati i passaggi secondari per la preproduzione:

Creare l'ambiente di testing in modo da simulare l'architettura iniziale progettata nel passaggio 2 relativo alla progettazione.
Inserire nello spazio di archiviazione il set di dati o parte di esso secondo quanto definito nel passaggio 1 relativo alla modellazione.
Sollecitare il sistema con un carico sintetico che rappresenti il carico di lavoro identificato nel passaggio 1 relativo alla modellazione.
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 i potenziali colli di bottiglia e ottimizzare l'architettura. Riprovare se è necessario.
Effettuare la distribuzione nell'ambiente di produzione.

Test

Il test è un fattore fondamentale per stabilire la capacità della progettazione del sistema di supportare le caratteristiche di utilizzo e carico di lavoro. Per informazioni dettagliate su come testare la distribuzione di SharePoint Server 2013, vedere Test delle prestazioni per SharePoint Server 2013 .

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

Distribuzione dell'ambiente pilota

Prima di distribuire SharePoint Server 2013 in un ambiente di produzione, è importante distribuire prima un ambiente pilota e testare accuratamente la farm per assicurarsi che possa soddisfare gli obiettivi di capacità e prestazioni per il carico massimo previsto. È consigliabile che l'ambiente pilota sia stato prima testato con carico sintetico soprattutto per distribuzioni di grandi dimensioni e quindi sottolineato da un piccolo set di utenti live e contenuti live. L'analisi di un ambiente pilota con un insieme ridotto di utenti attivi offre il vantaggio di poter confermare alcune delle ipotesi fatte sulle caratteristiche di utilizzo e sull'aumento del contenuto prima di passare definitivamente all'ambiente di produzione.

Ottimizzazione

Se non è possibile soddisfare gli obiettivi di capacità e prestazioni ridimensionando l'hardware della farm o apportando modifiche alla topologia, potrebbe essere necessario prendere in considerazione la revisione della soluzione. Se ad esempio i requisiti iniziali erano 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 dedicata 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: distribuzione

Dopo aver eseguito l'ultimo ciclo di test e aver confermato che l'architettura è stata selezionata, è possibile raggiungere gli obiettivi di prestazioni e capacità stabiliti in Passaggio 1: Modello, è possibile distribuire l'ambiente basato su SharePoint Server 2013 nell'ambiente di produzione.

La strategia di implementazione appropriata dipenderà dall'ambiente e dalla situazione. Anche se la distribuzione di SharePoint Server 2013 in genere non rientra nell'ambito di questo documento, esistono alcune attività suggerite che potrebbero uscire dall'esercizio di pianificazione della capacità. Ecco alcuni esempi:

Distribuzione di una nuova farm di SharePoint Server 2013: L'esercizio di pianificazione della capacità deve avere piani guidati e confermati per una progettazione e una distribuzione di SharePoint Server 2016. In questo caso, l'implementazione sarà la prima distribuzione generale di SharePoint Server 2013. Sarà necessario spostare o ricompilare i server e i servizi usati durante gli esercizi di pianificazione della capacità nell'ambiente di produzione. Questo è lo scenario più semplice perché non sono necessari aggiornamenti o modifiche a una farm esistente.
Aggiornamento di una farm di Office SharePoint Server 2007 a SharePoint Server 2013: L'esercizio di pianificazione della capacità dovrebbe avere convalidato la progettazione di una farm in grado di soddisfare le esigenze esistenti e aumentare le prestazioni per soddisfare l'aumento della domanda e dell'utilizzo di una farm di SharePoint Server 2013. Parte dell'esercizio di pianificazione della capacità deve includere migrazioni di test per convalidare il tempo necessario per il processo di aggiornamento, se è necessario modificare o sostituire codice personalizzato, se è necessario aggiornare eventuali strumenti di terze parti e così via. Al termine della pianificazione della capacità è necessario disporre di una progettazione convalidata e della quantità di tempo necessaria per eseguire l'aggiornamento e di un piano per il funzionamento 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, durante la pianificazione della capacità potrebbe essere stato rilevato che saranno necessari hardware aggiuntivi o aggiornati e considerazioni per i 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 eseguito la convalida della piattaforma hardware durante la pianificazione della capacità, è possibile procedere con il processo di aggiornamento a SharePoint Server 2013.
Miglioramento delle prestazioni di una farm di SharePoint Server 2013 esistente: L'esercizio di pianificazione della capacità avrebbe dovuto aiutare a identificare i colli di bottiglia nell'implementazione corrente, pianificare modi per ridurre o eliminare tali colli di bottiglia e convalidare un'implementazione migliorata che soddisfi i requisiti aziendali per i servizi di SharePoint Server 2013. Esistono diversi modi in cui i problemi di prestazioni potrebbero essere stati risolti, da qualcosa di semplice come la ridistribuzione dei servizi nell'hardware esistente, l'aggiornamento dell'hardware esistente o l'aggiunta di più hardware e l'aggiunta di altri servizi. I diversi approcci devono essere testati e convalidati durante l'esercizio di pianificazione della capacità e quindi un piano di distribuzione progettato in base ai risultati di tale test.

Passaggio 5: monitoraggio e manutenzione

Per mantenere le prestazioni del sistema, è necessario monitorare il server per individuare potenziali colli di bottiglia. Prima di 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 target definiti, è possibile modificarla aggiungendo o rimuovendo risorse hardware oppure modificando la topologia o la modalità di archiviazione dei dati.

Vedere Monitoraggio e gestione di SharePoint Server 2013 per un elenco delle impostazioni che è possibile modificare per monitorare l'ambiente nelle fasi iniziali, che consentono di determinare se sono necessarie modifiche. Considerare che l'estensione delle funzionalità di monitoraggio inciderà sullo spazio su disco richiesto dal database del servizio di utilizzo. Una volta che l'ambiente è stabile e questo monitoraggio dettagliato non è più necessario, è possibile invertire le impostazioni seguenti alle impostazioni predefinite.

Per altre informazioni sul monitoraggio dell'integrità e sulla risoluzione dei problemi usando gli strumenti di monitoraggio dell'integrità integrati nell'interfaccia di amministrazione centrale di SharePoint Server 2013, vedere:

Monitoraggio e creazione di report in SharePoint Server 2016

Risoluzione dei problemi