Pianificazione della capacità per SharePoint Server 2013

Articolo
03/21/2018

**Si applica a:**SharePoint Server 2013 Enterprise, SharePoint Server 2013 Standard

**Ultima modifica dell'argomento:**2017-08-25

**Riepilogo:**informazioni su come pianificare e gestire capacità e prestazioni per SharePoint Server 2013.

In questo articolo viene descritto come pianificare la capacità di una farm SharePoint Server 2013. Quando si dispone di una buona apprezzamento e informazioni di pianificazione della capacità e gestione, è possibile applicare la conoscenza di ridimensionamento del sistema. Ridimensionamento è il termine utilizzato per descrivere la selezione e la configurazione dell'architettura di dati appropriato, la topologia logica e fisica e hardware per una piattaforma di soluzioni. Non esiste un intervallo di gestione della capacità e considerazioni sull'utilizzo di che influiscono sulla modalità è necessario determinare le opzioni di configurazione e hardware più appropriato.

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

Importante

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

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

Contenuto dell'articolo:

Passaggio 1: modellazione
Passaggio 2: progettazione
Passaggio 3: implementazione dell'ambiente pilota, esecuzione dei test e ottimizzazione
Passaggio 4: distribuzione
Passaggio 5: monitoraggio e manutenzione

Passaggio 1: modellazione

Modellazione l' SharePoint Server 2013-ambiente basato sul inizia con l'analisi delle soluzioni esistenti e stima le destinazioni per la distribuzione e la domanda prevista si prevede di configurare. La raccolta di informazioni su base di utenti, i requisiti di dati, la latenza e gli obiettivi di velocità effettiva per avviare e documentare le caratteristiche di SharePoint Server 2013 che si desidera distribuire. Utilizzare questa sezione per acquisire familiarità con i dati è consigliabile raccogliere, sulle modalità di raccolta e come è possibile utilizzare nei passaggi successivi.

Comprensione del carico di lavoro e del set di dati previsti

Dimensioni appropriate di un'implementazione SharePoint Server 2013 richiede lo Studio e comprendere la domanda che si prevede di gestire le caratteristiche che è la soluzione. Informazioni che in grado di entrambi i protocolli richiedono le caratteristiche del carico di lavoro, ad esempio numero di utenti e più utilizzati frequentemente operazioni e le caratteristiche di set di dati, ad esempio 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	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 simultaneità delle operazioni eseguite nella server farm consiste nel calcolare il numero di utenti distinti che generano richieste in un determinato intervallo di tempo. Le metriche chiave sono rappresentate dalla media giornaliera e dal numero di utenti simultanei nelle ore di punta.
Richieste al secondo (RPS). RPS (Requests Per Second) è un indicatore comunemente utilizzato per descrivere la domanda per la server farm espressa come 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 specifiche dell'organizzazione. Per ulteriori informazioni su questo termine, vedere la sezione Glossario in Panoramica del dimensionamento e della gestione della capacità per SharePoint Server 2013.
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 misurazione 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 man mano che sempre più utenti adottano la tecnologia.
Distribuzione del carico di lavoro , nonché informazioni la distribuzione delle richieste di base per le applicazioni client che interagiscono con la farm possono aiutare prevedere la tendenza prevista e caricare le modifiche apportate dopo la migrazione a SharePoint Server 2013. Come transizione gli utenti per le versioni più recenti client, ad esempio Office 2013 e avviate utilizzando il carico di nuove funzionalità nuovi modelli, RPS e numero totale di richieste dovrebbe aumentare. Per ogni client è possibile descrivere il numero di utenti univoci utilizzo in un intervallo di tempo di un giorno e la quantità di richieste complessive generati dal client o caratteristica 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 osservare come la maggior parte del carico sia generata dal crawler di ricerca e dalla normale esplorazione del Web da parte dell'utente finale. È inoltre possibile osservare il carico significativo introdotto dalla funzionalità Outlook Social Connector (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. Analizzare innanzitutto le transazioni utilizzate più spesso 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.

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

Capacity - Workload Diagram

Per stimare 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 relativa a servizi e funzionalità nell'articolo Panoramica del dimensionamento e della gestione della capacità per SharePoint Server 2013. Concentrarsi sull'identificazione delle eventuali interazioni specifiche della 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.
Stimare il numero totale di utenti al giorno che si prevede di utilizzare ogni funzionalità, derivare stimati utenti simultanei e high level richieste al secondo, esistono alcuni presupposti si effettuano, ad esempio concorrenza presente e il fattore di richieste al secondo per utenti simultanei differente tra funzionalità, è necessario utilizzare la tabella di carico di lavoro più indietro in questa sezione per le stime. È importante per lo stato attivo sul ore di punta, anziché velocità media effettiva. Pianificazione per l'attività di picco, è possibile ridimensionare corretto il SharePoint Server 2013-soluzione di base.

Se si dispone di una soluzione di Office SharePoint Server 2007 esistente, è possibile ricavare dati dai file di log 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 stime approssimative. Nei passaggi successivi sarà necessario confermare le ipotesi fatte e ottimizzare il sistema.

Analisi dei log IIS in SharePoint Server 2013

Per individuare le metriche chiave su una distribuzione SharePoint Server 2013 esistente, ad esempio il numero di utenti attivi, come fortemente utilizzano il sistema, quali tipi di richieste in arrivo nel e dal tipo di client provengono, è necessario estrarre i dati dai registri ULS e IIS. Uno dei metodi più semplici per acquisire dati consiste nell'utilizzare Log Parser, uno strumento potente disponibile gratuitamente per il download da Microsoft. Log Parser può leggere e scrivere in un numero di formati testuali e binari, inclusi tutti i formati IIS.

Per informazioni dettagliate su come analizzare l'utilizzo di SharePoint Server 2013 tramite Log Parser, leggere l'analisi dei prodotti Microsoft SharePoint e sull'utilizzo di tecnologie (https://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e & informazioni = en & destinazione).

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

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 : informazioni sulle dimensioni del contenuto che si prevede di archiviare nel sistema SharePoint Server 2013 è importante per la pianificazione e architettura di archiviazione del sistema, nonché per dimensioni correttamente la soluzione di ricerca che verrà ricerca per indicizzazione e indice di contenuto. La dimensione del contenuto è descritto in spazio su disco totale. In caso di migrazione del contenuto di una distribuzione esistente potrebbe essere semplice identificare la dimensione totale verrà spostata; in fase di pianificazione è consigliabile lasciare spazio per espansione nel tempo in base ai 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 tra numerosi siti e raccolte siti, risulta più semplice da gestire rispetto a una singola raccolta documenti estesa contenente file molto grandi.
Dimensioni massime delle raccolte siti – è importante individuare l'unità più importante di contenuto che verranno archiviate in SharePoint Server 2013; in genere è un'esigenza dell'organizzazione che ne impediscono la divisione di tale unità del contenuto. Dimensione media di tutte le raccolte siti e il numero totale stimato di raccolte siti sono indicatori aggiuntivi che consentono di identificare l'architettura di dati preferita.
Caratteristiche dei dati applicazioni di servizio – oltre analizzando le esigenze di archiviazione per l'archivio del contenuto, è necessario analizzare e calcolare le dimensioni di altri archivi SharePoint Server 2013, 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 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: modello , è opportuno conoscere le destinazioni di prestazioni e affidabilità che adatta alle esigenze dell'organizzazione. Una soluzione progettata correttamente SharePoint Server 2013 deve essere in grado di raggiungere "quattro nove" (99,99%) del tempo di attività con tempi di risposta server frazioni di 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 il target aziendale definito. I target vengono descritti in genere con un numero di nove, ad esempio 99%, 99,9%, 99,99%.
Velocità di risposta dei server : il tempo necessario per elaborare le richieste della farm è un indicatore efficace per tenere traccia dello stato della farm. Questo indicatore viene in genere denominato latenza sul lato server e viene in genere utilizzare la media o mediana (50 ° percentile) di latenza delle richieste giornaliere servito. Gli obiettivi comunemente descritti in sub secondi o secondi. Si noti che se l'organizzazione dispone di una destinazione per gestire le pagine da SharePoint Server 2013 in meno di due secondi, quindi la verifica del lato server deve essere secondi sub lasciare il tempo per la pagina di raggiungere il client sulla rete e l'ora per il rendering nel browser. Anche in genere tempi di risposta server sono un'indicazione di una farm non integro, come questo genere come un impatto sulla velocità effettiva e raramente può RPS tenersi aggiornati se si lavora per più di un secondo nel server 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% più lento tra tutte le richieste. 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à poco frequente quando gli utenti interagiscono con il sistema. In un sistema integro vengono controllate anche le richieste più lente. Il target 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 disponibili per la gestione delle situazioni di sovraccarico.
Utilizzo delle risorse di sistema. Altri indicatori comuni utilizzati per monitorare l'integrità 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 la percentuale di utilizzo della CPU e la memoria disponibile. Esistono tuttavia molti altri contatori che consentono di individuare un sistema con stato non integro. Per ulteriori informazioni, vedere il Passaggio 5: manutenzione.

Passaggio 2: progettazione

Dopo avere raccolto alcuni fatti o stime per la soluzione da fornire, si è pronti per procedere con il passaggio successivo, ovvero la progettazione di una proposta di architettura che, in base alle proprie previsioni, dovrebbe essere in grado di soddisfare la domanda stimata.

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 scegliere le specifiche hardware per ognuno dei singoli server della progettazione. È 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 + 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 15000 richieste al minuto
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 15000 richieste al minuto

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; si può distribuire un solo server o la scalabilità orizzontale numero di server in una farm SharePoint Server 2013 con server database in cluster o con mirroring e server applicazioni distinte per diversi servizi. Successivamente si selezionerà le configurazioni hardware in base ai requisiti di ciascuno dei ruoli, in base alle esigenze di capacità, la disponibilità e la 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 ulteriori informazioni, vedere la sezione Architetture di riferimento in Panoramica del dimensionamento e della gestione della capacità per SharePoint Server 2013.

Case study tecnici di SharePoint Server 2010

Guida alla gestione della capacità per SharePoint Server 2013 include un numero di case study tecnici di ambienti di produzione esistente che presentano una descrizione dettagliata del esistente SharePoint Server 2013-base gli ambienti di produzione. Case study tecnici specifici di SharePoint Server 2013 verranno pubblicati man mano che diventano disponibili. case study SharePoint Server 2010 esistente può fungere da una Guida di riferimento su come progettare un SharePoint Server 2013-ambiente basato su per scopi specifici.

È possibile utilizzare queste case study come riferimento durante la progettazione dell'architettura delle soluzioni SharePoint Server 2013 soprattutto se la descrizione di queste distribuzione specifiche principali differenze simile le necessità e gli obiettivi della soluzione che architettura.

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

Specifiche, ad esempio componenti hardware, topologia e configurazione della farm
Carico di lavoro, inclusi la base di utenti e le caratteristiche di utilizzo
Set di dati, incluse le dimensioni, le caratteristiche 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 study (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 da prendere in considerazione utilizza macchine virtualizzate. Una farm SharePoint Server 2013 può essere distribuita utilizzando macchine virtuali. Anche se non è stata trovata la virtualizzazione per aggiungere le prestazioni, offre i vantaggi gestibilità. Virtualizzazione di computer basati su SQL Server in genere non è consigliabile, ma potrebbero verificarsi alcuni vantaggi per i server Web e server applicazioni per la virtualizzazione i livelli. Per ulteriori informazioni, vedere pianificazione della virtualizzazione (https://technet.microsoft.com/en-us/library/71c203cd-7534-47b0-9122-657d72ff0080 (14).

Per ulteriori 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 i processori a 64 bit. In genere più processori consentirà di soddisfare proposte maggiore.

In SharePoint Server 2013, server web singoli verrà implementare la scalabilità verticale mentre si aggiungono più core. Più core il server disponga di un carico maggiore in grado di sostenere, tutte le altre posizioni che sia uguale. Nelle distribuzioni di grandi dimensioni SharePoint Server 2013, è consigliabile allocare più server web 4 core (che possono essere virtualizzati) oppure un maggiore minore (8-:/ 16-/ 24 core) server web.

Requisiti di capacità del processore dei server applicazioni si differenziano in base al ruolo del server e i servizi in esecuzione. Alcune caratteristiche SharePoint Server 2013 richiedono la potenza di elaborazione maggiore rispetto ad altri. Ad esempio, il servizio di ricerca di SharePoint dipende altamente la potenza di elaborazione del server applicazioni.

I requisiti di capacità dei processori per SQL Server dipendono inoltre dai database dei servizi ospitati da un computer basato su SQL Server.

Scelta della memoria

I server richiederà diverse quantità di memoria, a seconda della funzione di server e ruoli. Ad esempio, i server che eseguono componenti di ricerca per indicizzazione ricerca dati vengono elaborati più rapidamente se dispongono di una grande quantità di memoria in quanto vengono letti i documenti in memoria per l'elaborazione. Server Web che si avvalgono di molte delle funzionalità di memorizzazione nella cache di SharePoint Server 2013 potrebbe essere necessario anche più memoria.

In generale, requisiti di memoria del server web sono altamente varia a seconda del numero di richieste simultanee servito e il numero di pool di applicazioni attivati nella farm. Nella maggior parte delle distribuzioni SharePoint Server 2013 produzione, è consigliabile allocare almeno 8 GB di RAM in ogni server web, con 16 GB consigliati per i server che hanno un traffico maggiore o configurare le distribuzioni con più pool di applicazioni per l'isolamento.

I requisiti di memoria dei server applicazioni si differenziano inoltre; alcune caratteristiche SharePoint Server 2013 sono i requisiti di memoria maggiore a livello di applicazione rispetto ad altri. Nella maggior parte delle distribuzioni SharePoint Server 2013 produzione è consigliabile allocare almeno 8 GB di RAM in ogni server applicazioni; 16 GB, 32 GB e a 64 GB server applicazione sono comuni quando numerose applicazioni servizi sono attivati nello stesso server o servizi che dipendono in memoria, ad esempio i servizi di calcolo Excel e SharePoint Server 2013 servizio di ricerca sono attivati.

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

Scelta delle reti

Oltre ai vantaggi offerti agli 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 è intenso 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 degli utenti finali 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 basati su SQL Server che ospitano i database del contenuto. I computer SQL Server che ospitano ogni database di 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 di almeno 1 Gbps.

Scelta dei dischi e dello spazio di archiviazione

La gestione dei dischi non ha semplicemente la funzione di fornire spazio adeguato per i dati. È necessario valutare la domanda corrente 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 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 ulteriori 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).

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: implementazione dell'ambiente pilota, esecuzione dei test e ottimizzazione

La fase di test e ottimizzazione è un elemento estremamente importante di gestione efficace della capacità. È consigliabile testare nuove architetture prima di distribuirli a quello di produzione ed è consigliabile condurre accettazione insieme alle procedure consigliate di monitoraggio seguenti per garantire le architetture di di che conformità raggiungere gli obiettivi di prestazioni e capacità. Ciò consente di identificare e ottimizzare possibili colli di bottiglia prima che influiscano sugli utenti in una distribuzione di live. Se esegue l'aggiornamento da un ambiente Office SharePoint Server 2007 e si intende apportare modifiche all'architettura o sono stima utente delle nuove funzionalità SharePoint Server 2013, quindi il test di carico particolarmente importante per assicurarsi che la nuova SharePoint Server 2013-ambiente basato sul grado di soddisfare 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.

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

Creare l'ambiente di testing simulando l'architettura iniziale progettata nel Passaggio 2: 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 potenziali colli di bottiglia e ottimizzare l'architettura. Rieseguire i test, se necessario.
Effettuare la distribuzione nell'ambiente di produzione.

Esecuzione dei test

Il test è un fattore critico per stabilire la possibilità di progettazione del sistema per supportare il carico di lavoro e le caratteristiche di utilizzo. Vedere Esecuzione dei test delle prestazioni di SharePoint Server 2013 per informazioni dettagliate su come testare la distribuzione 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 innanzitutto distribuire un ambiente pilota e personalizzate mirate a testare la farm per verificare che è possibile soddisfare capacità e caricare gli obiettivi di prestazioni per il massimo previsto. È consigliabile che l'ambiente pilota è dapprima eseguito il test con un carico sintetico particolare per distribuzioni di grandi dimensioni e quindi sottolineato per un piccolo gruppo di utenti live e contenuto in diretta. Il vantaggio di analisi di un ambiente pilota utilizzando un piccolo gruppo di utenti live è la possibilità di convalidare alcuni presupposti eseguiti sulle caratteristiche di utilizzo e la crescita contenuta prima di iniziare completamente nell'ambiente di produzione.

Ottimizzazione

Se non è possibile soddisfare i target 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 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 round dei test e verificato che l'architettura è stata selezionata presenta le prestazioni e capacità riguarda è stabilito nella passaggio 1: modello, è possibile distribuire il SharePoint Server 2013-dell'ambiente di produzione basato su.

La strategia di implementazione appropriato varia a seconda dell'ambiente e la situazione. Durante la distribuzione SharePoint Server 2013 in genere è compreso nell'ambito di questo documento, esistono alcuni suggerimenti relativi ad attività che possono entrare da esercizio di pianificazione della capacità. Di seguito sono riportati alcuni esempi:

Distribuzione di una nuova farm SharePoint Server 2013: esercizio di pianificazione della capacità deve avere interattiva e confermato piani per una progettazione e la distribuzione di SharePoint Server 2016. In questo caso, l'implementazione sarà l'ampia distribuzione prima di SharePoint Server 2013. È necessario spostare o ricostruzione server e i servizi utilizzati durante le esercitazioni di pianificazione della capacità nell'ambiente di produzione. Si tratta dello scenario più dirette dal momento che non vi sono tutti gli aggiornamenti o apportare le modifiche necessarie in una farm esistente.
Aggiornamento di una farm Office SharePoint Server 2007 a SharePoint Server 2013: esercizio di pianificazione della capacità deve aver convalidato la progettazione di una farm in grado di soddisfare le richieste esistenti e scala backup per soddisfare un aumento della domanda e l'utilizzo di una farm SharePoint Server 2013. Parte della capacità di pianificazione esercizio deve sono incluse le migrazioni test per convalidare la il processo di aggiornamento durata, se il codice personalizzato deve essere modificato o sostituito, se gli strumenti di terze parti devono essere aggiornate, e così via al termine della pianificazione della capacità che è necessario disporre di una progettazione convalidato e conoscenza di quanto tempo necessario per l'aggiornamento e un piano per la procedura per il funzionamento tramite il processo di aggiornamento, ad esempio, un aggiornamento sul posto o database di migrazione del contenuto in una nuova farm. Se si sta eseguendo un aggiornamento sul posto quindi durante la pianificazione della capacità che potrebbe avere trovato di hardware aggiuntivo o aggiornati sarà necessari e considerazioni per il tempo di inattività. Parte dell'output dal esercizio pianificazione deve essere un elenco delle modifiche apportate hardware necessari e un piano dettagliato per distribuire l'hardware viene modificato prima nella farm. Una volta la piattaforma hardware convalidato durante la pianificazione della capacità, è possibile spostare in avanti il processo di aggiornamento a SharePoint Server 2013.
Miglioramento delle prestazioni di una farm esistente SharePoint Server 2013: esercizio di pianificazione della capacità deve hanno consentito di identificare colli di bottiglia nell'implementazione corrente, pianificare i metodi per ridurre o eliminare i colli di bottiglia e convalidare un'implementazione migliorata che soddisfi i requisiti aziendali per i servizi SharePoint Server 2013. Esistono diversi modi in cui problemi di prestazioni potrebbero siano stati risolti, da un elemento con facilità la redistribuzione servizi tra hardware esistente, aggiornare l'hardware esistente, o aggiungere ulteriori componenti hardware e aggiungere altri servizi. I diversi approcci devono essere test e convalida durante l'esercizio di pianificazione della capacità e quindi un piano di distribuzione progettato in base ai risultati di questo 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.

Per un elenco delle impostazioni che è possibile modificare per monitorare l'ambiente nelle fasi iniziali e per determinare se è necessario apportare eventuali modifiche, vedere Monitoraggio e manutenzione di SharePoint Server 2013. Considerare che l'estensione delle funzionalità di monitoraggio inciderà sullo spazio su disco richiesto dal database del 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 la risoluzione dei problemi tramite gli strumenti di monitoraggio dello stati incorporati nell'interfaccia di amministrazione centrale SharePoint Server 2013, vedere gli articoli seguenti:

Monitoraggio e creazione di report in SharePoint Server 2016

Risoluzione dei problemi e alla risoluzione dei problemi (https://technet.microsoft.com/en-us/library/ee748639 (14)